ウォーターフォールが持つ利点と欠点

 分析、設計、実装、テスト、という開発の工程(手順)を踏み、その間を仕様書というドキュメントで意図を伝える、いわゆる「ウォーターフォール」と呼ばれる従来手法のどこに問題があるのだろうか。

 スクラムを提唱したジェフ・サザーランドは、以下のように指摘している。

1.最初に、綿密な計画が作成される。計画では、最終製品が注意深く検討・設計され、そして詳細に文書化される。

2.計画を実施するために必要な作業が決定され、作業は「ガントチャート」や「マイクロソフトプロジェクト」のようなツールを使って作られる。見積は、展開された詳細見積の積算となる。

3.ステークホルダーが計画を詳細にレビュー・承認した後で、チームが開発に着手する。

4.チームメンバーは各自が担当工程を受け持ち、作業が完了すると次の工程の担当者に成果物を手渡す。

5.開発が完了すると、製品はいったん品質保証を担当する組織に納品される。そこで最終顧客への納品前にテストを行う。ここでは、最初の計画・設計どおりに作られていることを保証するために、全工程を通じて計画からの「ずれ」で管理される。

 このアプローチには、利点と欠点がある。利点は、非常に論理的である、ということだ。作る前に十分検討し、文書化し、計画に従い、すべてをできるだけ体系的に管理しようとする。しかし、このプロセスに「人間」が関与しているという欠点がある。この唯一の欠点のために多くの問題が起こる。

 たとえば、人の創造性を奪ってしまう。

 ウォーターフォールのアプローチでは、途中で計画外のよりよいやり方が見つかっても採用できない。すべてのよいアイディアは、プロジェクトの最初で計画化する必要がある。

 しかし、みんな知っているように、現実にはよいアイディアは工程の途中で見つかることが多く、ときには最終リリースの1日前に見つかることだってある。変更を認めないプロセスは、こういったイノベーションの機会を潰してしまう。ウォーターフォールにおいては、最後に見つかった素晴らしいアイディアは、幸運ではなく、むしろ脅威となる。

ウォーターフォール開発の仕事は「楽しくない」

 ひらめきのタイミングが悪くなる、という問題にも悩まされる。

 製品に触れたときに、はじめてよいアイディアが思いつくことはないだろうか? ちょっと触ってみると、具体的な改善点が20も思いつく。しかし不幸なことに、この重要なひらめきは、変更が難しい製品開発の最後の段階で起こる。別の言葉で言うと、この段階は、従来のウォーターフォール型開発では、変更が一番高価な「悪いタイミング」なのだ。

 このように変更を拒むプロセスからは、平凡な製品しか生まれない。