改造ならではの難しさとは，「既存システムへの影響調査」と「“他に影響がない”ことを確認するテスト」の二つに集約できる。ソフトウェア・メインテナンス研究会 幹事の増井和也氏（東芝ソリューション ソリューション第三事業部 参事）は，二つの作業工数が膨らむ改造のありさまを，“フタコブらくだ”と表現した（図1）。
 |
| 図1●改造作業は“フタコブらくだ” 稼働中のシステムに手を加えるため，プログラムをたった1行変えるだけでも，「既存システムへの影響調査」と「“他に影響がない”ことを確認するテスト」の二つの作業工数が大きくなることが特徴。これら二つの作業をいかに効率的，かつ確実にこなせるかが改造型開発の成否を分ける。図はソフトウェア・メインテナンス研究会（SMSG）の幹事である増井和也氏の資料を参考に作成した [画像のクリックで拡大表示] |
新規開発が“一から”なのに対して，改造は“元のプログラムありき”がスタート地点。変更要求に対して，目の前にあるシステムの「何を」「どこまで」「どうやって」変えるのかを調べなければならない。この作業工数の大きな山が，第一のコブの正体だ。
改造が与える影響には様々なものがある。住友林業の宮下氏は「リリースしたアプリケーションに問題がある場合は，それをやめれば済む。しかし，新規アプリケーションのために追加したインデックスが原因で，既存アプリケーションの性能が落ちるようなケースは根が深い」と説明する。
変更調査は，最終的にはソースコードに及ぶ。自分で書いたソースコードに比べて，他人が書いたものは，調べるのがより難しい。電通国際情報サービスの田邊達也氏（エンタープライズソリューションコンサルティング部 統括マネージャー）は，「やると決めた案件はビジネス上重要なものが多く，時間的な制約が厳しい。そのため，設計書をしっかりメンテナンスしておき，影響調査を効率的に行えるよう備えている」と対策を語る。
“ウラ”のテストが必須
二つ目のコブは，確認テストである。もちろん新規開発でもテストは行うが，ウインタートウル・スイス生命保険 情報システム部長の杉浦実氏は，「テストにより現行機能を保証する必要があることが新規開発との違い。新規に比べてテスト時間は長くなる」と，改造時ならではの特徴を語る。つまり，ここでも作業工数の大きな山ができる。これが二つ目のコブというわけだ。
INAXの松中栄治氏（経営管理本部 情報システム部 販売システムグループ 課長）は，改造時のテストは2種類あると説明する。「新機能がきちんと動くことを確かめる“オモテ”のテストと，これまで動いてきた機能に影響が無いことを証明する“ウラ”のテストが必要。ウラのテストをやっていないときに限って，後からトラブルになる。テスト・パターンが膨大なので，これをいかに効率化するかが課題だ」。
ソフトウエアの改造で失敗しないためには，「影響調査」と「確認テスト」を確実にこなすことが求められる。第1回で見た，労働金庫連合会で発生したトラブルも，この二つが再発防止のポイントといえるだろう。
