プロジェクト管理方法論について調べたことがある方なら、ウォーターフォール手法について耳にしたことがあると思います。ウォーターフォールは、アジャイル、スクラム、シックスシグマ、カンバンと並んで定評のあるプロジェクト管理手法で、Winston Royce 博士が1970年に大規模なソフトウェア開発プロジェクトの非効率性に関する論文で初めて定義したものとされていますが、この手法自体を開発したのが誰かは分かっていません。

その定義から半世紀ほどが経ちましたが、ウォーターフォールは現代のビジネスの世界でも大きな存在感を示しています。ただ、あらゆる状況に適した方法論ではありません。以下では、ウォーターフォールモデルの長所と短所に加え、Lucidchart を使ってこのモデルを次のプロジェクトで活用する方法を説明しています。

ウォーターフォールモデルの長所

ウォーターフォール手法では、チームが一連のステップに従い、前のフェーズが完了して始めて次のフェーズへと進みます。比較的小規模で、成果物が最初から定義しやすいプロジェクトに適した仕組みです。

「The Digital Project Manager」の Ben Aston 氏はこう記しています。「ウォーターフォールは一般に、非効率的でトレンドから外れた旧式のプロジェクト管理アプローチとしてある種軽蔑されているが、要件が固定しており、十分文書化されて明確な場合や、対象のテクノロジーが成熟していてよく理解されている場合、また短期間のプロジェクトで「アジャイル」化することから得られる価値が特にないような場合には、ウォーターフォール手法が適していることもある。実際に、予算、タイムラインやスコープの点で、予測可能性が高い最終結果をもたらしてくれる仕組みである。」

では、ウォーターフォール手法の主なメリットについて詳しく見ていきましょう。

1. 構造がわかりやすい

他の手法と比べると、ウォーターフォールのステップは非常に明確に定義されています。構造はシンプルで、どのプロジェクトも以下のステップで進みます。

• 要件収集とドキュメンテーション
• システム設計
• 実装
• テスト
• 提供/デプロイ
• メンテナンス

チームが次のステップに進むには、その前のステップを完了しなければならないため、完了する上で何か障害があれば、すぐにそれが判明します。未完成のプロジェクトが仮置きのまま取り残されるリスクも低く、プロジェクト完了時の完成度や洗練度も高くなります。

ウォーターフォールの進行は分かりやすいだけでなく、直感的でもあります。シックスシグマやスクラムとは異なり、プロジェクトマネージャーや従業員向けの認定や特別なトレーニングも不要です。Lucidchart を使って開始時点でプロセスを視覚的に示し、ウォーターフォール手法を説明すれば、メンバーはすぐにこのシステムに取りかかれ、仕組みの学習に時間を取られて進捗が遅れることもありません。

2. 最終目標が早い段階で決まる

ウォーターフォール手法で特徴的なステップのひとつが、最初の時点で最終製品、目標や成果物にコミットするというもので、チームはそうしたコミットメントからの逸脱を極力避けます。目標が明確で小規模なプロジェクトの場合、このステップを踏むことでチーム全体が開始時点から全体的な目標を認識できるようになり、プロジェクトの進行につれて方向性が危うくなることを避けられるようになります。

プロジェクトを個別のスプリントに分割するスクラムとは異なり、ウォーターフォールでは、常に最終目標から目を離しません。チームに具体的な目標があり、期限もはっきりしているなら、途中で行き詰まることなく目標に向かって進める手法として適しているでしょう。

3. 情報をうまく伝達できる

ウォーターフォール手法のアプローチは非常に組織的であり、各ステップにおける情報の伝達でも明確さが重視されます。ソフトウェア開発の環境では、新しいステップには新メンバーの参加がつきものです。また、会社によって状況は異なりますが、プロジェクトのライフサイクルを通じて情報を文書化するよう努める必要があります。各ステップでプロジェクトを引き継ぐ際や予想外の異動が発生した際など、ウォーターフォール手法では情報へのアクセスを優先するため、チームに新しく加わったメンバーもすぐに馴染むことができます。

こうしたウォーターフォール特有のメリットを最大限に活かすには、適切なプロセスに沿ってプロジェクトを進めることが大切です。プロジェクトが担当箇所まで進んだ際に各メンバーが完了している部分を確認できるよう、Lucidchart (登録は無料！) を使ってプロセスを文書化しましょう。

ウォーターフォールモデルの短所

ウォーターフォールは定評ある手法ですが、近年、時代遅れのモデルとして批判の対象となっています。対象のプロジェクトの規模、タイプや目標によっては、その限界が特に目立ちやすくなります。ウォーターフォール手法の枠組みに組織を後付けで合わせるのではなく、こうした限界を事前に考慮し、チームに適した手法かどうかを検討しましょう。

1. 変更が難しくなる

ウォーターフォールでは、チームが常に前進し続けるため、一連のステップに完璧に従うことを基本としています。従来型の方法で行えば、不測の変更や修正がほぼ発生しない手法であり、もしチームが忠実にステップに従い、プロジェクト完了間近でスコープや目標の変更が避けられない不測の障害に遭遇したとしたら、方向転換は容易ではありません。非常に具体的で厳格な前提に基づくプロジェクトでは、膨大な作業が必要となりますが、プロジェクトのパラメーターが急に変更されると、それまで行った作業が完全にムダとなり、タイムライン自体が機能しなくなる恐れもあります。

チームが取り組むプロジェクトが予測不能なものだったり、頻繁な変更が行われる場合には、プロジェクト完了時ではなく途中で振り返りや修正ができるよう、ウォーターフォール手法に調整を加えれば時間と労力のムダを避けられます。この方法をとる場合には、Lucidchart のテンプレートをカスタマイズしてチームオリジナルのウォーターフォールに仕立て、メンバー全員に調整済みのプロセスを使うことを周知しておきましょう。

2. 顧客やエンドユーザーが疎外される

ウォーターフォールは本来社内向けのプロセスのため、エンドユーザーや顧客のプロジェクトへの関与にはほとんど重きが置かれていません。これは、その目的が、社内チームのプロジェクトにおける各フェーズの移行の効率化にあるためです。ソフトウェア開発業界においてはこれがうまく機能してきましたが、それ以外の業界では、顧客がプロジェクト中に関与し、意見を追加したり、プロジェクトの進行に合わせて要望を明確にしてくることもしばしばあります。

プロジェクトの目標が最初から明確で変更がなく、開発プロセスでエンドユーザーや顧客への状況説明が必要ないようであれば、ウォーターフォール手法がうまく機能するでしょう。そうでない場合には、変更に対応しやすく、プロジェクトの過程を通じてステークホルダーに絶えず情報共有を行うアジャイル手法の採用を検討してみましょう。ステークホルダーを巻き込むことで、変更のリクエストが遅れ、プロジェクトの期限が守れなくなるリスクを軽減できます。

3. プロジェクトが完了しないとテストができない

プロジェクト後半になるまで製品のテストをしないとリスクが高くなりますが、ウォーターフォール手法では、6つのステップのうち4つ目でようやくテストを行います。ソフトウェア業界以外の世界では、テストフェーズには、顧客への新しいウェブサイトデザインの提示、コンテンツの A/B テスト、プロジェクトの実行可能性を図るための実証データの収集など、多数の作業が含まれます。この時点までにプロジェクトの完了を目指して多大な時間がすでに費やされているため、大きな修正が発生すれば大幅な遅延につながりかねません。

ウォーターフォールのこうした原則に対応するために作られたのがアジャイル手法です。ウォーターフォールに対する批判には、プロジェクト完了間近まで問題が手つかずのまま残り、大規模で費用のかかる修正を行わざるを得ないという見方がありました。頻繁にテストを行う方がチームに適していると思われる場合には、プロジェクトの全段階の終了時点でテストを行えば、問題を残したまま次のステップへ進むこともなくなります。または、プロセス過程での振り返りと修正を奨励する別のプロジェクト管理手法を試してみるのもよいでしょう。

ウォーターフォールモデルの長所と短所を使いこなす

ウォーターフォール手法には、創設以来賛否両論がありましたが、その欠点を補う他の手法が多数登場した今でも、大きな存在感を示し続けています。チームが小規模で、一貫した予測可能なプロジェクトであれば、プロセスを整理した状態でスケジュール通りに進められる最適なフレームワークといえます。

そうでない場合には、状況に合わせてプロジェクト管理手法を自由にカスタマイズしましょう。Lucidchart を使えば、チーム固有のニーズにぴったり合った構造を自在に作り上げることができます。

ウォーターフォールプロセスなど、お好きな手法を追跡できます。

今すぐ Lucidchart に登録しましょう！