「何かあれば早めに共有してください。」

プロジェクトではよく聞く言葉です。

しかし実際には、「何をもって困ったと言えるのか」は人によって判断が異なります。

あるメンバーは30分で相談します。

一方で、あるメンバーは3日間悩み続けます。

これでは、相談するタイミングは個人の判断に依存してしまいます。

そこで重要になるのが、「問題が起きる前兆」を設計することです。

前兆はプロジェクトによって違う

前回の記事では、助けを求めるシグナルを標準化する重要性について紹介しました。

しかし、「何をシグナルにするのか」はプロジェクトによって大きく異なります。

つまり、すべてのプロジェクトに共通する前兆は存在しません。

PMは、そのプロジェクトで何が問題の前兆になるのかを考え、設計する必要があります。

ウォーターフォール型のシステム開発で見られる前兆

例えば、ウォーターフォール型のシステム開発では、次のような前兆があります。

• レビュー指摘件数が急に増えた
• 同じ仕様への質問が繰り返される
• WBSは完了しているのにレビューが終わらない
• タスクの更新が止まっている

これらは、まだ問題ではありません。

しかし、後になって品質問題や納期遅延につながる可能性があります。

EPCプロジェクトで見られる前兆

私が多く経験してきたEPCプロジェクトでは、少し違う前兆があります。

• 他部署からの回答が返ってこない
• 承認待ちが長期間続く
• 設計変更依頼が増えてきた
• 資材納期が変更になった

どれも、その時点では問題になっていません。

しかし放置すると、工程全体へ影響します。

だからこそ、この段階で関係者が集まり、相談や調整を始める必要があります。

アジャイル開発でも前兆は存在する

アジャイル開発では毎日コミュニケーションがあります。

それでも、問題の前兆は存在します。

• 同じタスクが何日も「進行中」のまま
• デイリースクラムで毎日同じ内容を話している
• レビュー待ちが増えている
• ベロシティが急に落ちた

このような変化は、チームが何かにつまずいているサインかもしれません。

前兆には共通する4つの型がある

プロジェクトによって前兆は異なります。

しかし整理してみると、大きく4つの型に分類できると私は考えています。

① 時間

一定期間、状態が変わらないことです。

例

• 承認待ちが3日以上続く
• タスク更新が止まっている
• 回答待ちが長期化している

② 数量

件数や量が急に変化することです。

例

• レビュー指摘件数
• 不具合件数
• 設計変更件数

③ 状態

本来あるべき状態から外れていることです。

例

• レビュー未実施
• Blocked状態
• テスト未着手

④ 変化

普段とは違う変化が起きることです。

例

• 質問が急に増える
• 会議への参加者が減る
• 進捗が急に悪化する

PMが本当に設計するべきもの

ここまで考えると、PMの役割は問題が起きた後に対応することではありません。

また、メンバーへ「早めに相談してください」とお願いすることでもありません。

本当に設計するべきなのは、

「この前兆が現れたら、相談・レビュー・調整を始める。」

というルールです。

つまり、

前兆 → コミュニケーション

を設計することです。

これが、人に依存しないコミュニケーションマネジメントにつながります。

まとめ

相談のタイミングを人に任せると、どうしても遅れが発生します。

だからこそPMは、「何が問題の前兆なのか」を考え、その前兆が現れたら自然とコミュニケーションが始まる仕組みを設計する必要があります。

プロジェクトごとに前兆は異なります。

だからこそ、プロジェクト開始時には、

「このプロジェクトでは、何を前兆として監視するのか。」

をチームで話し合うことが、コミュニケーションマネジメントとリスクマネジメントをつなぐ第一歩になるのではないでしょうか。

おわりに

皆さんのプロジェクトでは、「問題」を管理できていますか。

それとも、「問題の前兆」を管理できていますか。

プロジェクトの成功を左右するのは、問題が起きた後の対応ではありません。

その前にどれだけ前兆に気付き、適切なコミュニケーションにつなげられるかが重要だと私は考えています。

The post プロジェクトによって「相談のタイミング」は違う。だからPMは「前兆」を設計する。 first appeared on PM道場.

その中でも代表的なものがウォーターフォールです。

ウォーターフォールは、プロジェクトをいくつかの工程に分け、基本的に上流工程から下流工程へ順番に進めていくプロジェクトの進め方です。

「要件を決める → 設計する → 開発する → テストする」というように、工程を順番に進めることから、滝（Waterfall）のように水が上から下へ流れるイメージで「ウォーターフォール」と呼ばれています。

特に、要件や成果物を事前に明確に定義しやすいシステム開発や、変更を厳格に管理する必要があるプロジェクトなどで利用されます。

一言でいうと

ウォーターフォールとは、プロジェクトを複数の工程に分け、基本的に上流工程から下流工程へ順番に進めるプロジェクトの進め方です。

代表的な流れは、

要件定義 → 設計 → 開発 → テスト → リリース

です。

後工程に進んでから前工程の内容を変更すると、影響範囲が大きくなるため、各工程で成果物を確認し、次の工程へ進むことが重要になります。

ウォーターフォールとは

ウォーターフォールは、プロジェクトを段階的な工程に分け、それぞれの工程を順番に完了させながら進めるアプローチです。

例えばシステム開発であれば、

• 要件定義
• 基本設計
• 詳細設計
• 実装
• テスト
• リリース

という流れで進めます。

もちろん、実際のプロジェクトでは工程の名称や分け方は異なります。

重要なのは、プロジェクトを段階的な工程に分け、計画に基づいて順番に進めるという考え方です。

なぜ「ウォーターフォール」と呼ばれるのか

ウォーターフォール（Waterfall）は、日本語にすると「滝」です。

プロジェクトの工程を上から下へ流れる水に見立てていることから、この名前が付けられています。

例えば、

要件定義

↓

設計

↓

開発

↓

テスト

↓

リリース

というように、工程が順番に進んでいくイメージです。

ウォーターフォールの代表的な工程

ウォーターフォールでよく使われる工程には、次のようなものがあります。

プロジェクトによっては、要件定義の前に企画工程があったり、テストを複数の工程に分けたりすることもあります。

したがって、「ウォーターフォール＝必ずこの工程で進める」という決まりがあるわけではありません。

ウォーターフォールの特徴

計画を立ててから進める

ウォーターフォールでは、プロジェクトの開始時点で、できるだけ必要な作業や成果物、スケジュールなどを明確にします。

そのため、プロジェクト全体の計画を立てやすいという特徴があります。

工程ごとの成果物を明確にする

各工程では、次の工程につなげるための成果物を作成します。

例えば、要件定義では要件定義書、設計では設計書などを作成します。

こうした成果物を確認しながら、次の工程へ進みます。

変更を管理しやすい

ウォーターフォールでは、計画や要求事項を明確にしたうえで進めるため、変更が発生した場合には、変更管理の手続きを通して影響を確認することが一般的です。

そのため、変更を厳格に管理する必要があるプロジェクトに適しています。

後工程での変更は影響が大きくなりやすい

一方で、プロジェクトが進んだ後に要件を変更すると、設計や開発、テストなど多くの工程に影響する可能性があります。

そのため、ウォーターフォールでは上流工程で要求事項をできるだけ明確にすることが重要です。

ウォーターフォールのメリット

プロジェクト全体を計画しやすい

工程を順番に進めるため、プロジェクト全体のスケジュールや必要な作業を計画しやすくなります。

特に、いつまでに何を完成させるのかを明確にする必要があるプロジェクトでは有効です。

進捗を管理しやすい

工程や成果物が明確になっているため、計画と実績を比較しやすくなります。

例えば、

• 要件定義は完了したか
• 設計は予定どおり進んでいるか
• テストはいつ開始できるか

などを確認できます。

成果物を明確にできる

各工程で作成する成果物を定義しやすいため、レビューや承認などの管理を行いやすくなります。

役割分担がしやすい

工程が明確になっているため、どの組織や担当者がどの工程を担当するのかを整理しやすくなります。

規制や承認が重要なプロジェクトに適している

成果物や承認プロセスを明確にしやすいため、記録や証跡が重視されるプロジェクトでも活用しやすい方法です。

ウォーターフォールのデメリット

変更への対応に時間がかかる

上流工程で決めた内容を後から変更すると、すでに完了した設計や開発、テストなどに影響する可能性があります。

そのため、変更が多いプロジェクトでは、対応に時間やコストがかかる場合があります。

完成した成果物を見るまで時間がかかる

基本的には工程を順番に進めるため、ユーザーが実際に利用できる状態になるまで時間がかかることがあります。

その結果、利用者からのフィードバックを得られるのが遅くなる場合があります。

初期の要求が不明確だと問題が後工程に影響する

上流工程で要求を十分に整理できていないと、その問題が設計や開発、テストなど後工程で発見されることがあります。

後工程で発見されるほど、修正の影響が大きくなる可能性があります。

利用者からのフィードバックが遅くなりやすい

実際に動く成果物が完成するまで時間がかかるため、利用者が「思っていたものと違う」と気付くタイミングが遅くなる可能性があります。

ウォーターフォールに向いているプロジェクト

ウォーターフォールは、すべてのプロジェクトに適しているわけではありません。

特に、次のようなプロジェクトでは適用しやすいと考えられます。

• 要求事項が比較的明確である
• 要求事項の変更が少ない
• 成果物や仕様を事前に定義しやすい
• 工程ごとの承認が必要である
• 規制や契約上の制約が多い
• プロジェクト全体の計画を重視する必要がある

例えば、要件が明確で、設計や承認を厳格に管理する必要がある大規模なシステム開発などでは、ウォーターフォールが適している場合があります。

ウォーターフォールに向いていないプロジェクト

一方、次のようなプロジェクトでは、ウォーターフォールだけでは対応しにくい場合があります。

• 要求事項が頻繁に変わる
• ユーザーのニーズがまだ明確ではない
• 市場環境が大きく変化する
• 早い段階でユーザーからフィードバックを得たい
• 試行錯誤しながら成果物を改善したい

このような場合には、アジャイルなどの反復的・適応的なアプローチが適している可能性があります。

ウォーターフォールとアジャイルの違い

ウォーターフォールと比較されることが多いのがアジャイルです。

ただし、ウォーターフォールとアジャイルのどちらが優れているという話ではありません。

プロジェクトの特性に応じて、適切なアプローチを選択することが重要です。

ウォーターフォールとアジャイルは組み合わせられる？

実際のプロジェクトでは、ウォーターフォールかアジャイルかを完全に二択にする必要はありません。

例えば、全体としては大きな工程やマイルストーンをウォーターフォール型に計画し、個々の開発部分ではアジャイルの反復的な進め方を採用することもできます。

このように、プロジェクトの特性に応じて複数のアプローチを組み合わせることをハイブリッドアプローチと呼びます。

重要なのは、「ウォーターフォールだからこうする」と形式的に決めることではなく、プロジェクトの目的、要求の安定性、リスク、組織の状況などを考慮して、適切な進め方を選択することです。

ウォーターフォールで重要な変更管理

ウォーターフォールでは、プロジェクトの途中で要求や仕様が変更されると、複数の工程に影響する可能性があります。

そのため、変更管理が重要になります。

例えば変更要求が発生した場合には、

• 何を変更するのか
• なぜ変更するのか
• スケジュールへの影響はあるか
• コストへの影響はあるか
• 品質への影響はあるか
• 他の成果物への影響はあるか

などを確認したうえで、変更を承認するかどうかを判断します。

つまり、ウォーターフォールでは「変更しないこと」よりも「変更の影響を評価して適切に管理すること」が重要です。

プロジェクトマネジメントでのウォーターフォール

ウォーターフォール型のプロジェクトでは、プロジェクトマネージャは工程ごとの進捗や成果物、品質、課題、リスクなどを管理します。

例えば、

• スケジュールを作成する
• 工程ごとの成果物を定義する
• レビューや承認を管理する
• 進捗を確認する
• 変更要求を管理する
• リスクを管理する
• 課題を管理する
• ステークホルダーとコミュニケーションする

といった活動が重要になります。

特に、後工程への影響を考慮しながら上流工程で問題を早期に発見することが重要です。

ウォーターフォールで重要なレビュー

ウォーターフォールでは、工程ごとに成果物を作成するため、レビューが重要な役割を持ちます。

例えば、要件定義書をレビューし、要求事項の漏れや矛盾を確認します。

その後、設計書をレビューし、要件を正しく設計に反映できているか確認します。

このように、後工程に問題を持ち越さないために、各工程で成果物の品質を確認することが重要です。

ウォーターフォールで重要なテスト

ウォーターフォールでは、開発した成果物を後工程でまとめてテストすることが一般的です。

そのため、テスト工程で重大な問題が見つかると、修正によってスケジュールに大きな影響が出る可能性があります。

このリスクを抑えるためには、テスト工程だけに品質確認を任せるのではなく、要件定義や設計などの上流工程から品質を作り込むことが重要です。

プロジェクトマネージャ試験ではここが重要

ウォーターフォールについては、単に「順番に工程を進める方法」と覚えるだけでは不十分です。

重要なのは、

• 工程を順番に進める
• 上流工程で要求事項を明確にする
• 工程ごとに成果物を作成する
• レビューや承認を行う
• 変更の影響を管理する
• 後工程への問題の持ち越しを防ぐ

という特徴を理解することです。

また、ウォーターフォールとアジャイルを単純に「どちらが優れているか」で考えないことも重要です。

プロジェクトの特性に応じて、適切な開発・プロジェクトアプローチを選択するという視点が重要になります。

PM道場のワンポイント

ウォーターフォールのポイントは、「後から戻ることが難しいから、上流工程を丁寧に行う」ということです。

ウォーターフォールでは、要件定義の後に設計、設計の後に開発、開発の後にテストという流れで進みます。

そのため、上流工程の問題が後工程に影響しやすいという特徴があります。

例えば、要件定義で漏れがあった場合、

要件漏れ

↓

設計への反映漏れ

↓

実装漏れ

↓

テストで不具合として発見

というように、問題が後工程へ流れていく可能性があります。

だからこそ、ウォーターフォールでは、「後でテストすればよい」ではなく、「前の工程でできるだけ問題を見つける」ことが重要です。

レビューやインスペクションなどを活用し、上流工程で成果物の品質を高めることが、プロジェクト全体の品質やスケジュールを守ることにつながります。

そして、ウォーターフォールを選択すること自体が目的ではありません。

「このプロジェクトでは、なぜウォーターフォールが適しているのか？」

を考えることが、プロジェクトマネージャにとって重要です。

関連用語

• アジャイル
• スクラム
• スプリント
• プロジェクトマネジメント
• プロセス群
• パフォーマンスドメイン
• 要件定義
• 変更管理
• レビュー
• インスペクション
• テスト
• 品質管理
• リスク
• 課題
• ステークホルダーエンゲージメント

まとめ

ウォーターフォールとは、プロジェクトを複数の工程に分け、基本的に上流工程から下流工程へ順番に進めるプロジェクトの進め方です。

代表的な流れは、

要件定義 → 設計 → 開発 → テスト → リリース

です。

ウォーターフォールには、

• プロジェクト全体を計画しやすい
• 進捗を管理しやすい
• 成果物を明確にできる
• 工程ごとのレビューや承認を行いやすい

というメリットがあります。

一方で、

• 後からの変更による影響が大きくなりやすい
• 利用者からのフィードバックが遅くなりやすい
• 上流工程の問題が後工程に影響しやすい

という特徴もあります。

そのため、ウォーターフォールを採用する際には、要求事項の明確化、成果物のレビュー、変更管理、上流工程での品質確保が重要になります。

また、要求事項が頻繁に変化するプロジェクトでは、アジャイルなどの別のアプローチが適している場合があります。

重要なのは、ウォーターフォールかアジャイルかを形式的に選ぶことではありません。

プロジェクトの特性に合わせて、最も適した進め方を選択すること。

これがプロジェクトマネージャに求められる重要な判断の一つです。

関連記事

• アジャイルとは？
• スクラムとは？
• スプリントとは？
• レビューとは？
• インスペクションとは？
• テストとは？
• 品質管理とは？
• 変更管理とは？
• リスクとは？
• 課題とは？
• ステークホルダーエンゲージメントとは？
• パフォーマンスドメインとは？

よくある質問（FAQ）

Q. ウォーターフォールとは何ですか？

A. ウォーターフォールとは、プロジェクトを複数の工程に分け、基本的に上流工程から下流工程へ順番に進めるプロジェクトの進め方です。

Q. ウォーターフォールの代表的な工程は何ですか？

A. 一般的には、要件定義、設計、開発、テスト、リリースなどの工程があります。ただし、工程の名称や分け方はプロジェクトによって異なります。

Q. ウォーターフォールは変更に弱いのですか？

A. 後工程に進んでから上流工程の内容を変更すると、設計、開発、テストなどに影響する可能性があります。そのため、変更の影響が大きくなりやすいという特徴があります。ただし、変更を禁止するのではなく、変更管理によって影響を評価し、適切に管理することが重要です。

Q. ウォーターフォールとアジャイルの違いは何ですか？

A. ウォーターフォールは工程を順番に進めることを基本とするのに対し、アジャイルは短い期間で計画・開発・フィードバックを繰り返しながら成果物を改善していくアプローチです。

Q. ウォーターフォールとアジャイルではどちらが優れていますか？

A. 一概にどちらが優れているとはいえません。要求事項が比較的明確で変更が少ないプロジェクトではウォーターフォールが適する場合があり、要求事項が変化しやすいプロジェクトではアジャイルが適する場合があります。プロジェクトの特性に応じて選択することが重要です。

Q. ウォーターフォールではなぜ上流工程が重要なのですか？

A. 上流工程で発生した問題が、設計、開発、テストなどの後工程に影響する可能性があるためです。要件定義や設計などの段階でレビューを行い、問題を早期に発見することが重要です。

The post ウォーターフォールとは？特徴・工程・メリットとデメリットをわかりやすく解説 first appeared on PM道場.