エンジニアにコーチやメンターが必要な理由

エンジニアがお仕事をする上でどのように様々な技術を身につけるかを自分自身のことで思い出してみよう。

新卒のエンジニア候補生を集めた集合教育でスライドやテキストを横に置いて、開発環境の整え方や実際にコードを書いて評価されるような形式が多いのではないだろうか。

現場では即戦力が欲しいから、当然、研修を行う担当（または業者）には実務（＝コードを書く）ができるエンジニアを促成するために道具の使い方を教えるように要請される。

まあ、そうだよね。それにどこか問題があるのかどうか。

研修を受けているエンジニア候補生が現場に配置されれば、現場に起きている業務課題を解決することが求められる。それはそうだ。だって、ITを使い課題を解決するために採用されたのだから。

でも、研修で教えられるのは道具の使い方だけである。開発ツールという道具、言語という道具の使い方を教えられただけである。これは、研修で教えられることは教科書的な教え方しかできない、ということだ。

ところが、現場で起きている業務課題は現場ごとに違う。これも当然だ。業務自体が組織により違うからだ。

研修で出来ることと現場で必要な教育の内容は最初からズレているのであれば、現場の研修に対する期待自体が無理筋なのではないのかということになる。

では研修の担当者ができることは何か。

それは、開発環境や言語は道具でしかなく、置き換わるものだという考え方と開発環境や言語を置き換えたときにどうやって新しい技術を身につけるかという技術の捕まえ方なのではないかということだ。

言い換えれば、業務課題を解決するために知っている、身につけている技術を適用するのではなく、解決に適切な技術をどう選ぶかということだ。

ただ、研修では道具の使い方しか教えられない状況なのであれば、配属されたエンジニアに対してそういったことを教える役割が必要となってくる。

それをコーチやメンターが担う。

現場の特性に合わせて必要となる技術を示したり、参考となる書籍を読み合わせたりとエンジニアの側にいて、技術の習得を促す。

エンジニアの技術力云々の記事を見かける事が多いが、何もしなければ技術力相応の価値がないのだから、だったら、コーチやメンターにコストを支払って組織的な技術力のレベル上げに使ったほうが良いし、コーチやメンターを内製化するならそれを担うエンジニアが自分自身へ再教育を行うキッカケとなるのでその点でも良い策である。