プログラマの思索

初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。
本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。
以下、メモ書き。

【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。
ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。

駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。
影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。

清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。
人体でも、風邪を引いた場合、抗生剤を飲む。
しかし、抗生剤は人によっては免疫機能が働いて拒否反応を起こす危険なもの。
そうでなくても、抗生剤は、悪玉だけであく善玉の細菌まで殺してしまう。

ソフトウェア開発でも、機能追加は慎重に行わなければ、既存の機能の品質まで劣化させてしまう。

そうなってしまう理由は、SW開発の殆どは、既存のソースに機能を追加してVerUpしていくスタイルが多い事実を見落としていないか？

SW開発のその特徴を類推すると、VerUpしていくたびにテストケース数が単調増加していく事実もあげられる。
過去の機能が正常動作する保証の元に、追加した機能のテストも行う。
影響範囲をきちんと見極めないと、既存の機能まで壊してしまう。

XPならば自動テストのプロセスがあるため、回帰テストによって、既存の機能の正常動作を保証できる。
しかし、そのプロセスがなければ、回帰テストのコストが大きすぎるため、デグレの危険をいつもはらむ。
デグレは、顧客の信用を激しく落とし、開発者自身のモチベーションも大きく落とすとても危険な現象だ。

【2】XDDPには、要求と仕様を厳密に区別し、変更管理をきちんと追跡していくプロセスがある。

要求と仕様の一番の違いは、要求は1回限りだったりするけど、仕様はVerUpしていく、という話にすごくピンと来た。
この話によれば、仕様書もソースと同じく構成管理の下に置くべき対象なのだ。

駄目なプロジェクトでは、中途半端に仕様書を直しては、設計漏れが出るたびに仕様書を修正するパターンの繰り返しだ。
XDDPでは、変更管理プロセスがしっかりしているため、CCB(変更管理委員会)の決定やレビューが終わらない限り、仕様書に修正が入ることはない。

清水さんは、この特徴があるおかげで、並行開発や五月雨式開発が可能になる、と言っていた。
例えば、組み込み製品ならば、普通は、似たような仕様を持つ製品ファミリーがたくさんあり、それぞれが並行開発されている。
機能追加が起きると、全ての製品ライン上でマージ作業を行わなければならない。
だから、変更管理プロセスを制御することで、デグレが起きないようにするのがポイントらしい。

僕は清水さんに、ブランチを巧く使えば制御できるのではないか？と質問したら、ブランチからマージするのは大変ではないですか？と切り換えされた。
確かに、タスクブランチは現実的な解決方法の一つであるが、制御するのが難しい技術の一つだから。

また、要件からテスト仕様書が作られる。
XDDPでは、要件仕様書がしっかりしているため、受入テストのテストケースを作るのがかなり楽になる印象を受けた。

TestLinkでテスト管理し始めてから、テストケースの元ネタである要件の重要性を痛感している。
テストケースを作る場合、一番重要な観点は、全ての要件を網羅できているか、という要件カバレッジだ。
実際にテストケースを作ってみると、テストで確認しない要件がポロポロ出てくる。
つまり、テストがMECEでないのだ。
そこから、検証できていない機能が発生して、潜在バグが生まれる。

実際は、全ての要件をテストでカバーするのは非常に面倒な作業だ。
一つのテストケースには複数の要件が混じっていたり、要件を検証するステップを追加するたびにテストケースは肥大化しがち。

そもそも要件IDが振られた要件定義書が存在しない場合もある。
そのプロジェクトは、テストケースの品質が非常に低いといえるだろう。

幸いなことにTestLinkでは要件解析の機能があり、テストしていない要件、要件に紐づかないテストなどをリアルタイムに一覧表示できる。
この要件解析の機能をフルに使うと、テストケースの品質を向上させることができる。

【3】清水さんの本にもあるが「SEはプロセスを自在に設計する能力が必要だ」というフレーズが僕は好きだ。
プロジェクト毎にそれに合った開発プロセスを設計して運用する能力がPLには必須。
そのためのツールがDFDっぽいPFDというツールらしい。

XDDPがアジャイル開発と似ている印象を持ったのは、SW開発の殆どは機能追加という保守開発である、という認識を前提として、ソースからリバースエンジニアリングで設計しようという開発スタイルだからだ。
XPは仕様書よりも動くプログラムを重視するが、XDDPも既存のプログラムを分析するのを重視する。
ウォーターフォール型開発のような上からの開発ではなく、下からの開発スタイル。

清水さんの話の中で「一人プロジェクトは危険だ」というフレーズがあった。
つまり、一人で設計し修正しテストして終わる作業は非常に危険だということ。
一人だけの作業は思い込みが生じたりして、品質が安定しない恐れがあるから。
大人数のチームであっても、運用保守の作業はコストをかけられないため、一人プロジェクトになっている時も多い。
だから、アフターケアやレビューの重要性を言っていた。

これは、XPのペアプロの発想に似ている。
一人だけでバグ修正してバグを検証すればOKというわけではない。
二人の目を通した作業の方が、時間はかかっても品質は安定する。

XDDPは運用保守に強い開発スタイルのような印象を持った。
色々調べてみる価値はある気がする。