◆反復型開発の落とし穴
最新のシステム構築スタイルとして、「反復開発」や「アジャイル」というものがある。要求仕様が決まったところからシステムを部分的に構築し、早期に使用を開始する。そして、次の要求を決めて、また、開発して、使用を開始する。こういった、要求仕様確定・開発・使用開始という短いサイクルを反復してシステム構築を進める手法である。
背景には、前述の業務改革型や創造型のシステム構築では、具体的な仕様が決まらず、また、例え決めたとしても、従来のやり方では、仕様変更が多発し手戻りが生じて効率が悪いということから発生した手法である。インターネット・ビジネスのＷｅｂサイトなど、要求仕様が最初から明確化できないシステムの構築に良く使われている。
問題は、プロジェクト全体のコスト・納期・品質をコントロールすることが難しいことである。決まったところから開発する場合、たいてい分かりやすい目に触れる部分から開発が始まる。システムの裏側で動く、データベースなどは、なかなか決まらないので後回しになる。その場合、肝心の基幹部分を開発する予算を使い切ってしまったらどうなるのか、とか、これまで開発済みの部分が、大幅に手直しが必要になったらどうするのかなど工夫の余地がある。
著者は、生産管理システムなどの基幹業務システムの構築には、反復型開発は向かないのではないかと見ている。理由は、上記のプロジェクト管理の困難さもあるが、そもそも、この反復型の考え方は、これまでの既存システムの保守そのものではないのか。（最近はDevOpeと言うらしい。）長年の反復開発を積み重ねた結果、システムが混迷し、誰も手が付けられなくなったレガシシステムとして揶揄されている。それと同じことが起こる可能性がある。反復型開発では、そうならないように工夫がされているが、それを確実に実行できるかどうかは、開発チームの能力にかなり依存する。これがうまく機能するならば、レガシ・システムなどという言葉は生まれていないはずだ。現場の大多数のプログラマは、保守をすればするほど、システムを複雑怪奇にしてしまうというのが著者の経験則である。業界では、これを「保守地獄」と称しているが、反復型開発では、いつ終わるかも知れぬ「反復地獄」という、落とし穴がまっているかもしれない。
反復型開発手法を用いる場合、あるいは業者が使用する場合、全体のコスト・納期・品質を、どうやってコントロールするのか、その見通しを十分確認した上で採用されたい。うまく活用できれば、最小の投資で、最大の効果を生むシステム構築が、短期間で可能となるかもしれないが、失敗すれば、止め処ない反復開発と、コスト・納期の超過、ツギハギだらけの劣悪な品質のシステムが待ち受けている。そして、これに関わった人々も疲弊してしまう。そうならないためには、やはりフロントローディングで、全体の要求仕様をしっかりまとめた上で、「２：４：２：３の法則」で述べたように、不足分のみを追加開 発することをお勧めする。
コメント