プログラマの思索

清水吉男さんの「「派生開発」を成功させるプロセス改善の技術と極意」を読んだ。
気付いたことをメモ。

【1】是正保守と改良保守の違い
ソフトウェア保守 - Wikipediaの定義がJISに公開されている。

是正保守は普通の障害修正に近い。
改良保守は、既存の製品に新機能を追加していくこと。例えば、ケータイにカメラやワンセグ、お財布携帯を追加していくこと。

後者はどう考えても保守ではない。清水さんはこの保守を意識して区別している。
おそらく世の中のSW開発の殆どは派生開発である、という指摘は、組み込み製品だけではなく、大規模な業務システムほど同様だ。
だから、継ぎ接ぎだらけで、たくさんの人のパッチが入った複雑なシステムになりがち。
リファクタリングそのものも危険になるから保守性も下がるし、品質も下がる。

そしてこれら保守の特徴は、開発期間が短く見積もり工数が小さいことだ。
2週間とか1ヶ月で終わらせて、一人で担当することも少なくない。
だから、仕様を部分理解したに過ぎないのに、ソースを弄って、リリース後に品質の悪さが露呈する場合も多い。

派生開発は、このような問題に対し、ソフトウェア保守に特化した開発スタイル。
この開発スタイルはXDDPと言われる。

【2】要求の表現に注力する

清水さんの派生開発の手法で面白い点は、変更要求の表現に注力すること。
萩本さんが提唱する要求開発が、見えない要求を見出していく点に力を入れているのと対照的だ。

XDDPでは、変更要求に要求が発生した理由も添えて、要求を階層化する。
その階層では、変更要求が親階層、変更仕様が子階層に書かれる。
理由は、要求の本来の意図を探り出して、他の要求や仕様への影響を調べたいからだ。

変更要求は「before/after」で書く。
派生開発だから、既存の要求が何に変わるのか、を明確に書くためだ。
これによって、本来の意図がはっきりし、仕様を正確に書きやすくなる。
レビューアも指摘しやすい。

要求仕様書と機能仕様書は書き方が違う、という指摘も参考になる。
機能仕様書は「～の動作をする」「～の操作ができる」のように機能が主語。IT技術者にとって馴染み深い。
しかし、要求仕様書は「～の動作(操作)ができて欲しい」のようにアクターが主語。慣れないと書きづらい。

「「派生開発」を成功させるプロセス改善の技術と極意」には特に書かれていないが、構成管理で重要な点は、機能仕様書はVerUpするが、要求仕様書はプロジェクト1回限りのものであること。
機能仕様書はプロジェクトが生きている間、システムが修正される度に更新されて版管理されるが、要求仕様書は修正が反映されたら、リリースされた要求としてお蔵入りとなる。
つまり、機能仕様書もソースと同じく構成管理の管理下におくべき成果物の一つなのだ。

【3】保守性や移植性などの品質要求も変更要求の一つ

機能仕様書と要求仕様書の違いの一つに、品質要求が要求仕様書に含まれる点がある。
「10年間のバージョンアップに耐えれるようにして欲しい」という保守性の要求や、「今後の新製品ファミリーへ展開できるようにモジュール化して欲しい」という移植性の要求も含まれる。

特に派生開発では、保守性や移植性は重要な品質要求になる。
実際の派生開発では、新機能を追加していくために、既存のソースをリファクタリングしないと機能追加できない時が多い。だから、保守性という品質が良くないと、たった2人日の修正工数を見積もったのに、実は1人月もかかってしまった時もよくある。

又、派生開発では、既存のモジュールを新製品ファミリーへ移植する時も多い。
その時、普通は、移植元のソースコードを取り出し、移植先のシステムに合うように手を加えてカスタマイズする時が多い。何故なら、移植先にそのまま組み込めばいい場合は稀で、インターフェイスを若干修正する必要があるからだ。
すると、移植元のモジュールがバージョンアップすると、移植先にも影響を及ぼす点に注意する必要がある。

「「派生開発」を成功させるプロセス改善の技術と極意」には特に書かれていないが、構成管理の観点では、移植性を実現するには「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」に書かれているベンダブランチを使えばいいと思う。
つまり、移植元のソースをベンダブランチとして別管理し、trunkに組み込む時にベンダブランチをカスタマイズして取り込む手法を取れば、移植元のバージョンアップに対してもシステマティックに対応できると思う。

XDDPでは、これらの品質要求も開発に取り入れることができるのが強みの一つ。

【4】トレーサビリティマトリクス(TM)で漏れをチェックする

トレーサビリティマトリクスは、縦に変更要求や変更仕様、横に機能を描いたマトリクス。
修正する箇所をマトリクスの交差点にポイントし、その交差点に変更設計書をリンクさせる。
変更設計書はソースの実際の修正方法。
変更設計書は、実際のソースコードをリバースエンジニアリングして作る。
清水さんの方法では、C言語が多いようなので、PADや構造図が多いらしい。
この作業をスペックアウトと呼んでいるようだ。

TMの利点は、変更要求や仕様がどの機能に影響しているか、を特定しやすい点にある。
SW開発の要件定義や設計のような上流工程で重要なポイントは、漏れが無いこと。
漏れが発生すれば、後工程でそれを見つけるのは難しいからだ。

個人的には、TMは、TestLinkの要件カバレッジやテストケース同士の依存関係でも表現して欲しいと思う。
要件がどのテストケースに紐づいているのか、一覧することができれば、テスト仕様書のレビューにも使えるからだ。

【5】変更要求仕様書、トレーサビリティマトリクス、変更設計書の3点セットがあるからデザインレビューもやりやすい

XDDPでは、3点セットを成果物として必ず作る。
このおかげで、これら成果物がデザインレビューのための資料になりうる。
既存製品の開発を経験した人がレビューアになれば、これら成果物を見れば、修正作業の影響範囲やその方法、工数見積もできる。

「「派生開発」を成功させるプロセス改善の技術と極意」で興味深い点は、その生産性だ。
XDDPでは100行/時間のペースでソース修正できるらしい。
但しこの計測方法にはからくりがあり、実際にソースに触ってから修正完了するまでの期間を指している。

XDDPによらない手法では、最初にソースに触って、デバッグしながら修正していくから、短い修正行数に対して、長い期間をかけて修正していることになる。
だから、1ヶ月でわずか100行しか修正していないというケースもありうる。

XDDPでは、いきなりソースに手を付けず、ソースからリバースエンジニアリングして設計する工程に時間をかけて、ソース修正する時は一気に行う。
つまり、設計工程で影響範囲を十分に見極めてから短時間にソースを修正するから、品質も良いのだろう。

構成管理の観点で重要な点は、派生開発は、trunkとは別のブランチで作業することで対応できることだ。
XDDPでは、ソースや機能仕様書を設計中にいじくることはしない。
しかし、やはりソースを触って実験したい時もある。
そんな場合は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」にあるタスクブランチやトピックブランチのように、trunkからブランチを切って、そのブランチ上で派生開発の作業を行えば良いと思う。
そうすれば、trunkで開発中のソースや機能仕様書に影響を及ぼす危険はない。

【6】ソフトウェアプロダクトラインのような製品ファミリー開発も派生開発の一種

XDDPの応用の一つに、製品ファミリーへ展開するという五月雨開発の例がある。
例えば、既存の製品から複数の派生機種を作り出す場合だ。
iPodファミリーやMS Office製品のように、組み込み製品やパッケージ製品でよく見られる開発スタイルだ。
これはソフトウェアプロダクトラインと原理的に同じだ。

XDDPの特徴は、変更要求仕様書、トレーサビリティマトリクス、変更設計書の3点セットを作ってからソースを修正する点なので、共通部分の改修チームはまずそれらの設計書を書き起こす。
だから、後続の派生機種の開発チームは、改修チームが作った3点セットの設計書を見ながら、影響を受ける機能を洗い出して設計する作業を先行してできる。
そうでなければ、共通部分のソースが完成しないと派生機種の開発ができないから、その分納期がずれ込んでしまう。

つまり、この手法は移植する作業を含めた派生開発に相当する。
だから、構成管理の観点では、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」に書かれているベンダブランチを派生先の製品開発チームが使うと良いだろうと思う。

ソフトウェアプロダクトラインにXDDPの手法も取り入れれば、製品ファミリーの開発の生産性も向上するのではないかと思う。

【7】インクリメンタルなアジャイル開発も実は派生開発になっている

XDDPのもう一つの応用例が、インクリメンタル開発に派生開発のアイデアを持ち込む点。
この点は僕も理解できている。
というのも、アジャイル開発は実は並行開発の構造を持っているからだ。

実際、短期間にリリースしながら小刻みに機能拡張していく開発スタイルだから、イテレーションで実装したモジュールをリリースしたら、そのモジュールを保守しながら機能追加しなければならない。
だから、バグ修正と仕様変更を織り交ぜて開発していくから、きちんとしたプロセスを持っていなければ品質が劣化しやすい弱点がある。

しかし、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」にあるメインラインモデルという構成管理手法でリリースブランチとtrunkを使い分ける戦略を取れば、この問題は解決できると思っている。
理由は、リリースして本番環境で動くシステムはリリースブランチ、ガンガン機能改善していくソースはtrunkと使い分ければ、障害修正はリリースブランチ、機能追加はtrunkと作業を使い分けることができる。
これによって、システム改修の影響を分離でき、システムの品質を安定させることができるはず。

「「派生開発」を成功させるプロセス改善の技術と極意」は多少くどいけれど、現場で鍛えられたノウハウだから、ツボにはまると非常に分かりやすいし役立つ。
個人的には、派生開発と構成管理の手法を絡めれば、もっとブラッシュアップできると考えている。