現在働いているチームの目指すべき姿の一つに、答えではなく「観点」を理解する ことで次回以降一人でその答えに辿り着けるようにする。というものがあります。 自分はこの言葉がすごく好きではあるのですが、答えにたどり着く観点の他に、その答えの他に考えていたいくつかの「答え」候補を選ばなかった理由も合わせて知ることが、考える力と判断する力を養う一つのアプローチになるのではないかと考えています。
選ばなかった理由を知ることの例えとして、技術選定のプロセスを考えます。
このプロセスでは 特定の技術を採用する というのが最終的なゴールになります。
特定の技術を採用するということは、候補として上がっていた他の技術を採用しなかった ということになるわけで、その技術たちを どうして採用しなかったのか ということの方が、採用した経緯を知るより学べる事が多いと感じています。
もう一つの例えとしてコードを書くことを考えて見ます。
「コードを書く瞬間の思考」にアドバイスを貰える
書かなかったコードや、なぜそれを残さなかったのかにも学びがある
書かれたコードだけでなく、書かなかったコードや、なぜそれを残さなかったかにも学びがあるんですよね。それらはペアプロのセッションでは全て見えますが、コミット時にはコメントに残れば良い方で、テンポや順番は既に失われています。
— Takuto Wada (@t_wada) 2017年2月3日
コーディングにおいてはもっとわかりやすいですが、「書かなかった理由 = 選ばなかった理由」であり、できる人のコードの書く瞬間が一番勉強になります。
現に自分であれば書いたであろう1行を書かないわけですから、その意図や理由は非常に勉強になります。
技術選定にしろ、コードを書くことにろ、結局は「課題解決」の手段として捉えればできる人の意思決定を真似るには できる人が選ばないことを自分も選ばなければいい ということに落ち着くのではないかと考えています。
ある特定の問題解決を使用する際に、いくつかソリューションの候補はあげますが、いざ決める時にその人の「思考」が詰まっています。
その思考のことをノウハウというのではないかと考えてるようになりました。
何かの意思決定をすることは することを決める ことですが、これは しないことを決める と同義です。
しかしながら、することを決める ノウハウは様々な場で知見が共有される一方で、しないことを決める ノウハウは語られることは少なく、そもそも語られなかったりして、「なぜ選ばなかったのか？」「なぜしなかったのか？」ということはあまり知見として広まっていないように感じています。
意思決定の瞬間の思考を深掘りするときに、どうして選ばなかったのかをしっかり説明できるようになりたいし、意思決定する際には「しない」理由にも目を向けると、自身の価値判断の手数が増えていき、武器が増えていくように感じます。
たくさんの選ばない理由に触れ、吸収し続けることの大事さを最近感じる出来事があったので、備忘録としてまとめて見ました。
おわり
