Downloaded 62 times
![スコープを管理する
インセプションデッキ/エレベーターピッチ
• リーンキャンバスの結果をサマリ
• [プロダクト名] というプロダクトは、
• [潜在的なニーズを満たしたり、
潜在的な課題を解決したり] したい
• [対象顧客] 向けの、
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある理由] ができ、
• [代替手段の最右翼] とは違って、
• [差別化の決定的な特徴] が備わっている。
27参考：アジャイルサムライ−達人開発者への道](https://image.slidesharecdn.com/easg-20181017-01-181017111950/85/2018-10-28-320.jpg)
Uploaded byYusuke Suzuki
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
2018/10/17に開催されたエンタープライズアジャイル勉強会 2018年10月セミナーでの講演「エンタープライズアジャイルでチームが超えるべきこと」の資料です。
More Related Content
Similar to エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
![[G-Tech2014講演資料] 汎用プラクティスとしてのアジャイル開発 - グローバルナレッジ](https://cdn.slidesharecdn.com/ss_thumbnails/c-1-141020210341-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[XP祭り2016][B-5(2)]エンタープライズアジャイルへの挑戦と苦悩（公開版）](https://cdn.slidesharecdn.com/ss_thumbnails/xp2016-160923121717-thumbnail.jpg?width=640&height=640&fit=bounds)
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
- 1.
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 »http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 3. アジェンダ • エンタープライズアジャイル • WFとアジャイルの橋渡し •エンタープライズアジャイルの勘所 »スコープを管理する »リードタイムを管理する »プロセスを共有する • まとめ 2
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. スコープを管理する QCDS • 品質（Quality） • 価格（Cost） • 納期（Delivery ） • 範囲（Scope） »提供される機能の範囲 18
- 20.
- 21.
- 22. スコープを管理する なぜQCDを先に決めるのか？ • チームの固定：効率的だから »繰り返すことが前提のため調達コストが省かれる »人の学習能力と依存 ＞適切な要員の調達 • 日付の固定：リズムが安定するから »次のリリース日があることでスコープ調整がしやすい • ゆるやかに変更することは許容される 21
- 23. スコープを管理する 作業の区切り方が変わる • 要件定義や基本設計をしないわけではない 22 企画 要件 定義 基本 設計 実装 テスト 企画 要件 定義 基本 設計 実装テスト WBS 従来型 （常に全体） アジャイル （概要と部分） 基本 設計 実装 テスト 基本 設計 実装 テスト スプリント0 スプリント1 スプリント2 スプリント3 要件 定義 要件 定義
- 24.
- 25.
- 26. スコープを管理する リーンキャンバス • 誰にとって価値があるサービスなのか？ »この時点で優先順位を明確にしてもらう 25 課題 ※代替品 ｿﾘｭｰｼｮﾝ 独自の 価値提案 圧倒的な 優位性 顧客 ｾｸﾞﾒﾝﾄ 主要指標チャネル コスト構造 収益の流れ ①② ③ ④ ⑤ 誰の どんな課題を どんな機能で どんな特徴が なにで評価する
- 27. スコープを管理する インセプションデッキ 26参考：アジャイルサムライ−達人開発者への道 →目標 →概要 →イメージ →機能の優先順位 →ステークホルダー →概要アーキテクチャ →リスク →マイルストーン →PDCSの優先順位 →コスト • 我われはなぜここにいるのか • エレベーターピッチを作る •パッケージデザインを作る • やらないことリストを作る • 「ご近所さん」を探せ • 解決案を描く • 夜も眠れなくなるような問題は何だろう • 期間を見極める • 何を諦めるのかをはっきりさせる • 何がどれだけ必要なのか
- 28. スコープを管理する インセプションデッキ/エレベーターピッチ • リーンキャンバスの結果をサマリ • [プロダクト名]というプロダクトは、 • [潜在的なニーズを満たしたり、 潜在的な課題を解決したり] したい • [対象顧客] 向けの、 • [プロダクトのカテゴリー] です。 • これは [重要な利点、対価に見合う説得力のある理由] ができ、 • [代替手段の最右翼] とは違って、 • [差別化の決定的な特徴] が備わっている。 27参考：アジャイルサムライ−達人開発者への道
- 29.
- 30.
- 31.
- 32.
- 33. スコープを管理する プロジェクトを立ち上げる • 最初のリリースまで3か月を目標に »スプリント0を1～2か月で駆け抜ける »スプリント3ぐらいでβリリース 32 ﾘｰﾝ ｷｬﾝﾊﾞｽ ｲﾝｾﾌﾟｼｮﾝ ﾃﾞｯｷ ｶｽﾀﾏｰ ｼﾞｬｰﾆｰ ｻｰﾋﾞｽ ﾌﾞﾙｰﾌﾟﾘﾝﾄ ﾕｰｻﾞｰ ｽﾄｰﾘｰ ﾀｽｸ 成果物 ﾕｰｻﾞｰ ｽﾄｰﾘｰ ﾀｽｸ成果物 ﾕｰｻﾞｰ ｽﾄｰﾘｰ ﾀｽｸ 成果物 スプリント0 スプリント1 スプリント2 スプリント3 ｶｽﾀﾏｰ ｼﾞｬｰﾆｰ ｻｰﾋﾞｽ ﾌﾞﾙｰﾌﾟﾘﾝﾄ ｶｽﾀﾏｰ ｼﾞｬｰﾆｰ ｻｰﾋﾞｽ ﾌﾞﾙｰﾌﾟﾘﾝﾄ
- 34. スコープを管理する MVP（Minimum Viable Product/実用最小限の製品） •どうやって部分を積み重ねるかが肝 »残念ながら「こうすればいいです」はない… 33https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
- 35. スコープを管理する 稟議書との戦い • 稟議書の書いた内容/期限/費用を守って欲しい »試行錯誤の結果、工数が足りなくなっても • 全部、大事なんです »優先順位を決められず「要件が決まった機能」から作ってしまう ▸要件がすぐ決まる≒あまり価値がない機能 •全部ないと意味がないんです »全機能そろうまでリリースができない 34
- 36.
- 37.
- 38. リードタイムを管理する 起こりがちな問題 • 開発中に続々と「急ぎの案件」が持ち込まれる »「急ぎ」がバックログに積まれていく • 承認者と合意した後で技術的に実現できないことが分かる »見積り精査できていない機能で承認されている •開発したものの業務や営業調整で変更がはいる »仕様が固まっていないものがバックログに入る 37
- 39. リードタイムを管理する バックログの精度を明確にする • プロダクトバックログには見積り可能なものしかいれない »仕様が不明瞭、技術的に曖昧 »技術的に可能かを確認する、といったバックログはOK • 手前に「候補」を管理する箱を作る »OpportunityBacklogなどと呼称 38 候補 バックログ プロダクト バックログ スプリント バックログ
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48. 利用期間 リードタイムを管理する 本当のリードタイム • 企画してから学びを得るまで »リリース後、顧客からのフィードバックが得られるまでを期間と して見るほうが望ましい »稟議は効果検証まで伴っているのを見ることは少ないが… 47 3か月（企画） 3か月（開発） 3か月（企画）3か月（開発） 3か月（企画） 3か月（開発） 3か月（企画） 3か月（開発）
- 49.
- 50. プロセスを共有する 起こりがちな問題 • たくさんの関係部署から個別に相談が持ち込まれる »POがオーバーワークになって開発に相手ができない • 複数チーム間で技術的な不整合や重複が生まれる »チーム間で互いのやることを知らないというムダ •既存ルールに従わないことが受け入れられない »部署の縦割りによって「今まで通り」以外は対応しない 49
- 51.
- 52. プロセスを共有する VSM（Value Stream Mapping） •製品またはサービスを初期から顧客に提供までの「価値の 流れ」を表現することで課題を洗い出し、改善するための 手法 »特にリードタイム（待ち時間）に注目して無駄を取り除く »元々は製造業におけるリーンマネジメントの手法で、トヨタでは 「材料と情報フローのマッピング」として知られる 51
- 53. プロセスを共有する VSM（Value Stream Mapping） •タスク単位にリードタイムを明確にする »待ち時間：前タスクの完了から、タスクが開始されるまでの時間 »実施時間：タスク自体に必要な時間 »リードタイム＝待ち時間＋実施時間 • 成果物も併記するとよい »特にチームを跨がるところのIN/OUTは明確に • 課題箇所を発見し、改善策を練る »ムリ、ムラ、ムダの排除 52
- 54.
- 55.
- 56.
- 57.
- 58.
- 59. まとめ エンタープライズアジャイルの勘所 • スコープを管理する • リードタイムを管理する •プロセスを共有する 58
- 60. まとめ スコープを管理する • 「S→QCD」から「QCD→S」へ • 全部を相手にせず、部分を積み重ねる »「使い方」に注目して検討を進める ▸リーンキャンバス→ インセプションデッキ → カスタマージャーニー → サービスブループリント → ユーザーストーリー →タスク • 稟議書との戦い »何を実現することが本質 59
- 61.
- 62. まとめ プロセスを共有する • 開発チームが1つだとしても、実質的には複数チーム »エンタープライズアジャイルではたくさんの部署を跨がる • VSMを使って現状を整理し、改善を行う »ムリ、ムラ、ムダの排除 •プロセスを厳密に運用することで組織として効率化を目指 す 61
- 63.
- 64.