ウォーターフォール型プロジェクト管理とは？

ウォーターフォール型プロジェクト管理は、プロジェクトを一直線に、順番に進める手法です。計画から始まり、分析、設計、実装、テストを経て、最後に展開へ進みます。

この構造は、明確な計画や具体的な成果物が必要で、決まった順序でタスクを完了しなければならないプロジェクトによく使われます。目標、タスク、日程を明確に把握できることが利点です。

ウォーターフォール型はシンプルで、チームが従う明確な道筋と、わかりやすい日程を示すため役立ちます。客観的に測定・追跡できる具体的な成果物も定めるので、プロジェクトをより厳密に管理できます。また、厳格な進め方により、構想から実装まで円滑に進み、プロジェクトの成功につながります。

ウォーターフォール型は、プロジェクト管理ソフトウェアに組み込んで簡単に活用できる手法でもあります。各段階には、次へ進むために完了すべきタスクがあります。前の段階を終えてから、次の段階を始めます。Hiveなどのプロジェクト管理ソフトウェアで、とても簡単に再現できる構造です。

ウォーターフォール手法の登場

ウォーターフォール型プロジェクト管理は、建設プロジェクトや製造工程を管理する方法として始まりました。そのため、厳格な性質と直線的な段階への依存が特徴になっています。

ウォーターフォールという概念がいつ生まれたかには諸説あります。1950年代とする説もあれば、60年代を重視する説もあります。しかし、ソフトウェア開発への明確な適用が初めて示されたのは1970年です。Winston Royce博士が「大規模ソフトウェアシステムの開発管理」という論文を発表しました。この論文でも、Royceは「ウォーターフォール」という言葉を使っていません。滝を連想させたのは図の構造でした。プロジェクトの段階がページの左上から右下へ配置され、矢印で次の段階につながっていたのです。

この手法が初めて「ウォーターフォール」と呼ばれたのは、後に1976年に発表された論文だと考えられています。著者のT. E. BellとT. A. Thayerは、要件をより明確に定めるため、ソフトウェア工学に新しい技法が必要だと主張しました。

2001年にアジャイル宣言が発表されると、ウォーターフォール型は脚光を浴びる存在ではなくなりました。しかし、消え去ったわけではありません。現在も、元の形に多少の修正を加えながら使われています。アジャイルと融合して明るい未来を築くと考えるプロジェクト管理の専門家も多くいます。

では、ウォーターフォール型プロジェクト管理とは、具体的にどのようなものなのでしょうか？

ウォーターフォール型プロジェクト管理の考え方

[caption id="attachment_4568" align="aligncenter" width="539"] 画像提供： Product Tribe。[/caption]

アジャイルの枠組みと異なり、ウォーターフォール型は、開始から終了までの手順をより厳密かつ体系的に整理します。直線的な時間モデルを使い、プロジェクトを複数の部分に分け、順番に完了します。開始から終了までの各段階は、水が下へ流れる様子として視覚的に捉えられます。工程が滝のように上から下へ流れるのです。

一度流れ落ちた滝の水を逆流させられないのと同様に、開始時に一連の目標を定めると、途中で調整や変更をする余地はほとんどありません。順序立てた計画を作り、完了まで各段階を実行することが基本です。

この特徴は、ウォーターフォール型の最大の欠点と見られがちです。しかし、この手法が悪いという意味ではありません。実用性がなければ、50年以上も使われ続けてはいないでしょう。

ウォーターフォールを詳しく知る

この手法を詳しく知るには、各段階をより深く理解することが必要です。各段階は独立した部分として存在し、1つを完了しなければ次へ進めません。

Royceが最初に記した段階は、次のとおりです。

1. 要件

最初の段階では、要件一覧の作成を重視します。要件は顧客とプロジェクト関係者が示した指針に基づき、製品の目的を満たすのに十分な内容でなければなりません。企業の新製品開発プロセスの後続段階で指針として使える形で記録します。

1. 分析

分析と要件を1つの手順にまとめる場合もありますが、別の段階と考える場合もあります。要件段階では最終製品に必要な各要素を特定します。一方、分析段階では、制作に携わる全員と関係者、プロダクトオーナーが、要件をどのように実現できるかを十分に理解します。

1. 設計

この段階から実際の制作が始まります。プログラミング言語などの具体的な事項や、大枠の詳細について合意します。ここで決めた設計の柱が、以降のプロジェクト全体を支える枠組みになります。

1. コーディング

「設計」で築いた基盤から最終製品を作るために、必要な細部を埋める段階といえます。ソフトウェア開発では、前の段階で決めた要件や重要な指針に基づき、ソフトウェアそのものを作成します。

1. テスト

ソフトウェアが完成したら、その完成形をテストします。要件を満たしているか確認し、プログラム内の不具合の発見と修正に十分な時間をかけます。通常は、完成した製品をできるだけ徹底的に分析するため、さまざまなテスト担当者が検証します。たとえば負荷テストでは、特定の条件下での性能を調べ、継続運用の可能性や拡張性を把握します。

現在は、この工程に特化したソフトウェアテストサービスが数多くあります。APIセキュリティテストやA/Bテストなどが含まれます。

1. 運用

Royceの元のモデルの最終段階である「運用」は、開発したシステムの継続的な導入と保守です。企業の製品開発プロセスの最終成果を納品し、実際の環境に導入します。こうして滝の流れが終わります。

もちろん、これらの段階はソフトウェア開発のために作られました。ただし、基本原則はほかのさまざまなプロジェクトにも応用できます。厳格な性質から、やはりソフトウェア開発に最も適しているという意見は多いでしょう。それでも、段階と目標が明確な別のプロジェクトに合わせて調整し、導入することをためらう必要はありません。

ウォーターフォールのプロセスを修正する

前述のとおり、構造は厳格でも、ウォーターフォールには大きく変形した手法を導入できます。Royce自身も、先ほどのモデルから大幅に変更した「最終モデル」を開発しました。

1970年の論文、つまりソフトウェア開発の正式な手法としてウォーターフォールを紹介した論文で、Royceはテストが直線的な工程の終盤にあるため失敗の可能性があると認めています。後戻りできないため、最後のテストで失敗すると、発見した問題の解決には小さな調整ではなく、大規模な改修が必要になります。

そこでRoyceは、途中でフィードバックを行い、段階同士のやり取りを増やす修正を提案しました。たとえば最終モデルでは、テストと設計の間のフィードバックや、設計から要件へのフィードバックが重要になりました。

ほかの人もRoyceのモデルに独自の工夫を加えました。たとえばPeter DeGraceは、サシミモデルを導入しました。見た目はウォーターフォールと同じですが、1つ大きな違いがあります。各段階が進行を示す矢印だけで結ばれた独立した要素ではなく、互いに重なっているのです。

ウォーターフォール型は今も使われている？

もちろんです！

直線的なモデルには特有のリスクがありますが、世界中のプロジェクトマネージャーが特定の案件で今もこの手法を好んで使います。元の形を使う人も、修正版を好む人もいますが、基本原則は同じです。

かつてほどの人気はなくても、多くのプロジェクトマネージャーが、チームの目標達成と製品の提供を支えるためにウォーターフォールを選びます。時代遅れと思われることもありますが、特定の要件や特徴を持つプロジェクトでは今も役割があります。

たとえば、次のようなプロジェクトに特に適しています。

• 顧客が仕様と要件を明確に示している

• 製品開発の間、指針が変わらない

• 厳密な期限と順序立った目標がある

• 単純な開発構造と日程がチームに役立つ

• 使用技術に実績があり、開発チームが習熟している

ウォーターフォールは文書化を重視する点でも特徴的です。開発期間中に引き継ぎや人員の入れ替わりが想定されるチームに有利です。厳密な文書化と単純な開発構造により、新しい担当者もプロジェクトを引き継ぎ、完了まで進めやすくなります。

ウォーターフォール型プロジェクト管理のツール

ほかのプロジェクト管理手法と同様に、チームで導入しやすくするため、数多くの技術が開発されています。これらのソフトウェアは、特定の機能を使ってウォーターフォールの可視化と整理を効果的にします。たとえば、近代的なプロジェクト管理の初期からあるガントチャートは、ウォーターフォールの実践に優れた視覚ツールです。

ガントチャート

オンラインのプロジェクト管理ソリューションが広く普及し、その技術も進歩したため、ガントチャートはさらに便利になりました。今では動的に変更でき、カスタマイズや共同作業にも対応しています。ウォーターフォールでプロジェクトを進めるチームに、優れた使い心地を提供します。

代表的なソフトウェアには、次のものがあります。

1. Hive

2. ProjectManager

3. Wrike

4. Redbooth

5. ClickUp

Google DriveやOffice365などを使うチームなら、Google SheetsやMicrosoftのExcelでもガントチャートを作成できます。

どのガントチャートソフトウェアを選んでも、それがウォーターフォール型管理の中心になるといえます。ガントチャートはRoyceが提案した元のモデルと見た目が似ているだけではありません。2つの軸によって、完了すべきタスクの一覧と適切な実施日程を示し、チームを支えます。

文書化

詳細で一貫した文書化が重要なため、プロジェクトマネージャーは、クラウド上で共同作業ができるソリューションをよく利用します。チーム全員が同時に文書へアクセスし、簡単に修正できるようにするためです。

Evernoteなどの一般的なサービスやGoogle Drive、Dropboxなら、プロジェクト要件や重要な文書を簡単にまとめられます。

プロジェクト管理により特化したソフトウェアには、次のものがあります。

1. Hive

2. Huddle

3. Onehub

ただし、これは利用できる製品の一部にすぎません。最適なツールの組み合わせは、チームとプロジェクトマネージャーが、自分たちの工程に合わせてウォーターフォールをどう調整するかによって大きく変わります。

ウォーターフォールに未来はある？

誕生から数十年たっても使われていますが、2000年代初頭からアジャイルが主流となった中で、ウォーターフォール型がいつまで有効なのか疑問に思うプロジェクトマネージャーもいるでしょう。

未来があることに疑いはありませんが、Alex RodovやJordi Teixidóなどの専門家は、プロジェクト管理の進化によって、ウォーターフォールとアジャイルを組み合わせた形が生まれると予測しています。実際、Royce自身が1970年の提案時にその歩みを始めたともいえます。論文の中で、段階的なテストやフィードバックの余地がない直線的なモデルのリスクを認めていたからです。

2016年、RodovとTeixidóは論文を発表し、両者を1つの主要な手法にうまく融合させるための提案をまとめました。ウォーターフォールは長年、誤った形で使われることが多く、その不適切な運用が、専門家によるアジャイルとの比較に大きく影響してきたと指摘しています。

両者を組み合わせたモデルでは、アジャイルのユーザーストーリーと、ウォーターフォール特有の要件重視の姿勢を融合させることを提案しています。また、最初にプロジェクトの範囲を定める際には、ウォーターフォール型の管理戦略を使うことを勧めています。ただし、この予測が実現するのか、それともプロジェクト管理が予想外の方向へ進むのかは、時間がたたなければわかりません。

これまでの仕事でウォーターフォール手法を使ったことはありますか？役立つと感じますか？下のコメント欄で教えてください。