問題が起きたらまずは状況把握！原因を推測するのはその後。

システム開発やシステムの運用保守をやっているとシステム障害に遭遇することは結構ありますよね。そんなときに、原因を特定する作業を「勘」でやっている人はいませんか？

エンジニアの長年の勘は無視できない鋭さがあります。しかし、習熟度の低いエンジニアであれば勘なんて宝くじを当てるような低い確率でしか的中しません。

そこで今回は、私がシステム障害等の問題発生時に、原因を特定するために実施している方法をご紹介します。

やるべきことは以下5つです。

・状況把握
・事実の書き出し
・仮説の書き出し
・仮説の検証
・原因の特定

■ 状況把握

まずやるべきことはこれです。何が起きているのか、どんな状況なのかを正確に把握することです。

こうやって書くと当たり前のことなんですが、状況を断片的にしか把握せずに行動に移す人が多いです。闇雲に動いても良いことはないので、まずは落ち着いて状況を把握しましょう。

■ 事実の書き出し

ここで集めるものは「事象」です。事象とは客観的事実のことであり、100人が見たら100人が同じ受け取り方をするものです。例えば「エラー画面が出た」というものは誰が見てもエラー画面なので、これは事象です。

このときの注意点は、事実と仮説（推測）を混在させないことです。事実と仮説を混在させて考えると混乱の元になります。

■ 仮説の書き出し

ここで集めるものは「〜ではないだろうか？」というものです。例えば「システムエラー画面が出た」という事象に対して、「セッション情報が不足しているのではないだろうか？」「DBにnullが入っているのではないだろうか？」のようなものです。

このときの注意点は「事実」をインプットにして仮説を立てることです。必ず「この仮説は事実に反していないだろうか？」「この事実ならこの仮説はありうるだろう」と考えてください。事実に反している仮説は混乱の元になります。

■ 仮説の検証

「仮説」の正否を確認していきます。裏取した結果はそれも1つの事実ですので「事実」に追加します。

■ 原因の特定

「事実」が出揃ったところで原因を考えます。ここまでのプロセスの中で原因を特定するだけのネタは出揃っているはずです。もし、原因にたどり着かなかったら、また仮説の書き出しからやり直してください。それでもダメなら事実に嘘があります。

というのが、私がオススメするプロセスです。

ただ、ここまで紹介しておいてあれですが、勘であたりをつけて一発でビンゴ！という場合も結構な確率であります。しかし、勘だけに頼った場合、壁にぶつかった時のタイムロスが相当デカいため、勘と上記プロセスを併用するのが良いかなと思います。

■ 閑話

私は原因の特定作業を推理小説を読むのと同じ感覚でやっています。犯人＝原因と思えば推理ゲームですので、私は楽しみながら犯人（原因）探しをしています。