考える順番を守る - Konifar's ZATSU

何かを進める上で、守るべき考える順番 というのがあると思ってるんだけど、あんまり整理できていないので雑に書き出してみる。 たとえばシステムの不具合対応の調査。コードのいたるところにログを仕込んだり推測で修正したりする前に、発生事象と事実確認、そして原因の仮説と特定という順番を踏まないといけない。当てずっぽうで進めると結果的に時間がかかるし、もしかしたら報告自体が勘違いで不具合ですらないなんてこともある。 たとえばシステム障害発生後の振り返り。再発防止策をいろいろ考える前に、発生事象の事実確認と真因の分析という順番を踏まないといけない。こうすれば改善するよねというHOWらしきものをいくら話しても、何を防止するのかが固まっていないと芯を食った再発防止にならない。 新しいツールの導入なんかも同じ。なぜやるかを明確にして、選択肢を広げて、評価軸を整理して評価して、ひとつを選ぶみたいな順番がある。

[sav-djahvoe]

考える順番は守るべきである