プロジェクト管理に携わっている人なら、ウォーターフォール手法に遭遇したことがあるに違いありません。これは、1970 年代から存在する昔ながらのソフトウェア開発手法です。
ウォーターフォール型のプロセスでは、各プロジェクト フェーズを完了してから次のフェーズに進む必要があります。とても厳格で直線的なやり方です。この手法は、始める前に決めた要件、行った検討に大きく依存しています。
この言葉を聞いたことがなくても心配要りません。ウォーターフォール手法の仕組みを詳しく見ていきましょう。
ウォーターフォール手法とは
ウォーターフォール手法は、確立されたプロジェクト管理ワークフローです。プロセスの各フェーズは、滝が流れ落ちるように、5 つのフェーズ（要件定義、設計、実装、検証、保守）を順番に進んでいきます。
この手法は、コンピューター科学者 Winston Royce のソフトウェア開発に関する 1970 年の研究論文に基づいています。このモデルを「ウォーターフォール」と名付けたのは Royce ではありませんが、彼は直線的で厳格なプロジェクト管理システムを作成したことで評価されています。
アジャイルなど他の手法とは異なり、ウォーターフォールには柔軟性がありません。1 つのフェーズを完了してから次のフェーズを開始する必要があります。問題を解決するまで前に進めないのです。さらに、プロジェクト管理の概要ガイドで概説されているように、次のプロジェクト フェーズに移ってしまうと、もうバグや技術的負債に対応できなくなります。
ウォーターフォール手法の各段階
ウォーターフォール手法は、要件定義、設計、実装、検証、保守の 5 つのフェーズで構成されています。ウォーターフォール型開発の 5 つのフェーズについて詳しく知り、各フェーズを完了してから次のフェーズに進むことがなぜ重要なのかを理解しましょう。
製品要件
要件定義フェーズでは、システムで何を実現すべきかを記述します。この段階では、会社に課されている義務からユーザーのニーズまで、プロジェクトのスコープを決定します。これにより、プロジェクト全体の高レベルの概要を把握できます。要件には以下を明記する必要があります。
- プロジェクトに必要な資源。
- 各チーム メンバーが何に、どの段階で取り組むのか。
- 各段階にかかる時間をおおまかに示した、プロジェクト全体のタイムライン。
- プロセスの各段階の詳細。
しかし、これらの要件は、「非常に抽象的なものから数値的な仕様が細かく記述されているものまで多岐にわたります」と、Old Dominion 大学のコンピューター サイエンス教授である Steven Zeil 氏は書いています。その理由は、要件には実装の手順を細かく記述しなくてもよいためです。そのような作業は、後から開発の段階で行います。
デザイン
すべての要件を定義したら、設計フェーズに移ります。ここでは要件を満たすソリューションを開発します。そのためには、以下を行います。
- スケジュールとプロジェクトのマイルストーンを作成します。
- 正確な成果物を決定します。
- 成果物の設計やブループリントを作成します。
成果物にはソフトウェアが含まれる場合もあれば、物理的な製品で構成されている場合もあります。たとえば、ソフトウェアのシステム アーキテクチャとユース ケースを決定します。物理的な製品の場合には、製造時の精密な仕様を作成します。
実装
設計が完成して承認されたら、次は実装です。設計者は開発者に構築すべき仕様書を渡します。
実装のために、開発者は以下を行います。
- 実装計画を作成します。
- 構築に必要なデータを収集し、調査を行います。
- チームに特定のタスクとリソースを割り当てます。
ここで、一部の設計は実装できないと判明することがあります。それが大きな問題なら、一歩下がって設計フェーズに戻る必要があります。
認証
設計のコーディングが完了したら、次は品質保証です。優れたユーザー エクスペリエンスを確保するには、すべてのユース ケースをテストすることが重要です。それは、バグのある製品を顧客にリリースしないようにするためです。
品質保証では以下も行います。
- テスト ケースを作成します。
- 修正すべきバグやエラーをすべて文書化します。
- 一度に 1 つの側面をテストします。
- どの QA 指標を追跡するかを決めます。
- さまざまなユース ケース シナリオと環境を網羅します。
保守
製品リリース後、バグの修正が必要になることもあります。顧客は、問題が発生するとサポート スタッフに報告します。その後、その要求に応え、製品の新しいバージョンをリリースするかどうかはチーム次第です。
ご覧のとおり、各段階はその前の段階に依存しています。フェーズ間またはフェーズ内のエラーはほとんど許容されません。
たとえば、検証フェーズで関係者が要件を追加したい場合、プロジェクト全体を再検討する必要があります。それはすべてを捨てて最初からやり直すことを意味します。
ウォーターフォール手法の利点
ウォーターフォール手法にも利点があり、そのおかげで決まった成果に依存するプロジェクトでは長年使用されています。2020 年の調査では、プロジェクトの専門家の 56% が前年に従来のモデル、つまりウォーターフォール型を使用していたことが判明しています。
ウォーターフォール手法での計画には、次のような利点があります。
- 明確なプロジェクト構造：ウォーターフォール手法では綿密に計画が行われるため、混乱の余地はほとんどありません。取り組んでいる最終目標がはっきり見えています。
- 決まったコスト：綿密な計画を立てることで、プロジェクトの時間とコストを事前に把握できます。
- 追跡しやすさ: 部門横断的な作業が少ないため、すばやく進捗を評価できます。Jira にあるガント チャートを使用してプロジェクト全体を管理することもできます。
- 複製可能なプロセス：プロジェクトが成功したら、同じような要件を持つ別のプロジェクトにそのプロセスを再び使用できます。
- 包括的なプロジェクト ドキュメンテーション：ウォーターフォール手法では、ブループリントや過去のプロジェクトの記録が作成されるので、プロジェクトの包括的な概要を把握できます。
- リスク管理の改善：事前に綿密な計画を立てるので、リスクが軽減され、コードを書く前に設計上の問題を発見できます。
- 責任と説明責任の強化：チームは各プロセスのフェーズ内で責任を負います。フェーズごとに、明確な目標、マイルストーン、タイムラインがあります。
- 専門家ではない従業員向けのより正確な実行手順：ウォーターフォール手法では、経験の浅いチーム メンバーでもプロセスに参加できます。
- 要件の追加による遅延の減少：ニーズを事前に把握しているので、関係者や顧客からの追加の依頼がありません。
ウォーターフォール手法の限界
ウォーターフォール手法にも限界があります。そのため、多くの製品チームがアジャイル手法を選択しています。
ウォーターフォール手法は、予測可能なプロジェクトでは大きな効果を発揮しますが、不確定要素や未知数が多いプロジェクトではうまくいきません。それでは、ウォーターフォール型計画の限界を見てみましょう。
- 納期が長い：アジャイルやリーンのような反復的なプロセスとは異なり、柔軟性のない段階的なプロセスを採用しているため、最終製品の納品には通常よりも時間がかかる可能性があります。
- イノベーションの柔軟性が限定的：予期せぬ出来事が起こると、プロジェクトは破滅的な影響を受ける可能性があります。1 つの問題が起こっただけでプロジェクトが 2 段階後退することもあります。
- クライアントからのフィードバックの機会が限定的：要件定義フェーズが完了すると、プロジェクトはクライアントの手を離れます。
- 大量の機能リクエスト：プロジェクトの実行中、クライアントはほとんど意見を言えないため、リリース後、既存のコードへの新機能の追加など、変更リクエストが殺到することがあります。これにより、追加の保守課題が発生し、リリースに長くかかる可能性があります。
- 期限が徐々に伸びる：あるフェーズで重大な問題が発生すると、すべてが滞ります。問題が解決するまで先に進めません。場合によっては、問題を解決するためには前のフェーズに戻る必要があります。
以下は、ウォーターフォール手法を使用したプロジェクトの図です。ご覧のとおり、プロジェクトは厳格な時間枠に分割されています。このような硬直性があると、開発者、製品マネージャー、関係者がそれぞれの時間帯にできるだけ多くの時間を割り当ててほしいと求めるようになります。後から反復する機会がないかもしれないからです。
ウォーターフォール手法とアジャイル プロジェクト管理との違い
アジャイル プロジェクト管理とウォーターフォール手法には、明確なプロジェクト実行という同じ最終目標があります。ウォーターフォール手法での計画ではフェーズごとに孤立して作業するのに対し、アジャイル手法ではプロジェクトの複数のフェーズにわたる部門横断的な作業が可能です。厳格な手順に従うのではなく、計画、実行、評価、そして反復のサイクルで作業します。
「アジャイル マニフェスト」では、ウォーターフォール モデルに対するアジャイルの利点が説明されています。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うよりも変化に対応を
アジャイル プロジェクト管理をサポートし、ウォーターフォールと同じ最終目標の達成に役立つツールをお探しの場合は、ぜひ Jira をご検討ください。アジャイル プロジェクトに最適なこのソリューションにより、次のことができるようになります。
- 作業の追跡: ガント チャート、Advanced Roadmaps、タイムライン、その他のさまざまなツールを使えば、プロジェクト全体の進捗を簡単に追跡できます。
- チームの連携: 追跡により、複数のビジネス チームが関与する計画をシームレスに作成し、全員が同じ目標に向かって足並みを揃えられます。
- プロジェクトとワークフローの管理: Jira では、アジャイル ワークフローに使用できる Jira プロジェクト管理テンプレートにアクセスできます。
- あらゆる段階での計画: アトラシアンのもう 1 つの製品である Jira Product Discovery は、ディスカバリーからデリバリーまでのあらゆる段階で製品機能を計画し、優先順位を付ける製品ロードマップを提供します。
アトラシアンのアジャイル ツールは、製品開発ライフサイクルをサポートします。追跡のためのアジャイル指標も用意されています。Jira ではアジャイル プロセスを進められます。情報入力フォームを使って社内のチームが進めている作業を追跡し、リクエストに対して繰り返し使えるプロセスを提供しています。
これらの Jira 製品はアプリ内でネイティブに統合されており、チームは団結して迅速に作業できるようになります。
プロジェクト管理にアジャイル方法論を使用
ウォーターフォール方法論はプロジェクト管理において長い歴史がありますが、現代のソフトウェア開発者にとっては必ずしも正しい選択であるとは限りません。アジャイル方法論の方が柔軟性に優れています。
ほとんどのチームがアジャイル プロセスを選ぶ理由は以下のとおりです。
- 変化への適応性: 何かが発生しても、チームがその場で適切に調整できるようになります。ウォーターフォールは固定されているため、すべての障害に対処できるとは限りません。
- 継続的なフィードバック ループ: 継続的な改善にはフィードバック ループが必要です。アジャイルなら、プロセス中に関係者からフィードバックを収集して反映し、それを繰り返していくことができます。
- コミュニケーションの強化: チームはアジャイル プロセス内でコラボレーションします。ウォーターフォールは、異なるチーム間で引き継ぎをしていくため、効果的なコミュニケーションが妨げられます。
ここで、Jira のようなプロジェクト管理ツールがアジャイル手法に役立ちます。アジャイル プロジェクトにはプロジェクト管理テンプレートも使用できます。チームはプロジェクトの計画、コラボレーション、実施、報告を 1 つのツールで行えます。これにより、どのようなプロジェクトでも全員の足並みが揃い、プロジェクト管理が合理化されます。
ウォーターフォール方法論: よくある質問
ウォーターフォール方法論に最も適しているのは誰ですか?
ウォーターフォール方法論は、次のようなプロジェクトに取り組んでいるプロジェクト マネージャーに適しています。
- それほど複雑ではない目標: 複雑な要件のないプロジェクトであれば、ウォーターフォールに最適です。
- 予測可能な成果: ウォーターフォールは、再現可能で実証済みのプロジェクトに最適です。
- プロジェクト スコープからの逸脱の可能性の低減: クライアントが最終的に要件を提示する可能性が低いプロジェクトは、ウォーターフォールに適しています。
ウォーターフォール方法論に最も適しているのは誰ですか?
アジャイル手法は、次のようなイテレーション思考の機敏なチームに最適です。
- 部門横断型チーム: プロジェクトのさまざまな側面に取り組むことができる、異なるスキルセットを持つ人々のいるチームです。柔軟性があり、コラボレーティブなタイプの人々で構成されています。
- 自己組織化チーム: 多くのサポートを必要としない、自律的なチームです。プロジェクトの曖昧さを受け入れ、問題解決にも優れています。この考え方では、結果に対する責任感も高く保たれます。
- スタートアップ企業と中小企業: このような企業は「即座に行動せよ、そして破壊せよ」という考え方を利用しています。そのため、迅速に失敗、学習、改善を進められます。
つまり、アジャイルはインプットによって反復が可能になる、顧客中心のプロジェクトに適しています。
プロジェクト管理アプローチを導入するには、どのような要素を考慮したらよいですか?
プロジェクト管理に実装する適切な方法論を決定する際には、プロジェクトの複雑さ、組織の目標、チームの専門知識、関係者の関与という 4 つの主な要素を考慮します。
それぞれの詳細を見てみましょう。
- プロジェクトの複雑さ: ウォーターフォールでは、大規模で複雑なプロジェクトを、細かい期待値と目標に分割できます。しかし、柔軟性がないため、未知のことや変化にはうまく対処できません。不確定要素の多い複雑なプロジェクトには、アジャイルが適しています。
- 組織目標: お客様の組織では何を達成しようとしていますか? 目指しているのは革新ですか、それとも現状維持ですか? サイロを解消したいのであれば、アジャイル方法論が最適です。チームはさらに自主的かつコラボレーティブに作業できるようになります。
- チームの専門知識: チームが部門横断型で、さまざまなスキルセットを利用して作業できる場合は、アジャイルが最適です。チーム メンバーが単一のスキルセットに大きく依存している場合は、ウォーターフォールのほうが適しているでしょう。
- 関係者の関与: 関係者がさらに実践的に関与するのであれば、継続的なフィードバックとイテレーションが可能なアジャイルが最も適しています。