既存システムやプログラムへの影響を洗い出したら,変更個所をドキュメントにまとめていく。決まったフォーマットは無いが,「変更個所に漏れがないか一覧できる」ことが目標である。ソフトウエア開発プロセスのコンサルタントである,システムクリエイツの清水吉男氏が考案した手法で,改造計画のまとめ方のコツを見ていこう。

 清水氏は改造作業に対して,「何を変更するのか(What)」「その変更はどこにあるのか(Where)」「どのように変更するのか(How)」を表現する三つのドキュメントを作成することを勧めている(図1)。まず,変更要求や変更仕様を洗い出し「変更要求仕様書」にまとめる。ロジックの変更点だけでなく,メモリーの使用量が増えるといった,改造による変化を漏らさず書き出す。「改造にはソースコードを変えない“変更”もあり得る。変更要求仕様書には,そういったものも表現しておく」(清水氏)。

図1●システムクリエイツの清水吉男氏が考案した改造計画の成果物
図1●システムクリエイツの清水吉男氏が考案した改造計画の成果物
「変更要求仕様書」→「トレーサビリティ・マトリクス」→「変更設計書」の順番で,変更作業のWhat/Where/Howを洗い出す。この3点セットが完成するまでは,ソースコードの変更を許さないというルールを採っている
[画像のクリックで拡大表示]

 次に,それぞれの変更要求に影響を受ける,変更対象となるソースコードなどの名前を「トレーサビリティ・マトリクス」と呼ぶ表形式のドキュメントでマッピングする。変更対象の洗い出しは,UNIXのgrepコマンドなどを使い,クラス名やテーブル名でパターン検索するのが一般的だ。ただし,見つけ足りない,あるいは見つけ過ぎることがあるので,検索結果には注意したい。

 清水氏の場合,トレーサビリティ・マトリクスが完成したら,それに基づいてソースコードを変更するための工数を見積もる。「どれぐらい直せばいいか全体量が見えないから,見つけたところから直したくなる。ここでしっかり見積もっておけば,後で時間が不足するようなことはない」(同氏)。

 最後に,変更対象についてそれぞれ「変更設計書」を作り,具体的な変更方法をまとめる。変更設計書はソースコード上に表すのではなく,言葉で書くことがルールだ。清水氏によれば,「言葉で書けないときは,変更個所が間違っている可能性がある」という。

 こうした一連の作業を,清水氏は顧客と一緒に進める。成果物である三つのドキュメントは,すべてレビュー対象である。清水氏は「処理の中でデータの名前が変わっているようなケースは,レビューで見つけてほしい。うまく見つけてもらえるように,自分が気づいたことを分かりやすく表現することが大切」と,ドキュメント作りのポイントを挙げる。

ここからは会員の登録が必要です。