ハイブリッドプロジェクトマネジメント: Agile と Waterfall の組み合わせ方

著者: Tara Minh · 更新日: 2026年10月10日

ハイブリッドプロジェクトマネジメントは、Waterfall の計画主導のプラクティスと Agile の反復的なデリバリーを、1つのプロジェクトの中で組み合わせる手法です。多くの場合、スコープの境界、予算、コンプライアンス上のゲートを事前に固定し、その後は短いサイクルで開発を進めて、学びながら詳細を調整します。

重要な事実

• 「ウォーター・スクラム・フォール」という呼び名は、アナリスト Dave West による2011年7月の Forrester のレポートに由来し、多くの組織が実際に Agile をどう実践しているかを表すために使われました（Forrester）。
• PMI の2024年版 Pulse of the Profession（第15版）によれば、ハイブリッドアプローチの利用は2020年の20%から2023年には31%に増加しました（MPUG の要約）。
• Forrester の中心的な警告は次のとおりです。このモデルは自動的に悪いわけではありませんが、境界線をどこに引くかを意図して決めないチームは、Agile の恩恵を得られる可能性が低くなります（Forrester）。
• ハイブリッドが最も機能するのは、各フェーズについて、事前に計画するのか、進めながら見つけていくのかを言い切れる場合です。

ハイブリッドプロジェクトマネジメントとは

ハイブリッドプロジェクトマネジメントとは、安定した部分の仕事には予測型（Waterfall 型）の手法を、そうでない部分には Agile の手法を、意図して使い分けるプロジェクトの進め方です。全員が少しずつ何でもやるような妥協ではありません。確実性がある場所とない場所を見極めて、フェーズごと、またはワークストリームごとに下す意思決定です。

PMI の PMBOK Guide 第7版は、予測型、Agile、ハイブリッドのいずれのデリバリーアプローチであっても原則を適用し、テーラリングを中心に据えています（PMBOK Guide の概要を参照）。実際には、最初にブランド名で手法を選ぶのではなく、まず仕事を見て、それに合うアプローチを選ぶということです。

典型的な例を挙げます。新しい顧客ポータルを構築する企業には、決まったローンチ日、承認済みの予算、省略できないセキュリティレビューがあります。しかし、顧客が実際にどの機能を使うかは誰にも分かりません。そこで経営陣はスコープと予算を事前に承認し（予測型）、チームは2週間のスプリントでポータルを構築し（Agile）、セキュリティレビューと本番稼働は正式なチェックリストに従って進めます（再び予測型）。

まず純粋な形から知りたい場合は、Agile と Waterfall の比較、Waterfall 手法、そして Agile 手法とは何かから始めてください。

考え方の由来: ウォーター・スクラム・フォール

Forrester の Dave West は2011年に、このパターンに名前を付けました。彼のレポート「Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today」は、実際の Agile 導入が Agile Manifesto の理念から離れてしまっていると論じました。チームはプロジェクトの中盤で Scrum を実践する一方、開始時の要件収集と最後のリリース管理は従来のままでした（Forrester）。

この名前が定着したのは、的確だからです。Water は事前の計画と要件定義、Scrum は反復的な構築、Fall は正式なテスト、承認、リリースを指します。

West はこれを失敗とは呼びませんでした。彼の主張は、このモデルには2つの境界、つまり Water から Scrum へ、そして Scrum から Fall への移行を意図して管理する必要がある、というものです。各スプリントのフィードバックが、Water フェーズで固定された要件を変えられないなら、スプリントは元の計画を小分けにして納品しているだけです。また、スプリントの成果が四半期ごとのリリースを待って滞留するなら、中盤で得たスピードは最後に失われます。

これは今でも、健全なハイブリッドを見分ける最良のテストです。それぞれの境界で何が起きるかを問いかけてください。

よくあるハイブリッドモデル

ハイブリッドは1種類ではありません。最もよく見られるパターンを紹介します。

ハイブリッドとその他のアプローチの比較

ハイブリッドを、純粋な手法や名前のついたフレームワークと比べると、それぞれがどこでトレードオフを取っているかが分かります。

独自のブレンドを作るのではなく、ライフサイクルを選ぶための体系的なツールキットがほしい場合は、Disciplined Agileを一度見てみる価値があります。

ハイブリッドが適切な選択になるとき

プロジェクトに固定的な要素と流動的な要素の両方があり、1つの手法に押し込むと固定側か流動側のどちらかが損なわれる場合に、ハイブリッドを使います。

• 不確実性を伴うコンプライアンス対応。 銀行は決まった日に監査に通らなければなりませんが、顧客向けの画面は進化していきます。監査証跡と承認手順は固定し、画面は反復して作ります。
• ハードウェアとソフトウェアの組み合わせ。 機器メーカーは射出成形の金型を毎週反復することはできませんが、連携アプリはスプリントごとにリリースできます。
• 予算サイクルのある大規模プログラム。 財務部門が年間予算を承認しても、デリバリーチームは毎月優先順位を見直す必要があります。
• Waterfall から Agile へ移行するチーム。 多くの組織は、ガバナンス、契約、ツールを一度にすべて変えることはできません。最終的な状態が、なし崩しの結果ではなく意思決定によるものであるかぎり、ハイブリッドは正当な足がかりです。
• リズムの異なるベンダーとクライアント。 クライアントが成果物を月次でレビューし、チームが隔週でスプリントを回すなら、ハイブリッドなケイデンスが双方を誠実に保ちます。

PMI は、ハイブリッドの利用が2020年から2023年にかけて20%から31%に増えたと報告しており、もはや珍しい選択ではありません。

プロジェクトが小規模でスコープが安定しており、誰もゲートを求めていないなら、純粋な Waterfall か純粋な Agile を選びましょう。ハイブリッドは調整コストを増やすため、それで得られるものが必要なときにだけそのコストを払うべきです。

ハイブリッドプロジェクトの立ち上げ方（ステップ別）

ステップ1: 固定された制約を洗い出す

動かせないものをすべて書き出します。ローンチ日、予算の上限、規制上のチェックポイント、契約上の成果物、固定のベンダーリードタイムなどです。これらが予測型の拠り所になります。

ステップ2: 未知の要素を洗い出す

次に、現時点では正直に把握できないものを挙げます。ユーザーの好み、技術的な実現可能性、ベンダーの実績、正確な機能セットなどです。プレモーテムは、チームが放置しがちな未知の要素を素早く表に出す方法であり、不確実性のコーンは、プロジェクト初期の見積もりが本来的に幅広くなることを思い出させてくれます。

ステップ3: 仕事を予測型と適応型に分ける

作業分解構成図を見ながら、各フェーズやワークストリームを、予測型、適応型、混合型のいずれかに分類します。目安は次のとおりです。受け入れ基準を今日書けて、それが変わらないと見込めるなら予測型です。基準がまだ集めていないフィードバックに左右されるなら適応型です。

ステップ4: 境界を定義する

多くのチームが飛ばすのがこのステップで、Forrester の警告が当てはまるのもここです。予測型の部分と適応型の部分の間の引き継ぎごとに、次を書き出します。

• 適応型のチームが受け取るもの（200ページの仕様書ではなく、目標と制約）。
• 変更が許される範囲と、より大きな変更を誰が承認するか。
• 予測型のプロセスに返すもの（デモ、ビルド、テストレポート）。
• リリースプロセスがその成果をどれだけ速く受け入れられるか。

ステップ5: ケイデンスとセレモニーを選ぶ

適応型の仕事にはスプリントまたはフローのケイデンスを、予測型の仕事にはゲートまたはレビューのスケジュールを設定します。可能なかぎり両者を揃えてください。ゲートレビューが月次なら、1回おきのスプリントレビューをゲート準備状況の確認にします。タイムボックスを使って、イテレーションの作業がゲートのカレンダーいっぱいに引き延ばされないようにします。

ステップ6: ローリングウェーブで計画する

近い将来は詳細に、遠い将来は粗いままにします。ローリングウェーブ計画は自然に適合します。コミットしたロードマップはマイルストーンのレベルにとどめ、次の1〜2イテレーションを詳細に計画します。

ステップ7: 共通の指標を1セット決める

予測型の仕事は通常、スケジュールとコストの差異を報告します。適応型の仕事は、ベロシティまたはスループットとバーンダウンを報告します。エグゼクティブが翻訳なしで読める少数の共通指標を選びましょう。たとえば、達成したマイルストーン、計画に対する納品済みスコープ、未解決のリスクです。

ステップ8: ブレンドを見直して調整する

各ゲートで、この分割がまだ適しているかを問いかけます。予測型だと思っていたフェーズが変わり続けているかもしれませんし、適応型の領域が安定したかもしれません。そうなれば境界線を動かします。ハイブリッドは固定するものではなく、調整するものです。

ハイブリッドプロジェクト計画テンプレート

これをドキュメントやスプレッドシートにコピーして、プロジェクトごとに記入してください。フェーズまたはワークストリームごとに1行です。

その下に、境界のセクションを追加します。

ビジネス機能別のハイブリッド事例

ソフトウェアと IT。 課金システムを刷新する企業は、切り替え日とデータ移行計画を固定し（予測型）、チームは新しい請求ワークフローをスプリントで構築して、2週間ごとに経理のユーザーとテストします。

マーケティング。 製品ローンチには、決まった日付、承認済みの予算、主張内容の法務レビューがあります。コンテンツ、広告クリエイティブ、ランディングページは週次のスプリントで進めます。法務の承認とメディア購入は、ゲートを設けた手順で進めます。

オペレーションと施設。 新しい倉庫の開設には、許認可のスケジュール、設備の納入、内装工事を順番に進める必要があります。その内部の在庫管理とスキャンのワークフローは、反復的に整備し、1つの通路で試してから拡大します。

人事。 新しい人事評価プロセスの展開は、評価サイクルや制度承認に連動したカレンダーに従います。フォーム、マネージャー向けの研修、コミュニケーションは、パイロットグループを通じて改良していきます。

プロダクト開発。 製造業者は、ステージゲートで資金を解放します。ゲートの間は、エンジニアがプロトタイプを反復し、テスト結果が次のゲートのビジネスケースを形づくります。こうした仕事の検証側については、V モデルを参照してください。

営業とカスタマーサクセス。 CRM の移行では、旧システムの契約終了日が確定しています。データクレンジングは予測型で進め、ダッシュボード、プレイブック、ルーティングルールは、それを使うチームとともに短いサイクルで調整します。

ハイブリッドプロジェクトマネジメントの Do と Don't

Do

• 分け方を意図して決める。 どの部分が予測型でどの部分が適応型か、そしてその理由を書き出します。
• 境界を最初に管理する。 ハイブリッドが失敗するのは引き継ぎの場面なので、設計の労力はそこに注ぎます。
• 制約の範囲内で、適応型チームに実質的な権限を与える。 そうしないと、朝会があるだけの Waterfall になります。
• ガバナンスを適正な水準に保つ。 ゲートは成果とリスクを確認するものであり、スプリントごとに同じドキュメントを要求するものではありません。
• 共通の言葉を使う。 「完了」「マイルストーン」「リリース」といった用語を合意し、双方が同じ意味で使えるようにします。
• ゲートごとにブレンドを見直し、証拠が示すなら境界線を動かします。

Don't

• 固定された計画にデイリースタンドアップを取り付けただけで Agile と呼ばない。 柔軟性のない儀式は何も変えません。
• Water フェーズで要件を凍結しておいて、スプリントに「適応」を求めない。 スプリントのフィードバックの行き場がなくなります。
• スプリントの成果を四半期ごとのリリースの後ろにまとめて溜めない。 頻繁にデリバリーする利点が失われます。
• エグゼクティブが自分で突き合わせなければならない2つのレポートシステムを運用しない。
• 「ハイブリッド」を、意思決定を避ける言い訳にしない。 何が固定で何が流動的かを言えないなら、まだハイブリッドを設計できていません。
• 1つの手法できれいに片づく、小規模で安定したプロジェクトに、ハイブリッドの複雑さを持ち込まない。

よくある課題と対処法