システムの設計や実装を担当する開発SEと，完成したシステムの安定稼働を支える運用SE。両者の間に隙間があれば，システム障害を招くだけでなく，障害からの復旧も長引く。

　両者が歩み寄り，適切に守備範囲をカバーしていれば隙間は生じない。しかし，踏み込みの加減を誤れば，両者の関係にヒビが入り，それが隙間へと発展する。相手への遠慮からくる踏み込み「不足」，専門外に横槍を入れる踏み込みの「過剰」は，いずれも加減を誤った例だ。

　また，開発SEと運用SEの関係では，“開発SEが運用SEよりも立場が上”とするヒエラルキーが根付いていることも大きな問題だ。ヒエラルキーにより，開発側は運用側を下に見る。運用側はそれに対して少なからずコンプレックスを抱く。それがやがてわだかまりとなり，隙間が生まれていく。こうした“構造的な隙間”も取り除かなければ，システム障害は繰り返される。

　「これじゃあ仕事にならないじゃないか」――。ある年の4月1日，ある役所で稼働したばかりの電子文書管理システムは，パフォーマンスに大きな問題があり，職員から非難が殺到した。データ登録をしてもレスポンスがなかなか返ってこない，登録済みの文書を検索してもしばらく反応がない。パフォーマンスがあまりに低く，時には全く動かなくなることもあった。

　直接的な原因はキャパシティの不足。役所の職員約500人がほぼ同時にアクセスする状況を，システム設計時に考慮していなかった。アプリケーションを開発したSIベンダーA社の田中重之氏（仮名，27歳）は「500人も同時アクセスされるとは知らなかった。もし分かっていれば，時間を割いてでも負荷テストを実施していた」と振り返る。役所側が作成した要件定義書には，画面ごとに「3秒」や「6秒」というレスポンスタイムの記載があるだけ。想定される接続端末数や同時アクセス数の記述はどこにもなかった。

　田中氏は，この役所のシステム運用を手掛けていた先輩の菊池紀夫氏（仮名，30歳）が何でそれを教えてくれなかったのかといぶかる。しかし，それも“後の祭り”。田中氏自身は既に，5月末のカットオーバーを目指す別のプロジェクトにサブリーダーとして参加しており，電子文書管理システムからは離れている。後は運用SEである菊池氏に託した。「運用時の障害対応は菊池さんの仕事だ。しゃしゃり出る必要はない」。田中氏は新たなプロジェクトに専念した。

　障害対応を託された菊池氏は困惑していた。技術力が乏しい菊池氏は，自分の力で復旧できなかったのだ。そこで後輩の田中氏を呼び付け，こう言った。「この障害は設計ミスだろう。だから対応は任せるよ」。職員からのクレームが相次ぐ中，菊池氏は何とか田中氏に復旧してもらわなければ，自分の面目がつぶれると焦っていた。

[画像のクリックで拡大表示]

　仕方なく，田中氏は対症療法を菊池氏に伝える。田中氏は，パフォーマンスが悪い原因として，Webアプリケーション・サーバーの「IIS（Internet Information Services）」があやしい，とにらんでいた。そこで「IISの再起動」という回避策を伝え，自分のプロジェクトへと戻った。

　それから1カ月半。既にゴールデンウィークも明けていた。にもかかわらず，菊池氏はいまだにIISの再起動を繰り返し，根本的な原因を解決していなかった。システムが全く使えないことはなかったが，時間帯によっては耐え難いパフォーマンスだった。

　ある日，そうした状況を同僚に聞かされた田中氏は，その怠慢ぶりに呆れた。しかし，さすがに何とかしなければと感じ，上司に相談。1日だけ現在のプロジェクトを離れる許可をもらい，対応に当たることにした。

　田中氏が障害対応に当たると，その原因が極めて単純であることが明らかになった。IISのプロセスの起動方法が，デフォルト値である「インプロセス」になっていたのだ。インプロセスとは，Webサーバーが動作するアドレス空間でプロセスを立ち上げるモード。これを独立したアドレス空間を使って，それぞれのプロセスを立ち上げる「アウトプロセス」に設定し直すと，いとも簡単にパフォーマンスは向上した。

　田中氏は，開発側がIISのパラメータの一覧を運用側に渡していないことを反省したが，「こんなのマニュアルを見ればすぐに分かるじゃないか」と，障害を放置した菊池氏の神経を疑った。

　一方の菊池氏。無事にシステムが復旧したことにまずは胸をなで下ろし，田中氏にこう言った。「こんなに簡単ならもっと早く直してくれればよかったんだよ」。田中氏は開いた口がふさがらなかった。障害発生から既に，2カ月あまりが経過していた。

　このケースでは，開発SEと運用SEの隙間によって大きく二つの問題が生じた。一つは，500人という同時アクセスの状況を知り得る立場にある菊池氏がシステム設計時に田中氏にアドバイスしなかったこと。田中氏も菊池氏にアドバイスを求めなかった。その結果，「3秒」「6秒」といったレスポンスタイムを満たしているか否かを，田中氏は自分のPC1台でテストし，問題無しと判断した。500人の同時アクセスを想定した負荷テストは実施されることがなく，カットオーバー後にシステム障害を招いた。

　もう一つの問題は，両者に隙間があったために，IISのパラメータを1カ所変更すれば済むような修正を，2カ月あまりも放置したこと。菊池氏は障害の責任を開発SEの田中氏に押し付けた。一方，田中氏は先輩に遠慮して障害対応作業から身を引いた。結局，スキルが足りない菊池氏が「再起動」に頼り続け，障害を長引かせた。

　田中氏は「先輩への遠慮」を捨て，障害復旧を優先すべきだった。菊池氏の責任感のなさや怠慢ぶりには呆れるばかりだが，そこで遠慮していては，また同様のシステム障害は繰り返されるだろう。