PR

 続発するシステムのトラブルが大きな被害をもたらしている。航空管制システム(関連記事)やジャパンネット銀行(関連記事)など,システムの停止が生活を直撃することも珍しくない。“停止”以外にもトラブルはある。東京証券取引所では,約定などの情報が増加したことで,情報配信が遅延。社会保険庁では,“正常稼働”していたものの,プログラムのミスが見過ごされ,過去4年間にわたり約24億円の年金の払い過ぎを招いた。

 トラブルの原因は多様だ。プログラムのバグや運用上のミス,ハードウエアの故障など,不具合が重なって復旧に手間取ることもある。どうすればトラブルは防げるのか。日経システム構築の8月号 特集「システムはなぜ止まったのか」では,ユーザーの再発防止策から,そのポイントをまとめた。

 システム面の対策はこの特集で詳しく書いたので,ここでは体制面に触れたいと思う。特に,トラブルをはさんだユーザーとベンダーの責任範囲である。ほとんどの場合,トラブルの発端はベンダー側のSEのミスだった。ベンダー側の責任はもちろん重い。しかし,原因や再発防止策を取材するにつれ,ユーザー側もベンダーのミスをチェックできる技術力,あるいは管理能力をより強化しなければならない,と強く感じるようになってきた。

ユーザーの管理責任が問われる

 例を一つ示そう。5月8日に発生したジャパンネット銀行のトラブルである。午後6時過ぎに突然データベース・サーバーが停止。その後,22時間にわたり全業務が利用不能に陥った。
 
 トラブルの原因は,富士通製のファイル管理ソフト「SafeFILE」のバグにある(関連記事)。5月4日の休日にファイルを拡張した際,このバグの作用により,SafeFILE上のステータスに矛盾が発生。8日にOracleがこのファイルにアクセスしたタイミングで,SafeFILEが異常を検知してシステムがダウンした。

 このバグは,昨年6月に適用したパッチにより,SafeFILEに潜在的に埋め込まれた。しかも,その後,1年間も放置された。SafeFILEの不具合,該当パッチの内容や適用方針などについて富士通は,「特定の顧客にかかわることなので,一切お話できない」(広報部)とする。しかし,ジャパンネット銀行を担当する富士通のSEが,バグの内容をきちんと把握していたかは疑わしい。

 その理由は,5月4日に実施されたメンテナンス作業の手順を見れば明らかだ。当初の計画では,(1)SafeFILEにパッチを適用し,その後に(2)データベース・サーバーのファイル拡張を行うことになっていた。この計画は富士通が作成し,ジャパンネット銀行が承認した。ところが実際は(2)(1)の順で作業を実施。そのために,拡張したファイルの一部に,SafeFILE上のステータスの矛盾が発生してしまった。バグの影響を理解していれば,担当者は計画どおりに作業を進めたはずだ。

 さらに,作業後のステータス確認にも漏れがあった。SafeFILEにパッチを適用した際はステータスを確認することになっている。ところがデータベース・サーバーについては,5月4日に確認したファイルはサーバー機の内蔵ディスクのみ。ファイルを拡張した共有ディスクは確認しなかった。

 作業手順が守られず,ステータスの確認が漏れた――これら2つのミスが重なり,本番までバグが持ち越された。もちろん,SafeFILEにバグを潜ませた富士通には,トラブルを引き起こした責任がある。5月4日の一連の作業ミスも同様だ。しかし,ジャパンネット銀行にバグを発見するチャンスはなかったのか。これが筆者の疑問だ。

 5月4日のメンテナンス作業後,当然,富士通から報告が上がったはずだ。作業手順やステータス確認など,どのように報告されたかは明らかではない。確かなことは,ジャパンネット銀行が報告に対して疑問を持てなかったこと。原因は,富士通の報告の仕方に不備がある,またはジャパンネット銀行の理解力が不足している,あるいはその両方だ。ジャパンネット銀行は「作業の管理責任は免れない」と認識し,再発防止策を策定している。

ユーザー側の管理能力の低下もトラブル増加の一因

 他の大規模なトラブルでも,やはりベンダー側だけでなく,ユーザー側の管理能力にも問題があった。例えば航空管制システムのトラブルも,プログラムにチェック機能を実装し忘れたのはNECだが,国土交通省がテストを徹底していれば不具合は発見できた(関連記事)。郵政公社では,公社化に伴うプログラムの開発やテストをベンダー主導で,しかも短期間で進めた結果,国庫金データを作成するシステムなどでバグが多発した。

 特に大規模なシステムでは,ベンダーと組んでシステムを構築,運用することはごく普通だ。例えば,プログラム開発にベンダーの力を借りた場合,バグを取り切れないのはベンダーに責任がある。しかしユーザーには,バグが本番に流れ込まないように抑え込む責任がある。これが筆者の考えだ。当たり前のようだが,テストや作業の検証といった,ユーザー側の“管理能力”の低下が,トラブルを増やしている要因の一つではないか。

 実際,トラブルに遭遇したユーザーの再発防止策には,ベンダーの仕事をシステム・レベルで理解,管理しようという動きが目立つ。「システム構築の節目で,システム部門からきちんと意見を求めることを制度化した」(日本郵政公社 貯金事業本部),「これまでのシステム運営・管理体制を見直し,当社とベンダー各々の運用管理者が緊密な連携を行う」(ジャパンネット銀行),「プログラムの品質保証のための請負者の監督指導体制の強化」(国土交通省)などだ。

 トラブルの事例を並べてみると,システムの技術的な面へのユーザーの関心が希薄になっていたのではないか,と感じるケースは少なくない。「行き過ぎたアウトソーシングの弊害」と断ずるのは簡単だが,システムの複雑化などにより,「システム全体を理解することが難しくなってきた」といった事情もある。

 「外部の力を借りる限り,技術への関心が薄くなるのは当然」との声もあるだろう。しかし,技術への関心を失えば,トラブルの発生原因さえ「プログラムのバグ」で止まり,その先の中味が追い詰められなくなる。

 開発や運用自体をベンダーに任せても,作業内容を的確に理解して管理する技術力を内部に保てるか。その能力の有無が今,ユーザーに問われている。ベンダーを疑えと言っているわけではない。ただ,ベンダーとわたりあえるだけの技術力がなければ,システムの安定性や性能が保てない。頻発するトラブルを通して,こうした技術力を土台にしたユーザー側の管理能力の必要性が再認識されてきたのだ。

(森山 徹=日経システム構築副編集長)