実務未経験の中途社員エンジニアのメンターを担当した5ヶ月を振り返る

2021年11月〜2022年3月の5ヶ月間で実務未経験で中途入社された新米エンジニアの社内メンターを担当したので、

などをまとめます。

「社内メンター」という呼び方をしていますが、いわゆる「1番身近な先輩的なポジション」のことだとイメージしてください。

同じプロジェクトで開発業務をサポートをしていたので開発業務に関することがメインです。

自分は社会人経験6年ほどあるとはいえエンジニアとしてはまだ2年くらいであること、それにくわえてエンジニアとして初のメンター（教育担当）だったので、色々と手探りなところがありましたが、

などに参考になる内容となっていますので、ぜひ最後までご覧ください！

メンターとしてのマインドセットは「話させること」と「聞くこと」

僕個人が大事にしていたマインドセットは「話させること」と「聞くこと」です。

メンターはメンティーにとって気軽に何でも相談できる先輩であるべきだと思います。そして、相談する内容は業務に直結することでもプライベートなことでも良いと思っています。

気軽に何でも相談できる人間になるためには、まずは相談してもらうこと、相談しやすい雰囲気を作ることが大事です。

なので「話させること」を重要なマインドセットの1つに設定していました。

また、メンティーが相談したいということは解消したい疑問や悩みがあるということなので、メンティーが発した言葉を聞く、うまく言葉にできないことについては引き出した上で少しでも解消に向けたアドバイスができれば良いと思い、「聞くこと」も大事なマインドセットの1つとして設定しました。

メンターとしてやったこと

そのうえでですが、僕がやったことは大きく以下の3つです。

1つずつ説明していきます。

できたこと・できるようになったことは褒める

「褒める」と書くとわざとらしく聞こえますが、「できたこと・できるようになったことは褒める」はかなり意識していました。

その理由は2つあります。

1つ目は、メンティーのモチベーションを上げるためです。

人間、色々なタイプがいますが褒められて嫌な気持ちになる人はあまり多くないと思います。もちろん僕も褒められることは好きです。

異業種からキャリアチェンジしたエンジニアはある程度の社会人経験があるうえで新卒レベルから再スタートするので、メンタル的に苦労することが多いと思います。

「新卒の状態で全然仕事ができない」より「アラサーなのに全く仕事できない…」方がメンタルをやられやすいので、メンターが自分の努力や成長を褒めてくれると

と感じることができ、心が折れることなくモチベーションを上げることができると思っています。

2つ目は、褒められた方が嬉しい人がほとんどだと思うからです。

僕が新卒で入った会社では、教育担当が褒めない（かつ厳しめに指摘する）タイプだったので

と思っていた時期が少しだけあります。（人事評価は結構よかった）

何でもかんでも褒めるのは違いますが、メンティーのモチベーションを上げて成長を促すこともメンターの役割だと思います。

このような理由から「できたこと・できるようになったこと褒める」を意識し、それを実践できたことはよかったと思います。

改善した方が良いと思ったことは正直に伝える

「できたこと・できるようになったことを褒める」とは真逆っぽいですが、「改善した方が良いと思ったことは正直に伝える」というのも徹底してできたと思います。

極端にいえば「メンターがダメ出しをする」ということなのでメンター、メンティーの性格によっては別の指導法をとった方がお互いが幸せです。まずは信頼関係の構築をするべきです。

僕の場合、担当した方がはじめのほうに「ダメなところは遠慮なく全て言って欲しい」と言ってくれたので、こちらの心理的ハードルが下がり、コードの書き方、PR（プルリクスト）の書き方、仕事を進めるうえでのコミュニケーションなどの開発業務に関することをメインに遠慮なく全てお伝えしました。

相手に伝えるときにかなり気をつけたのは、「なぜそうした方が良いのか」の根拠を必ず添えることです。（以下、例）

ただ単に「こうした方が良い」と言われるより、その理由と一緒に言われる方が言われる側は納得感を持つことができると思います。

なるべく改善した方が良いと思ったことは正直に伝えた方が良いということが僕の考えです。

「改善点を伝えること」メンティーの成長のためには大事と思う一方、伝え方（言葉選び）・受け取り側の捉え方によっては「グダグダ口うるさい上司」のように悪く認識されてしまう可能性もあるので、メンターとメンティーの信頼関係の構築が重要です。

自分の言葉で話してもらう

僕がPRのレビューをする時はなるべくメンティーに自分が書いたコードを自分の口で説明してもらっていました。
（なお、それなりに時間がかかる作業なので全てのコードに対してではなく、重要なところに絞っていました）

エンジニアは経験歴に関わらず、自分が書いたコードの意味はその時点では必ず理解しておくべきだと思います。

経験が浅いうちは機能の実装に時間がかかるため、既存コードから使えそうなコードを流用したり、ググってヒットしたコードをそのままコピペすることもあるのではないかと思います。

※既存コードを流用することはプロダクト全体のコードの質を揃えるという視点でチーム開発では大切ですが、ここではコードの意味を理解していない状態でとりあえずそのまま使うという意味をイメージしてください。

「コードの意味はわかっていないけどとりあえず使ったてみた／とりあえず動いた」という状態は、エンジニアの本質的な成長には繋がりません。

それを防ぎ、着実に成長してもらうために「自分が書いたコードを自分で説明してもらう」を実践しました。

これによりメンティー自身は自分が理解できていないところを明確に把握することができます。（自分の口で説明するためにはちゃんと理解しておかないといけない）

できなかったこと・改善点

次は自分がうまくできなかったことや反省点を書いていきます。今後はここに書く内容も改善できるように頑張りたいです。

技術的なアドバイスが上手くできない時があった

僕のWebエンジニアとしての経験が2年なので時には技術的な質問に対して満点の回答ができなかった時がありました。

全然わからない、ということはなく「もっとベストな回答がある気がする…」という感じです。

これはまだエンジニアとして経験豊富ではないと言ってしまえばそれまでなのでもっといろいろなことを知って引き出しを多くしていきたいと思いました。

これはパッと改善することではなく、メンター側もプライドと熱意を持って色々な情報をインプットし、アウトプットし、スキルアップする必要があるので、今後も情報収集を勢力的に行い当時より良いアドバイスができるようにしたい所存です。

自分が忙しい時に対応が雑になった

業務の種類に関わらず、タスク量には「波」があります。

自分にあまり余裕がないときにメンティーへのタスク依頼が雑になった時がありました。

「雑」というは「〇〇を△△して欲しい」くらいのざっくりしたもので、エンジニアとしてざっくりした要件を自分で噛み砕いて、周りと擦り合わせて自分で仕事を進める力は必要です。

しかし経験が浅い場合はその辺をよしなにするための知識も経験もないので手戻りを減らすためにもできる限りこちらで要件を詰めた状態でお渡しすべきでした。
（幸いなことにメンティーのスペックが高く結構よしなにしてくれたので大きな舵の切り直しはなかったのが幸いでした）

メンタリング、指導の内容はメンティーのレベルによっては大きく変わることは認識していましたが、実感できたのは反省点はありつつ、これははこれで収穫でした。

最後に

冒頭で書いた自分が大切にしているマインドセットである「話させること」と「聞くこと」にもとづいてやったこと、できなかったことを書きました。

メンタリング、指導はベストプラクティスはなく、性格や思考性によって最善のものがあると思いますが、何よりメンター・メンティーのお互いの信頼関係が重要だと思いました。

メンター（教育担当）を任されたばかりの方、これからそのような役割を担当したいと思っている方などの参考になれば嬉しいです！