心がけていること - 無知・・・

早く
賢く
効率よく
・・・オシム

これは、仕事（お金をもらっている）をする上で心がけなければならないことです。
最近、デバッグについて教える（時には、代わりにデバッグしたりする・・・）ことが多いです。なので、それについて書きます。

デバッグの基本

今のところ、自分が正しいと考えるデバッグの手順をメモします。
＃完全な持論。

１．情報収集
＝事象の把握（原因ではない）
必要な情報を集め、正確に把握する。
状況によっては、ここで再現性の確認も行う。
例：ログ収集、画面の動作チェック、同じようなつ処理を持つ、ほかの箇所の動作との差異を確認など。

２．分析
１で収集した情報に対する分析。
過去に発生したものと類似していないかや、事象が複数発生しているのであれば、共通点も見つけるなど。

３．仮説
２．を元に、「あたりをつける」ということ。
勘ではＮＧです。あくまで、ロジカルに。

４．検証
３．に基づいて検証。
障害であれば、この前に改修を行う。ただし、改修前に、テスト環境などで再現させることが必須。でなければ改修された確認ができないことになる。

下位作業は、常に上位作業の結果を元に行います。（１の作業結果を元にして、２を行うといった具合に。）

あまりに簡単なものは、「１.情報収集」→「４.検証」と、２つだけを行うことで、”解決したと感じている”経験があるかもしれません。ただし、それは「２.分析」、「３.仮説」を飛ばしているのではなく、実は「１.情報収集」と同時に「２.分析」、「３.仮説」をやれているだけです。または、よほど運が良い、もしくは、直前のものと同様の事象だった場合です。

デバッグが下手な（時間がかかる、解決できない）人の傾向

いきなり「あたり」をつける

根拠なく、”思い込み”で、いきなり「あたり」をつけて、「検証」作業を行っている。

自分に原因はないと思い込んでいる

この”思い込み”をもとに「あたり」をつけ、「検証」作業を行っている。

やみくもに調査する

「あたり」をつけることもなく、ただひたすら何か手を動かしている。

ここまでを考えてみると、「思い込み」がネックなような気がします。

例えば・・・「突然、家の電気が消えた」から、どういう手順で「停電だった」までにいきつくでしょうか。

「電気が消えた」
↓↓↓
次に、何を行うでしょうか？おそらく、「ブレーカーを確認」（情報収集）でしょう。
↓↓↓
その結果、「ブレーカーはおちていない」（情報収集）場合、次に何をするでしょうか？
↓↓↓
「隣近所を見てみる」（情報収集）
↓↓↓
「隣近所も電気が消えている」（さらに、情報収集）
↓↓↓
これらを考えてみた（分析）結果
↓↓↓
「停電では？」と仮説を立てる。
↓↓↓
隣近所の人に、同時刻に電気が消えたか聞いてみる。（検証）

極端な例ですが、おそらく、デバッグが下手な人は、「隣近所を見てみる」前に、「回線が〜」などと考え（根拠なくあたりをつける）、回線を調べたりする。そうすると、無駄な時間、作業となってしまいます。

上記にあてはまる人は、おそらく気が焦ってしまって、そのような行動をとるのでしょう。もしくは、何かをやっていることで、自分を安心させているのでしょうか。

そのような人に「落ち着いてやりなさい」「ロジカルにやりなさい」は、漠然としていますし、指示が曖昧ですし、おそらく改善されないでしょう。なので、デバッグに関して、具体的指示に落とすと、「１〜４の作業を手順どおりに行うこと」、さらにそれぞれに対して、より具体的な作業指示を出すこと、です。これは緊急性を要するものこそ、必要な手順です（ミスが許されない）。これこそが、

早く
賢く
効率よく

です。