派生開発の混乱を救う「XDDP」
（eXtreme Derivative Development Process）
株式会社システムクリエイツ
代表取締役 清水 吉男
1．派生開発の問題
派生開発というのは、ある製品やシステム（のソースコード）をベースにして、新しい機能を追加したり、操作性などを改良して製品やシステムを作り上げて行く開発方法で、その過程で新しい製品やシステムの体系が生み出されることがあります。
派生開発のプロジェクトの特徴として、一人プロジェクトになるような小さな変更案件から数十人で対応するような大きな変更案件まであることです。開発期間が１ヶ月という短期間のものから１年以上のケースもあり、変更行数が５００行程度のものから１０万行に達するようなものまであります。
また、多くの場合、ソースコード上で該当すると思われる箇所を見つけ次第に変更しています。もともと変更要件の実現方法も複数あり、いずれの変更方法でもテストでは「正しい」と評価される可能性があります。でも担当者が気づくのは通常はその中の「１つ」です。しかも必ずしも適切な変更箇所が選ばれているとは限りません。
また、プロジェクト終了時の反省会では、相変わらず「全体を理解できていなかったから・・・」という声が出てきます。そしてそれで皆さんが納得しているのです。
でも
- 「全体」とはどの範囲ですか？
- 「理解」とはどの状態を言うのですか？
また、派生開発では下表のように新しい機能の追加に伴って問題が発生しているケースが少なくありません。これも派生開発の特徴です。
2．保守開発との違い
もともとソフトウェアエンジニアリングの世界には、「保守」あるいは「保守開発」というプロセスがあります。（JIS X 0160：ソフトウェアライフサイクルプロセス）
「保守開発」で想定しているのは、主にバグなどの「是正保守」や稼働後の環境の変化に対応するための「適応保守」であり、そのようなケースでは今でも「保守」のプロセスで対応しても支障はないと思います。
ビジネス分野においては、このようなケースが多いと思われますが、それでも最近は、新しい機能の追加なども伴うことが多く、変更要件が複雑になっていると思われます。
これに対して、組み込みシステムの世界では「是正保守」よりも、機能追加や性能の改良などを行って新しい製品として市場に出すというケースが多く、そこには「保守開発」という概念はありません。たとえば「携帯電話」が今日の｢ケータイ｣端末に変化（進化）する過程は「保守」では説明がつきません。パッケージソフトや流通などの制御システムでも、ビジネスの競争に勝つという要求に応えるために頻繁に機能の追加が行われています。
こうした中で、2008年にJIS X 0160が改訂され「緊急保守」と「改良保守」が追加されました。「改良保守」は主に機能追加など新しい要求への対応を想定しています。ただし、「是正保守」と「改良保守」では求められている「要求」が根本的に異なるという、新しい問題が生じます。
3．XDDPの考え方
「XDDP」は派生開発に特化した開発アプローチで、派生開発の特徴である「短納期」や「部分理解」の中での作業に対応しています。短納期の要求に対しては無駄のない合理的なプロセスで対応する必要があります。また「部分理解」に対してはいきなりソースコードを変更するのではなく、適切な成果物を生成して他の人のレビューを受ける機会を作ることが重要です。
「部分理解」に対応した開発アプローチによって手戻り作業が大幅に減り、結果として「短納期」を支援することにもなります。XDDPによって「Q」と「C」「D」を同時に手に入れることに繋がるのです。
また派生開発では、変更行数が少ないときは「一人プロジェクト」になるのはやむを得ませんが、「部分理解」の下で生じる思い込みや勘違いを防ぐ方法を講じる必要があります。XDDPの開発アプローチはこの問題にも対応できます。
「XDDP」は、下図のように「USDM」と「PFD」の２つの主要な技術に支えられています。
「PFD」 ( Process Flow Diagram ) は、今回の派生開発の要求（納期やコストも含む）を達成するために合理的な成果物とプロセスの連鎖を設計する技術であり、これによって手戻りが起きにくい開発アプローチを設計します。また途中での変化に対しても、開発アプローチの「別案」を考え出すための重要なツールなのです。
ただし、設計された開発アプローチの合理性を判断するには、そこに現れる成果物の構成などの定義とプロセスにおける作業の定義が必要になります。
一方「USDM」 ( Universal Specification Describing Manner ) の方は、今回の要求（追加／変更）を適切に表現し、そこから必要な仕様を引き出す方法を提供します。USDMは要求と仕様を階層関係の中で捉えますが、これはもともとモレが生じにくい構成です。そして要求に含まれる「動詞」をしっかりと表現することで、要求に含まれる「仕様」を引き出すテクニックを提供しています。
このようなUSDMの表記法によって、実際にベースライン設定後の仕様変更率が「１％」にまで押さえることもできています。
4．XDDPの特徴
XDDPの主な特徴を以下に列記します。
- 変更と機能追加をそれぞれ別々のプロセスで対応し、これらを並行させます
- そのため、変更要求仕様書と追加機能要求仕様書の２種類の要求仕様書を用意します
- 変更と追加の要求仕様書は「USDM」の表記法を用います
- 変更プロセスでは変更要求仕様書、TM ( Traceability Matrix ) 、変更設計書の「３点セット」の成果物を作ります
- 変更要求仕様や変更設計書はすべて「before/after」で記述します
- これによって、追加も含めてXDDPで生成する成果物はすべて「差分」になります
- 機能追加は追加機能要求仕様を作成すると同時に、それをベースのソースコードに受け入れるための変更要求仕様を対応させます
- ソースコードの変更は、すべての変更箇所と変更方法を明らかにしたあとで一斉に取り掛かります
- 機能仕様書や設計書などの公式文書は、テスト終了後に「差分」の情報によって更新します
もっとも重要なことは、「変更」と「追加」を異なるプロセスで対応することです。「追加」は通常の要求仕様書が必要で、その後の設計プロセスや実装プロセスも新規開発のアプローチが使えます。そこに現れないのはシステム全体の「アーキテクチャを設計する」プロセスぐらいです。
一方「変更」は、簡単なケースでは変更要件から該当箇所の当たりをつけてソースコード上で見つけて変更する、というプロセスも必ずしも否定できません。税率の変更などはこのような対応でも問題は生じないでしょう。
もちろん、変更要件の内容によっては、もっと緻密なプロセスが必要になります。たとえば現状のソースコードを解析して不足している設計書の記述を補いながら、関係箇所の相互関係の理解を進めたり、メモリーの競合やCPUの負荷の状況を検証したりしながら、最適な変更箇所を特定するといった方法も必要です。しかも、こうして見つけた「変更箇所」も担当者の思い込みや勘違いの可能性があり、レビューの機会を設けながら作業を進める必要があります。
XDDPでは、このように「追加」と「変更」の要求が異なることを考慮し、変更プロセスにおいて「変更要求仕様書」「TM（Traceability Matrix）」「変更設計書」の３種類の成果物（３点セット）の作成を勧めています。これらは「What」「Where」「How」の３つの視点から変更箇所の情報を表現しています。
「変更要求仕様書」は、変更要求に対して変更箇所を「変更仕様」として記述しますが、すべて「before / after」で表現することを求めています。「追加する」や「削除する」は、それ自身が「before / after」を内包している用語です。そこでXDDPでは「変更」も「現状の仕様」に対して「新しい仕様」を対峙して記述することで「変更」の意図を表現します。この副次効果として影響箇所の気づきを誘導し、変更の難易度や変更行数の見積もりも容易になります。
「３点セット」のポイントは、生成するタイミングが異なることです。従来は、変更要件ごとに
①該当箇所（変更箇所）を見つけて
②変更方法を考え
③その場でソースコードを変更する
という一連の作業が行われますが、XDDPでは①で変更要求仕様（とTM）を作成し、すべての変更要件に対して①の作業が終わった後にレビューを行い、担当者の思い込みや勘違いを除去してから②の作業に入って変更設計書を作成します。そしてすべての変更仕様に対して変更設計書を作成し必要なレビューを終えてから、変更設計書に沿ってソースコードを一気に変更します。
このように「３点セット」の成果物を作るタイミングが工夫されていることで、担当者自身でも思い込みや勘違いを除去できるのと同時に、それぞれの段階で関係者によるレビューを可能にしているのです。そして最後になって一気にソースコードの変更に取り掛かります。この一気呵成のソースコードの変更はXDDPの特徴の一つです。
こうすることで、複数の変更要件で変更箇所が重なるケースにも対応しやすくなり、従来のように何度もソースコードを変更し直す必要もなくなります。また別の変更要件の探索中に、既に対応した変更要件の対応方法で漏れていた箇所などに気づくこともあります。その場合でもまだソースコードを変更していませんので、より適切な情報に基づいて変更要求仕様を訂正できるのです。
5．XDDPの効果
XDDPの開発アプローチは適切な成果物を生成しながら作業を進めるため、途中で思い込みや勘違いに気づき易く、総じてバグは減ります。特に、複数人数で対応するケースでは、従来では各担当者が分担するソースコードを結合してテストに入ったところで、お互いの食い違いが元でバグが噴き出します。XDDPでは「３点セット」の成果物によって互いに変更箇所やその意図を確認する方法を提供してことで、テストで発見されるバグは大幅に減るのです。
また「一気にソースコードを変更する」というのもXDDPの特徴です。一般に上位のプロセスは要件の内容が生産性に影響を与えますが、実装プロセスは事前の準備さえ整えておけば個人の生産性データがそのまま適用できます。要件の内容に左右されることはありません。
XDDPでは変更設計書によって、すべての変更要件について具体的な変更方法まで記述していますので、ソースコードの実装工程は予定通りに進行します。ソースコードの同じ箇所を何度も変更することもありません。
従来の方法ではソースコードの変更に着手するのが早く、１時間あたりのコード生産性が「５行前後」というケースも少なくありません。その結果、２００００行の変更（追加も含む）に４０００時間（５人で４ヶ月）必要になります。
これに対してXDDPではコード生産性は一般に８０行～１００行に達します。
有効変更行数＝２００００行
担当人数 ＝５人
この結果、従来方法ではソースコードの変更作業を終えるのに合計５０００時間超の工数が必要になります。またその後テストに回されたところで２００件を超えるバグ（10件／KLOC）が発生します。さらに変更箇所の記録がないためにバグの対応に１０００時間超の手戻り工数（平均５時間／１件）が費やされます。
これに対して、XDDPでは「３点セット」の成果物を作りながら作業を進めますので、ソースコードの変更作業はわずか２５０時間、日程にして約１週間で終わってしまいます。つまり、３７５０時間（４０００時間-２５０時間）を投入して「３点セット」の成果物を作ってレビューすれば、わずか１週間余りでソースコードを変更できるということです。
実際には変更依頼から変更設計書に展開するのに「３７５０時間」を必要とせず、２割?３割ぐらいは余ります。この「２割」というのは従来方法では
- 変更作業を進める中で変更要件を依頼者に確認しなおしたり
- 何度もソースコードの同じ箇所を読み返したり
- 既に変更した箇所を読み返してその意図を思い出したり、さらに変更し直したり
している工数です。
XDDPの開発アプローチには「３点セット」があることでレビューなどによって思い込みや勘違いが相当数除去されますので、テストで発見されるバグも１／５～１／１０に減ります。上のケースでは３０件程度に減ると予想されます。さらに変更箇所の記録が残っていますので、バグの平均対応時間も半分に減り、手戻り工数は８０～１００時間程度で済むはずです。
こうして、従来方法で６０００時間を要していた工数が、XDDPでは３１００時間程度で対応できるということになります。実際にこれを裏付けるデータが多数上がっています。
