機能追加型開発
プログラムをすべて新規開発するプロジェクトは、いまやほとんどない。コンピュータは、あらゆる部門にすでに導入済みである。相互に接続する。接続を変更する。一部を更改する。新しい機能を追加する。このような開発パターンが大半である。
しかし、プロジェクト管理の教科書に機能追加のケースを扱ったものは、なかなか見あたらない。機能追加用にカスタマイズした管理手法を、プロジェクト管理の専門家が用意していない。見積もり方法、進捗管理方法、品質管理方法など、あらゆる面で配慮が必要と、皆口を揃えるのだが。
たとえば、機能追加部分の規模だけで見積もっては不足する。1KLの母体に1KLを追加するケースと、100KLの母体に1KLを追加する工数が同じわけがない。母体の複雑さに加え、難易度や要求される品質が大きく影響する。追加部分と母体の間の結合度が小さければ、つまり追加部分が独立していれば、母体のデグレード試験を少なくできる。
しかし、同じ1KLの追加でも、母体のあちこちに細かく追加の手が入るパターンでは、母体の既存機能がデグレードしていないか、多くの試験工数が必要となる。交換機は後者のパターンであった。デグレード試験の大半を自動化したものの、平均してみると、なんと9Lの追加修正で１項目試験するというすさまじさであった。交換機のプログラムは、少ないメモリの中に詰め込まれており、また性能重視のために非常に最適化していたことが原因だ。
言い換えれば、メモリ量や性能を犠牲にすれば、結合度の低いソフト構造が可能となり、機能追加時の試験を減らすことができる。理想は、母体規模に依らず、1KLの追加が1KLの新規開発と同等になることであろう。
多くのミドルウェアやフレームワークが目指す理想だ。基本機能はこれらが提供し、差分だけ機能追加する開発パターンだ。母体とのインタフェースがポイントだ。習得のハードルは低くないが、一度習得してしまえば、新規に近い。
