ハイブリッド型プロジェクト管理｜予測型と適応型の組合せ

ハイブリッド型では、計画を先に固める部分と、成果を見ながら調整する部分を組み合わせます。画面だけをアジャイル、基盤だけをウォーターフォールと固定する方法ではなく、不確かさ、依存関係、統制条件から選びます。

異なる進め方を採用しても、全体の目的、受入条件、提供時期、変更の判断はそろえる必要があります。各チームが順調でも、つなぎ方が決まっていなければ全体のリリースは遅れます。

本文の演習は学習用のオリジナル事例です。解答例の表現は一例で、公式問題の解答・配点ではありません。

1. 適用する部分と境界を決める

適応型でも文書や承認が不要になるわけではありません。必要な統制と変化への対応を両立させ、どの変更をチーム内で決め、どれを全体へ報告するかを合意します。

基盤と画面の間では、API・データ形式・認証・性能条件と提供版を合意します。基盤の提供待ちが画面側の検証を止めないよう、スタブと実接続の確認時期を計画します。

チーム内で完成していても、全体の業務シナリオや移行条件を満たすとは限りません。結合テスト、業務受入、運用準備、データ移行を共通のマイルストーンへ対応付けます。

要求の追加は、バックログの順序だけで吸収できるか、基盤や契約・全体の期限に影響するかを見ます。後者なら全体の変更管理へつなぎ、必要な合意を得て計画を更新します。

条件：基盤を予測型、画面を反復型で開発する。画面チームは毎回APIの応答形式を変えたいと考えている。

問い：全体の手戻りを防ぐため先に合意する事項を述べよ。（40字以内）

解答例：共通APIの仕様・提供版と、変更時の影響評価・承認手順。（28字）

根拠：接続点が変わると複数チームへ影響するため、共同で管理する範囲を明確にします。

確認ポイント：画面側のバックログだけを変えても、基盤側の設計と検証へ通知されません。

条件：画面機能はスプリント内で完成したが、実基盤との連携、業務受入、移行確認は未実施である。

問い：全体リリースを承認する前の確認を述べよ。（40字以内）

解答例：実基盤との連携、業務受入、移行条件が満たされるか確認する。（29字）

根拠：チーム内の完成条件と全体の受入・リリース条件を対応付けて確認します。

確認ポイント：一つのチームの完成だけで、全体の利用開始条件が満たされたとは判断できません。