こんにちは、テックリードの Steven です。この記事で開発部門におけるメンタリングの体制を紹介して、学んだことを説明できればと思います。

メンタリングの目的

メンタリングはエンジニアが仕事を通して提供する価値が上がるようにサポートすることだと思います。技術力を伸ばすのも重要ですが、仕事が全体的にもっと効率よく進むように仕事のやり方を改善するのがポイントです。

調査のやり方、コミュニケーションの取り方、時間管理、振り返り方、作業のタスク分けとスケジュールなど仕事を進める中で必要となるスキルを伸ばすことを目的としています。

メンタリングはティーチングとも違っていて、どうすればいいのかをただ教えるのではなく、あくまでメンティーをサポートして、自分一人で成長できるようにすることです。何をすればいいのかを指示するのではなく、問題をどうすれば解決できるのか解決策を助言するか、判断しやすくなるようにアクションを提案することに留めます。

もちろん成長要素のない問題が発生した場合、正解が一つしかない場合、わざわざ考えさせる意味がないので、その時に限って答えを教えます。手取り足取り、全てを細かく説明するのが優しいと感じられることがありますが、それだと、相手が自分で考えることなく、言われたことをそのまま実行するだけなので、成長には繋がりにくいと思います。メンターがいなくなって、新しい問題が発生したら、解決するには多分苦労するでしょう。メンタリングはその状況を避けるためにあって、優しさより成長を優先すべきだと思います。

当然ですが、メンタリングは社員全員にではなく、新卒やジュニア限定としています。それも当人の技術力、仕事の捌き方によって決まるもので、基準値を超えれば、メンタリングを終わりとします。

メンタリングの体制

開発部門でメンタリングを受けるメンティーにメンターが一人付きます。そのメンターは日々の作業の手助け、成長のためのサポート、作業のレビュー、週次振り返りを担当します。メンティーのために時間が取れるように、メンターは基本的に一人のメンティーだけを担当します。

メンティーは 1on1 という対面月次振り返りも受けます。対面相手はリーダー層のエンジニアになります。

それとは別でメンターのメンタリングのための会議も毎月実施しています。メンターとメンタリングの経験があるエンジニアが集まる MTG です。

メンティーの週次振り返り

毎週メンティーとメンターで振り返り MTG を実施して、一週間の間にメンティーが行った作業と、発生した問題を分析して、改善案を出します。 YWT の形で行っていて、やったこと(Y)、わかったこと(W)、次やること(T)を事前にメンティーに記事にまとめていただいてから、メンターと二人で話し合います。

YWT の記事でまとめるのは作業内容も含まれますが、それよりも仕事の進め方を改善するために取ったアクション(Y)、作業をする中でやり方についてわかった重要なこと(W)、次の振り返りまで仕事の進め方を改善するために取る予定のアクション(T)というのが内容となります。技術についてわかったことは自然と増えて、メンタリングをそんなに必要とするものでもないので、それで時間を浪費しすぎないように気をつけています。

その記事を確認した上でメンターはメンティーとディスカッションをして、時間の使い方がよくないとか、調査方法が非効率だとか、メンティーが抱えている問題を掘り出して、改善アクションを提案します。メンターはできるだけ、表面的な問題ではなく、根底にある問題を暴き出すように努めます。

改善アクションが決まれば、口頭で終わらせるのではなく、アクションをしっかりと振り返り記事に記録して、次の振り返りで実施されたかどうか、フォローアップを行います。アクションがわかりやすくまとめられて、実施される前提でメンターが振る舞えば、メンティーもやる気が出て、アクションが取りやすくなるかと思います。

YWT の例

以下は振り返りに慣れたエンジニアが実際に書いた YWT です。入社したてのメンティーでこんな風に状況を分析して情報をまとめるのが難しいと思いますが、目指すべき振り返りの形だと思います。

レビュー入力欄改善と検索UIはプロジェクトの名前です。

Y(Yattakoto)

レビュー入力欄改善はキリのいいところで一旦打ち切った
検索UIではfigmaや画面仕様を見ながら詳細設計した

W(Wakattakoto)

プロジェクトにアサインされたばかりだが画面仕様書の作成を通して実装できるぐらいには仕様を把握することができた
検索UIのチケット1枚あたりの作業量は膨大ではないのですぐ終わってモチベーションが保ちやすい。レビュー入力欄改善のタスクはチケット1つで結構な作業量なのでチケットを細分化する必要があると感じた。
コンポーネント作成のタスクに入ったが、cssの適用はしないのででき上がるviewは不完全なものになるのでタスクはどうやったら完了なのかが曖昧なのがわかった

T(Tsugiyarukoto)

ペアプロを通してタスクの完了ラインについて把握する

メンティーの 1on1

毎月メンティーとリーダー層のエンジニアの間で 1on1 という対面振り返り MTG も実施しています。１ヶ月において、行った作業と成長したところ、まだ抱えている問題を確認します。

目的は週次振り返りと同じで、仕事のやり方に対する問題の掘り出しと、改善アクションの提案です。メンターと違う方が見ることで、メンターが見逃した問題を発見することもできれば、メンターに相談しにくい話も聞けます。

それに加えて、人事考課で設定した半期の目標の進捗も確認して、進捗が悪ければ、アクションプランを提案します。カウンセリングというストレスチェックも行って、作業量が多すぎるとか、最近成果が出せてないとか、ストレス要素の排除に努めます。

メンターのメンタリング

メンタリングは制度だけではなく、メンターのスキルでもあるので、そのスキルが磨かれるようにメンターのメンタリングも行っています。初めてメンターになる方の場合、最初のうちはメンティーの週次振り返りに経験者も同伴します。最初の会はその経験者が仕切ってメンタリングのやり方を見せますが、それ以降はメンターに任せて、サポートに徹します。

それとは別で、毎月現役メンターとメンタリングの経験者が MTG で集まります。メンターによるメンティーの話を通して、次にメンターが取るべきアクションをディスカッションします。メンターのやり方に問題があるとわかれば、何に気をつけるべきか、どんな風に問題を解決すべきかと伝えて、アクションを取っていただきます。軌道修正の意味合いが強くて、あくまで問題があれば指摘をして、それ以外はメンターに判断を任せます。

メンターも月次 1on1 を受けることがあるので、必要に応じてその場面でもメンタリングに対する助言をします。

学んだこと

当然かもしれませんが、メンタリングにおいても明確な目標を持った方がいいです。メンティーの課題を分析した上で目標を設定して、達成のためにアクションを取っていただいて、改善の経過を計測するのが重要です。日々発生する細かい問題をスポットで解決するだけではメンタリングの本当の効果は得られず、メンティーの成長に時間がかかってしまいます。

日々の作業の中で発生する表面的な問題を通して、メンティーがかかえている根本的な課題を掘り出すのもポイントです。特定の機能のソースコードの場所がわからなくて、ずっと悩んでいて作業が進まなかったというのが問題であれば、課題はソースコードの場所を覚えてないのではなく、調査方法に問題があるか、すべきだった相談をしなかったというところにあります。そこからメンティーとのディスカッションを通してより細かい原因を割り出して（迷惑をかけたくなかったので、相談をしなかったとか）、改善アクションを決めるのが適切だと思います。ここでソースコードの場所を教えるだけだと、問題は一時的に解決しますが、おそらく違う形でまた発生するので、根本的な解決にはならないです。

どの時点でメンタリングが不要なのかと基準を設けるのもいいでしょう。試験とまで行かなくても、誰でも確認できる、共通化された基準があると、メンターとしてもメンティーとしてもやりやすくて、やる気も出ると思います。

最後に、メンタリングの目的とやり方はメンターの間でブレることがあるので、認識合わせをしっかりと行った方が安全です。特にメンタリングの経験が少ない方だと、メンタリングとティーチングの違いを把握しきれないことがあるので、時間を取ってゆっくりと説明した方がいいと思います。メンタリングで行うことを明文化して、流用できるガイドを用意できると、ベストかもしれません。