「全ソースコードを対象にした個別調査では，時間がいくらあっても足りない」──。昨年，改修に伴う影響分析で，500万ステップに及ぶソースコード（COBOL）の内部仕様を，わずか1カ月，それも1人で見える化した野村総合研究所の藤田由起氏（情報技術本部 生産技術部 副主任テクニカルエンジニア）はこう強調する。藤田氏は「複雑な内部仕様は全体の一部。それを全体の傾向から探り当てることが時間をかけない秘訣」と明かす。
内部仕様の中心は，処理ロジックである。この処理ロジックは，一部の言語を除いて，リバース機能を持つツールを使えば見える化できる。ただし，ソースコードが複雑に絡み合うスパゲッティ状態にあると，リバースしても内容が複雑すぎて解釈できない。その問題を回避するには，スパゲッティ状態のソースコードを，あらかじめ解きほぐす必要がある。
そこで藤田氏は，スパゲッティ状態にあるソースコードの全体傾向を「規模」「重複度」「デッド・コード」「複雑度」という四つの視点で把握（図1）。そこから問題のソースコードを探り当てている。
具体的には，まず全ソースコードのステップ数をカウントし，規模を把握する。続いて，ソースコード同士を比較して処理ロジックが一致したコードを重複と判断する。さらに，どこからも参照/呼び出しがないデッド・コードを見える化。重複分とデッド・コードは，個別調査の対象外とする
次に，処理（関数やメソッド）と経路（パス）の数によって，スパゲッティ状態（複雑度）を見極める。藤田氏はここで「循環複雑度」と「本質複雑度」の二つの指標を使う。循環複雑度とは，全パスがどれほど深く連続しているかという複雑度。本質複雑度は，全パスのうち構造化を無視して処理が飛躍するようなパス（GOTO文など）を対象とした複雑度である。
循環複雑度と本質複雑度が分かったらグラフ上にマッピングし，それぞれの数値あるいは両者の数値が高いソースコードを選んで個別調査に入る。いずれの数値も高ければ，最もスパゲッティ状態が深刻といえる。
ただし，ここでもすべてのソースコードを調査対象とはしない。「複雑度の傾向が近いものは，スパゲッティ状態もほぼ同じ」（藤田氏）と考えられるためである。そこで代表となるスパゲッティ状態のソースコードに着目し，1ステップずつ順番に解きほぐしていくという。
画面/シェルを起点にたどる
改修に伴う影響分析では，処理ロジックだけでなく，影響がシステムのどこまで及ぶのかを探る必要がある。
多いのは，「データ項目」によってたどるケースだ。例えばあるデータ項目のケタ数を変更した場合，そのデータ項目を含むソースコードを検索して見える化する。しかし，本来同じデータ項目の名称がソースコードによって異なっていると，検索に合致しない恐れがある。その上，全ソースコードを対象にするため，改修に影響しない未使用のソースコードも該当してしまう。もし本来あるべきソースコードがライブラリ上になければ，それらのソースコードが影響範囲として見える化されることはない。
こうした状況から，ソースコード同士の関係を浮き彫りにし，未使用，重複，不足を明らかにする「棚卸し」は，改修に伴う影響分析では必須となる。問題はその方法だ。
そこで実践したいのが，シェル・スクリプト（メインフレームの場合はJCL：Job Control Language）や画面を起点とした，ソースコードの棚卸しだ（図2）。
この方法を推奨する富士通の佐野隆氏（アシュアランス本部 APMサービスセンター長）は「個々のソースコードをバラバラに見て未使用，重複，不足のソースコードを探るのは困難。信頼できる起点からたどるのが原則」と説明する。
具体的には，バッチ処理ではシェル・スクリプト（またはJCL），オンライン処理では画面を起点にソースコードの関連をたどる。まずシェル・スクリプトと画面から，実行されるライブラリ上のプログラムを特定。次に，それらのプログラムが呼び出す別のプログラム，または参照先のデータ定義といった定義体を特定していく。
これらの関連は，図2のように矢印で見える化する（佐野氏らはツールを利用）。その上で，シェル・スクリプトや画面から矢印でたどれないプログラムや定義体を「未使用」とする。矢印の元と行き先が同じであれば「重複」と判断できる。もし矢印の先に必要なプログラムや定義体がなければ，それは「不足」となる。これにより，改修に伴う影響分析も「調査工数を劇的に短縮できるようになる」（佐野氏）。
