調査と改善、考える順番 - Konifar's ZATSU

開発の不具合調査やちょっとした改善を進める時、考えるべき"順番"がある。 タスクの粒度の差はあれど、自分はいまだに順番を間違えては無駄な遠回りをしているので雑にまとめておく。 1. 事実を確認する 誰かからの報告や予想を鵜呑みにしてはいけない 本当に起きている事実を自分で確認しにいくこと 2. 問題を理解する 結局何が問題なのかを理解せずに対応してはいけない なんとなくわかった気になることなく、何が問題かを理解すること 3. 真因を特定する なぜその問題が発生しているのかを特定せずに局所的に解決しようとしてはいけない 仮説を立ててもいいが、全体像を理解し広げて考えた上で、削ぎ落として真因を特定していくこと 4. 解決策を選択する 真因に対してたったひとつだけの思いつき解決策に飛びついてはいけない 最終的に一つに決める前に、決定軸を整理して評価し選択すること 例を一個上げると、たとえばあるジ

[L3deck2256]

自分の周囲での観測範囲では2の深堀ができない、3の選択肢が少ないというのがよくある。限度はあってもあらゆる可能性を想像する能力（というか経験）に欠ける。

[koogawa]

“ もしかしたらログの出力ミスだけでコケていないみたいなこともありうる” こういうケース本当にあるのよね。思い込み注意