改造ならではの難しさとは，「既存システムへの影響調査」と「“他に影響がない”ことを確認するテスト」の二つに集約できる。ソフトウェア・メインテナンス研究会 幹事の増井和也氏（東芝ソリューション ソリューション第三事業部 参事）は，二つの作業工数が膨らむ改造のありさまを，“フタコブらくだ”と表現した（図1）。

　新規開発が“一から”なのに対して，改造は“元のプログラムありき”がスタート地点。変更要求に対して，目の前にあるシステムの「何を」「どこまで」「どうやって」変えるのかを調べなければならない。この作業工数の大きな山が，第一のコブの正体だ。

　改造が与える影響には様々なものがある。住友林業の宮下氏は「リリースしたアプリケーションに問題がある場合は，それをやめれば済む。しかし，新規アプリケーションのために追加したインデックスが原因で，既存アプリケーションの性能が落ちるようなケースは根が深い」と説明する。

　変更調査は，最終的にはソースコードに及ぶ。自分で書いたソースコードに比べて，他人が書いたものは，調べるのがより難しい。電通国際情報サービスの田邊達也氏（エンタープライズソリューションコンサルティング部 統括マネージャー）は，「やると決めた案件はビジネス上重要なものが多く，時間的な制約が厳しい。そのため，設計書をしっかりメンテナンスしておき，影響調査を効率的に行えるよう備えている」と対策を語る。

“ウラ”のテストが必須

　二つ目のコブは，確認テストである。もちろん新規開発でもテストは行うが，ウインタートウル・スイス生命保険 情報システム部長の杉浦実氏は，「テストにより現行機能を保証する必要があることが新規開発との違い。新規に比べてテスト時間は長くなる」と，改造時ならではの特徴を語る。つまり，ここでも作業工数の大きな山ができる。これが二つ目のコブというわけだ。

　INAXの松中栄治氏（経営管理本部 情報システム部 販売システムグループ 課長）は，改造時のテストは2種類あると説明する。「新機能がきちんと動くことを確かめる“オモテ”のテストと，これまで動いてきた機能に影響が無いことを証明する“ウラ”のテストが必要。ウラのテストをやっていないときに限って，後からトラブルになる。テスト・パターンが膨大なので，これをいかに効率化するかが課題だ」。

　ソフトウエアの改造で失敗しないためには，「影響調査」と「確認テスト」を確実にこなすことが求められる。第1回で見た，労働金庫連合会で発生したトラブルも，この二つが再発防止のポイントといえるだろう。

まずは案件選びから

　次回以降，改造に必要なスキル，ノウハウを解説していく（図2）。中心になるのは言うまでもなく影響調査と確認テストのフタコブである。

　ただし，改造作業に突入する前に，やるべき案件を選ばなければならない。寄せられる要望の数は多いが，その内容はいろいろある。やみ雲に応じていては，工数がいくらあっても足りない。第3回，第4回では，価値の高い改造案件を選ぶ方法を解説する。

　第5回と第6回では，影響調査のポイントを解説する。設計書などのドキュメントから変更個所を洗い出し，レビューによって調査の漏れを補っていく。独自の調査手法を考案したシステムクリエイツ 代表取締役の清水吉男氏は，「変更を見つけたそばから直し始めると，全体量が見えず，あとで慌てる。調査が終わるまでは，ソースコードに触れるべきではない」と釘をさす。

ゴールは本番リリース

　第7回以降では改造ならではのテスト手法を解説する。テスト範囲を見極めると同時に，効率化も図っていく。

　テストを完了すれば，あとはプログラムを本番にリリース（移行）するだけだ。だが，ここで安心するのは早い。開発環境/本番環境の管理に問題があり，トラブルとなることもあるからだ。

　神奈川県の茅ヶ崎市役所は，2005年8月に「国民健康保険オンラインシステム」を再構築して以来，5回のシステム障害に遭った。2006年2月には，市民に発送した「納入通知書兼納付書（自主納付分）」に記載ミスがあった。コンビニ収納用のバーコードに他人のものが印刷されていた。

　原因を調べた結果，開発を担当したSIベンダーのエンジニアが，納入通知書兼納付書の印刷プログラムを変更していた。このエンジニアは印刷プログラムにバグがあると思い込み，勝手にプログラムを“修正”していた。

　運用担当者に無断で，開発者が本番環境のプログラムを変更するのはルール違反のはずだ。しかし，茅ヶ崎市役所のシステムには，こうした本番アクセスを防ぐ制御機能が無かった。

　第9回は，プログラムを安全にリリースする仕組みを紹介し，ソフトウエア改造の作業を締めくくる