ローリングウェーブ計画: プログレッシブ・エラボレーションを解説

始まって3週間のプロジェクトについて、スポンサーから18か月目までの詳細なスケジュールを求められたとします。しかし、それを誠実に出せるだけの情報はありません。ローリングウェーブ計画は、「適当に作ります」でも「スケジュールは出せません」でもない答えです。これは確かなルールを持つ本物の手法であり、6週目までに書き直すことになる計画の代わりに、スポンサーが受け入れてくれる言葉を与えてくれます。

Key Facts

• PMBOK Guide第8版(PMI、2025年11月)は現行のPMBOK Guideで、7つのパフォーマンスドメインを軸に構成されています。そこにはスコープとスケジュールも含まれ、これはウェーブが切り替わるたびにローリングウェーブ計画が同期させ続けなければならない2つのドメインそのものです。
• Gregory D. Githens, PMPによるローリングウェーブでのプログラム管理に関するPMI自身のガイダンスによれば、「ローリングウェーブは、うまく実施すれば、プログラムチームに、統制と柔軟性のバランスがとれたプログラムアプローチを作るためのフレームワークを提供する」とされています。
• PMIによるfit-for-purposeへの転換に関する調査によれば、ハイブリッド型プロジェクトマネジメントの採用は、2020年のプロジェクトの20%から2023年には31.5%へと57.5%増加しました。この変化によって、ローリングウェーブ計画は本来のプログラムマネジメントの領域をはるかに超えて広まりました。
• Timothy J. Paskoによるアーンドバリューのためのプランニングパッケージの活用に関するPMIのガイダンスによれば、プランニングパッケージは「その作業に対するいかなる費用が発生する前にも、ワークパッケージに変換されなければならない」とされています。このルールは、まだ誰も詳細化していない作業に対して、ローリングウェーブ計画が知らないうちに支出してしまうことを防ぎます。

ローリングウェーブ計画とは実際には何か(プログレッシブ・エラボレーションとの違い)

このテーマのページの多くは、この2つの用語を同じ意味で使っており、まずそこを正す必要があります。プログレッシブ・エラボレーションは原則です。より良い情報が得られるにつれて、計画がより詳細で正確になるというもので、これはプロジェクト計画のスケジュールだけでなく、スコープ、コスト、リスクの各セクションにも等しく当てはまります。ローリングウェーブ計画は、その原則を決まったリズムで実践に移すスケジューリング手法であり、「進めながら考える」を、期間(ホライズン)と再計画の日付に変えるものです。

実際には、直近の作業をワークパッケージやアクティビティのレベル、つまりタスクに担当者、期間、依存関係のリストがあるレベルまで分解し、それより先のものはすべて、粗い「プランニングパッケージ」にまとめたままにすることを意味します。そこにあるのは予算の数字と大まかなマイルストーンだけです。ウェーブの境界が来ると、次のかたまりが詳細化され、ホライズンが前へ転がっていきます。これが「ローリング」の部分であり、この手法を場当たり的なプログレッシブ・エラボレーションと分けるものです。

この区別は覚えておいてください。ローリングウェーブ計画でうまくいかないことの大半は、手法そのもの、つまりウェーブ、リズム、プランニングパッケージのワークパッケージへの変換を任意のものとして扱い、「後で適応すればいい」というあいまいな精神だけを残してしまうことに行き着きます。PMBOK Guideのパフォーマンスドメインは、スコープとスケジュールを統合的に管理する領域として扱っており、ローリングウェーブ計画は、プロジェクトの先の部分がまだ分からないときにそれを実現する具体的な方法のひとつです。

ローリングウェーブ計画の実際の仕組み: ウェーブごとの見方

12か月のプラットフォーム移行プログラムを思い描いてください。Discovery、Build、Test、Cutoverという4つの順次フェーズに分かれ、ウェーブのホライズンは3か月です。キックオフ時点で、ワークパッケージのレベルまで分解されるのはDiscoveryだけです。それ以降のものは、フェーズごとに1つのプランニングパッケージとして存在し、予算の合計と目標の完了月はありますが、タスクのリストはありません。

これが「なんとかなるだろう」の言い換えに終わらず、機能する理由は2つあります。まず、すべてのプランニングパッケージには、実際の予算と目標日付がきちんと設定されており、内部が詳細化されていなくても、プログラムは初日から全体のベースラインを持っています。そして、プランニングパッケージのワークパッケージへの変換は、誰かが思い出したときではなく、決まった日付に行われます。Gregory GithensのPMIの記事はこれをうまく表現しています。将来の作業を、後から足す詳細の代わりとなる「ブラックボックス」のプレースホルダーで識別し、ウェーブの境界自体を予定された作業として扱います。つまり、プロジェクトが生み出すほかのあらゆるものに適用するのと同じプロジェクトの成果物の規律に組み込まれる成果物です。直近のウェーブの成果物には完全な受け入れ基準が設定され、2、3ウェーブ先の成果物は、そのウェーブが来るまでプレースホルダーのままです。

ウェーブのホライズンとリズムの選び方

ウェーブはちょうど6週間、あるいはちょうど1四半期であるべきだとする、PMI発行の表はありません。ホライズンは判断の問題であり、前提がどれだけ早く古くなるかによって決まります。短すぎると、作業そのものより再計画に時間を費やしてしまいます。長すぎると、コミットした「詳細な」ウェーブが、半分も進まないうちに現実から離れてしまいます。実際の要因は、要件の変動性、調達やベンダーのリードタイム、契約の種類、チームの安定性です(チームメンバーの平均在籍期間より長いホライズンは、トラブルを招きます)。Githens自身の実例が参考になります。3か月のホライズンと20%の安全係数を用いる18か月のプログラムでは、WBSの最上位におよそ7つのタイムホライズンができ、それぞれが、次の詳細のかたまりにコミットする前に前提を再検証するチェックポイントになります。

これは出発点であり、ルールではありません。実際のテストは、直近のウェーブがその期間を通じて正確なままかどうかです。そうでなければホライズンを短くします。何も変わらないのに再計画が形だけの作業に感じられるなら、長くします。本当に解消された不確実性には、そもそもウェーブは必要ありません。これは、表が示したホライズンを既定にするのではなく、プロジェクトリスクマネジメントの中で判断する価値のあることです。

ローリングウェーブ計画と作業分解構成図

ローリングウェーブ計画は作業分解構成図に取って代わるものではありません。それぞれの枝がいつ完全に分解されるかを変えるものです。100%ルールは、どの時点でもプログラム全体に適用されますが、遠い枝は、ワークパッケージの木ではなく、1つのプランニングパッケージでそれを満たします。この用語は、正式なEVM(アーンドバリューマネジメント)を使っていなくても借りる価値があります。Timothy PaskoのPMIの記事は、これを、特定し、スケジュールし、予算化することはできるが、まだ詳細計画されていない、コントロールアカウント内の先の作業と定義しています。そのルールに実効性を持たせるのが、実際の費用が発生する前に、1つ以上のワークパッケージに変換されるという点です。プレースホルダーに対して予算を組むことはできます。プレースホルダーに対して支出することはできません。

プログラム全体のWBSを、まずプランニングパッケージのレベルで作っておくことが、すべてのウェーブにわたって100%ルールを保つ要です。この手順を飛ばして各ウェーブのWBSをゼロから始めると、3ウェーブ先で忘れていたスコープを再発見することになります。初日に書き留めたプレースホルダーと照合して見つけるよりも、はるかに高くつく見つけ方です。

ベースラインとローリングウェーブ計画: 難しい部分

この手法の説明の多くが省略している、そして実際のプロジェクトマネージャーが本当に行き詰まる部分があります。WBSの半分が意図的に未定義のとき、どうやって意味のあるプロジェクトベースラインを保つのか、という点です。

ベースラインは、異なるレベルの確信度で、異なるものに対して設定し、計画全体が同じ重みを持つふりをせず、それを明示します。現在のウェーブのスコープ、スケジュール、コストは、ワークパッケージの詳細度でベースライン化します。完全な予測型プロジェクトに適用するのと同じ厳密さです。それ以降のものも、プランニングパッケージのレベルで、つまりタスクのリストではなく予算の合計とマイルストーンの日付でベースライン化します。外側の制約、つまりプログラムの総予算と終了日は、初日からベースライン化し、すべてのウェーブがその内側に収まらなければならないものとして保持します。

ここは、ローリングウェーブ計画が変更管理プロセスと最も直接的に交わるところです。プランニングパッケージのワークパッケージへの変換を、すでにコミットした境界で、予定どおりに行うことは、変更ではなく、計画が設計どおりに機能していることです。変更にあたるのは、予算を見直さずに将来のウェーブからスコープを前倒しにすること、あるいは現在のウェーブの詳細が、パッケージの規模を超えて膨らむことを許すことです。どちらも、ローリングウェーブの言葉で言えば、外から見るとスコープクリープとまったく同じに見えます。それらを区別するのは、その変更が、他のあらゆるベースライン変更と同じ承認を経たかどうかだけです。結果を誰も承認しないままパッケージを変換すれば、何が変わったのか誰も説明責任を負わないまま、数か月ごとにリセットされるベースラインができあがります。

ローリングウェーブでの見積り

現在のウェーブの見積りと、3ホライズン先のウェーブの見積りに、同じ手法を使うべきではありません。直近のウェーブの作業は、ボトムアップの見積りに値するほど十分に理解されています。タスクに分解し、三点見積りを適用して、確実性を装った単一の数字ではなく、楽観値、最頻値、悲観値の範囲を出します。遠いウェーブの作業は、類推見積り(プランニングパッケージを過去のプログラムの類似のものと比較する)やパラメトリック見積り(過去の単価に大まかな数量を掛ける)に頼ります。これらは、初期段階の予算策定のためのプロジェクトのコスト見積りで扱う手法です。

ウェーブを重ねるごとに精度が上がるべきなのは、これから現在のホライズンに入るものの見積りです。前のウェーブでは大まかな類推の数字だったものが、今のウェーブでは、その前のウェーブを実行して学んだことから作ったボトムアップの数字になります。他の場所では、この進行が、見積りの区分ごとに特定の確信度のパーセンテージを添えて説明されているのを見かけるでしょう。一方の端にラフオーダーオブマグニチュード、もう一方の端に確定見積りがあります。名前の挙がった、入手可能な情報源にたどれないものは、証拠ではなく飾りとして扱ってください。数字を添えなくても真実であることは、ウェーブごとに前提を測定値に置き換えるので範囲が狭まるということ、そしてその狭まりこそが要点だということです。

ローリングウェーブ計画が適する場所: 予測型、ハイブリッド、アジャイル

ローリングウェーブ計画は、コントロールアカウントとアーンドバリューの世界である、予測型でプログラム中心のプロジェクトマネジメントから生まれました。ハイブリッドなデリバリーでも同じようになじみ、そこではしばしば結合組織の役割を果たします。直近の作業はアジャイルのスプリントの中で行われ、それより先のものは、スプリントに対応できるバックログを用意する価値があるほど近づくまで、プランニングパッケージのレベルにとどまります。これが、元の領域を超えて広がった大きな理由のひとつです。PMI自身のfit-for-purposeなデリバリーへの転換に関する調査でも、ハイブリッドの採用は2020年のプロジェクトの20%から2023年の31.5%へ上昇したことが分かっています。

アジャイルとウォーターフォールの比較の多くが見落としていることがあります。バックログのリファインメントを行うアジャイルチームは、構造的には、ローリングウェーブ計画を実施しているプログラムと同じことをしており、用語が異なり、ホライズンが短いだけなのです。Scrum Guideは、リファインメントをProduct Backlog項目を分解して詳細を加えることと説明しており、項目は、その詳細が加わって初めて「Sprint Planningイベントでの選択の準備ができた」とみなされ、さらに下の項目は、順番が来るまで粗いままです。「スプリント」を「ウェーブ」に、「バックログリファインメント」を「プランニングパッケージの変換」に置き換えれば、同じ規律を説明していることになります。

「アジャイルのように聞こえる」言葉に懐疑的なスポンサーに対する率直な売り込みは、こうです。ローリングウェーブ計画は不確実性への譲歩ではなく、すでに存在する不確実性を、より正確に表現する方法です。前倒しの完全な計画は、その不確実性を取り除くのではなく、実際よりも自信があるように見える数字の中に隠すだけです。

ローリングウェーブ計画が不向きなとき

この手法が真価を発揮するのは、プロジェクトの先の部分が本当に分からないときです。そうでないとき、あるいは費用を負担する側が、この手法が構造上与えられない確実性を必要としているときには、不適切な選択です。

Githensは、逆方向に作用する関連した指摘もしており、繰り返す価値があります。ローリングウェーブは、先の部分が本当に未解決である開発作業のために作られており、導入プロジェクト(展開、移行、始まる前からよく理解されているゴーライブ)に適用すると、すべてを前倒しで計画するよりもプロジェクトが遅く、非効率になる可能性があります。これは特定の種類の不確実性に対する特定の答えであり、その不確実性がなくなったら、退場すべきものです。

ローリングウェーブ計画はどう悪用されるか

多くの解説が省略している、そして懐疑的なPMOに対してこの手法を擁護するときに最も重要になるセクションです。「ローリングウェーブ」は正当な手法であり、同時に、そもそも計画するつもりがなかったチームの言い訳にもなる言葉です。

これらはどれも特殊なものではありません。ローリングウェーブの用語だけを、その規律なしに採用した結果として予測できるものであり、どれも、あいまいな意図があった場所に、日付、担当者、承認のステップを置くことで解決できます。

ローリングウェーブ計画の導入手順

ステップ1: これが本当に適切な手法かを確認する

不確実性が単に対処されていないのではなく、本物であることを確認します。後のフェーズがよく理解されているのに、それを計画する作業を誰もスケジュールしていないのであれば、それはローリングウェーブの出番ではなく、計画のギャップです。本物の不確実性は、通常、未解決の依存関係や、後のフェーズがまだ手元にない結果に左右されるプロジェクトライフサイクルにたどり着きます。

ステップ2: ウェーブのホライズンとリズムを設定する

上述の要因、つまり要件の変動性、調達のリードタイム、契約の種類、チームの安定性を使います。ホライズンと再計画の日付は、別の場での会話ではなく、スケジュール自体に書き込みます。

ステップ3: プログラム全体のWBSを、プランニングパッケージのレベルで構築する

すべてのフェーズと成果物に、それ以上分解する前に、少なくとも予算の数字とマイルストーンの日付を持つプランニングパッケージを1つ設けます。これによって、初日から、すべてのウェーブにわたって100%ルールが守られます。

ステップ4: 現在のウェーブを、ワークパッケージのレベルまで分解する

8/80ルールは、現在のウェーブにのみ適用します。作業が、実際の範囲を支えられるほど十分に理解されているので、三点見積りで見積ります。

ステップ5: 現在のウェーブと、プログラムの外側の制約をベースライン化する

現在のウェーブを完全な詳細度でベースライン化し、プログラムの総予算と終了日を、今後のすべてのウェーブが収まらなければならない制約としてベースライン化します。

ステップ6: 実行し、追跡し、ウェーブの境界の日付を守る

現在のウェーブを、他のあらゆるよく管理された作業と同じように運営し、今設定したベースラインに対して実績を追跡します。

ステップ7: 境界で再計画し、それを本物の成果物として扱う

境界が来たら、その前のウェーブを実行して学んだことを使って次のプランニングパッケージをワークパッケージに変換し、それによって生じるベースラインの変更は、正式な変更管理を通し、ホライズンを前へ転がします。

ローリングウェーブ計画でのよくある間違い

ローリングウェーブ計画は、コミットすることからの逃げ道ではありません。より誠実なコミットの仕方です。分かっていることには完全な詳細を、まだ分からないことには実際の予算と日付を、そしてそのギャップが埋まる固定の時点を。ホライズンを意図的に設定し、すべてのウェーブの再計画の作業に日付を置き、内部の詳細が前へ転がる間も外側のベースラインを安定して保てば、スポンサーが1か月目に信頼でき、12か月目にもなお信頼できる計画が手に入ります。