Waterfall について調査したことまとめ
Masashi Kondo所用でWaterfallについて調査する必要があり、雑に調べたことをまとめる。
Masashi Kondo書籍：The Fast Forward MBA in Project Management, 6th Edition / CHAPTER 4 Agile and Waterfall: Choose a Development Process
出版：2021/01
ざっくり項立て
- INTRODUCTION
- DEFINING VALUE: A NEW LENS FOR JUDGING PROJECTS INFORMS THE DEVELOPMENT PROCESS
- CHOOSE A PRODUCT DEVELOPMENT PROCESS THAT DELIVERS VALUE
- BEST PRACTICES FOR CAPTURING REQUIREMENTS ARE INTEGRATED INTO A PRODUCT DEVELOPMENT PROCESS
- A DEVELOPMENT PROCESS IS NOT PROJECT MANAGEMENT
- WATERFALL OR AGILE: WHICH DELIVERS THE BEST VALUE?
- COMMON AGILE PRACTICES
- COMMON AGILE BENEFITS
- CHOOSING BETWEEN AGILE AND WATERFALL DEVELOPMENT
- INNOVATION PROJECTS EXPERIMENT TO DISCOVER DESIRABILITY AND VIABILITY
- PRODUCT DEVELOPMENT METHODS INFLUENCE PROJECT MANAGEMENT
- END POINT
INTRODUCTION
本章では、
- プロジェクトの成功の定義を再検討し、プロジェクトが価値を提供するとはどういうことか、新たな視点を加える。
- 逐次フェーズを用いた従来の開発ライフサイクルと、ソフトウェア開発プロジェクトで普及しているアジャイル開発手法を比較する。
逐次フェーズを用いた従来の開発ライフサイクルというのがウォータフォールのことかな？
DEFINING VALUE: A NEW LENS FOR JUDGING PROJECTS INFORMS THE DEVELOPMENT PROCESS
IDEO Framework
IDEO というデザイン会社が作ったフレームワーク。以下３つのコンセプトがある。
- 実現可能性（Feasibility）
技術的に実現可能なソリューションであること。- 望ましさ（Desirability）
このソリューションを必要とする市場があり、人々はそれを望んでいる。- 実行可能性（Viability）
このソリューションは、持続可能なビジネスモデルの中で提供できる。
とても理解しやすく、従来の評価基準と対立しなくて良いらしい。詳細な解説は本書の第5章で取り扱うらしい。本章ではこれらのコンセプトを使って説明する。
CHOOSE A PRODUCT DEVELOPMENT PROCESS THAT DELIVERS VALUE
この章では一貫して「新薬開発プロセス」と「建設プロセス」の違いを説明している。
What Is a Product Development Process?
どの開発プロセスも基本的に「フェーズ（段階）」があり、それぞれでやることは大きく異なる。フェーズとフェーズの間に「フェーズゲート」と呼ばれる決定ポイントを設ける。その目的は以下二つ。
- その時点の品質を評価すること
- その時点で得られた新しい情報に基づいてビジネスケース（価値の方程式）を再評価すること
開発する製品に依り、開発のライフサイクルは大きく異なる。開発プロセスには製品に関する固有の課題が反映されるため。
資本建設のライフサイクルでは、実際の建設は1つの段階に過ぎませんが、その段階には費用の大半がかかります。資本建設では、設計に多大な投資を行います。設計段階で設計を修正するためのコストは、実際の建設が始まってからの手直しのコストに比べればわずかなものです。
この辺りは「Design It!/ Chapter3.2 Decide How Much to Design Up Front」あたりに通ずるものがありそう。
Benefits of a Consistent Development Process
開発プロセスでは、プロジェクトの各フェーズごとに標準的なWBSが用意されているのが一般的です。
共通のタスクリスト（WBS）があることで、計画がスピードアップし、品質保証も担保できる。また、全てのプロジェクトとタスクが同じ（構造の）WBSにあれば、タスクごとのコストの見積もりが容易になる。
第9章ではWBS、見積もりについては12章で説明とのこと。
A Development Process Addresses Feasibility, Viability, and Desirability
IDEO フレームワークについて
医薬品の開発プロセスでは、未知の部分が多いため、研究の初期段階では実現可能性を重視します。
上記に対し、建設プロセスでは Desirability と Viability が重視される傾向にある。通常の建築物は建設可能性（Feasibility）の限界を超えるものは無く、設計の複数フェーズで Desirability と Viability のバランスを考え、修正が安価なうちに設計を行うことが重要視されている。
BEST PRACTICES FOR CAPTURING REQUIREMENTS ARE INTEGRATED INTO A PRODUCT DEVELOPMENT PROCESS
ステークホルダーの望んでいることを明確に把握することは難しく、その理想的なアプローチは業界ごとに異なる。
革新的なデザインを提供するには、VoCと呼ばれる「お客様の声」を聞き取るプロセスがないと、非常に危険です。
自動車業界で、何が売れるかを把握するにはVoCプロセスが重要とのこと。
ソフトウェアや情報システムのプロジェクトでは、要求のジレンマをまったく別の方法で解決しています。要件を確実に定義することは非常に困難であるため、これらのプロジェクトでは不確実性を受け入れ、ソリューションの小刻みな生産を迅速に行い、顧客が評価できる具体的な製品を提供しています。
アジャイル開発のこと。
要件の収集と管理については、第22章で説明。
プロジェクトチームが優れた要件を決定することができれば、プロジェクトを開始したユーザーやその他のステークホルダーが当初想定していた価値を提供するソリューションが生み出される可能性が高まります。
A DEVELOPMENT PROCESS IS NOT PROJECT MANAGEMENT
WATERFALL OR AGILE: WHICH DELIVERS THE BEST VALUE?
この2つの開発戦略を検討する上で、最も重要な問いは「どちらのアプローチが最良の価値を提供するか」ということです。この質問を再構成すると、「どのアプローチが最も有用な製品を、最短時間で、最小コストで提供するか」ということになります。
Waterfall Is a Predictive Development Approach
ウォータフォール開発は「予測型」と呼ばれている。ライフサイクルの早い段階で、プロジェクトの範囲について明確な合意を得ることで、プロジェクトチームは信頼性の高いスケジュールと予算を立てることができる。
残念ながら、この開発プロセスを踏んだ多くの情報システムプロジェクトでは、明確な要件としっかりした設計ができるまでは、スコープの決定やコストの見積もりを正確に行うことができないことがわかった。
それはそう。
複雑な情報システムのプロジェクトでは、設計が完了する前に総予算の40〜50％が費やされてしまうかもしれません。その場合でも、情報システム・プロジェクトの建設段階の見積もりの精度は低いことが多い。
ウォータフォール型の予測手法は、プロジェクトのコストやスケジュールを予測するのには適していないとのこと。
Agile Frameworks Are Iterative
Masashi Kondoそういえば以前以下の記事を読んだことを思い出した。
改めて調べたら上記記事の著者が同期時の内容を短くまとめなおしていた。素晴らしい。