原因追及はすぐにやらない〜情シス目線のプロジェクトマネージメントTips#57

世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。

今回のテーマはシステム障害が合ったときの「原因追及」をやるタイミングの話です。

システム障害の原因は？

システム障害が発生したときには、おそらく大抵の人は原因を追究すると思います。原因を特定して、処置を施し、現象が再度起きないようにする・・・・「ダウンしているからとりあえずリブート」「とりあえず切り戻し」みたいなケースもありますが、これが基本的には対処法だと思います。

しかしながら「原因」というものは大抵の場合２つ存在しています。

障害に直接対処するエンジニアは、その障害の直接の原因を探ろうとします。障害で発生したエラーログの内容を確認したり、障害が発生する直前直後のログを解析したり、ベンダーへログを送って解析してもらったり、再現テストを繰り返したり・・・・と専門性と集中力が必要な作業をします。

逆にマネジメント層、時によって営業側の人達は、技術的な原因ではなく、なぜ障害が発生する状況になったのか？どの作業プロセスが悪くて障害のきっかけになったのか？を探します。場合によっては「誰のせいなのか？」を探すことになります。SIerが完成請負で納入したシステムの場合には瑕疵責任・・・・つまりお金のやり取りに関わる大事なことだからです。

犯人探しになりがちな原因追及

この「犯人探し」は非常に厄介な事態です。

原因追及が犯人探しになってしまうと、非常に厄介です。関係するそれぞれのメンバーが「自分の保護」に走ることになってしまうからです。こうなってしまうとミーティングをしたところで真実を話さなくなるからです。たとえ自分が犯人になる可能性がなかったとしても、誰かを貶めることになりかねませんし、下手をすれば犯人を追究する役割を押し付けられてしまうかもしれません。

よく航空機事故においては調査委員会は証言者に対して司法取引で免責を与え、真実を追究するという話がありますが、まさにこの「犯人探しによる硬直状態」「真実の隠蔽」を避けようとする動きです。

完成請負の場合、どうしても瑕疵責任があるので責任はユーザー企業かベンダーかを追求したくなりますが、これをやると泥仕合になるのは明白です。

解決もしてないのに犯人探し？

非常に良くない「犯人探し」ですが一番まずい状況は、まだ解決していないのに犯人探しが始まることです。

「犯人探し」ではなく「原因追及」だから大丈夫だと思う人もいるかも知れませんが、それは大きな間違いです。SIer・ベンダー側の人達は長い歴史の中で責任を追求され、犯人扱いにされ、時には心無い元請けに犯人を押し付けられてひどいことに会ってきたのです。エンジニアの多くにはすでにDNAの如く、その恐怖だけが刷り込まされています。マネジメント的な意味の「原因追及」が始まった途端、真実は闇の中に頬むられます。

もっとまずいのは障害にリアルに対応しているメンバーの思考が停止することです。そして足がすくんで進めなくなることです。もし自分の考えた対応策が空振りだったら・・・万が一、二次的被害を生んだなら・・・・つまりは悪目立ちしただけで、全責任を取らされかねないのです。

これでは応急措置すらままならない状況に陥ってしまいます。

少なくとも解決するまでは棚上げ

とはいえ双方の偉い人たちからは「何が原因だ！！」という突き上げが激しく行われます。何もコントロールしなければ、確実にそれは対応しているエンジニアの耳に入り、一気に硬直状態に陥ってしまいます。

この状況をなんとかできるのは「ユーザー企業側のプロマネ」しかいません。SIer・ベンダー側のプロマネはこれに贖うことは非常に難しいので、防御線は早々に崩壊するのは確実です。「ユーザー企業側のプロマネ」がきっぱりと

「その話はすべてが終わったあとにしましょう。今は眼の前の障害に向き合いましょう」

と言い切らないといけないのです。