エンジニアが、システム障害と「向き合う」

つい昨日、2～3年前に読んだ本を読み返しはじめました。

システム障害はなぜ二度起きたか　みずほ、12年の教訓（日経BP Next ICT選書）

いくつになっても、第一線の現場から離れても、やはり逃れられませんね。障害。自分が引き続きこれからどう向き合っていこうかの考えを巡らせる中で、他の方からどんなFBが返ってくるのかを見てみたいと思い、まとめてみた備忘を公開します。

障害（バグ）は出したくない

当たり前ですが、出したくて出してる人なんて全くもっていません。ついでにいうと、出してもいいやと思っている人も全くいません。本当に見たことはないです。しかし、障害はでる。そう、強いて言うのであれば、「出したくないので有効な施策を講じていない人」はいます。あしからず。

手を抜いたつもりもない

障害を出してしまった当の本人は、確認をおろそかにするつもりもなければ手を抜いているつもりもありません。一生懸命自分に思いつく限りの確認をしているのです。強いて言うのであれば「思いつく範囲や切り口が少ない人」はいます。あしからず。

でも後悔している

障害を出したいなんて思ってもおらず、手を抜いているつもりもない、しかしそれでもなお、バグを出して後悔しない人もいません。
「あのときああしていれば」
「あのときは気づかなかったけれど、翌々考えてみれば確認して当然では」「今度からここは気をつけよう」
というむやみな思考がひたすらに頭を駆け巡ります。強いて言うのであれば「後悔した後に、自動的に発動する再発防止システム」を設けることをしない、反省をしない人はいます。あしからず。

あしからず、な人とそうでない人の言葉

あしからず、という表現をしてみたこともあり、ここで個人的に少しだけまとめます。

「ちゃんと○○する」という人と、「○○できないかもしれない」という人
→　私は『ちゃんと』という言葉は次のアクションに対して定義不可能なためあまり好きではありません。バグと向き合うときにはNGワードと捉えます。

「次こそは○○するためには」という人と、「二度と○○しないためには」という人
→　『次は』という言葉を使うと、どうしてだかわかりませんが、『次の次』を想像してしまう自分がいます。そして『次の次』でなんとかできると思う、と甘えてしまう自分がいます。なので使わないことにしています。言うならば、『二度としない』という言葉を使ったほうが、真剣に向き合う覚悟が決まります。

「想定が『甘かった』」という人と、「○○を想定していなかった」という人
→　「甘かった」の言葉で済ませてしまう時は、どこに問題があったのかの掘り下げから逃げてしまったときかもしれません。何かを特定して「想定してなかった」というと、「他にもないだろうか」と不安になって最後まで探してくれる自分がいると感じます。

その姿勢が、「誰か助けてくれ」という学びの渇望につながる

少々大げさなモノ良いですが、ここまでいって始めてようやく「自分だけではどうにもならない、誰かの助けが必要だ」「どこかの誰かから学びたい」「きっと解決した人間がいるはずだ」につながるのでしょう。

そこでようやく、「監視」「テスト」「QA」「SRE」「DevOps」先人たちの様々な戦いの痕跡の価値を知り、我が身として吸収していくことになるのだろうと。

障害（バグ）と『向き合う』とは

そうして戦っていくことが「向き合う」なのだろうということなのだとは思いますが、少しだけまとめとして「向き合う」という言葉にも認識しやすいよう具体的なアクションを添えて締めようかと思います。

どれだけ「目に見える」アクションプランを、
どれほど「たくさん」、
どれだけ「明瞭に書き起こす」か。

障害と「向き合う」ということはそのためにどれだけの時間を注ぐことができたか。

当然のことのように見えますが、「改善策」をいざ実施しろと言われたときに、満場一致のアクションが取れる策になっていることも、また稀であるといえます。

１つ２つの「改善策」では失敗して通用しないかもしれません。

自分自身だけでなく、仲間たち、そして未来の仲間たちの身を案じて伝わるよう書き記してこそなはずです。

おしまい

バグを出さずに開発したい

バグを出しても問題ない環境を作りたい

人ではなくバグに向き合う文化を作りたい

言うは易しで宣うばかりになってしまいがちな我々エンジニアではありますが、せめてせめて、自分のしてきた仕事に納得ができるように、心がけだけでも時たま胸に留めておきたいものです。