「一から作ることが少なくなった」

　改造によるトラブルが増えてきた理由は，大きく二つ挙げられる。まず，改造案件の数が増えていること。野村総合研究所の鈴木昌人氏（エンハンス業務革新推進室 上級専門スタッフ）によれば，「会社の中を見回すとほとんどがエンハンス業務であり，一からシステムを作ることが少なくなってきた」という。

　システムは稼働開始した瞬間から，変更要求が寄せられる。「業務担当者の要望」や「バグ修正」「制度ルールの変化」など様々な要求がある（図2）。住友林業の宮下敬史氏（情報システム部 マネージャー）は，「ITがビジネスに深く入り込んでいるので，ちょっとした環境の変化でも，ITを触らないとビジネスが継続できない」と，要望が増えてきた一因を語る。

図2●保守作業の実態

日本情報システム・ユーザー協会(JUAS)は，会員企業に対して「保守」をテーマに調査を行い，「ユーザー企業SWM調査報告」にまとめた。保守作業が発生する理由の内訳などが明らかになった

[画像のクリックで拡大表示]

　例えば大成建設では，2005年末に緊急の改造を求められた。「合併した三菱東京UFJ銀行のスタートに合わせて，資金システムのカナ名称のけた数を増やす必要があった」（情報企画部 次長 服部正憲氏）。約1人日の工数を費やし，8本のJavaプログラム，およびデータベースの二つのテーブルを変更した。

　改造のミスがトラブルに直結する状況は，システムの使われ方にも関係がある。ジャステックの太田忠雄氏（常務取締役 兼 常務執行役員 営業本部本部長）は，「今のシステムは，変更したそばからリアルタイムで使われるのでミスの影響がすぐに表に出る。しかも，あるシステムのデータを他のシステムに連携させているような形態では，一つのミスが複数のシステムへと広がってしまう」と，最近のシステム事情を話す。

改造作業の1割が失敗する

　トラブルが増える理由の二つ目は，改造ならではの開発方法論がまとまっていないこと。ミサワホームの受発注システムには，年間で約200件の改造案件が寄せられる。案件をさばく松尾昇氏（情報システム部 基幹開発グループ マネージャー）は，「仕様の取り違えなどで，年間に十数件は対応したことによる不具合が出る」と話す。　日本情報システム・ユーザー協会（JUAS）が，保守プロジェクトに関して調査した「ユーザー企業SWM調査報告」を見ても，「保守リリース後1年以内に，10%の確率で欠陥が発生している」。JUASの専務理事である細川泰秀氏は，「システムの信頼性が問われるような最近のトラブルの多くは，保守フェーズで起きているのではないだろうか」と見ている。

　“1割が失敗”というソフトウエアの改造リスクは見逃せない。日本IBM 大和研究所の松本修氏（APTOソリューション開発 第一ソリューション開発 品質企画担当課長）は，「新規にコードを10行書くのと，1万行の中の10行を変更するのでは，リスクに大きな差がある」と，ソフトウエア改造のリスクの大きさを指摘する。

　週末にプログラムを変更し，月曜日の朝に「手に汗を握って」見守っているエンジニアは，少なくないだろう。

　もちろん，これまでもリスクを管理しながら改造してきたはずだ。野村総合研究所の鈴木氏は，「プログラムの変更はこれまでもやってきたし，作業の品質も悪くなかった」と話す。ただし，「標準が無いので，プロジェクトに閉じていたノウハウを整理したい」と付け加える。改造には，新規開発とは異なる“難しさ”がある。新規開発と同じやり方で不足を感じる現場では，改造力を鍛える試みが始まっている。