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

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

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

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

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

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

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

レビューの改善でバグが1/10に

　レビューの重要性はいまさら言うまでもないだろう。他者の目でチェックすることで，影響調査の広さ，深さの不足が補える。

　住友電気工業では，実施すると決めた案件に対して，担当者が改造のための設計書を作成してレビューにかける（図2）。レビューは，「仕様」や「設計内容」から，「実装方法」「単体テスト項目」までを一気に行う。これら資料をプロジェクターで投影し，ソースコードの変更方法まで開発メンバーがレビューする。「権限管理の部分など，担当者1人では影響を見切れないところが，レビューにより明らかになってくる」（中村氏）という。

図2●ソースコードの変更方法までレビューする住友電気工業 「仕様」「設計内容」「実装方法」「単体テスト項目」などの資料を案件ごとに担当者が作成。プロジェクターで映し出し，ソースコードの変更方法までチーム内でレビューする。こうしたレビューの仕組みを固めたことで，バグの発生率を従来の1/10に抑えることができた [画像のクリックで拡大表示]

　以前は，こうした形のレビューは行っていなかった。案件を振り分けられた担当者が，変更点をメモ書きする程度の準備で，ソースコードの変更に取り掛かっていた。このやり方ではバグが多かったことから，今のレビュー形式に変更。2005年，このレビュー形式を取り入れた社内申請システムは，改造案件に対するバグの発生量が従来の10分の1に減ったという。「レビューで皆に設計を見られるので，担当者は下手なものが出せない」（同氏）と，心理的効果も大きいようだ。

　日本IBMの大和研究所には，改造作業自体のリスクをレビューする仕組みがある。改造に取り掛かる前に，「リスク・スコアリング」カードを使い，プログラムのサイズ（新規/追加）や複雑度といったリスク要因を4段階で評価する（図3）。

図3●日本IBM 大和研究所の「リスク・スコアリング」カード

　この評価作業は，担当者/プロジェクト・マネージャ/品質担当者のように，立場の異なる3人が同時に行う。「三者三様の評価を持ち寄り，その中で最もリスクが高いスコアを選ぶ。このスコアに基づいて，必要なドキュメントの分量や，テスト・スケジュールなどを決める」（日本IBM の松本氏）。

次”の改造に備える

　一つの改造を無事にこなしても，改造案件は次々とやってくる。次の改造に備え，改造作業のトレーサビリティ（追跡管理）を高めようという取り組みが増えてきた。

　野村総合研究所では，「過去のテーマ対応結果」というドキュメントを作成し，改造作業のノウハウ共有を図っている。改造は類似するテーマが発生する可能性が高いため，同様の改造作業を効率的に進められるように備えているのである。

　設計書とプログラムをリンクさせ，改造の履歴をトレースする試みもある。ジャステックは，要件定義書―設計書―プログラムを双方向でリンクする試みを始めた。住友電気工業も同様に，外部仕様書―プログラム仕様書―プログラムが，同じIDで自動的にリンクされる仕組みを整えた（図4）。外部仕様書は，ページごとに分割するツールを作り，それで管理している。

図4●改造のトレーサビリティを高める 住友電気工業では，「外部仕様書」から「プログラム仕様書」，「プログラム」を自動的にリンクさせて管理している [画像のクリックで拡大表示]

　改造作業を追跡することは，次の改造作業を効率化するだけでなく，次のシステムの設計を下支えすることにつながる。積水化学工業で販売管理システムの構築などに携わってきた小笹淳二氏（経営戦略部 情報システムグループ 参事）は，「システムを5年も動かしていると，何で変えたのか理由が分からなくなってくる。稼働開始後に，どんな理由でどれだけ変えているのかをトレースして，次のシステム設計に生かすべきだ」と，トレーサビリティの必要性を語る。

システムは10年使う， 保守・運用費は予算の6～7割 佐藤 亘（さとう こう） 日本情報システム・ユーザー協会調査担当 　日本情報システム・ユーザー協会(JUAS)が毎年実施している「企業IT動向調査」によると，独自開発（スクラッチ開発）した基幹システムは平均で17年，パッケージを使用したシステムは平均で11年使用するという結果が明らかになっている。 　同じく「企業IT動向調査2006」では，再構築時に想定したシステムライフを調査した。結果は6～10年と回答した企業が最も多く，ホスト系からUNIX，Windows系システムへの移行の影響か，ライフサイクルが短くなっていると考えられる。とはいえ，システムは基本的には10年は使用するものと考えられており，その期間は保守費用が必要となってくる（図A）。 図A●システムにかかる費用 [画像のクリックで拡大表示] 5年間で初期開発費の1.85倍 　では，保守費用はどの程度必要なのであろうか。まず，IT予算全体のうち，保守費用の割合はどの程度なのかを見てみると，年間予算全体の6～7割を保守・運用費が占めている。 　一方，JUASが2005年度に実施した「ソフトウェアメトリックス調査」でも，保守費用について詳細に質問している。パッケージ開発の場合はパッケージ本体の保守費用として，毎年パッケージ金額の17%前後，アドオン開発については，開発部分の5%前後の保守費用が必要となるようだ。アドオンが増えればその分保守費用も高くなる。 　独自開発の場合もカットオーバー後5年間で，初期開発費の1.85倍の費用が必要となる。これは，カットオーバー時に積み残したシステムの追加開発が初期投資の約20％程度あることが影響している。 　このように，保守費用も，期間が長いと意外にコストがかかってくるものである。開発費＋保守・運用費の総費用を考慮したシステム構築が重要である。 　どの程度の企業がライフサイクルを考慮してシステム構築を進めているのか。企業IT動向調査2006の結果によると，何らかの形で考慮している企業が約6割，全く考慮していない企業が約4割という結果だった（図B）。 図B●ライフサイクル・コストを考慮しているか [画像のクリックで拡大表示] 　これは前年の調査結果と比較してあまり変化がないが，「必須ではないが考慮している」という回答が増加傾向にあることは，システムのライフサイクル・コストに対する認識が高まっていると考えられる。