orangeitems’s diary

クラウドで働くエンジニアの日々の感想です(ほぼ毎日更新)。

システム障害と反省文と役員会での朗読の話

f:id:orangeitems:20190518141442j:plain

 

システム障害と反省文

ちょっと面白そうなお話です。

 

togetter.com

 

 

 

考察

私もいくつものシステム障害を経験してきましたが、何となくこのトップの気持ちがわかるんですね。ネットでは非難轟々ですが。

障害報告書、特に社内向けのものについては、

・直接の関係者へその上司がヒアリングする
・上司が障害報告書を作成する
・そのまた上司に報告し修正が入る/担当の役員と協議する
・最後に社長に役員から報告をする

というフローになることが多いと思います。

ここで障害報告書を作成するのが上手な人がいるんですよね。私もこの文章を書くのが得意な方なので結構大量に作らされました。その過程で、何となくフィクションと言うか都合のいいストーリーが生まれるんですね。私もそうですが、「どうすれば、この問題に対して、運用者はベストを尽くしたのだけれども残念ながら、万が一の障害が発生してしまったのだ」という道筋を考えようとします。この時点で推理小説家のようです。これも悪いことばかりではなく、ユーザー側も「納得できる理由がわかればよい、関係者に早く説明したい。」ということで、ニーズとしては十分にあります。

なんとなく分かりやすするために、「話を盛る」とか「あえて間引く」とかやるんですね。嘘はついていない。例えば発生頻度について、「たまに」「ごく稀に」「過去事例のない初めての」みたいな形容詞をうまく使うことで、避けようがないような印象操作をするのが障害報告書です。

しかし、この仕事の仕方について、短所があります。本当の真実とズレて行ってしまうのです。特にトップ(社長)までとなると、そこまでの伝達経路にいろいろな政治家がいるので上がってきた話が真実と異なることはよく起きえる話です。もし本当の事実をもっと事前に知ることができたなら。特に現場をよく知っている社長は、障害報告書が作られる過程でいろいろなノイズが入ることを身に染みています。ノイズを入れて来た本人なケースも多いです。

会社において、一社員が役員会に呼ばれ、直接報告をしなければいけないというのは相当なストレスだと思います。以前、ドラマの半沢直樹で、主人公が役員会に呼ばれて、担当役員に倍返しをするなんて場面がありましたが、普通の神経ではできませんよね。反省文の朗読会、というのはその揶揄した表現だと思います。なかなかそんな場で、自分の意見を堂々と言える人はいないと思います。逆にいた場合は、すごく嫌われるリスクもある反面、気に入られるメリットもあります。いい面も悪い面もあります。

ただ、これまでの伝統的な階層構造の組織体系から、フラット化した組織体系になるとそういうことも日常の風景になることもあるのかなと思います。本来末端の社員を守るべき中間管理職はどんどん省略されていっている社会です。経営層-事業部長-チームぐらいの三層構造になってくると、直接聞いた方が良いという判断もあり得るのかなと思います。

まあ、責任が担当者にあることが前提・・というのはおかしい、責任を決めるのは最後でいいですからね。

ただ、こういった方法を取った理由を考えると、余計な第三者が挟んで都合よく情報を捻じ曲げないために、トップと直接共有しようということなんだと良心的に解釈しようと思えば思えます。担当者は役員会のメンバーから袋叩きにあっているような印象しか持てず、このような感想になっているのであれば、それはトップの説明不足としか言いようがないのかと思います。この仕組みは改善できそうな気がします。

 

どう改善するか

あまり情報がない中、担当者が直接役員に障害報告を行う仕組みにするなら、私ならこうすべきかなと思います。

1)トップが、担当者が直接役員まで報告することの目的を、全社員に説明する。
2)反省文、ではなく障害報告であることを強調する。
3)正しく報告することが責任であり、障害の責任を取る必要はないことを強調する。
4)障害報告までが責任であり、その再発防止策については個人的な見解として述べること。最終的には組織で考え、標準化していくこと。

経緯や状況については直接担当者から報告させた方がいいという判断自体は一理あると思われ、あとはその担当者が精神的な負担を抱え込まないよう、ケアをしていくべきかと思います。特に人前で報告したり話したりするのが苦手な人もいますので、昔はそのあたりを中間管理職が助けてくれたこともあり、今っぽい課題だと思います。

そのうち、AI課長とかAI部長とかが助けてくれるのかもしれませんけれども・・(冗談抜きで)。