既存システムやプログラムへの影響を洗い出したら，変更個所をドキュメントにまとめていく。決まったフォーマットは無いが，「変更個所に漏れがないか一覧できる」ことが目標である。ソフトウエア開発プロセスのコンサルタントである，システムクリエイツの清水吉男氏が考案した手法で，改造計画のまとめ方のコツを見ていこう。
清水氏は改造作業に対して，「何を変更するのか（What）」「その変更はどこにあるのか（Where）」「どのように変更するのか（How）」を表現する三つのドキュメントを作成することを勧めている（図1）。まず，変更要求や変更仕様を洗い出し「変更要求仕様書」にまとめる。ロジックの変更点だけでなく，メモリーの使用量が増えるといった，改造による変化を漏らさず書き出す。「改造にはソースコードを変えない“変更”もあり得る。変更要求仕様書には，そういったものも表現しておく」（清水氏）。
 |
| 図1●システムクリエイツの清水吉男氏が考案した改造計画の成果物 「変更要求仕様書」→「トレーサビリティ・マトリクス」→「変更設計書」の順番で，変更作業のWhat/Where/Howを洗い出す。この3点セットが完成するまでは，ソースコードの変更を許さないというルールを採っている [画像のクリックで拡大表示] |
次に，それぞれの変更要求に影響を受ける，変更対象となるソースコードなどの名前を「トレーサビリティ・マトリクス」と呼ぶ表形式のドキュメントでマッピングする。変更対象の洗い出しは，UNIXのgrepコマンドなどを使い，クラス名やテーブル名でパターン検索するのが一般的だ。ただし，見つけ足りない，あるいは見つけ過ぎることがあるので，検索結果には注意したい。
清水氏の場合，トレーサビリティ・マトリクスが完成したら，それに基づいてソースコードを変更するための工数を見積もる。「どれぐらい直せばいいか全体量が見えないから，見つけたところから直したくなる。ここでしっかり見積もっておけば，後で時間が不足するようなことはない」（同氏）。
最後に，変更対象についてそれぞれ「変更設計書」を作り，具体的な変更方法をまとめる。変更設計書はソースコード上に表すのではなく，言葉で書くことがルールだ。清水氏によれば，「言葉で書けないときは，変更個所が間違っている可能性がある」という。
こうした一連の作業を，清水氏は顧客と一緒に進める。成果物である三つのドキュメントは，すべてレビュー対象である。清水氏は「処理の中でデータの名前が変わっているようなケースは，レビューで見つけてほしい。うまく見つけてもらえるように，自分が気づいたことを分かりやすく表現することが大切」と，ドキュメント作りのポイントを挙げる。
