対応すべき案件が決まり，いざソフトウエアの改造に臨むとき，間違っても，いきなりプログラムを変え始めてはならない。「変更個所を見つけると，すぐにでもソースコードを変えたくなる。しかし，それでは後から後から変更個所が見つかり，作業に追われてしまうことになる」（システムクリエイツ の清水氏）からだ。
急ぎすぎた改造は，プログラム品質の低下も招く。住友電気工業はかつて，押し寄せる案件に対して，開発担当者が簡単なメモを作る程度で，プログラムの変更に着手していた。情報システム部の中村伸裕氏（システム技術グループ グループ長）は，「対応は早かったが，バグが多かった」と振り返る。こうした反省から，影響分析を徹底するように改造プロセスを改めた。「今ではソースコードの変更方法までレビューしている。レビューが通らない限り，担当者に本番のソースコードは触らせない」（中村氏）。
ソフトウエアの改造に当たり，エンジニアが直面する最初の課題は，既存のシステム，プログラムへの影響をうまく調査すること。影響調査は，「何を」「どこまで」「どうやって」直すのかを明らかにする。調査に漏れがあれば，あとでトラブルが発生する確率は高い。影響なしと判断された部分は，テスト対象から除外されることが多いからだ。
以下では，（1）改造工数の見積もり，（2）ソースコードの変更個所の洗い出し，（3）作業計画のレビュー，の三つのステップで影響調査のポイントを解説する。
分散範囲と分散度で手間が変わる
影響調査の第一ステップとして，ソフトウエア改造の工数見積もりを取り上げる。第3回でも工数を概算したが，ここではもう少し詳しく見積もる。改造工数を見積もるには，新規開発と同様のアプローチだけでは難しい。改造ならではの特性を押さえ，きちんと工数を確保しておかなければ，後続の作業が立ち行かなくなる。
中堅のソフト開発会社であるジャステックは，見積もりモデルを中心に，ソフトウエア開発の生産管理に力を入れている。同社が考案した改造型の見積もりモデルから，改造ならではの生産性の特徴が見えてくる（図1）。このモデルでは，「分散範囲」と「分散度」という二つのパラメータから，新規開発に比べてどれだけ改造型開発の生産性が低下するかが分かる。
 |
| 図1●ジャステックは「分散範囲」「分散度」から工数を見積もる 「分散範囲」(グラフの横軸），「分散度」(グラフの縦軸）の二つのパラメータで，新規開発に比べた，改造型開発の生産性の低下率を見積もっている。分散範囲は，改造対象プログラムの全体ボリュームを表し，ボリュームが大きくなるほど工数が膨らむ。分散度は，追加対象のプログラムの散らばりを表す。大きな塊で追加した方が生産性は高く，細かな追加がたくさんある方が生産性は低い [画像のクリックで拡大表示] |
分散範囲とは，改造対象である元プログラムのボリュームを表す。ボリュームが大きいほど，改造の工数はかさむ。一方の分散度は，追加するプログラムの散らばりを表す。「1カ所をドカンと直すのに比べて，細かくたくさんの部分を直す方が生産性は落ちる」（太田氏）。
「分散範囲」と「分散度」は，その値に応じてどれだけ生産性が低下するか係数を定めてある。両者の和が，そのソフトウエア改造における生産性の低下率だ。図1左上の例では，新規開発に比べて15%生産性が落ちる。改造作業に当たって，低下分の工数をあらかじめ上乗せしておく必要がある。「これまでに行ってきた開発実績から見積もりモデルを作った。今後，開発案件をこなす中でブラッシュアップしていき，係数の妥当性などを検証していく」（取締役 兼 執行役員 製造本部 本部長 高橋亨氏）という。
