新幹線トラブルに見る、開発部門と運用部門の情報格差

1/17（月）午前8時23分、JR東日本の運行管理システム「COSMOS（コスモス）」の運用でトラブルが生じ、JR東日本新幹線が全線不通になる事件がありました。

そのトラブルは、列車のダイヤを管理する画面の表示が部分的に消えてしまったというもので、駅側に正しくデータが届いているかを確認するために、全ての新幹線の運行停止判断を下したそうです。

1時間15分後に自然復旧したため、運行は再開されましたが、逆に「障害が起きたのにどうして自然復旧したのか？」という、システムエンジニアなら一番困るパターンに陥ってしまい、しばらくの間はJR東日本のデータセンターにベンダー担当が貼りつく予定になっていたことがプレスリリースされたのは18日の朝のこと。

しかし、その後の調査により、実は運用担当部門がシステムの仕様を知らされていなかったことで、規定の動作を「障害」と誤判定してしまったことが判明しました。

『都内にある新幹線運行本部のダイヤ管理用モニター２２台すべてで、各列車の駅への到着予定時刻を示す線が消え、運行指令はシステムの不具合が起きたと考えて全列車を止めた。

ＪＲ東によると、この日朝、雪で福島県内の東北新幹線のポイントが故障し、２４本の列車ダイヤを変更することになった。この際、修正必要箇所がシステム上限の６００件を超えて線が一時的に消えたという。

システム部門はこうした表示の仕組みや修正上限数を把握していたが、運行指令は知らされていなかった。』
http://www.asahi.com/travel/rail/news/TKY201101180470.html

なんだかよく見たことのある光景です。システムの開発側は要件を定義して構築する側ですから、細部に渡る仕様も熟知しているものですが、その情報がどこまで運用部門に伝えられるかは、その開発プロジェクトの多忙度合と開発側の献身性に委ねられているといって過言ではありません。

私が関わったことのある銀行のシステム運用部門では、ある日突然サーバ機器がマシンルームに搬入され、後から開発部門の人が「2週間後にシステムが稼働するから運用よろしく」という事態が日常的に発生しています。

これらの問題が生じる組織というのは、開発側と運用側の交流が限定的であり、少なくないケースで、むしろ敵対関係にあったりします。そして、多くの組織では、開発側よりも運用側の方が立場が弱いのです。

運用側の立場が弱い最大の理由は、開発側の方がハイスキルな人材が揃っており、スキル的にすでに負けているからです。システム開発ベンダーの単価（平均100万円/月以上）と運用ベンダーの単価（平均80万円/月以下）を見比べるだけでも明らかですね。スキル的に負けているからこそ、開発側が運用側に資料を授ける、という構図がこれまで当たり前だったと思います。

でも、今回の件でJR東日本は、運用標準を見直して改善活動を行うプロジェクトを、運用部門主体で立ち上げるでしょう。開発文書の読み直しから入って、必要な運用文書を作成することもきっとやると思います。このような事件がなければ、運用側優位の立場でここまでの取り組みはされないと思われます。

今回、JR東日本の運行部門の方々は、自身の立場の向上につながるだろうという意味で、不幸中の幸いになるやもしれません。

実はここまでのJR東日本の話は、その他多くの企業についても当てはまる話です。新聞沙汰になるようなシステムトラブルを経験しない限り、コストを払って劇的な改善を行うなんて、普通の経営者はしません。なぜなら、運用組織は一般的にコストセンターだからです。

でも、常日頃から運用業務の重要性を経営者にアピールする活動を続けていれば、だんだん雰囲気が醸成されて、「うちの組織ももうちょっと運用を高度化しないと駄目だ」と思わせることができるようになります。その段階で、IT部門のトップから「ITIL準拠プロセスの整備」といった号令を下すことになれば、きっとその組織の運用を取り巻く環境は改善します。

いざというときのため、日頃から地道な運用啓蒙活動を続け、運用現場のプレゼンス向上させていきましょう。