ウォーターフォール手法は厳格にも思われますが、これはこの手法が製造や建設などの非ソフトウェア業界におけるニーズに応えて生まれたという歴史的な経緯からくるものです。こうした業界では、プロジェクトのフェーズは順番に実行せねばならず、例えば、家の枠組みを作る前に乾式壁の塗装はできません。
したがって、ご想像のとおり、ウォーターフォールシステムには的確な計画立案が欠かせません。プロジェクトの要件を事前に明確にし、プロジェクトに関与する全員にその要因を周知させておく必要があります。また、チームメンバー全員がプロジェクトにおける各自の役割とその内容を理解していることも重要です。
これらの情報はすべて詳細に文書化し、プロジェクト関係者全員に配布する必要があります。チームメンバーは、プロセス全体を通して提供された文書を参照します。この文書を適切に活用すれば、期待事項が明確になり、プロジェクトのマイルストーンも示されるため、進捗状況を容易に把握できます。
ウォーターフォール型プロジェクト管理のフェーズ
ウォーターフォールの要件収集とドキュメンテーションの具体的なフェーズは出典により多少異なりますが、一般的に以下が含まれます。
1. 要件と文書を集める
この初期段階では、プロジェクトで必要となる情報を、インタビューからアンケート、インタラクティブなブレインストーミングなど、さまざまな方法で包括的に収集します。このフェーズが終わるまでには、プロジェクトの要件が明確になり、要件ドキュメントをチームメンバーに配布できるようになるはずです。
2. システム設計
要件が確立したら、最終製品を作成するために使用するシステムの設計に移ります。このフェーズではコーディングは行いませんが、プログラミング言語やハードウェア要件などの仕様をチームで決めていきます。
3. 実装
コーディングを行うフェーズです。開発者は前の段階からの情報を使って機能する製品を作っていきます。通常は部分ごとに分割した形でコードを実装し、このフェーズの最後または次のフェーズの最初の時点で統合します。
4. テスト
コーディングがすべて完了したら、製品のテストを開始できます。テスターが問題を体系的に見つけて報告し、重大な問題が発生した場合は、プロジェクトの再評価のために最初のフェーズに戻る場合もあります。
5. 提供/デプロイ
このフェーズでは製品が完成し、チームはデプロイまたはリリースする成果物を提出します。
6. メンテナンス
製品が顧客に納品され、使用されるフェーズです。問題が発生した場合には、パッチや更新を作成して対応する必要も生じます。ここでも、大きな問題が発生した場合には最初のフェーズに戻らざるを得ないこともあります。
ウォーターフォールモデルの利点
ウォーターフォール手法では、チームが一連のステップに従い、前のフェーズが完了して始めて次のフェーズへと進みます。比較的小規模で、成果物が最初から定義しやすいプロジェクトに適した仕組みです。
「The Digital Project Manager」の Ben Aston 氏はこう記しています。「ウォーターフォールは一般に、非効率的でトレンドから外れた旧式のプロジェクト管理アプローチとしてある種軽蔑されているが、要件が固定しており、十分文書化されて明確な場合や、対象のテクノロジーが成熟していてよく理解されている場合、また短期間のプロジェクトで「アジャイル」化することから得られる価値が特にないような場合には、ウォーターフォール手法が適していることもある。実際に、予算、タイムラインやスコープの点で、予測可能性が高い最終結果をもたらしてくれる仕組みである。」
では、ウォーターフォール手法の主なメリットについて詳しく見ていきましょう。
1. 構造がわかりやすい
他の開発手法と比較して、ウォーターフォールモデルは明確に定義された一連のステップに重点を置いており、構造もシンプルです。各プロジェクトは、前述の6つのフェーズを経て進められます。完了する上で何か障害があれば、すぐにそれが判明します。未完成のプロジェクトが仮置きのまま取り残されるリスクも低く、プロジェクト完了時の完成度や洗練度も高くなります。
2. 最終目標が早い段階で決まる
ウォーターフォール手法で特徴的な側面のひとつが、最初の時点で最終製品、目標や成果物にコミットするというもので、チームはそうしたコミットメントからの逸脱を極力避けます。目標が明確で小規模なプロジェクトの場合、このステップを踏むことでチーム全体が開始時点から全体的な目標を認識できるようになり、プロジェクトの進行につれて方向性が危うくなることを避けられ、この手法が有用となります。
チームに具体的な目標があり、期限もはっきりしているなら、途中で行き詰まることなく目標に向かって進める手法として適しているでしょう。
3. 情報をうまく伝達できる
ウォーターフォール手法のアプローチは非常に組織的であり、各ステップにおける情報の伝達でも明確さが重視されます。各ステップでプロジェクトを引き継ぐ際や予想外の異動が発生した際など、ウォーターフォール手法では情報へのアクセスを優先するため、チームに新しく加わったメンバーもすぐに馴染むことができます。
こうしたウォーターフォール特有のメリットを最大限に活かすには、プロジェクトが担当箇所まで進んだ際に各メンバーが完了している部分を確認できるよう、プロセスを文書化することことが重要です。
ウォーターフォールモデルの欠点
では、従来のウォーターフォール型開発手法の欠点は何でしょうか？
ウォーターフォールは定評ある手法ですが、時代遅れのモデルとして批判の対象ともなっています。プロジェクトの規模、タイプや目標によっては、その限界が特に目立ちやすくなります。こうした限界を事前に考慮し、チームに適した手法かどうかを検討しましょう。
1. 変更が難しくなる
ウォーターフォールモデルの利点の一つは、同時に欠点の一つでもあります。ウォーターフォールモデルはチームが常に前進し続けるための手順に従うことを基本としているため、従来通りの手法で実践すると予期せぬ変更や修正の余地がほとんどなくなります。
つまり、チームがプロジェクトのほぼ終盤までウォーターフォール方式の手順を忠実に踏襲してきたにもかかわらず、予期せぬ障害に直面してスコープや目標の変更が必要になった場合、方向転換は容易ではありません。プロジェクトのパラメーターが突然変更されると、それまでに行ってきた作業の多くが無駄になり、全体のタイムラインが狂ってしまう可能性があります。
2. 顧客やエンドユーザーが疎外される
ウォーターフォールモデルのもう一つの限界は、内部プロセスであるため、プロジェクトに関わるエンドユーザーやクライアントにほとんど焦点を当てていない点です。これは、その目的が、社内チームのプロジェクトにおける各フェーズの移行の効率化にあるためです。特定の業界においてはこれがうまく機能してきましたが、それ以外の業界では、顧客がプロジェクト中に関与し、意見を追加したり、プロジェクトの進行に合わせて要望を明確にしてくることもしばしばあります。
プロジェクトの目標が最初から明確で変更がなく、開発プロセスでエンドユーザーや顧客への状況説明が必要ないようであれば、ウォーターフォール手法がうまく機能するでしょう。そうでない場合には、変更に対応しやすく、プロジェクトの過程を通じてステークホルダーに絶えず情報共有を行うアジャイルフレームワークの採用を検討してみましょう。ステークホルダーを巻き込むことで、変更のリクエストが遅れ、プロジェクトの期限が守れなくなるリスクを軽減できます。
3. プロジェクトが完了しないとテストができない
テストは、従来のウォーターフォール型開発手法における最大の欠点の1つです。テスト段階をプロジェクトの後半まで残しておくのはリスクが高いのですが、ウォーターフォール型開発では、6段階中4段階目まで製品のテストを待つように指示されています。この段階では、プロジェクト作業にかなりの時間がかかっている可能性が高く、大規模な修正は大幅な遅延を引き起こす可能性があります。
ウォーターフォールのこうした原則に対応するために作られたのがアジャイル手法です。ウォーターフォールに対する批判には、プロジェクト完了間近まで問題が手つかずのまま残り、大規模で費用のかかる修正を行わざるを得ないという見方がありました。頻繁にテストを行う方がチームに適していると思われる場合には、プロジェクトの全段階の終了時点でテストを行えば、問題を残したまま次のステップへ進むこともなくなります。または、プロセス過程での振り返りと修正を奨励する別のプロジェクト管理手法を試してみるのもよいでしょう。
ウォーターフォールモデルの利点と欠点を理解する
その誕生以来、ウォーターフォール型開発手法には批判と支持の両方がありましたが、他の手法がその欠点を克服する形で進化を遂げた現在でも、依然として有効な手法です。チームの規模が小さく、プロジェクトが一貫性があり予測可能なものであれば、ウォーターフォール型はチームの組織化と進捗管理に理想的なフレームワークとなるでしょう。
そうでない場合は、プロジェクト管理手法を自由にカスタマイズして、ニーズに合ったものにしましょう。Lucid なら、チームとその独自のニーズに最適な構造を自由に作成できます。Lucid を使って、ウォーターフォールプロセスを始めとするあらゆる手法を視覚化しましょう。
