開発の不具合調査やちょっとした改善を進める時、考えるべき"順番"がある。
タスクの粒度の差はあれど、自分はいまだに順番を間違えては無駄な遠回りをしているので雑にまとめておく。
1. 事実を確認する
- 誰かからの報告や予想を鵜呑みにしてはいけない
- 本当に起きている事実を自分で確認しにいくこと
2. 問題を理解する
- 結局何が問題なのかを理解せずに対応してはいけない
- なんとなくわかった気になることなく、何が問題かを理解すること
3. 真因を特定する
- なぜその問題が発生しているのかを特定せずに局所的に解決しようとしてはいけない
- 仮説を立ててもいいが、全体像を理解し広げて考えた上で、削ぎ落として真因を特定していくこと
4. 解決策を選択する
- 真因に対してたったひとつだけの思いつき解決策に飛びついてはいけない
- 最終的に一つに決める前に、決定軸を整理して評価し選択すること
例を一個上げると、たとえばあるジョブがコケやすいみたいな報告が上がったとする。
「1. 事実を確認する」では、本当にコケてるのかを確認する。めちゃくちゃしょうもない話だが、もしかしたらログの出力ミスだけでコケていないみたいなこともありうる。自分でやりとりやデータを見て確認する。
「2. 問題を理解する」では、コケることによる問題を理解する。コケるなんて問題に決まっとるやろみたいに思いがちだが、実は仕様上想定されるもので、想定外の異常終了は問題だが、異常終了自体というよりも異常終了した場合のハンドリングの問題かもしれない。
「3. 真因を特定する」では、なぜその問題が発生しているのかを確認する。ここが一番疎かになりがち。ログやデータを確認して可能性を削ぎ落としてピンポイントな真因を特定しにいく。たとえばメモリ枯渇で落ちていることがわかったとして、なぜメモリ枯渇しているのかをさらに深ぼることなく対応を考えてはいけない。
「4. 解決策を選択する」では、真因に対して何をすればいいかを決める。特定のコードの修正になるかもしれないが、影響範囲の大きさや根本解決を考えた時にはいくつかの選択肢が出てくる。どんなことでも3つくらいは出てくると思うので、広げて考えてからひとつを選ぶようにする。
書くと当たり前の話でしかない。ちゃんと内容確認して、特定してからピンポイントに対応しようねという話である。
けどねぇ、思った以上にこの順番をすっ飛ばしちゃうんだよね。
1 をすっ飛ばして、実は報告内容がぜんぜん違ったとか。2をすっ飛ばして結局何の問題もない話だったとか。3をすっ飛ばして当てずっぽうに調査してめちゃくちゃ時間かかったとか。4をすっ飛ばしてレビューでそもそもの指摘を食らったりとか。それぞれできてると思っても深さが全然足りてなくて実態としてはまるでできていないこともある。
順番どおりに一個一個やらないと結局遠回りになるし、説明責任を全うできない。自分はできてると思ってる時ほどしっかりやろう。
