あの凄腕のエンジニアの技術習得や解決方法に至る考え方を聴きなさい

どこにもお手本になるような凄腕のエンジニアはいるものだ。少なくとも一定の技術レベルに到達するまでは憧れた凄腕のエンジニアがいたのではないか。いなかったとすると自分で目標を設定でき、孤高に自分を高みに向かって伸ばすことができたか、感性がアーティスティックの方に振れていたか、然もなくば、凡庸なエンジニアなのだろう。

 凄腕のエンジニアを知れば知るほど、その人にはなれないがその凄腕のエンジニアのようになってみたいと思うことはよくあることだ。それが憧れるということなのだから。

 

成長途中のエンジニアはついついそうした凄腕のエンジニアに技術習得のコツや抱えている問題の解決方法を聞いてくるものだ。目の前の課題と認識していることを解決するのが本人にとってプライオリティが最優先になっているからだ。

そうした凄腕のエンジニアと所蔵する組織が同じだとか、親密であれば度々教えてもらう機会が作れるだろう。しかし、面識もそれほどなかったり、社外の著名なエンジニアだとそうはいかない。話しかけられ、時間をもらうことができればラッキーな方だ。

技術習得や解決方法を聞いてはいけない

 確かにそれらはプライオリティが高いイシューだから、ここぞとばかり聴きたくなる気持ちはよくわかる。それにそうしたことを尋ねれば、凄腕のエンジニアも親身になって聞いてくれるし、(凄腕エンジニアなら)どうするかを教えてくれるだろう。

でも、解決方法は聞いてはいけない。

凄腕エンジニアにはなれないが、凄腕エンジニアが凄腕エンジニアであるイズムを取り込むことはできる。技術取得や解決方法を聞いてしまうと具体的な解決手段として得られるため、それを再利用できるように自分の中で経験知から形式知に変換するプロセスを経なければならない。

そして、多くのエンジニアはそれをしない。

技術習得や解決方法に至る考え方を聞く

聞かなければいけないのは、プライオリティの高い課題を解決する場合にどうした点を気にして、何を根拠に判断するか、その凄腕エンジニアが解決策に至る考え方、つまり、思考プロセスを聞くのだ。

もちろん、それを聞くために聴き方も工夫がいるだろう。必要そうな情報を箇条的に提示することで、追加情報を要求されたらそれもその凄腕エンジニアにとって確認したい情報としての重要性が隠れているかも知れないからだ。

こうした聴き方に変えることで、経験知から形式知への汎用化へ近づくため再利用する角度が高まるし、身につきやすい。