継ぎ足し開発の恐怖
patchwork viaduct / paulhome
既存の商品に機能を追加して新しい商品を開発する時に、今あるソフトウェアのベースに新しい機能を追加する派生開発がよく行われます。
ソフトウェア開発を中途半端に理解している開発リーダーは、派生開発ではベースソフトのアーキテクチャをそのまま使えるのでアーキテクチャ設計は不要と思いがちです。そして、変更部分に新しいソフトを継ぎ足して、テストすれば開発は完了すると思い込みます。そのような理由からか、派生開発はかなり短い開発期間しか割り当てられないことが多いようです。
ソフト開発者もソフト全体は見ずに、変更部分だけのプログラムを作製しようとするので部分的な理解に陥りやすくなります。また、納期が短いので、影響のある範囲を調べずにいきなりコード変更に走るのでバグを埋め込まれやすくなり、テストの範囲も限定しますのでバグが検出されにくくなって行きます。
巨大なブラックボックスのシステムの表面に少しずつ新しい機能を継ぎ足していく、そんなそんなその場しのぎの開発を続けていくと、ソフトの品質が徐々に劣化が進むと同時に、システムの全容が誰もわからなくなります。やがて、大きな変更が必要になった時に、対応ができなくなります。
派生開発で設計をスキップするという先送り行為は、そのうちシステムの全容が理解できなくなるという大きな負債を招きます(ちょうど時限爆弾ゲームのように)
防止策としては
- 清水吉男さんのXDDP手法を取り入れる
- 1人で開発しないで、複数人のチームを編成し細かなレビューとテストを繰り返す。
- 派生開発の工数の中でベースソフトのリファクタリングを進めていく。
などが有効です。新規開発以上にしっかりした戦略が必要ですし、新規開発とは違ったスキルが必要です。
posted with AZlink at 2014.2.20
清水 吉男
技術評論社
売り上げランキング: 172624
技術評論社
売り上げランキング: 172624