プリンタから出てきた請求書に誤りがあった。それを見たメイン・システムの担当者が叫んだ。「おい，これはいつの仕様だ？後で顧客から入った仕様変更が反映されていないじゃないか」。請求書をのぞき込んだサブ・システムの担当者は驚いた。「そんな仕様変更，聞いていませんよ」---。システム構築に携わる人と人の隙間(すきま)が，繰り返しシステム障害を引き起こしている。

　2006年2月に公開した記者の眼「あなたと同僚の“すき間”がシステム障害の温床に」では，ITpro読者にシステム障害に関するアンケートをお願いした。難しいテーマにもかかわらず，230件の回答が寄せられた。大変遅くなったが，協力していただいた方々に，この場を借りてお礼申し上げる。アンケートでは，どのようなシステム障害を経験したか，そこにどのような人と人の隙間が潜んでいたか，を聞いた。隙間を挟んで対峙していたのは，開発担当者と運用担当者，ユーザー企業とSIベンダーの担当者などであった。

　アンケートに回答していただいた何人かに，実際に会って話を聞いた。インタビューを通じ，「なぜ隙間が生じたのか」「どうすれば隙間は埋められるのか」を掘り下げるためである。取材結果は，日経SYSTEMSの連載コラム「深層ルポ●なぜ繰り返すのか システム障害」に全6回で掲載した。冒頭に紹介した請求書のエピソードはその一つである。

　「仕様変更が反映されていない」と叫んだのは，メイン・システムを担当する元請けのプロジェクト・マネージャ(PM)。サブ・システムの担当者は下請けのPMである。元請けのPMは，顧客から受けた仕様変更の要求を，下請けのPMに伝えなかった。その理由は，自分が担当するメイン・システムの変更を優先したから。しかも「伝えるのが遅くなっても，なんとかするだろう」と気楽に考えていたからだ。この行動の背景には，下請けのPMが元請けのPMに“御用聞き”に回って，顧客からの情報を教えてもらうという運用が常態化していたことがある。障害を引き起こす隙間は，日常に潜んでいた。日経SYSTEMSでは，こうした隙間を5つのパターンに分け，18のケースを紹介してきた。9月号での連載完了を機に，ここでアンケート結果とコラムを簡単にまとめたい。


アンケート・トップは「設計担当者と開発担当者の隙間」

　カットオーバーしたシステムには様々なシステム障害が待ち受けている。バグによる処理停止や処理誤り，過負荷による処理遅延，対策不足によるデータ漏えいなどだ。これら障害の直接的な原因は，例えばカットオーバー前のテスト不足にあるかもしれない。では，なぜテストが十分にできなかったのか。その間接的な原因として，人と人の間にある“隙間”に注目したのである。

　開発担当者や利用者，SIベンダーや情報システム部門など，システム構築にかかわる人の数は多い。各人には期待される役割があり，要求定義や開発，テスト，運用といったプロセスに応じた仕事を担う。こうした守備範囲にズレがあれば隙間が出来る。そこに「誰のものか分からない仕事」が残り，その結果がテスト不足などにつながっていく。こうした隙間を意識しなければ，いくらテストの徹底を叫んだところで，システム障害は繰り返されるのだと筆者は考える。野球に例えれば，誰もカバーしていない隙間には何度でもボールが落ちる。

　先のアンケートを集計したところ，最も多くの回答があった隙間は「設計担当者と開発担当者の隙間」(27件)。それに，「開発担当者と運用担当者の隙間」(25件)，「運用担当者同士の隙間」(15件)が続く。

　こうした隙間の種類によっては，障害に至るパターンが存在する。例えば，設計担当者と開発担当者の隙間。「特定の時間帯にサーバーのCPU負荷が大幅に高まり，レスポンスが大きく低下してしまった」(SIベンダー)というように，この隙間を原因とする障害は処理遅延が多い。似たようなアンケート回答を並べて見ると，システムの処理負荷について，設計担当者と開発担当者が合意しないままシステムを構築した結果，障害を招くというのが典型的だ。データ件数の見積もりが甘くて処理遅延に直面したあるケースでは，「“大量データを想定してきちんとテストして”と設計者が伝えたにもかかわらず，開発者は十分なテストを行わなかった。設計者はテスト結果をきちんと検証すべきだったし，開発者もどれくらいの件数が必要か設計者に確認すべきだった」(SIベンダー)と，両者の隙間がアンケートに記載されていた。


“相手への無関心”が大きな問題

　隙間の多くは，「あれを聞いておけば」「これを伝えておけば」といった担当者の踏み込み不足から生まれる。踏み込めない要因は様々ある。ある役所の文書管理システムは，開発担当者と運用担当者の隙間が原因で，キャパシティ不足に陥った。この役所のシステムを運用してきた運用担当SEが，文書管理システムを構築する開発担当SEに対して，キャパシティ要件を伝えなかったからだ。開発担当SEもアドバイスを求めなかった。運用担当SEと開発担当SEは，先輩／後輩の仲にあり，開発担当SEは先輩への遠慮から，隙間を埋めるための動きが取れなかったのだ。

　「遠慮」や「思い込み」「縄張り意識」など，連載コラムでは踏み込めなかった要因をいくつか紹介した。それらの中で，「相手の仕事への無関心」は最も大きな問題だと感じている。自分の仕事に打ち込むほどに，他人の仕事には無関心になりがちだ。しかも，無関心からは隙間を埋めようという力が生まれづらいからだ。あるプロジェクト・リーダーは，同僚の代理でソースコードのレビュー会に出席したものの，“代理だから”となおざりなレビューを行ってバグを見逃した。それが原因でEAIシステムが停止してしまった。このリーダーは，自分のプロジェクトでは「ミリ秒単位の応答性能にこだわる」ような，品質に対して厳しい目を持つ人物。普段の実力を考えれば，気づいて当然のバグだった。たとえ代理と言えど，引き受けたからには，責任を持って仕事を肩代わりすべきだろう。

　また，ある財務部の担当者は，独自にEUCシステムを作り，システム部門に伝えずに販売管理システムに接続していた。情報システム部門が販売管理システムを刷新したタイミングでEUCシステムが利用できなくなり，「以前のシステムに戻せ」と騒動になった。財務部の担当者は，情報システム部門の担当者にEUCシステムの存在を知らせておくべきだった。一方の情報システム部門の担当者も，刷新に当たって他システムへの影響を十分に調査すべきだった。

　こうして連載コラムを見直すと，もう少し相手の存在や役割に関心を持つだけで，埋められる隙間も多いと感じる。あなたがいる現場は，チーム・メンバー同士の関心が保たれ，一体感があるだろうか。「愛称が付かないプロジェクトはうまくいかない」と，よく言われる。ここで愛称は，プロジェクトがメンバーに愛され，一体感があることの象徴なのだろう。「急発進」や「超短期」といった単語が付くプロジェクトが増えている今，プロジェクトの一体感を醸成する時間が削られていることが想像できる。日経SYSTEMSの10月号では，「エンジニアの元気」をテーマにした特集記事を掲載する予定だ。取材は山場を越えたが，ここでも「一体感」が一つのポイントになりそうである。