続発するシステムのトラブルが大きな被害をもたらしている。航空管制システム（関連記事）やジャパンネット銀行（関連記事）など，システムの停止が生活を直撃することも珍しくない。“停止”以外にもトラブルはある。東京証券取引所では，約定などの情報が増加したことで，情報配信が遅延。社会保険庁では，“正常稼働”していたものの，プログラムのミスが見過ごされ，過去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だが，国土交通省がテストを徹底していれば不具合は発見できた（関連記事）。郵政公社では，公社化に伴うプログラムの開発やテストをベンダー主導で，しかも短期間で進めた結果，国庫金データを作成するシステムなどでバグが多発した。
特に大規模なシステムでは，ベンダーと組んでシステムを構築，運用することはごく普通だ。例えば，プログラム開発にベンダーの力を借りた場合，バグを取り切れないのはベンダーに責任がある。しかしユーザーには，バグが本番に流れ込まないように抑え込む責任がある。これが筆者の考えだ。当たり前のようだが，テストや作業の検証といった，ユーザー側の“管理能力”の低下が，トラブルを増やしている要因の一つではないか。
実際，トラブルに遭遇したユーザーの再発防止策には，ベンダーの仕事をシステム・レベルで理解，管理しようという動きが目立つ。「システム構築の節目で，システム部門からきちんと意見を求めることを制度化した」(日本郵政公社 貯金事業本部)，「これまでのシステム運営・管理体制を見直し，当社とベンダー各々の運用管理者が緊密な連携を行う」(ジャパンネット銀行)，「プログラムの品質保証のための請負者の監督指導体制の強化」(国土交通省）などだ。
トラブルの事例を並べてみると，システムの技術的な面へのユーザーの関心が希薄になっていたのではないか，と感じるケースは少なくない。「行き過ぎたアウトソーシングの弊害」と断ずるのは簡単だが，システムの複雑化などにより，「システム全体を理解することが難しくなってきた」といった事情もある。
「外部の力を借りる限り，技術への関心が薄くなるのは当然」との声もあるだろう。しかし，技術への関心を失えば，トラブルの発生原因さえ「プログラムのバグ」で止まり，その先の中味が追い詰められなくなる。
開発や運用自体をベンダーに任せても，作業内容を的確に理解して管理する技術力を内部に保てるか。その能力の有無が今，ユーザーに問われている。ベンダーを疑えと言っているわけではない。ただ，ベンダーとわたりあえるだけの技術力がなければ，システムの安定性や性能が保てない。頻発するトラブルを通して，こうした技術力を土台にしたユーザー側の管理能力の必要性が再認識されてきたのだ。
（森山 徹＝日経システム構築副編集長）
