ウォーターフォール

ウォーターフォールが狙うのは、作るものと段取りを早い段階で確定させ、進捗と品質を計画に照らして管理できる状態を作ることです。プロジェクトマネージャーは、開始時点で全体のスケジュールと工程ごとの成果物を定義し、どの成果物が揃えば次の工程に進めるかという判断基準（ゲート）をあらかじめ決めておきます。

典型的な工程の並びは、要求をまとめる要件定義から始まり、システム全体の構造を決める基本設計、内部の作り込みを決める詳細設計、プログラムを組む実装、単体テスト・結合テスト・総合テストという段階的な検証、そして本番への移行と続きます。各工程の終わりには要件定義書や設計書、テスト仕様書といった文書が残り、次の工程の入力になります。

この進め方が向くのは、作るものが早期に固まりやすく、途中で大きく変わりにくい案件です。関係者が多く、契約や監査で工程の証跡を求められる開発、たとえば基幹システムの刷新や公共系の案件などで採用されることが多いとされています。プロジェクトマネージャーにとっては、全体像を一枚の計画として示しやすく、進捗を工程単位で報告しやすい点が扱いやすさにつながります。

実際の進め方は、工程ごとに担い手と成果物がはっきり分かれます。全体の流れを、誰が何を作り、何をもって完了とみなすかという軸で追うと理解しやすくなります。

• 要件定義
  業務側とプロジェクトマネージャー、業務分析の担当が中心となり、実現したいことを要件定義書としてまとめます。ここで機能の範囲と優先度、非機能の条件を合意します。
• 設計
  設計担当が画面・データ・処理の構造を基本設計書と詳細設計書に落とします。前工程で決めた要件との対応が取れているかをレビューで確認します。
• 実装とテスト
  開発者が設計書に沿ってプログラムを組み、単体テストから結合テスト、総合テストへと検証の粒度を上げていきます。テスト仕様書と結果記録が品質の裏付けになります。
• 移行
  運用担当と業務側が本番環境への切り替えとデータ移行を進めます。移行手順書と切り戻し手順を用意しておくのが通例です。

プロジェクトマネージャーの役割は、各工程のレビューを通じて成果物の品質を確かめ、次工程へ進めてよいかを判断することです。工程の切れ目でスケジュールと予算、残作業を突き合わせ、遅れが見えたら人員や順序の調整を検討します。工程ごとにマイルストーンを置き、承認のタイミングをあらかじめ関係者と握っておくと、判断の場面で認識のずれが起きにくくなります。

ウォーターフォールで起きやすい問題は、後戻りのコストが工程を下るほど大きくなる構造から生まれます。上流の抜けや誤りが下流で表面化すると、設計や実装のやり直しが広い範囲に及びます。プロジェクトマネージャーが注意したい点を、原因の軸で整理します。

• 要件の固め残し
  要件定義で決めきれなかった項目を曖昧なまま次へ流すと、設計や実装の途中で解釈が割れます。合意の記録があっても、前提が言語化されていないと後で認識がずれます。
• テスト段階での要件変更
  下流でようやく動くものが見え、そこで業務側から変更要望が出ることがあります。計画に変更管理の枠を用意していないと、スケジュールと費用の見直しが難しくなります。
• 工程間の分業による情報の目減り
  担当が工程ごとに分かれると、要件の意図が設計・実装へ伝わる過程で薄まりがちです。文書だけに頼らず、工程をまたぐレビューや対話の場を挟むと補いやすくなります。

これらに対しては、要件定義の段階で決められない項目を明示し、いつ決めるかを合意しておくこと、変更が起きる前提で変更管理の手順を用意しておくことが助けになります。すべてを止められるわけではありませんが、後戻りの影響範囲を早めに見積もれるようにしておくと、判断の余地が広がります。

ウォーターフォールを理解するには、反復型の進め方と比べるのが近道です。ここでは、変更への向き合い方・進捗の見せ方・成果物が動く時期という三つの軸で並べます。

変更への向き合い方では、ウォーターフォールが上流で範囲を固めて後戻りを抑える前提に立つのに対し、スクラムは短い反復のたびに優先順位を見直し、変更を織り込みながら進めます。作るものが固まりにくい領域では反復型が扱いやすく、範囲と段取りを先に確定したい領域ではウォーターフォールが選ばれやすい、という整理ができます。

進捗の見せ方では、ウォーターフォールが工程の完了率と成果物の承認状況で示すのに対し、スクラムは反復ごとに動くものを見せて進み具合を確認します。成果物が動く時期も、前者はテスト工程まで全体像が動きにくいのに対し、後者は早い段階から一部が動きます。どちらが優れているという話ではなく、案件の性質と関係者の期待に合わせて選ぶ、あるいは工程によって組み合わせる判断がプロジェクトマネージャーに求められます。

ウォーターフォールの工程と成果物を説明できることは、プロジェクトマネージャーの土台になります。要件定義から移行までの流れを、誰が何を作り何をもって完了とするかという言葉で語れると、計画づくりや関係者への進捗報告で足場が安定します。とくにSIerや客先常駐の現場では、この進め方を前提にした案件が多く、工程の切れ目でどう判断するかという経験が評価されやすい傾向があります。

一方で、反復型との違いを自分の言葉で整理しておくと、案件の性質に応じた選択や組み合わせを提案できるようになります。ウォーターフォールを万能とも時代遅れとも決めつけず、向き不向きを説明できる状態が、進め方に幅を持たせたいPMのキャリアで役に立ちます。

ウォーターフォールはもう古い進め方なのでしょうか。

古いというより、向く場面が限られてきたと捉えるのが実態に近いです。作るものが早期に固まり、工程の証跡が求められる案件では今も使われています。案件の性質次第で、反復型と使い分けたり組み合わせたりする判断が現実的です。

ウォーターフォールとスクラムはどちらを選ぶべきですか。

作るものの固まりやすさで考えると選びやすくなります。範囲と段取りを先に確定したい案件はウォーターフォール、変更を織り込みながら進めたい案件はスクラムが扱いやすいとされます。工程ごとに使い分ける形も見られます。

ウォーターフォールでプロジェクトマネージャーが最も気をつける点は何ですか。

上流の抜けが下流で大きな後戻りにつながる構造への備えです。要件定義で決めきれない項目をいつ決めるか合意しておくこと、変更が起きる前提で変更管理の手順を用意しておくことが、影響範囲を早めに見積もる助けになります。