ソフトウェア開発のほとんどは「派生開発」

意外に知られていないことかもしれませんが，実はソフトウェアの開発現場では「新規開発」の機会なんて滅多にないといいます。開発のほとんどは「派生開発」だといわれています。「⁠派生開発」とは聞き慣れない言葉かもしれませんが，既存のシステムがありそれに対して

• 既存機能を使いやすくするための変更が加えられたり，
• いくつかの新しい機能が追加されたり，
• 前回のテストで発見しきれなかったバグや，対応を持ち越したバグが修正される

という開発プロジェクトを本書では「派生開発」と位置づけています。「⁠保守開発」などと近いかもしれませんが，まったく新しい機能を追加し5万行ものソースコードを新規に書いて新製品として出すようなケースでは，もはや「保守」という概念では捉えきれないでしょう。従来の「保守」に代わって適応範囲の広い「派生開発」という概念を提案しています。この派生開発は以下のような特徴があります。

• 要求は変更が中心で，機能追加を伴うことがある。いま稼働しているソフトウェアシステムに手を加えることになる
• 開発期間は2週間～6ヶ月と幅があるが，一般的に“⁠短い⁠”と認識されている
• 変更規模が小さいときは「一人プロジェクト」になることもある
• 新規開発されたときの担当者とは別の人が担当することが多く，他人が書いたソースコードに手を入れることになる
• 不完全な機能仕様書や設計資料しか残されていない（ときには，まともな機能仕様書も各段階の設計書もない）
• これまでの派生開発のなかで，当初の設計思想は崩されていることが多い
• 時間的にも技術的にも，“⁠全部を理解⁠”してとりかかることはできない
• 変更規模と関係なく，テスト期間は適切に確保しなければならない

このような特徴を持つ派生開発の現場で行われていることは，「⁠ここを変更してほしい」という要求に対して，ソースコード上で“⁠該当箇所⁠”を探し，見つけ次第に変更をしてしまうことです。つまり，新規開発のときのように「要求を確定し，そこで振る舞いとして必要な仕様を抽出する」という行為は存在しないのです。上記のような制限があるなかでは（特に納期の圧力は大きい⁠）⁠，いきなりソースコードを変更してしまいたくなるのでしょうが，その結果，派生開発のほとんどは「失敗」しているのが現状です。（⁠「⁠なぜいつも派生開発は失敗するのか」については本書でじっくりと解説しているのでご参照ください⁠）⁠。

「派生開発」に特化したプロセスとは？

このように「派生開発」の性質は明らかに新規開発と大きく異なるため，新規開発とは違った対応が必要とされます。そこで，「⁠派生開発」に特化した開発プロセスとして本書で提案するのが「XDDP（eXtreme Derivative Development Process⁠）⁠」です。著者が長年現場で培ってきたノウハウをまとめあげたこのプロセスによって，ほぼ100％「派生開発」は成功します（少なくとも，現在多くの現場に求められている「期限内に終了する」方法です⁠）⁠。

その大きな特徴は３つの成果物を作成することです。変更要求を「変更要求仕様書」にまとめ，変更箇所を「トレーサビリティ・マトリクス」によって特定し，変更方法を「変更設計書」に記述するのです。そして，それぞれの段階でソースコードの変更行数の見積りが行われ，レビューが行われます。実際にソースコードに手を入れるのは，すべてが確定した一番最後の段階です。

このプロセスにより，ソースコードの変更をむやみに急がせるようなやり方から脱却し，品質問題も納期遅延の問題も解決することができ，開発の現場で疲労するエンジニアはいなくなるでしょう。本書は，現場のエンジニアやプロジェクトリーダーはもちろん，変更案件を発する側の人や組織の上級管理者，CMMやソフトウェアのプロセス改善を推進している人達にも，大いに参考になると思います。ぜひ読んでいただきたい一冊です。