ウォーターフォール

一言でいうと

要件定義から設計、実装、テストへと工程を順に進める開発の進め方です。採用の場面では、求人票よりも候補者の職務経歴書で出会うことのほうが多くなります。

提唱者と登場年

この図式の最初の詳細な記述は、1970年のWinston W. Royceの論文に求められるのが通例です。ただしRoyce自身はその論文で、テストが最後にしか行われない点を欠陥として指摘しており、推奨する形として示したわけではありません。ウォーターフォールという語自体も論文には登場せず、1976年のBellとThayerの論文が初出とされます。

一次文書のPDFは公開元が限定的で、素のアクセスでは取得できません。ここでは書誌情報が確認できる二次資料を出典に置いています。

何を解決するか

工程を順に固定することで、計画と進捗を管理しやすくします。作るものが事前に確定していて、途中で変わらない領域では有効に働きます。契約や監査の要求で、どの工程で何を確認したかを文書で示す必要がある場合にも選ばれます。

裏返せば、要件が動く領域では弱くなります。後の工程で見つかった問題を前に戻して直す想定がないため、修正の費用が工程を下るほど大きくなります。

実際の進み方

各工程の終わりに成果物のレビューを置き、承認を得てから次へ進みます。要件定義書、基本設計書、詳細設計書といった文書が工程間の受け渡しになります。

現実には、純粋な形で運用されることは多くありません。工程を区切りつつ試作を挟む、テストを前倒しするなど、変形して使われるのが一般的です。

導入でよくある失敗

• 要件が固まらないまま工程を進める。後工程で戻れず、破綻が終盤に集中します
• 文書の作成が目的化する。承認のための書類が増え、判断が遅くなります
• テストを最後にまとめる。Royceが1970年の時点で指摘した弱点そのものです

求人票にこの語がある場合に読み取れること

この語に最も多く出会うのは求人票ではなく、候補者の職務経歴書です。受託開発や業務システムの出身者は中途市場の大きな母集団で、その経歴には工程の名前が並びます。

経歴書で読むときは、担当した工程の範囲を見てください。要件定義から関わったのか、詳細設計以降だけか、テストにどこまで関与したかで、任せられる仕事が変わります。工程が分業されている環境では、設計の判断を経験していない場合があります。

自社の求人票に書くときは注意が要ります。「ウォーターフォールからの脱却」と書くと、いま挙げた母集団に対して間口を狭めます。否定ではなく、これから何をするかで書いてください。

隣接手法との違い

関連キーワード

アジャイル / V字モデル / 要件定義 / シフトレフト