PR

 今年5月から6月にかけて,システム保守について集中的に取材した。ユーザー企業やユーザー系システム子会社を中心に20社以上回った。日経コンピュータ7月12日号の特集「もうシステムを錆びつかせない」をまとめるためだ。

 ビジネスの変化に応じてアプリケーションを拡張・改修する保守は,もともとシステム部門にとって大切な業務である。これまでも,地道に保守作業をこなしてきたはずだ。ただ最近は,ビジネスがものすごく激しく変化している。さらにシステムとビジネスの関係はますます密接になっている。保守作業にかけられる時間は短くなっているはずだ。

 ビジネスの変化にシステムは迅速に対処できているのか。システムが大規模化,複雑化するなかで,システム部門は保守の課題にどう取り組んでいるのか。システム保守についてこれまで本格的に誌面で紹介したことがなかったこともあり,この状況をぜひ報道したいと考えた。

 金融業や製造業,サービス業のシステム保守の現場をたずねると,保守の大切さを訴え,システムの保守性を高めるために,並々ならぬ努力を続けている担当者の方々にたくさん会うことができた。しかし同時に,保守性を維持することの難しさもひしひしと感じた。保守性を維持することをあきらめてしまっている人がかなりいたのである。担当者のレベルでは十分な保守ができないという構造的な問題があった。

 システム担当者の保守性を高める努力については特集記事を参照していただくことにして,ここでは保守性の構造的な問題に絞りたい。保守性がどんどん劣化してしまう悪循環を断ち切ってほしい――そう願っているからだ。

 なお,ここでは保守の対象はアプリケーションに限定する。主に(1)新しいサービスや機能を実装するために,すでに稼働しているシステムに新しくプログラムを拡張する,(2)合併や分社化,制度変更などによって現行プログラム,データを改修する,といった保守作業について述べる。

保守を行うよりも全面的に作り変えた方が早い

 あるサービス業の取材で,システム担当者がエピソードを披露してくれた。その企業では,システム部門の規模が小さいこともあり,基幹業務システムの保守作業をベンダーに委託していた。業務内容の変化に合わせて何度となくアプリケーション保守を重ねていった。システム部門は保守作業の内容はまったく把握していなかった。いわゆる丸投げ状態だった。

 その結果,新規稼働から7年ほどたったとき,ある機能を拡張するアプリケーション保守作業にかかる費用の見積もりが,システム全体を再構築するのと同じくらい高額になってしまった。「その保守は,新事業を始めるために必須だった。保守費用が巨額になったため,結局はシステムを全面再構築したが,そのために新事業の展開が遅れてしまった。保守しづらいことが本業に大きく影響を及ぼしてしまった」とその担当者は振り返る。

 そこまで費用がかかるようになったのは,アプリケーションがスパゲティ状態になっていたからだ。ベンダーは保守作業のスピードアップを重視するあまり,既存のアプリケーションの変更個所を慎重に見極めることなく,その場しのぎでプログラムを付け足していた。システムが複雑になり,アプリケーションの一部を変更しようとすると,他のどこに影響が及ぶかがつかめなくなった。

 アプリケーションの影響がどこに及ぶかをつかめなければ,保守は非常に困難になる。保守で他のアプリケーションに影響が及べば,影響が出たアプリケーションを使っている業務部門の業務に支障をきたす。これではシステムに手をつけられない。

保守性の維持・向上を妨げる構造的な問題

 ここ数年,このような悪循環を断ち切る取り組みを進めている企業が増えてきた。いずれも「システムを動かしたあと,アプリケーション保守は必ず発生する」という考えで取り組みを進めている。保守作業時の影響範囲を特定しやすくなるようにシステムの情報を一元管理する,データの流れが明確になるようにシステムを図示してきちんと改訂する,モジュール化して保守しやすくなるように既存システムを構造改革する,といった対策をとっている。

 しかし,従来の「開発優先」から「保守ありき」へと考え方を切り替えていくことは,そう簡単なことではない。納期厳守,コスト削減の圧力など,制約が厳しいシステム開発では,悲しいかな前述のようなスパゲティ化を余儀なくされることがよくある。保守段階に入ると目先の期限に追われるあまり,システムの構造がぐちゃぐちゃになっていく。

 このような事態はシステムに詳しくなく,保守性の維持がいかに難しいかを実感できない人がプロジェクトの責任者になると頻発する。例えば,システムには素人の経営企画担当者が,「新サービスを始めるためにどうしても短期間でシステムを作ってくれ」という納期優先の要請をすることがよくある。このときにシステム担当者が押し切られ,付け焼き刃のような措置を講じると保守性が悪化する。

 保守作業を担当するベンダーが,保守性を考慮してくれるとは限らない。むしろ保守性が悪くなることを黙認することもある。保守工数が増えれば売り上げも増加するからだ。つぎはぎだらけのシステムになればレスポンスが落ちるので,ハードウエアの性能を高める必要も出てくる。「保守性が悪くなればなるほどベンダーは儲かる」という仕組みになっているのだ。

 保守性を維持・向上しようという意識がユーザー企業になければ,機能拡張や改修のたびにシステムの構造は悪化しやすい。システム構造が悪ければ,次の機能拡張や改修もその場しのぎになり,保守性はさらに悪くなる。この悪循環を断ち切るには,ユーザーが保守性に自ら気を配るしかない。「丸投げ,人任せ」では決して保守性を維持・向上できないのだ。

 ちなみに,保守ありきの考え方を取り入れなければならないのは,システム部門やベンダーだけではない。実はマスコミもそうだ。筆者はつい先日,あるコンサルタントからこのことを指摘された。コンサルタント氏いわく,「システム関係の雑誌って,新規開発の話しか取りあげないでしょ。それってどうかと思うよ。システムが本当に生きてくるのは,運用や保守フェーズに入ってから。雑誌はそこを取りあげなきゃ」。

 システム関係の雑誌作りに携わっている筆者にとっても,耳の痛いご指摘である。しかし耳の痛いご指摘ほどありがたい。システム開発に関するテーマもさることながら,システム保守やシステム運用といったテーマを積極的に取りあげていけるように努力していきたい。

(西村 崇=日経コンピュータ)

「プロジェクトマネジメント」に関心がある方へ
日本IBMでいくつもの大型プロジェクトを指揮し、現在PMリサーチ代表取締役として後進の指導にもあたっている岡村正司氏が、プロジェクトマネジメントの実践的なノウハウを定員50人のクラスで丁寧に伝授します。
詳しくはこちらのページをどうぞ。

9月15日(水)・東京「世界標準PMBOKを活用したプロジェクトマネジメント実践研修~プロジェクトを赤字にしないためのポイント~」
10月20日(水)・東京「プロジェクト・マネジャが知っておくべき物作りのセオリー~システム開発に必須の基本技術をマスターする~」
主催:日経コンピュータ