マネージメントに携わるようになってウォーターフォールにも理があると思うことが多い。（もちろん最適解ではないが。）
ウォーターフォール・反復に次ぐ、実践的な開発プロセスを検討したいとずっと思ってる。そんな検討をしていこうと思う。
ということで、語りつくされてはいるが「アジャイルかウォーターフォールか？」から考える。
アジャイルかウォーターフォールか？
アジャイルプロセスが提唱されてから既に数年、業界の多くの著名人がアジャイルを推奨し、多くの書籍が揃う。
アジャイルの考え方は、ウォーターフォールプロセスによる開発で「仕様変更」と「コストオーバー」、「スケジュールオーバー」に苦しめられてきた開発者達の、怨念にも似た声から生み出されたものだ。
エンジニアの視点から考えると理想的な開発の進め方のように思う。
しかしながら、やはり実際の開発現場は依然として、ウォーターフォール式の開発プロセスを採用するところが多い。
この背後にあるのは、なんだろうか。
それぞれのソフトウェア会社が不勉強というわけではない。
また、保守的な会社が多いと言う理由ばかりでもない。
エンドユーザーが非協力的というのも違うようだ。
私自身、マネージメントに関わるようになってウォーターフォールモデルを採用せざるを得ない理由が理解できた。つまりウォーターフォールモデルを採用するのはマネージメント上の理由からだと言える。
アジャイルと一口に言っても、その提唱内容は開発の進め方にとどまらず、
エンジニアの姿勢や考え方そのものまで多岐にわたる。
そのためここではウォーターフォールと対比するものとして、イテレーション開発に絞る。
イテレーション開発では、以下の点がマネージメント上のボトルネックになる。
- 1.全期間に渡って開発要員の確保が必要
- 2.要件の肥大化を招く
- 3.後工程でしか出来上がらない成果物を初期段階で利用しなくてはならない
（例えば、ER図やコンバートをかけた後の既存データ）
- 4.スケジュールとコストの見積が容易ではない
1.全期間に渡って開発要員の確保が必要
ウォーターフォールモデルの開発では、後続工程に進むにつれて要員に対する要求スキルが変わってくる。
要件定義では、業務アナリストのようなスキルが必要であるが、実装工程では、プログラミングのスキルが必要である。
つまり、要件定義工程が済めば基本的に業務アナリストの仕事は終わりで次の必要スキルをもったエンジニアにバトンタッチする。
※しかし、ここにSI業界の落とし穴があって、最終責任をとらないアナリストがやりたい放題やった要件定義をSIerに押し付けるという酷いプロジェクトもしばしば存在する。
エンジニアのみならず、ビジネスマンとしては、自分の仕事に責任はとらなくてはならないと思う。
ともかく、イテレーション開発では下流上流を問わず全種類のスキルパターンを持つエンジニアが揃っている必要がある。
持論として（また弊社の方針として）
「上流エンジニアは下流のスキルを兼ね備えているべきだ」
と思っている。アジャイルな時代になるにつれ、その傾向は強くなるだろう。
そんなことから、うちの会社に限って言えば、この点はそんなに大きな問題にはならない。
今後、我々のような思想を持つソフトウェア会社も増えてくると思う。
それにスーパーエンジニアがプロジェクトに1人いれば、初期の頃は何とかなるので、楽観視してもいいかもしれない。
2.要件の肥大化を招く
繰り返し開発では、要件が肥大化してコストオーバーになる傾向にある。
要求を提示する側の顧客の心理としては無理もないと思う。
要求に対してある程度動く物を見せられたら、よりイメージが具体化して更なる要求が湧きあがるのは当然だ。
そもそも、要求を余すことなく吸い上げるのがイテレーションの狙いである。
しかし「余すことなく」というのが曲者で、「なんらかのトレードオフがない限り、人間の要求に際限はない。」のが現実だ。
要求に対するトレードオフと言えばコストだ。
コストにあらない要求については、要件定義を行うエンジニアが顧客との要件定義作業のなかで食い止めるべきであるという意見もある。
しかしそうなると、顧客からしてみればワザワザ時間を割いて反復をしている意味合いが理解できない。
また、要件肥大化を防ぐことばかりに躍起になりだすと、
顧客満足度という本来のサービス業の原則から離れてしまうことに違和感もある。
3.後工程でしか出来上がってこない成果物を始めの頃から利用しなくてはならない
いまプロジェクトでDBAを担当していることもあって非常に強く感じるが、既存データの取り扱いが、企業システムの開発プロジェクトでは非常に大きな関心事である。
既存データの無い企業システム開発プロジェクトはない。
それは紙に印刷されたドキュメントかもしれないし、Excelのようなデータかもしれない。
RDBMSにデータが残されていたら幸いなほうだが、それでもデータ移行は長大な作業だ。
なぜなら、移行データと移行設計が新しいシステムのデータベースレイアウトに大きく関わるからだ。
つまり、要件定義するだけではなく移行設計まで落とし込まないことには、新システムデータベースレイアウトやER図は出来上がらない。
これらの完成は、ウォーターフォールモデルなら詳細設計ぐらいまで先送りにできる。
しかし、イテレーション開発では捨てるとわかっているDBを作らなくてはいけなくなる。
DBの変更はシステムの根幹であり、これを捨て、作りかけたアプリケーションだけを残すとなれば、システム開発は大混乱する。
ということで考えると、XPで提唱するように「作りかけたシステムは、ほとんど捨てる」方が混乱がないだけマシだ。
これが許容できるプロジェクトはどれだけあるだろう？
この点も大きな課題と言える。
4.スケジュールとコストの見積が容易ではない
私が感じる最大のポイントはここである。
システムは莫大なお金で作られているので、発注側・受注側にとって最も気になるのはコストなのである。
そして、システム開発のコストはほとんどが人件費でありつまり開発に時間がかかればかかるほど、コストは膨れ上がる。
スケジュールとコストはリンクしていて切り離せない。
その上、システムは全体像が目に見えない「要求」を扱う上に、「進捗」も「成果物」も全体像が見えにくい。
こういったものを扱うプロジェクトであるため、そもそも費用の見積は難しい。
予定外のリスクが顕在化すれば一瞬にして利益は吹き飛び、赤字プロジェクトになる。
かといって、リスクに見合う分だけの費用を発注側にお願いすることもできないことが多い。
競合他社に出し抜かれて、開発を受注できなければ仕事にならないからだ。
こういった状況下でオマケに「2.」で挙げたように、要求のボリュームも流動的なものになってしまうとお手上げだ。
この点が、ウォーターフォールモデルが生き残る最大のポイントだと思っている。
ウォーターフォールモデルでは、無理やりにでもフェーズを区切って後戻りしないことを理由にして要求を食い止め、どうしても必要なものは2次開発や3次開発として仕切りなおす根拠になる。
これを言ったときに、アジャイル志向な後輩は「そんなのはエンジニア側の傲慢を顧客に押し付けているんだ」と言った。
もっともな意見だと思う。
プロであれば、顧客満足度を最大にするべきだ。
そのため、このウォーターフォールモデルを採用する動機として「要求の肥大化を防ぐ」ことをあげるのは、「最低限失敗プロジェクトにしない。」というレベルの目標でしかないといえる。
しかし、その最低限のレベルすら守れていないプロジェクトも多い中、ウォーターフォールが残るのは無理もないのかもしれない。
私は、この状況をどうにかしたいと思っている。なんらかの提案はできないものか。
その検討は、一旦課題としてここでは問題提起のみとする。
