ウォーターフォール法の歴史
Waterfall は、計画、構築、テスト、リリースを順番に行う論理的なパターンです。ウォーターフォールの歴史は、ウィンストン・W・ロイスの 1970 年の「大規模ソフトウェア システムの開発を管理する IEEE WESCON の論文集」の記事に由来します。Royce の記事はおそらくソフトウェア開発における Waterfall の最初の議論でしたが、「waterfall」という言葉は記事のどこにも表示されません。正式な用語は、トマス・E・ベルと T.A. で導入されました。Thayer の 1976 年の論文は、ソフトウェア エンジニアリングに関する第 2 回国際会議論文集、「ソフトウェア要件: それらは本当に問題ですか?」から取られたものです。しかし、多くの場所で知られていたように、Royce の論文はその方法を賞賛していませんでした。実際、彼はそれを不器用な言葉で説明し、欠陥があり、多くの点で失敗を招いていると述べています。彼はその後、おそらくアジャイル アプローチの基礎となる、より反復的な アプローチについて話しました。
Bell 氏と Thayer 氏の論文では、MIL STD 490/483 (MIL STD 490では仕様慣行について、MIL STD 483 ではシステムの構成管理プラクティスについて説明しています) でのこのアプローチの採用を参照しながら、ソフトウェア要件の開発におけるアプローチのボトムアップからトップダウンへの変更について説明しています。この論文は主に、どのアプローチが最も適しているかを判断するために、経験的にアプローチを調べることに関心を向けています。最終的に、論文は「過去 10 年間でより多くの構造と規律が採用され、実務家はトップダウン アプローチが過去のボトムアップ アプローチよりも優れていると結論付けた」と宣言しています。「ウォーターフォール」という用語は、ウィンストン・ロイスの論文を直接参照して使用されます。
Royce が説明した欠陥にもかかわらず、Waterfall は 1985 年に国防総省が防衛システム ソフトウェア開発局のdod - std - 2167 aを発行した際に好ましい方法となりました。ソフトウェア開発サイクルは次のように説明されています。
- ソフトウェア要件分析
- 予備設計
- 詳細なデザイン
- コーディングとユニット テスト
- コンピューター ソフトウェア コンポーネント (CSC) の統合とテスト
- テスト
フォワードは、「この標準は、急速に進化するソフトウェア テクノロジー分野にダイナミックで応答性を発揮することを意図しています。そのため、この標準は、各ソフトウェア獲得プログラムの独自の特性に合わせて選択的に適用され、調整される必要があります。しかし、要件は白黒でレイアウトされ、宗教的に続きました。
Waterfall 手法は、業界のリーダーがその柔軟性に不満を抱き、アジャイル マニフェストを開発した際に、一般的な使用から消え始めました。それ以来、アジャイルを採用する企業が増えていますが、多くの企業はまだ Waterfall にしがみついています。そして正当な理由があります。Waterfall には欠点がありますが、その利点もあり、適切な環境ではベスト プラクティスです。
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
View the guide
Waterfall プロジェクト管理のメリット
Waterfall に対するすべての批判には、その実装にはいくつかの本当の利点があります。
- シンプルでストレートなアプローチです。
- すべてのフェーズに開始と終了があるため、Waterfall プロジェクトを管理するための計画を立てるのは簡単で、何を開発すべきか、いつ、いつテストを開始するのかなどをコーディングする前に知っています。
- 早期計画は、外部システムと統合するコンポーネントを設計するための優れた基礎となります。
- Waterfall のリソースを計画するのは簡単です。なぜなら、すべてがいつ始まり、終わるのかがわかります。
- 決定的な開始日と終了日を求めているクライアントは、Waterfall が安心できるということを知ることができます。顧客は製品を手に入れる日を伝え、プロジェクトが Waterfall アプローチに適している場合は、その日に納品されます。
- 開発コストは事前に決定できます。
- 詳細な手順は、プロセスのすべての部分を規制するために使用できます。
- Waterfall のデザイン重視のアプローチは、開発に対する規律正しいアプローチを強制し、期待を明確にします。
- チーム メンバーは、フェーズが始まる前またはフェーズが終了した後に、必要に応じてプロジェクトに戻って、他のプロジェクトに参加できます。
- 設計ドキュメントに依存することで、開発者の離職によるストレスを軽減できます。
- 設計が重いアプローチは、設計フェーズでエラーが発見できることを意味します。これには明らかな落とし穴があり、Waterfall メソッドで作業した人は誰でもデザイン エラーが発生することを知っていますが、経験豊富なチームを取って計画をまとめると、多くの場合、計画に従って実行できるしっかりとしたデザインが得られます。
ウォーターフォール プロジェクト管理の欠点
Waterfall の最も懸念事項と批判の一部を次に示します。
- 大規模なプロジェクトでは、リリースまでの時間が非常に長くなります。Royce の論文は、小規模で社内のプロジェクトに関しては Waterfall に親切でしたが、より大規模で複雑なプロジェクトでは非常に欠陥があると考えていました。実際、アジャイルが人気を高めている主な理由は、おそらくこれが原因です。大きすぎるプロジェクトは、Waterfall メソッドを使用して完了する前にキャンセルされました。
- Waterfall の第 2 の主要な批判は、変化が歓迎されないということです。テストが始まったら、開発に戻ったり、プロジェクトを再設計したりするのは非常に費用がかかります。デザインは、行き過ぎる前に慎重かつ正しく書く必要があります。
- 作業ソフトウェアはプロジェクトの後半まで表示されません。
- プロジェクトの早い段階で書かれたバグは、後のコードに大きな問題を引き起こしますが、テストが始まるまで明らかになることはなく、コードの修正に費用がかかり、時間がかかります。
- オブジェクト指向のアプローチではありません。Waterfall プロジェクトは非常に統合されています。これは、柔軟性を低下させる Waterfall のもう 1 つの側面です。
- メンテナンスやその他の種類の長期プロジェクトには適した方法ではありません。
- 前述の批判と密接にかかわってるのは、プロジェクトが始まる前に顧客が何を求めているのかわからないことが多いということです。
- チームが経験の浅い、または未知の海域に入っている場合、障害が発生し、プロジェクトが危険にさらされているように見えます。
- スケジュールを維持するためにテストは短く変更される可能性があり、製品の納品後に顧客がバグを発見する必要があります。
- イベントによって、プロジェクト全体が強制的に廃止される可能性があります。たとえば、開発フェーズ中に発生する業界の変化により、プロジェクト全体が時代遅れになる可能性があります。もう 1 つの出来事として、設計上の欠陥が非常に深刻で、プロジェクト全体が再設計に戻る必要があり、顧客がプロジェクトを拒絶するコストがかかる場合もあります。
ウォーターフォールとアジャイルの比較
Waterfall はプロジェクトの設計フェーズに焦点を当て、Agile は設計に最小限の時間を必要とします。どちらのプロジェクト管理オプションも作業ソフトウェアの提供を目指していますが、Waterfall プロジェクトは通常、年に 1 〜 2 回 (またはそれ以下の頻度で) リリースを提供し、Agile は週に 1 回の頻度で動作するソフトウェアを提供できます。Waterfall での納品は大きく、長期間のテストが必要な場合があり、多くの企業も顧客を使用して β テストを行っています。アジャイルはソフトウェアの構築時にテストを行い、開発者は多くの場合テストを実行します。
Waterfall と Agiry の大きな違いは、Waterfall は方法論ですが、Agile は Agir の原則と価値を適用するさまざまな派生手法を持つ「動き」であるということです。Scrum、eXtreme プログラミング (XP)、カンバン、スクラムバン、その他の多くの方法で開発チームのオプションが可能であるため、その中に最適な選択肢があるかもしれません。
アジャイル手法は、クライアントが要件について不確実だったり、開発プロセスに密接に関与したい場合や、タイムラインが短く、迅速な納品が必要な場合に優れた選択です。複雑な依存関係がある場合は Waterfall が優れていますが、依存関係が最小限の場合は Agile が好ましいです。アジャイルは、品質よりもスピードが重要な場合にも最適です。
Agile のデメリットは次のとおりです。
- 顧客の関与が必要
- コストとタイムラインが不確実
- 計画は難しい
- 最終結果に対する明確性の欠如
- 最小限のドキュメント
- チーム メンバーは部門を超えていなければならない – 不慣れな役割に関する経験がない人もいる
- 開発者は単一のプロジェクトに専念している
- スコープ クリープはリスクであり、プロジェクトが変更を歓迎すると、制御できない状態に成長し、期日を超えて実行される可能性がある
Agile が Waterfall から劇的に逸脱するという考えは、完全に真実ではありません。アジャイル アプローチは、実際には調整された Waterfall アプローチの多くであり、変更に対する抵抗と長い納品日の面で Waterfall のデメリットの一部に対処しようとします。柔軟性の欠如とキャンセルされたプロジェクトの割合が高いため、多くのチームが Waterfall からアジャイルに切り替わりました。しかし、Agile はまだシーケンシャルなアプローチを取り、より短い順序を使用していることを理解することが重要です。アジャイルには最初にいくつかの要件分析とデザインが含まれていますが、コーディングは要件と設計が完了するまで開始されず、書き込まれていないコードや、テストおよび統合されていないコードをテストすることはできません。したがって、Agile は、より柔軟で迅速な Waterfall プロジェクト管理の形と考えることができます。
アジャイル手法を使用して、次のプロジェクトのヒントとベスト プラクティスを紹介します。
アジャイル プロジェクト管理について知っておくべきことと、Agile PM のベスト プラクティスの導入を開始するのに役立つヒントをすべて学びましょう。
プロジェクト管理に Waterfall メソッドを使用するタイミング
Waterfall と Agile の間で決定することは、プロジェクトの特徴と顧客のニーズを調べることです。特に、プロジェクトの要件、目標、目的に細心の注意を払います。ウォーターフォールは、多くの場合、次の場合に優れた選択です。
- 要件はよく理解されており、変更される可能性は高くはありません。
- 顧客は厳しい変化を起こしやすいわけではありません。
- 顧客は開発に関与しないことを好みますが、最初に相談し、プロジェクトの終わりに作業パッケージを受け取りたいと考えています。アジャイルは、顧客がすべてのフェーズ (イテレーションのたびに製品のレビュー) に関与している場合に最適ですが、Waterfall のお客様はリリースを受け取ってインストールするだけで済みます。(注: これは簡素化です。また、顧客はシステムの使用に関する教育を受ける必要があり、それは長く重要なステップになる可能性があります。これは、使用する方法に関係なく同じであり、大規模なリリースで新しい機能に関するユーザーの教育を年に 1 回または 2 回行う方が、より小さな機能セットで顧客を毎月または毎週教育するよりも、侵入しにくい場合があります。また、関与したい顧客は Waterfall ベースのプロジェクトに参加できます。顧客に頻繁にレビューしてもらうと、気が散る可能性があり、不要な変更リクエストにつながる可能性がありますが、プロジェクトは顧客のニーズを満たすことに集中できます)。
- プロジェクトは小さいです。
- 納品のスピードは重要ではありません。
- 納品は、変更を起こしにくい従来のシステムに適用する必要があります。
- 将来的には同様のプロジェクトがあり、プロジェクト計画の再利用が可能になり、前のプロジェクトの重い文書から教訓を得ることができます。
トップ プロジェクト管理手法の概略
ウォーターフォールは、多くの競合する手法の 1 つにすぎません。一方または他の実装を決定する際には、それらが何であるかを考えるのに役立ちます。以下に、現在使用されているプロジェクト管理のトップ手法を簡単に紹介します。
Waterfall
The Waterfall 手法は、一般的にプロジェクト管理に対する従来のアプローチと見なされます。Waterfall は、プロジェクトの 1 つのフェーズが別の始まりの前に終わるという、順番に起こっているすべての概念に基づいていました。これにより、多くの依存関係が発生し、ソフトウェア開発にとってかなり悲惨な状況が発生しました。プロジェクトは、多くの場合、スケジュールの遅れや予算超過、場合によってはテクノロジーの急速な変化によって完全にキャンセルされました。
クリティカル パス法 (CPM)
CPM 法は、各ステップが前のステップの完了に依存していると仮定する別のシーケンシャル メソッドです。CPM プロジェクトの計画段階では、リソースを割り当て、ボトルネックを回避するために、プロジェクトの最もリソースの多い部分を特定することです。このメソッドの適用は次の方法で行われます。
- 必要なタスクを特定し、それを完了するための順序を定義する。
- 必要なタスクの依存関係を定義する。
- タスク間で重要で、重要ではない関係を決定する。
- 各タスクに期待されるタイムラインをスケジュールする。
- クリティカル パス用の計画 B を作成する。
クリティカル チェーン プロジェクト マネジメント (CCPM)
Waterfall はデザインに重点を置き、CPM はタスクに重点を置いていますが、CCPM はリソースとリソースの割り当てに重点を置いています。CCPM は、タイムライン、コスト、パフォーマンス、納品不足のリスクに影響を与える可能性のある要因に集中しています。CCPM のアプローチは、問題が発生した場合にタイムリーに納品できるように、クリティカル チェーンを定義し、最も優れた作業を行うことができるリソースを適用し、最終的に重要なタスクにタイム バッファを導入することです。
PMI PMBOK®ガイド
PMI PMBOK®ガイドのプロジェクト管理方法は、PMI の 5 つのプロセス グループをテキスト「プロジェクト管理知識体系ガイド」から適用します。これらのグループの大まかな概要を次に示します。
- 開始 — ビジョンを設定します。これは、プロジェクトマネージャーが選択されているプロセスグループでもあります。
- 計画 — 範囲を設定します。PMBOK では、計画段階で 24 のプロセスについて説明します。
- 実行 — 計画を実行に移します。
- 監視と制御 — これはプロジェクト全体の間に発生し、別のフェーズが終了するまで待機するシーケンシャル フェーズではありません。
- 終了 — 顧客がプロジェクトの承認に同意した場合に発生します。
アジャイル手法
アジャイルは、方法論ではなく、動きとして定義されますが、アジャイル手法のファミリーは、アジャイルの価値と原則に従って開発されています。
Scrum
Scrum メソッドには、Scrum マスターが率いる小さなアジャイル チームがあります。Scrum マスターの役割は、チームの仕事を促進することです。計画は最小限に抑え、作業するタスクのリストが作成されます。タスクは通常 2 ～ 4 週間の「スプリント」で動作します。毎日の簡単なミーティング(デイリースクラムと呼ばれる)は,その日のタスクを乗り越え,障害を特定するために開催されます。チーム メンバーは、プロジェクトのすべての従来のタスクを実行し、進むにつれて設計し、タスクを完了する際にテストします。Scrum の目標は、動作するソフトウェアを引き継げることです。1 つの Sprint が終了すると、次のスプリントが始まり、チームはプロジェクトのバックログから一連のタスクを作成します。プロジェクト全体の目標が達成され、タスクがなくなったら、プロジェクトは完了します。
Kanban
カンバン方法は、メンテナンス プロジェクトに最も適しています。Kanban メソッドの中核となるのは、継続的に更新され、すべてのチーム メンバーに簡単に表示される、実行されるすべてのタスク (カンバン カードとも呼ばれる) のリストである Kanban ボードです。リソース (チーム メンバー) が利用可能になると、そのチーム メンバーはボードからタスクを受け取り、それに取り組みます。タスクはボードに追加され、継続的に作業されます。プロジェクトの開始または終了が定義されていない。
エクストリーム プログラミング (XP)
スプリントは通常 1 週間の長さで、多くのイテレーションが行われます。XPで は変更が重要であり、XP プログラマーは関係者と緊密に連携しています。XP は要件が絶えず変化している環境に最適です。タスクは Sprint の途中で置き換えることができます。
アダプティブ プロジェクト フレームワーク (APF)
APF は、IT プロジェクトは非常に大きく異なり、誰のアプローチも意味をなさないと仮定しています。IT プロジェクトはリスク、コスト、長さ、複雑さが異なり、多くの場合、市場、ビジネス価値、顧客関与、目標に不確実性が伴います。したがって、APF プロジェクトは、戦略的目標を定義するための要件の分析から始まります。プロジェクトは反復的に実行され、ポストモーテムはイテレーションの後に実行され、プロセスを改善します。通常、分析は進行中であるため、プロジェクト全体を不確実性の問題に対応して再定義または適応させ、ビジネス価値を維持または増加させます。
リーン
リーンは、無駄を減らし、価値を最大化することを目的としています。リーンの中核となる価値は、継続的な漸増的な改善と人々への敬意です。リーンは、顧客に最も価値を提供し、フローを維持し、作業を均等に割り当てること、そして何よりも無駄をなくすることに重点を置いています。
シックス シグマ
シックス シグマは、効率的なプロセスとプロセスの継続的な改善を通じて、開発における欠陥を排除することです。シックス シグマの評価は、製品に欠陥がない 99.99966% であることを意味します。シックス シグマの評価を受けたプロセスがある場合、それらの製品を介して提供されるすべての製品が同じ結果を達成することが期待できます。
リーン シックス シグマ
リーン シックス シグマは、リーン シグマとシックス シグマのアプローチを組み合わせて、プロセスをより効率的にするための無駄を排除し、高い価値と低い欠陥を顧客に提供しようとします。
プロセスベースのプロジェクト管理
プロセスベースのプロジェクト管理では、各プロジェクトを企業のミッションと価値に合わせることに重点を置いています。プロジェクトは企業戦略に組み込まれます。その結果、指標など、プロジェクト分析の従来の側面は、その目的がどれだけ達成されるかを判断するために使用されます。
PRINCE2
Prince2メソッドは、あまり成功の少ない PRINCE 法に基づいています。PRINCE メソッドは扱いにくいため広く採用されず、1996 年に 150 のヨーロッパの組織で構成される委員会によって PRINCE2 に改訂されました。PRINCE は IT コストと時間の超過を削減することを意図していましたが、あらゆる種類のプロジェクトのプロジェクト管理手法としても開発されました。PRINCE2 は 2009 年に大幅な改訂を行い、この方法を簡素化し、プロジェクト成功の 7 つの基本原則を導入しました。
持続可能な方法を統合するプロジェクト (PRiSM)
PRiSMは、社会的責任のあるプロジェクト管理に重点を置いています。その目的は、環境への悪影響を減らし、社会的に有益なプロジェクトを促進しながら、プロジェクトを管理することです。
メリット実現
メリット実現方法は、すべて顧客についてです。この方法は、最初から最後まで、コストやタイムラインを超えて、顧客が成果物から最大の利益を得られるようにすることを目指しています。
多くのプロジェクト管理方法は多くの機会に等しい
プロジェクト管理の世界には多くの方法があります。ほとんどの人は、新しいアプローチやさまざまなニーズを中心に成長しており、ソフトウェア業界がより複雑 (さまざまな方法や言語) になり、コードの書きやすさも向上しました。しかし、プロジェクト管理の古い方法は、Waterfall 手法でプロジェクトを開発している企業によって証明されているように、依然として適切な環境で価値を保持しています。多くのお客様は、開発に合意する前に何が必要で、いつ行われるかを知りたいと考えています。重要な情報がなければ、成果物にビジネス価値があるかどうかをどのように知るでしょうか?
Smartsheet が Waterfall プロジェクト管理に強力なツールである理由
シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。