情報システムの保守体制を見直すユーザー企業が増えている。新サービスのための機能拡張、事業再編に伴う改修など、経営サイドのニーズに素早く応えるためだ。しかしシステムが錆びついてしまい、迅速に拡張・改修できない企業が多い。保守体制を抜本的に改革しているシステム部門の動きを追う。

保守優先は時代の流れ　
乗り遅れると企業競争力が低下

経営とシステムが密接になればなるほど保守の重要性は増し、企業競争力を左右する。その保守を担うユーザー企業のシステム部門の役割は増している。しかし保守性の向上は難しく、落とし穴もある。組織的に取り組む必要がある。

　「新しい合弁会社設立まで3カ月。基幹システムはどうするのか」。今年1月の会議で、こう役員に問われたカシオ計算機 業務開発部の矢澤篤志部長は「新しく作ります」と明言した。

　カシオは今年4月に携帯電話端末事業を再編、日立製作所との合弁であるカシオ日立モバイルコミュニケーションズを設立した。矢澤部長がこの計画を知ったのは11月半ば。4月までに新会社の会計や出荷業務の手順を決めながら、システム化するのは容易ではない。最初は両社の既存システムを使い続けようとした。しかし、それでは調達一本化など合弁の効果が十分に得られない。「やはり新会社のシステムを作ろう」。矢澤部長は踏み切った。

　踏み切れたのは矢澤部長が「以前から、変化への対応、つまり保守こそが情報システムのキモと考え、準備を進めていた」からだ。携帯電話端末などの製造業務を徹底的に分析、それに必要なデータ項目や業務フローを押さえ再利用可能なモデルを作っていた。「モデルがあったから新会社向けプロトタイプを1月から3週間で作れた。あとはそれに肉付けすればよかった」。

経営と密接になる保守

　システムの保守体制が経営戦略に大きな影響を及ぼすようになった。カシオのようにシステムが経営の要請に応えられた例もあるが珍しいほうだ。逆に新事業に伴う機能拡張をシステム部門に指示した経営者が、システム部門から「基幹系システムの保守性が悪いので、機能拡張には1年かかります」と言われ、がっかりする話はよくある。2002年に合併したがシステムの改修・統合と支店統廃合が思うようにできなかったみずほ銀行のような例もある。

　保守性の悪化という問題はたいていの企業が抱えている。システムの素早い拡張・改修を求める経営ニーズに応えられずに、経営者がシステム部門に対する不満を募らせる元凶にもなっている。これが、保守体制の再構築の背景にある。

図1●保守性を高めた「磨き上げられたシステム」は保守しづらい「錆びついたシステム」よりも経営や業務の変化に即応しやすい

　保守性向上には長年の積み重ねが大切だ。システムの変更管理ができず、システムの内部をきちんと把握していない場合、必ずといってよいほど悪循環に陥る（図1[拡大表示]）。例えば機能を拡張するときにデータベースを修整すると、内部がわからなければ他のプログラムに悪影響が及び、不具合が起こることがある。

　これを避けるためによく使われるのが、データベースをコピーしてシステムの外にその場しのぎのシステムを新たに作ってしまうことだ。つぎはぎだらけの温泉旅館のようになるので、保守性が悪くなり、次の機能拡張もその場しのぎになる。システムが硬直化し、新サービスの早期市場投入や事業再編を最適なタイミングで行えなくなる。

　これに対しカシオのように保守優先の方針を貫けば、経営戦略を素早く反映させることができる柔軟なシステムになる。企業競争力も高められる。

保守の主役はシステム部門

　保守が重視されるようになった理由は二つある。一つは、システムが複雑になったことである。システムの規模が大きくなるとともに、システム同士は密接に連携するようになった。このため、拡張・改修の影響範囲が広がり、保守の作業量が膨大になった。

　もう一つの理由は、合併や子会社化など経営環境の急激な変化が日常茶飯事になったことだ。事業再編は極秘のうちに進み、急に決まることが多い。しかし、事業再編の効果を上げるために、素早いシステム改修が求められる。

　保守を迅速に行うためには、ビジネスを理解していなければならない。例えば、データの流れやシステム化の意図をつかんでいないと、ソース・コードを見ても保守はできない。ベンダーにはおいそれと保守を任せられない。

　もちろんシステム部門もビジネスの分析に注力する必要がある。東京海上システム開発は、「ビジネスの急速な変化にシステムが耐えられるようにするには、業務とシステムを整理しなければならない。このためにシステムの全体像を描いて最適化を追求するためのEA（エンタープライズ・アーキテクチャ）を導入し、データ・モデルを描いている」（経営企画部の小林賢也コーポレートソリューションプロデューサー）。清水建設も「注文から建物引き渡しまでの全体像をとらえながら、当社の各業務が何をやっているのかを分析して、システムに反映している」（情報システム部の安井昌男課長）。

　こうした作業は、システム部門を強化することになる。「保守性を高めるためのビジネス分析を行うと、事業領域と利害関係者が明らかになり、経営者もシステム部門も自社の強みを改めて認識することになる。その結果、強みを伸ばすような、あるいは弱点を補強するような、経営に貢献するシステムを作れるようになる」と独立系コンサルティング会社、ビジネス情報システム・アーキテクトの手島歩三代表取締役は語る。

図2●情報システム部門はアプリケーション保守業務に関して板ばさみの状態になっている

保守は「議論の俎上に乗せにくい」

　成功している企業がある半面、システムの大規模化・複雑化と、経営の急激な変化の間で板ばさみになっている企業も多い（図2[拡大表示]）。保守が困難になるケースはたくさんあり、保守性を高める対策は容易ではない。

　例えば図3[拡大表示]（a）のようにプログラムの作り方がまちまちだと、1カ所を修整したときに、影響がどこまで波及するのか、いちいち調べなければならず、保守に時間をとられることがよくある。急いで作業すると直し忘れて誤った動作や障害が生じることがあるので手を抜けない。図3[拡大表示]（b）は、拡張・改修の際にシステム内部がわからず、つぎはぎだらけのシステムができた例。内部をいじらずに、データベースの一部をコピーしてしまう方法だ。こういう作り方をするとデータベースBを変更すると、システムBだけでなく、システムC、Dにも影響が及ぶ可能性があり、保守が非常に大変になる。

図3●起こりやすい保守のトラブル例

　保守性を高めるためには、「データ項目の統一やプログラミング方法のルール化など地道な対策を体系化して着実に実施しなければならない」と日本IBMアプリケーション・マネジメント・サービス事業部AMSソリューション企画の山下欣也氏は強調する。

　しかし、こうした取り組みを実践するのは容易ではない。例えば、データ項目を一部でも勝手に定義したり、変更作業のドキュメントを書かなかったりすると、システム全体の保守性はまたたく間に悪化する。保守は一人の技術者の奮闘で解決できる問題ではない。「システム部門だけでなくベンダーも含め、全体が一丸となって組織的に保守性向上に向けて取り組まねばならない」（コンサルティング会社、一の大槻繁専任コンサルタント）。

　ところがユーザー企業内では、保守性の問題点を真剣に議論できない雰囲気がある。経営者や経営企画部が保守性を高めるための苦労を理解できないことが少なくないからだ。一方、ベンダーは、保守性の悪いシステムを作ると儲かるようにもなっているので、保守性を高めようとする動機が起こりづらい。

　そもそも保守性を高められる人材が減少している、という指摘もある。プロジェクト・マネジャを育成するPMリサーチの岡村正司代表取締役は、「保守性を考えない若手・中堅の技術者が目立つようになった。本来はシステムの土台（基盤システム）を長期的な視野に立って作り、保守性を高める必要がある。ところがそういう作業があることさえ知らない若手・中堅が多い。ユーザー要件だけを聞いてそのまま実装する技術者がその典型例だ。団塊の世代が持っていた保守のスキルが失われつつある。団塊の世代が引退する2007年問題の本質は、保守と密接に関係している」と警鐘を鳴らす。

　ユーザー企業のシステム部門は、保守性について、社内で議論を尽くすべきだ。「保守をコストととらえるから後ろ向きになる。保守は業務に合わせてシステムを変える作業であり、システムの資産価値を上げる取り組みと考えるべきだ。経営者とシステム部門は長期的視野を持って保守に取り組まねばならない」と、保守の課題解決に取り組むNPO（非営利団体）、ソフトウェア・メインテナンス研究会の塩谷和範氏と田中創氏は主張する。