デッドラインへ間に合わせろ！！ 絶対に失敗することができない開発を 乗り越えたマネジメントアプローチ

Transcript

1. デッドラインへ間に合わせろ！！ 絶対に失敗することができない開発を 乗り越えたマネジメントアプローチ - プロジェクトマネジメントとアジャイルの調合 -
2. 自己紹介 👤吉野 正義(せいぎ) 🖥エンジニアリングマネージャー 📣スクラムフェス神奈川 🎧Podcast「yoriyoku.fm」
3. 今日お話しすること チームのマネージャーとしてプロジェクトのデリバリーについて責任を持つ立場と なった時、プロジェクトのデッドライン対しどのようなアプローチができるか？ そのために • プロジェクトマネージャー視点で行ったこと • アジャイルコーチ視点で行ったこと について、お話しします
4. 私の立場 : プロジェクトマネージャーとしてプロジェクトにJoin もともとはアジャイルコーチ 社内で立ち上がったプロジェクトの完遂という期待をミッションとして託していただ き、プロジェクトにJoinしました アジャイルコーチに固執せず、プロジェクトマネージャーという帽子を被った
5. どんなプロジェクトだったか？
6. プロジェクト状況 • 1ミリも動かせない厳しいデッドライン (後ろだけでなく前にも) • 未確定かつ途中で変更があり得る膨大な要求 • 20名弱の急造チーム • 重大な障害は絶対に回避
7. プロジェクトの成功を脅かすリスク 絶対に避けたいこと • リリースがデッドラインに間に合わない • 間に合ったけど重大な障害の発生 特に目立つリスクをピックアップすると... • 20名弱の急造チームがワークできない • 要求に対しての不明確さ・不確実性が高いことによる手戻り
8. プロジェクトの成功を脅かすリスク 絶対に避けたいこと • リリースがデッドラインに間に合わない • 間に合ったけど重大な障害の発生 特に目立つリスクをピックアップすると... • 20名弱の急造チームがワークできない • 要求に対しての不明確さ・不確実性が高いことによる手戻り デッドラインを守るため これらのリスクにどう向き合ったかを話します
9. まずはチームがワークできている状態を目指す
10. 最初の難関：チームとしてワークできるようになる 組成されたチームの状況 • メンバーはプロジェクトのために急遽召集された • スタートは6名だったが、1ヶ月で2倍以上のメンバー増員 • 多くのメンバーは同じチームで働いたことがない (ある人もいるが...) 具体のプロセス等の経験はバラバラ ※ただし、開発組織という広域における文化・マインドは揃っている
11. 「チームがワークできている」とは？ 目指してた状態 • ゴールがチームの共通理解となっている • 成果物を継続的に出し続けることができている • 成果物とチームの改善を行えている
12. できるだけ立ち止まりたくない デッドラインのある案件では、成果物を『出し続ける』ことが止まった瞬間に ゴール到達が危ぶまれる 逆に、成果物が出続けていても、改善が止まれば『間違った方向』へ突き進む
13. 幸い、開発組織の文化に”アジャイル”の定着があった 開発組織発足時からアジャイルな開発が意識され、マインドが定着していた 多くのチームは開発手法としてスクラムやアジャイルな手法を採用していた そのため、チームおよびメンバーの主体性に頼ろうとした しかし...
14. チーム主体での対話の限界 スケジュールや優先度の決定について「みんなで決めよう」とチーム内での対話 に一度任せてみたが... スケジュール等の初期案や優先順位の案が定まらず、工数だけが溶けていった
15. チーム内の対話による意思決定が機能不全に落ちいる要因 チームビルディング不足から起きる様々な不都合 • ゴールに対しての揺らぎ • 責任の分散による「決定の回避」 • 情報密度のバラつき • 「良質な妥協」による、尖った解の消失 単純にチームメンバーの仲だけではなく、必要な議論や意思決定を行うための 環境が整っていなかった
16. チーム内の対話による意思決定が機能不全に落ちいる要因 チームビルディング不足から起きる様々な不都合 • ゴールに対しての揺らぎ • 責任の分散による「決定の回避」 • 情報密度のバラつき • 「良質な妥協」による、尖った解の消失 単純にチームメンバーの仲だけではなく、必要な議論や意思決定を行うための 環境が整っていなかった 各メンバーの情報の差、ゴールの理解度、デリゲーションの共有認識 etc…
17. 「プロジェクトマネージャー」としての振る舞いとリーダーシップ ゴールと道筋を見せる • とにかく様々な情報を獲得 • 自分が引いた「暫定スケジュールとゴール」を提示 • 自分が責任を持つことを提示しつつ、開発プロセスに対しての意思決定を リードする • 結果、チームの開発が軌道に乗るまでの硬直を解消 ゆくゆくはチームで情報の取得や意思決定を行えるようにするが、 開発初期における硬直解消と必要な環境の整備を行うために自ら活動
18. 「アジャイルコーチ」としての振る舞いとリーダーシップ プロジェクト全体のファシリテーションを担当 各メンバーにタスクを私から全て割り振るのではなく、自分たちでどのような タスクを拾うのか・どのようなグループに分かれて活動するのか観察 チームが徐々に自己組織化されてきたら、各グループが適切にコミュニケーショ ンを取れるように場の設計等フォロー サーバントな動きで有効なサイロ化の促進を狙った
19. リーダーシップの使い分け プロジェクトマネジメント と アジャイル は対立しない 二つの視点を高速に往復し続けることで、チームが時間の制約がある環境化で 自律的にワークできるようになるための支援につながる プロジェクトマネジメント アジャイル スコープ、予算、納期を守り切る 変化に柔軟に対応し、最高の成果を出す 逆算による長期的なスケジュール 短時間でのサイクルとフィードバック 計画段階で不確実性・リスクを排除 やってみて、失敗から即座に学ぶ
20. デッドラインに向き合う
21. とりあえず作るのではなく、ゴールを見据える 『とりあえず』の積み重ねは、デッドライン直前で必ず牙を剥く 例えば... • リリース直前で品質に関する指摘が入る • 詳細が決まっていない部分を都合の良い解釈で開発し手戻りの発生 結果、間に合わない　もしくは　不具合の発生 につながる
22. デッドラインを守るためには何ができるか？ 不確実性がデッドラインの達成を難しくさせる要因の一つ 要求・要件の不確実性は後々の手戻りリスクが大きくなる
23. イテレーティブ & インクリメンタルをプロセスに組み込む 重要な部分から、成果物の状況をチーム内やステークホルダーと反復的に チェックことで、要求に対してのイメージや体験のズレを減らす 手戻りリスクの低下 ユーザーストーリーごとに機能を作り上げていくことで、開発フェーズとテスト フェーズを並列して進行させる デッドラインに間に合わないリスクの分散
24. そして、品質に対しての要求も明確に求められていた 機能要件を満たせているだけではなく、 「安心・安全なリリースをして欲しい」というオーダー • 不具合・障害を出さない • セキュリティやパフォーマンス面でのインシデントを起こさない など 守るべき品質を把握しアプローチしなければ不具合の見落としなどにつながる 当たり前だけど....
25. 品質についての設計は早い段階で行う 「アジャイルだから、品質も走りながら考えればいい」 は時に危険な場合もある 要求・要件・仕様への変更は早くキャッチできるように、ステークホルダーから 定期的なフィードバックを得ていた しかし、リリースプラン、セキュリティやパフォーマンスなどに対しての変更は 手戻りコストが大きくなりやすく、効果的なフィードバックを得られるタイミン グも後になりがち
26. 完成の定義に品質観点を盛り込む iso25010の品質特性を観点として取り入れた受け入れ基準を設定 各主特性の内、必要な副特性を観点として定め、プロジェクト序盤に一定の 叩き台としての基準を策定 後半における観点の不足や見落としを防ぐことができた IPA独立行政法人 情報処理推進機構 : システム及びソフトウェアの品質測定量とその測定方法
27. リリースプランを最序盤に定める 徐々に適応範囲を広げることで本番での動作や実データの検証を行いつつ、 安全なリリースを実現 1. 社内リリース 2. カナリアリリース1st 3. カナリアリリース2nd 4. 全体リリース デッドラインのある開発では、後半になるにつれ慌ただしくなってくるため最序 盤でスケジューリング等の想定をできておくとステークホルダーとの調整等が圧 倒的にしやすくなる
28. - まとめ - プロジェクトの進行における2つの視点
29. プロジェクトに向き合う時に必要な視点 鳥の目 • プロジェクトマネジメント視点 • プロジェクト全体を俯瞰し、プロジェクトの健康状態を確認し手を打つ 虫の目 • アジャイル視点 • 現場の違和感・問題を検知し、メンバーを巻き込みながら改善していく
30. プロジェクトマネジメント × アジャイルの調合 プロジェクトマネジメントさ • 全体俯瞰 • ゴール設定と達成までのプロセス整備 • フェーズゲートの設定 アジャイルさ • 現場目線 • 一定サイクルでのプロダクトとチームに対しての検査と適応 • チームの効果的な自己組織化を支援
31. プロジェクトマネジメント × アジャイルの調合 プロジェクトマネジメントさ • 全体俯瞰 • ゴール設定と達成までのプロセス整備 • フェーズゲートの設定 アジャイルさ • 現場目線 • 一定サイクルでのプロダクトとチームに対しての検査と適応 • チームの効果的な自己組織化を支援 それぞれのプラクティス・手法を活用し アプローチをしていくことで成功の確度を高める
32. Side B…
33. Side B: プロジェクトマネジメントは、AI駆動のステージへ 【現在の取り組み】 • 人間が集めていた様々な「コンテキスト」をAIに集約 • プロジェクトのリード / 様々な成果物作成をAIに任せる • 仕様の整合性チェックやリスク検知をAIが常時実行 • 人間は レビュー、意思決定、コミュニケーションに全振りする
34. Side B: AI駆動開発によって変わったこと / 守ること 変わったこと • モックとしてレビューできる成果物の作成と破棄のサイクルが早くなった • メンバーの担当職能を越境したワークがしやすくなった 引き続き守ること • 最終的な意思決定・GO判断は人が行う • ステークホルダーとのコミュニケーションは同期的な時間を継続して確保し ている
35. ご清聴ありがとうございました