「成り行きで注文しても全然約定しないんだが」--顧客からの1本の電話で，証券取引システムに障害が発生していることが分かった。システムの処理能力が限界に達したのだ。顧客からのクレームや問い合わせは後を絶たず，午前中のうちに1000件を超えた。
「障害が起きましたので，後はよろしくお願いします」。この金融機関でシステム開発・運用を手掛けるシステム子会社E社の運用SE，山崎憲司氏（仮名，32歳）は，先輩の開発SEである石川進氏（仮名，42歳）にこう伝えた。石川氏はベテランの開発SEで，同システムの開発にも携わった1人である。チーム内の信頼も厚かった。
石川氏は，「いったいどんな障害なのか」「おおまかな原因は何なのか」といった報告を一切しない山崎氏に不満を募らせた。「運用SEの仕事を完全に放棄しているな。全くやる気がない…」。障害対応に当たるチーム・メンバーを遠巻きに見ていた山崎氏は，「どうせ評価も処遇も低いんだから，まともにやっていられるか」とつぶやいた。
障害の原因はデータベース設計にあることが判明した。同システムは，注文を受け付けるDBサーバーと株価をリアルタイムに更新するDBサーバーを物理的に分けていた。それをデータ連携機能によってマッチングしていた。この処理形態において，注文数が急増したために，データベースやネットワークの負荷が高まりパフォーマンスが低下してしまったのだ。
そこで石川氏は，注文受け付けと株価更新のデータベースを同一サーバー上で稼働させた。同時にプログラムを一部修正してデータ連携機能を使用しないようにした。その結果，処理の遅延は解消された。
プログラムを修正している間，山崎氏の対応に，石川氏の不満は高まるばかりだった。まず，アクセス・ログなど障害対応に必要な情報を一切開示しなかった。さらに，実は過去に何度も同様の障害が発生していたことが分かったのだ。たとえ今回のようにシステムが停止に至らなくても，日々のログやパフォーマンスの状況を確認していれば，DBサーバーの性能が限界に迫っていることは容易に把握できたはずだった。ところが当の山崎氏は，パフォーマンスに問題があってもサーバーの再起動で回避し，障害の報告も一切していなかった。
システム障害の直接の原因は，過去に何度も同様の障害が発生していたにもかかわらず，それを運用SEの山崎氏が何ら報告していなかったことだ。山崎氏は事前にシステムの危機を知っていながら，そのたびにサーバーの再起動を繰り返してしのいでいた。その揚げ句，システム障害を引き起こした。
しかし，根本的な原因は，山崎氏がやる気を喪失していたことにある。このシステム子会社では「優秀な人材は開発担当に，そうでない人材は運用担当に」という周知のルールがあり，評価や処遇にも差があった。20代後半に運用部門に配属された山崎氏は，自信とやる気を失い，学習意欲もなくなった。これではスキルも向上せず，本来やるべき仕事もこなせない。いくら石川氏が山崎氏を育てようとしても，両者の隙間を埋めることは困難だった。
開発SEの方が給与が高い，出世が早いという組織は少なからずある。このケースのようにそれを公言している限り，開発SEと運用SEの構造的な隙間は埋まらない。
