何かを進める上で、守るべき考える順番 というのがあると思ってるんだけど、あんまり整理できていないので雑に書き出してみる。
たとえばシステムの不具合対応の調査。コードのいたるところにログを仕込んだり推測で修正したりする前に、発生事象と事実確認、そして原因の仮説と特定という順番を踏まないといけない。当てずっぽうで進めると結果的に時間がかかるし、もしかしたら報告自体が勘違いで不具合ですらないなんてこともある。
たとえばシステム障害発生後の振り返り。再発防止策をいろいろ考える前に、発生事象の事実確認と真因の分析という順番を踏まないといけない。こうすれば改善するよねというHOWらしきものをいくら話しても、何を防止するのかが固まっていないと芯を食った再発防止にならない。
新しいツールの導入なんかも同じ。なぜやるかを明確にして、選択肢を広げて、評価軸を整理して評価して、ひとつを選ぶみたいな順番がある。
データを分析する時に仮説を先に立てるとかもそう。依頼に取り掛かる前に依頼内容を理解するとか、仲裁の前に双方の話を聞くとかも。
こういう順番は人によって違うとかいう話じゃない。守らないといけないもの。「そんなの当たり前というか、その順番じゃないと "できない" だろ」と思う人も多いと思う。それは100%正しい。正しいんだけど、実は自分もすっ飛ばしてしまうことがある。
たとえば、採用募集要項を書く前には、いま何が問題で何を解決したいのか、なぜ人員の採用という選択肢をとるのかといった整理を先にしなければならない。一方で、きっちり順番どおりに整理しきる前に、ある程度の内容で固めて並行して募集要項を公開するみたいな動き方をしてしまうことがある。
よくないよね。よくないんですよ。よくないんだけど、まあ程度問題もあるというか、考える順番というのはグラデーションがあるんだろうね。
あるべき順番を認識して、それを逸脱して進めていると自覚的になることが大事なのかもしれない。いや、これは自分の言い訳みたいなもんで、きっちりひとつひとつ順番を踏んでいくほうが遠回りしないし気持ちがいい。しっかりやっていこう。
