The path to More Effective Agile

5.4K Views

September 15, 21

スライド概要

「More Effective Agile」になるためのみちしるべ的な内容です。

profile-image

サーバントワークス株式会社 代表取締役/アジャイルストラテジスト/アジャイルコーチ/エバンジェリスト DASA Ambassador DASA DevOps 認定トレーナー 株式会社Helpfeel アドバイザー 講演や支援のご相談はぜひお気軽に(ご相談は無料です)! PSPO II, PSM II, SPS, PAL-EBM, PAL I, PSU I, PSK I, PSD I, PSPO I, PSM I, CSM

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

v2021.09 長沢 智治 @tnagasawa © 2021 Servant Works Inc.

2.

長沢 智治 • サーバントワークス株式会社 代表取締役 • Nota株式会社 アドバイザー • DASA (DevOps Agile Skills Association) Ambassador • 略歴: INTEC ▷ Rational Software ▷ IBM ▷ Borland ▷ Microsoft ▷ Atlassian • エンジニア、業務改善コンサルタント、エバンジェリスト • ソフトウェア開発現場および、ビジネス企画の業務改善コンサルタント/コーチ • ビジネス戦略および、マーケティング戦略のアドバイザー • 講演・執筆・翻訳・監訳

3.

監訳書籍 • 理想のアジャイルでなく、 現実のアジャイル • リーダー層向けに書かれた数少ない書籍 • 参照文献多数

4.

本日のテーマ • アジャイルが必要な領域 • アジャイルの特長と戦略 • スクラムフレームワーク • スクラム導入のエッセンス • アジャイルのスケーリング

5.

アジェンダ

6.

正解のない時代

7.

問われる変化速度 外部の変化速度が、組織内の変化速度を上回っているのであれば、 その組織の終わりは近い。 GE 元CEO ジャック・ウェルチ

8.

ビジネスと IT の関係の変化 2000s 1990s IT 便利 IT 有効 IT はコストセンター ビジネス 2010s IT 不可欠 2020s IT コア IT はビジネス戦略 • 既存のビジネスモデル • 新しいビジネスモデル • 自社内で意思決定 • 市場が意思決定 • 守るプロダクト • 攻めるプロダクト servantworks.co.jp/resources/business-with-it/ IT © Tomoharu Nagasawa

9.

複雑さを受け入れる指針 既知の既知 明白 JUST DO IT 不確実 既知の未知 計画駆動 未知の未知 複雑 WHAT 煩雑 経験駆動 不可知の未知 混沌 行動あるのみ 確実 HOW 不確実 Stacy Matrix

10.

問題領域の変化 ビジネス 2000s 1990s IT 便利 IT 有効 IT はコストセンター 明白 servantworks.co.jp/resources/business-with-it/ 2010s IT 不可欠 IT 2020s IT コア IT はビジネス戦略 煩雑 複雑 © Tomoharu Nagasawa

11.

正解のない時代 V U 体験と価値 C A 変動性 不確実性 複雑性 曖昧性 Volatility Uncertainty Complexity Ambiguity 正解のない時代 直接タッチ ビジネス 2010s IT 不可欠 競争激化 IT 2020s IT コア IT はビジネス戦略 • 新しいビジネスモデル デバイス AI クラウド IoT • 市場が意思決定 • 攻めるプロダクト © Tomoharu Nagasawa

12.

クネビンフレームワーク 複雑 煩雑 complex complicated 未知の未知 既知の未知 無秩序 disorder 混沌 明白 chaotic obvious 不可知の未知 既知の既知 Cynefin Framework

13.

ユーザーの期待値(今まで) 過程を重視 自ら問題を分析して、経験しながら、 解決策を模索する 複雑 煩雑 complex complicated 未知の未知 既知の未知 無秩序 専門家やツールを 活用しながら、 自らの問題と向き合う 改善の積み重ね disorder 崩れる みんなで集まって なんとかする 混沌 明白 chaotic obvious 不可知の未知 既知の既知 自ら問題を解決する Cynefin Framework

14.

ユーザーの期待値(現在) 成果を重視 複雑 煩雑 complex complicated 未知の未知 既知の未知 無秩序 改善の積み重ね disorder 崩れる 混沌 明白 chaotic obvious 不可知の未知 既知の既知 体験 • 解決策を提示して ほしい • やりたいことに 集中したい Cynefin Framework

15.

経験駆動アプローチの必然 ジャストインタイムな移行 探索 経験駆動 複雑 煩雑 complex complicated 体験を創造 未知の未知 既知の未知 計画駆動 改善の積み重ね 無秩序 disorder 崩れる 混沌 明白 chaotic obvious 不可知の未知 既知の既知 Cynefin Framework

16.

従来の考え方 正解主義 予測主義 自前主義 分業主義 従来の前提 計画主義 定義済みプロセス • • • 経験済み 安定している 調達可能になりつつある

17.

従来の考え方からの脱却(体験創造の考え方) 仮説 経験 主義 主義 共創 主義 専業 主義 これからの前提 経験主義(実証主義) 経験的プロセス制御 • • • 経験したことがない 試行することで見出す 価値の変化に適応

18.

プロセスモデルの特徴 定義済みのプロセスモデル 経験的プロセス制御 ゴールが明確で変動しない ゴールが不確かで変動する 統制型マネジメント 自律型マネジメント 全体的な絶対値による見積もり 逐次的な相対的な見積もり 権限の一本化による統率 権限の委譲による規律 約束で期待値を管理 成果で期待値を管理 形式知を重視 集合知を重視

19.

アジャイル

20.

アジャイル適用事例 • 新番組の企画開発(NPR) • 新しい機械の開発(ジョンディア) • 新しい戦闘機の生産(サーブ) • マーケティング(イントロニス) • 人事(C.H.ロビンソン) • ワインの生産、倉庫管理、上級幹部の運営(ミッションベル) • 全社的な変身(GE) 出典:『臨機応変のマネジメントで生産性を劇的に高めるアジャイル開発を経営に活かす6つの原則』(Embracing Agile, ダイアモンドハーバードビジネスレビュー, 2016)

21.

アジャイルソフトウェア開発宣言

22.

アジャイル相互依存宣言 servantworks.co.jp/2019/agile-project-management-manifesto-japanese/ • 継続的な価値の流れによる投資対効果 • 顧客との信頼関係と確かな成果 • 透明性による不確実性の予測 • 個人のチカラを発揮する環境 • 責務を共有するチーム • 状況に応じた戦略と改善 ©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.

23.

アジャイルの特徴 中間成果物 output < • できるだけ頻繁に • できるだけ持続可能に • できるだけムリ、ムラ、ムダなく • 目的・自律・熟達できる『チーム』 成果(価値) outcome

24.

アジャイルでの計画と戦略

25.

鉄の三角形 範囲 Scope 品質 Quality 費用 期日 Cost Delivery

26.

従来のアプローチ 範囲 Scope 品質 Quality 費用 期日 Cost Delivery

27.

従来のアプローチ C 費用 = 人月 D 期日 = 納期 S 範囲 = 要件

28.

従来のアプローチ 定義した価値 定義した価値 計画した作業量 約束した期日 期日までの時間

29.

アジャイルのアプローチ(右) <全体計画> <価値を計画> 範囲 費用 期日 Scope Cost Delivery 品質 Quality 品質 Quality 費用 期日 範囲 Cost Delivery Scope 従来の考え方 アジャイルの考え方

30.

Ready でない 価値は先送り C 費用 = チーム固定 Ready な価値 アジャイルのアプローチ D 期日 = 反復 (タイムボックス) #1 #2 #3 #4 #5 S 範囲 = 価値

31.

アジャイルのアプローチ 従来 アジャイル 価値が上がったか 常に調整する 時間固定(タイムボックス)で成果を出す アジャイルの考え方

32.

アジャイルでの計画と予測可能性の戦略(概略) スプリント #3 #2 #1 #4 タイムボックス ポイント ベロシティ 予測値 7 7 6 6 5 4 5 6 6 6 5 3 2 1 #1 #2 #3 #4 6 実績値

33.

アプローチの比較 タスク指向 定義した価値 価値指向(Value up) 価値が上がったか 常に調整する 計画した作業量 時間固定(タイムボックス)で成果を出す 期日までの時間 従来の考え方 アジャイルの考え方

34.

不確実性コーンにみる見積もりの難しさ 確実な見積もりや予測はどのアプローチでも不可能に近い x4 x1.25 x0.8 x0.25

35.

不確実性コーン下での現実的な戦術 従来 アジャイル 確実な見積もりや予測はどのアプローチでも不可能に近い 提供できる価値を調整する x0.25 x4 提供する時間を調整する 時間固定(タイムボックス)で成果を出す

36.

費用対効果を最大化する 従来 アジャイル 回収 投資

37.

機会損失を減らす(体験を頻繁に提供し制御) 映画 ドラマ 数年単位のサイクル 3ヶ月単位のサイクル 公開 or 中止 1週間単位の見直し 莫大な予算と準備期間 継続可能な予算と準備期間

38.

スクラムフレームワーク

39.

スクラムはフレームワーク • 複雑な問題を解決するフレームワーク • プロセスでも、プラクティスでもない • フレームワークは従う・乗るもの • 一部だけを導入することは可能だが、スクラムではない(ScrumBut) • 技法・方法論・プラクティスの入れ物として機能する(ScrumAnd) 完璧とは、付け加えるものがなくなったときではなく、 削るものがなくなったときのことである。 アントワーヌ・ド・サン=テグジュペリ

40.

スクラムガイド • スクラムの公式のガイドでありルール • 10数ページ • 2009年に初公開され、随時改訂されている • 2009, 2010, 2011, 2013, 2016, 2017, 2020 (最新) • https://www.scrumguides.org/ で各国語版を入手できる(含む、日本語訳)

41.

スクラムの基本 プロダクトバックログ スクラムチーム プロダクト インクリメント スプリントバックログ ステークホルダー 完成の定義 プロダクトゴール スプリントゴール スプリント プランニング デイリー スクラム スプリント レビュー スプリント スプリント レトロスペク ティブ © Tomoharu Nagasawa, Servant Works Inc.

42.

スクラム • 経験主義とリーン思考 • 観察による意思決定 引用「スクラム: リスクを軽減し早期に価値を提供するフレームワーク」(翻訳: 長沢智治)

43.

スクラム 引用「スクラム: リスクを軽減し早期に価値を提供するフレームワーク」(翻訳: 長沢智治)

44.

スクラム 〜 1枚の絵で表現できるフレームワーク

45.

スクラム 〜 1枚の絵で表現できるフレームワーク 引用「スクラム: リスクを軽減し早期に価値を提供するフレームワーク」(翻訳: 長沢智治)

46.

スクラム 〜 1枚の絵で表現できるフレームワーク プロダクトゴール ステーク ホルダー スプリントゴール スプリント スクラムチーム プロダクト バックログ 改善 1ヶ月 スプリントレトロスペクティブ スクラムチーム あれば 3時間 完成の定義 スプリント バックログ スプリントバックログ インクリメント プロダクトオーナー 開発者 開発者 スプリントプランニング プロダクトバックログ リファインメント スクラムチーム デイリースクラム スクラムチーム ステーク ホルダー 15分 スプリントレビュー 8時間 スクラムチーム 適時 4時間 フィードバック 透明性 適応 検査 経験主義の柱 servantworks.co.jp/resources/scrum̲overview̲figures/ 集中 focus 尊敬 respect 公開 openness 勇気 courage スクラムの価値基準 確約 プロダクト 開発者 スクラム オーナー マスター commitment スクラムチーム © Tomoharu Nagasawa, Servant Works Inc.

47.

スクラム 〜 1枚の絵で表現できるフレームワーク 開発者 各スプリントでの利用可能なインクリメントの あらゆる側面の作成を確約する。 ・スプリントバックログの管理 ・完成の定義の遵守による品質 価値 ・スプリントゴールに向けた計画の適応(毎日) プロダクトゴール 完成の定義 を満たす プロダクト バックログ スプリントゴール インクリメント スプリント バックログ プロダクトオーナー 時間 スクラムチームの作業による プロダクト価値を最大化する ために、効果的なプロダクト バックログの管理に責任を持つ servantworks.co.jp/resources/scrum̲overview̲figures/ スクラムマスター スクラムが確立されることの結果 責任を持つ。 スクラムチームがスクラム フレームワーク内で改善できる スプリント(期間固定: タイムボックス) ようになるよう責任を果たす。 例: 全スクラムイベントの開催、 タイムボックスの遵守 © Tomoharu Nagasawa, Servant Works Inc.

48.

スクラを支える経験主義の柱とチームワーク チーム 〜 同じ景色をみている 〜 透明性 適応 検査 • 目的・価値観 • やり方を共有 • フォローして達成

49.

経験主義に基づくフレームワークの例 戦略と計測 問題への対応 起業 LEARN EBM エビデンスベースド マネジメント BUILD MEASURE スクラム リーン スタートアップ

50.

参考)エビデンスベースドマネジメント(EBM) 指標 仮説 戦略的ゴール 実験と計測 実現できる 可能性のある 付加価値とは? 実験ループ 中間ゴール 適応 検査 現在の状態 即時戦術ゴール 未実現の価値 UV 現在の価値 CV 時間 現在、組織が どのような価値を 提供しているのか? アジリティ ビジネス価値 組織は価値の 改善にどれくらい 効果があるのか? イノベーション の能力 A2I 市場に出す までの時間 © 2020 Scrum.org. All Rights Reserved. 組織的な能力 開始の状態 引用「エビデンスベースドマネジメントガイド」(翻訳: 長沢智治、角征典) 市場価値 T2M 新しい価値提供に どれくらいの時間が かかるのか?

51.

複雑な問題への対応の進め方 ■よくある進め方: 複雑な問題 チーム アジャイル (スクラム) ■あるべき進め方: アジャイル (スクラム) チーム 複雑な問題 ©Tomoharu Nagasawa, Servant Works Inc.

52.

問題へのよくある進め方の問題点 ■よくある進め方: 複雑な問題 チーム アジャイル (スクラム) 問題点: • 初動が遅れる • チームが立ち上がらない • 「複雑 複雑」(問題とスクラム実践)で問題を分解できない

53.

問題へのあるべき進め方の恩恵 恩恵: • アジャイル(複雑な問題への対応方法)を事前に習得 • チームの立ち上がりが早い • 問題の複雑さに純粋に取り組める ■あるべき進め方: アジャイル (スクラム) チーム 複雑な問題

54.

取り組みを組織に根付かせるには 組織 チーム 組織 チーム 組織 チーム 個人 個人 個人 成長しない 成果がでない 発展しない ©Tomoharu Nagasawa, Servant Works Inc.

55.

アジャイルのスケーリング

56.

アジリティの象徴としてのクモ

57.

アジリティの象徴としてのクモ 問題. クモがゾウのような大きさに「進化」を遂げたら それは何に近づいているでしょうか? A. クモ B. ゾウ C. スパイダーマン

58.

アジリティの象徴としてのクモ?

59.

大規模なのは何か? • ステークホルダーの数や規模 • 開発者の人数や規模 • 多重構造 • プロダクトの規模や複雑さ • 組織構造 • 抱えている人的リソース(の効率化) • 導入したいフレームワークが大規模 • その他

60.

価値(成果)に直結するのか? • 既存の状況ではなく、あるべき姿で検討 • アジャイルとそうでないものとの境界 • スケーリングで価値が向上するか検討 スケーリングの第1の原則: スケーリングしないこと

61.

価値(成果)に直結するスケーリングの鉄則① コンウェイの法則 システムの構造にはそのシステムを構築した組織構造が反映される ブルックスの法則 遅れているプロジェクトに人員を追加しても、さらに遅れるだけだ 例外: 作業を完全に分離できるのであれば必ずしも当てはまらない 段階的アプローチを取る必要がある Crawl, Walk, Run

62.

価値(成果)に直結するスケーリングの鉄則② プロダクトバックログ プロダクトゴール スクラムチーム プロダクト インクリメント スプリントバックログ ステークホルダー 完成の定義 スプリントゴール スプリント プランニング デイリー スクラム スプリント レビュー スプリント スプリント レトロスペク ティブ © Tomoharu Nagasawa, Servant Works Inc. スクラムからはじめる

63.

価値(成果)に直結するスケーリングの鉄則③ スクラムチーム プロダクト インクリメント プロダクトバックログ スプリントバックログ 完成の定義 統合プロダクト インクリメント スプリントゴール プロダクトゴール スクラムチーム スプリントバックログ プロダクト インクリメント ステークホルダー 完成の定義 完成の定義 スプリントゴール 常に価値を向上させる(統合する)

64.

スクラムの生みの親が作った Nexus

65.

まとめ

66.

まとめ • アジャイルが活用できるシーン:「複雑な領域」 • アジャイル:価値駆動、経験的プロセス制御、チーム • スクラム: 複雑さに対応するフレームワーク • EBM: 複雑さに対応する意思決定とメトリクスのフレームワーク • Nexus: 大規模チームでのスクラム実装フレームワーク

67.

お話していないこと • スクラムの詳細 • アジャイルリーダーシップと環境づくり • エビデンスベースドマネジメントの詳細 • Nexus の詳細 ご要望をお待ちしております

68.

情報リソース スクラムガイド スクラムホワイトペーパー scrumguides.org scrum.org/resources/scrum-framework-reducerisk-and-deliver-value-sooner

69.

情報リソース スクラムの価値基準 スクラム用語集 thescrumvalues.org scrumglossary.org

70.

情報リソース エビデンスベースド マネジメントガイド scrum.org/ebm Nexus ガイド scrum.org/nexus

71.

情報リソース servantworks.co.jp/works/translated/ scrum.org/nexus

72.

提供 アジリティに関する導入・定着化支援サービス、研修サービスを提供いたします contact@servantworks.co.jp ご清聴くださり、誠にありがとうございました

73.

のご支援サービスの特徴 STEP STEP 3 1 対処・学習・改善 STEP キックオフ 把握・調査・行動 サイクル #1 サイクル #2 1週間 1週間 サイクル #m 2週間 2 分類・分析・把握 サイクル #n 4週間