Waterfallについて

mixiのマイミクさんから別件で、翔泳社さんの「開発の現場 Vol.9」を紹介してもらったのでパラパラと読んでいます。で、ちょっと気になったのが、特集「技術力アップの新常識」のコラムの一つです。というわけでご紹介。

ウォーターフォールは時代遅れ～ウォーターフォールは使い方次第
ウォーターフォールモデルの弊害はさまざまなところで指摘されています。しかし、このモデルが開発の現場でいまだに利用されているのはなぜでしょうか。それは、使い方次第で弊害を克服できるからです。本稿ではそうした、ウォーターフォールモデルを「いけるプロセス」に変身させるためのいくつかの工夫を紹介します。
翔泳社 開発の現場 Vol.9 より text:豆蔵 笠原規男

個人的には一部の分野(基幹系システムや、ミッションクリティカル度の極めて高いシステム開発)を除けばウォーターフォール型のシステム開発は不適切だと考えています。そう考える理由は2つです。
1つは現代に求められる(開発する)ITシステムが高度化し、人間系と密接に絡み合ったものとなったために最初の工程で全てを設計した上で開発する事が非常に高リスクとなった、という仮説です。取扱う問題が広い為に、少人数の担当者(エンドユーザ、システム担当者、開発者)が全てのシステムリスクを短期間につぶすことが困難であるため、段階的に開発せざるをえないと考えています。
もう1つはコストの問題です。ウォーターフォール型のシステム開発プロジェクトは、そのスケジュールの中で必要な要員スキルが大きく変化します。要件定義や設計フェーズでは「設計力」「ヒアリング力」などが要求されますが、開発実装フェーズでは「実装力」「技術力」、テストフェーズでは「テスト力」が要求されます。実際にそれぞれの局面で適切なスキルを持った要員を配置し、局面ごとに切替えていくのは非常に難しい。また、各局面の専門家どうしのコミュニケーションコストを考えただけでも頭がいたくなります。解決のためには要員体制を平準化する必要があるので、単純なウォーターフォール型開発は厳しいのではないかと。

というわけで自分のプロジェクトはだいたいフェーズ分割を行って段階的反復開発にしてしまうのですが、この本で書かれている「アーキテクチャ中心」アプローチは良さそう。ぜひいつか参考にしてみたいと思っています。

開発の現場 Vol.009

posted with amazlet on 07.09.28

SE編集部
翔泳社 (2007/07/12)
売り上げランキング: 46117

Amazon.co.jp で詳細を見る

ところでこのエントリを書くに当たってWeb上でウォーターフォールに関していろいろと検索してみたのですが、面白かったのがこれ。

Waterfall 2006 (日本語)
2006年に行われたWaterfall型開発に関するカンファレンスのようです。って、良く見ると内容が怪しい。セッションテーマがこんな感じなんですが……

• 超巨大プロジェクト: どのように遅らせるか - 決して完成しないだろうということを知られないために by Jutta Eckstein
• コラボレーションの排除: 一人で作業しよう by Jean Tabaka
• パターンからのアンファクタリング: 読みにくいコードで職を守る by Joshua Kerievsky
• テスト: 重要な工程を最後に実施する by Lisa Crispin

良く見ると開催日が2006/4/1、開催地はナイアガラの滝です。つまりエイプリルフールネタのジョークページなんですね。知らなかった。

参考：
はてなブックマーク タグ「ウォーターフォール」を含む注目エントリー