エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
•
5 recomendaciones•8,516 vistas
2018年7月23日におこなわれた要求開発アライアンス2018年7月定例会での講演「エンタープライズアジャイルにおける要求探索の勘所」の資料です。 https://redajp.connpass.com/event/93398/
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Similar a エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会 (19)
Más de Yusuke Suzuki
Último
Último (10)
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 3. アジェンダ • エンタープライズアジャイル • なぜアジャイルなのか？ • エンタープライズアジャイルの勘所 »スコープを管理する »リードタイムを管理する »プロセスを共有する • まとめ 2
- 7. エンタープライズアジャイル エンタープライズアジャイルあるある • 稟議決裁 »決められた期間に決められた機能を決められたコストで • 既存のルール »すでに完成されたウォーターフォール前提のルール • 部署の縦割り »部署は自分の役割のみしかやらない 6
- 9. なぜアジャイルなのか？ 開発の外側で起きていること • そもそも、なぜウォーターフォール環境下でアジャイルに 取り組まなくてはならないのか？ • ウォーターフォールでは何がダメなのか？ • システム開発の外側では何が起きているのか？ 8
- 11. 開発現場の外側 企業システムの類型 • SoR（System of Record）/mode 1 »情報を正しく「記録」するためのシステム »ユーザーは従業員が中心。取引情報を長期間にわたって保持し、 ビジネスの基幹となるシステム »変更頻度は低め、システム障害影響大 • SoE（System of Engagement）/mode 2 »顧客や取引先との「絆」を作るためにシステム »最新の状況を表示し、判断を行ってもらう。機能はユーザーごと に最適化され、高頻度で改善していく 10
- 13. なぜアジャイルなのか？ ウォーターフォールの進め方 • 最終成果物に向けて、フェーズごとの中間成果物を定め、 段階的に品質を確認する • 中間成果物は基本的に文書 12 基本設計 実装 テスト要件定義 計 画 受 入 文書 文書 文書 文書文書
- 14. なぜアジャイルなのか？ ウォーターフォールの課題 • 途中で「欲しい最終成果物」が変化してしまう »終わるころにはビジネス要件がさらに変化してもらう • 中間成果物では品質が確認できない »文書を見ているだけでは評価できないことがある • 調整が後手後手になりやすい »PMに集まる情報だけでは情勢の見極めが困難 13
- 15. なぜアジャイルなのか？ アジャイルソフトウェア開発宣言（2001年） • プロセスやツールよりも個人と対話を、 • 包括的なドキュメントよりも動くソフトウェアを、 • 契約交渉よりも顧客との協調を、 • 計画に従うことよりも変化への対応を 14参考：http://www.agilemanifesto.org/iso/ja/
- 16. なぜアジャイルなのか？ アジャイルのアプローチ • リソースを定め、短期＆定期的に計画と評価を繰り返す • 評価は関係者全員で動くソフトウエアを確認 15 設計 実装 ﾃｽﾄ計 画 受 入 設計 実装 ﾃｽﾄ計 画 受 入 設計 実装 ﾃｽﾄ計 画 受 入
- 17. なぜアジャイルなのか？ アジャイルのメリット • 「今」欲しいものを得られる »このリリースで何かを得たいか、を決めればいい • 定期的に評価ができる »成果物へのフィードバックを元に改善をしていく • プロセスではなくチーム »現場チーム内で状況が共有できるので判断が行いやすい 16
- 19. なぜアジャイルなのか？ SoEでは、誰も正しい要求が分からない • 正しい要求＝ビジネス成果を生み出す仕様 »成果が出るかどうかは結果論。やってみて調整していくしかない • フィードバックを受けて改善していくことが大事 »アジャイル型で実現しやすいこと • 継続的に要求探索をしていく必要がある 18
- 20. #redajp Scrum 19
- 22. Scrum 主な用語 • 定期的な実行期間：スプリント »計画：スプリントプランニング »計測＆調整：スプリントレビュー • 責任者：プロダクトオーナー »製品価値の最大化に責任を持つ ▸PM（計画の立案と実行に責任を持つ人）はいない ▸計画の立案と実行はチーム全員で責任を持つ • サーバントなリーダー：スクラムマスター 21
- 24. エンタープライズアジャイルの勘所 実践にあたっての勘所 • スコープを管理する • リードタイムを管理する • プロセスを共有する ※多くの現場では、上記の段階を経て成熟していく 23 →POレベル →企画と開発レベル →組織レベル
- 26. スコープを管理する 起こりがちな問題（POレベル） • 稟議書の書いた内容/期限/費用を守って欲しい »試行錯誤の結果、工数が足りなくなっても • 全部、大事なんです »優先順位を決められず「要件が決まった機能」から作ってしまう ▸要件がすぐ決まる≒あまり価値がない機能 • 全部ないと意味がないんです »全機能そろうまでリリースができない 25
- 27. スコープを管理する QCDS • 品質（Quality） • 価格（Cost ） • 納期（Delivery ） • 範囲（Scope） »提供される機能の範囲 26
- 30. スコープを管理する なぜQCDを先に決めるのか？ • チームの固定：効率的だから »繰り返すことが前提のため調達コストを省く »適度な人への依存 • 日付の固定：リズムが安定するから »次のリリースが決まっていることでスコープ調整がしやすい • ゆるやかに変更することは許容される 29
- 31. スコープを管理する MVP（Minimum Viable Product） • 優先度というよりはMVP（実用最小限の製品） 30https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
- 34. スコープを管理する エレベーターピッチ •[プロダクト名] というプロダクトは、 •[潜在的なニーズを満たしたり、 潜在的な課題を解決したり] したい •[対象顧客] 向けの、 •[プロダクトのカテゴリー] です。 •これは [重要な利点、対価に見合う説得力のある理由] ができ、 •[代替手段の最右翼] とは違って、 •[差別化の決定的な特徴] が備わっている。 33参考：アジャイルサムライ−達人開発者への道
- 40. リードタイムを管理する 起こりがちな問題（企画と開発レベル） • 開発中に続々と「急ぎの案件」が持ち込まれる »「急ぎ」がバックログに積まれていく • 承認者と合意した後で技術的に実現できないことが分かる »見積り精査できていない機能で承認されている • 開発したものの業務や営業調整で変更がはいる »仕様が固まっていないものがバックログに入る 39
- 41. リードタイムを管理する バックログの精度を明確にする • プロダクトバックログには見積り可能なものしかいれない »仕様が不明瞭、技術的に曖昧 »技術的に可能かを確認する、といったバックログはOK • 手前に「候補」を管理する箱を作る »Opportunity Backlogなどと呼称 »この箱にいれたまま精査を行う 40 候補 バックログ プロダクト バックログ スプリント バックログ
- 43. リードタイムを管理する リリースサイクルとリードタイムの一致 • リリースは3か月おきにしたいがリードタイムは6か月 »つまり、2チームいないと回らない »もしくは、企画と開発が交互 42 6か月 6か月 6か月 3か月（企画） 3か月（開発） 3か月（企画） 3か月（開発） 3か月（企画） 3か月（開発）
- 50. 利用期間 リードタイムを管理する 本当のリードタイム • 企画してから学びを得るまで »リリース後、顧客からのフィードバックが得られるまでを期間と して見るほうが望ましい »稟議は効果検証まで伴っているのを見ることは少ないが… 49 3か月（企画） 3か月（開発） 3か月（企画） 3か月（開発） 3か月（企画） 3か月（開発） 3か月（企画） 3か月（開発）
- 52. プロセスを共有する 起こりがちな問題（組織レベル） • たくさんの関係部署から個別に相談が持ち込まれる »POがオーバーワークになって開発に相手ができない • 複数チーム間で技術的な不整合や重複が生まれる »チーム間で互いのやることを知らないというムダ • 既存ルールに従わないことが受け入れられない »部署の縦割りによって「今まで通り」以外は対応しない 51
- 54. プロセスを共有する VSM（Value Stream Mapping） • 製品またはサービスを初期から顧客に提供までの「価値の 流れ」を表現することで課題を洗い出し、改善するための 手法 »特にリードタイム（待ち時間）に注目して無駄を取り除く »元々は製造業におけるリーンマネジメントの手法で、トヨタでは 「材料と情報フローのマッピング」として知られる 53
- 55. プロセスを共有する VSM（Value Stream Mapping） • タスク単位にリードタイムを明確にする »待ち時間：前タスクの完了から、タスクが開始されるまでの時間 »実施時間：タスク自体に必要な時間 »リードタイム＝待ち時間＋実施時間 • 成果物も併記するとよい »特にチームを跨がるところのIN/OUTは明確に • 課題箇所を発見し、改善策を練る »ムリ、ムラ、ムダの排除 54
- 59. #redajp まとめ 58
- 60. まとめ エンタープライズアジャイルとは • すでに完成されているウォータオーフォール型開発プロセ スがある上でのアジャイル導入 • 稟議決裁 • 既存のルール • 部署の縦割り 59
- 62. まとめ エンタープライズアジャイルの勘所 • スコープを管理する • リードタイムを管理する • プロセスを共有する 61
- 63. まとめ スコープを管理する • 「S→QCD」から「QCD→S」へ • 優先順位というよりもMVPをどうするのか？ »何を提供するとMVPになるのか »製品コンセプトから機能までのツリーを明確にする ▸エレベーターピッチ → カスタマージャーニー → ユーザーストーリー • 稟議書との戦い »何を実現することが本質 62
- 65. まとめ プロセスを共有する • 開発チームが1つだとしても、実質的には複数チーム »エンタープライズアジャイルではたくさんの部署を跨がる • VSMを使って現状を整理し、改善を行う »ムリ、ムラ、ムダの排除 • プロセスを厳密に運用することで組織として効率化を目指 す 64