最近メンタリングについて興味深い記事を2つ見かけたので、自分の経験について書いておこうと思う。
まずは自分（メンター）とメンティー（複数）についていくつか整理をしておく。
- 双方ソフトウェアエンジニアである
- 自分が5年目〜8年目くらいの経験である
- メンティーは新卒入社（つまり業務経験はない）
- メンティーは入社する時点で結構なレベルを持っている（と思う）
- メンターをメンタリングした経験も含む
この文章は2016年くらいに一度まとめていたものをベースに再構成している。
メンタリングの目的
新卒で入社したばかりのメンティーはある程度技術も知っているしそれなりにタスクをこなしていくこともできるが、まだまだ一人前のソフトウェアエンジニアと呼ばれるにはトレーニングが必要。
一人前のソフトウェアエンジニアまでにはそれなりに経験も必要で数ヶ月から1年でそれらを経験できるわけではない。それまでずっと付き添うわけにはいかないので 自分自身で一人前のソフトウェアエンジニアになれる という状態を目指す。
やること
失敗させる
普段の仕事の中で明確な成功というのは感じづらいが失敗は大きなものから小さなものまで色々なものを経験することができる。 更に成功より失敗の方から学ぶことの方が多いので、メンタリング中に一番意識するのは失敗させること。
できれば大きなものから小さなものまで失敗をさせたい。 もちろん自分から見れば事前に失敗すると分かっているものもいっぱいある。が、それに気がついていたとしても失敗して大きな問題にならなければそのままやってもらう。
その失敗を一緒に振り返ることで、どうしたら回避できたのか・何が足りなかったのかを考えてもらい経験値にしてもらう。 こういう経験・知識は他人の話を聞いてもあまり実感が沸かず、自分で体験するからこそ自らの経験値になるのでなるべく多く経験してもらうようにしている。
セーフティーネット
失敗をするとどんな人でも少なからずダメージを受けるはずなのでこれはケアしなければいけない。
なのでメンターがセーフティーネットになり続けること、メンターがセーフティーネットであることをメンティーに伝えることが非常に大事。
メンティーに伝えるときは1回の言葉だけではなく、実際の行動でもそれを示す。
このセーフティーネットの存在はメンティーに安心感を与えるはずで、そういう安心感があればより自信を持ってチャレンジができるはず。
セーフティーネットではメンティーに 致命的な失敗をさせない ことが一番大事。 致命的な失敗は回復不可能なダメージを負う場合があり、場合によっては1発でキャリアに大きな影響を及ぼしかねない。それは 絶対に避ける。
最初はできない前提
本当に初期の頃は何も出来ない前提で話を進める。 もちろん大概においてそんなことはなく、意外にできるのだがそれでも最初はできないという前提においておく。
そして基本的には助けてあげる。
最初の頃に任せるタスクというのは簡単で基本的なタスクになることが多いと思う。 それでもできない前提で細かいところもケアしてあげる。
これの目的はこういうところをすっ飛ばしたりして後からできてないこと・足りてないことに気がつくと後戻りが面倒なので最初のうちに一通り教えてしまうことである。 学校の授業に近いところがあるかもしれない。体系化された知識なので覚えてしまう・1回体験してしまえば身につけることができると思う。
これを最初にやってしまえば、それ以降もつまらないことで引っかかることがなくスムーズに行くようになると思う。
説明してもらうようにする
どれくらい理解しているのか、そもそも何を理解していて何が分かってないのかを簡単に判断する方法は説明してもらうことである。
なので特に初期の段階においては説明してもらう機会を増やし理解の範囲を把握する手段として活用する。
様子をよく観察する
メンティーの様子はよく観察する。 そのために座席は隣・向かいなどの隣接したところに座ってもらうのが良い。逆に離れてしまうとかなりメンタリングが難しくなる。
何を観察するのかというと、端的にいえば人間観察をする。
何かをやってもらっているとき、直接話してない時の様子をよく観察する。 作業している様子をよく観察することでタスクに対するストレス度を大まかに図れるようにはなっておきたい。
これはメンタリングする上で少しずつタスクの難易度を上げていくことになるが、どこまで上げても大丈夫なのかを測るために重要になる。
普段の様子をよく観察することで、困っている時の表情・仕草などを読み取れるようになると声をかけるタイミングも見極めやすくなる。
一人でタスクをやっていたとしても困っている時は何らかの表情が出ていることが多い。 人によっては些細な変化かもしれないがそれを見落とさないように注意する。
性格・性質を見極める
メンティーの性格や性質は色々なところに影響してくる。メンタリング時の伝え方に影響したり、そもそも業務を進めていく上でのアドバンテージになったりウィークポイントになったりもする。
メンターは成長へ責任を持つのでこういったところへも配慮してあげる。
ウィークポイントが分かったとしてもあえて直さないということも十分にありえる。 組織は様々な人がいてからこそ成り立ち強くなるので、概ねそのままで良い。むしろ後から修正していくのは難しくお互いがストレスになってしまうこともあると思う。
なので良いところを伸ばしていく方がやりやすいし幸せになれるだろう。 ウィークポイントについては、やんわりとこういうところが苦手だよねというのが伝わっていれば十分。
自ら学んでもらう
少し経験を積み始めた頃から普段の業務の中で自ら学ぶ方法を身につけてもらうようにする。 そのために あえて教えないこと もする。
そのために今身につけなければいけないこと、将来身につければいいことといったことはきっちりと区別しできればこれをメンティーと共有しておくと良い。 メンティーに伝えるかどうかというのはその人の性格や性質などに依るところもあるので必須ではないが、メンターの中で今やるべきことと将来やるべきことの区別といった計画は必須である。
信頼される
仕事をする上で信頼されるというのは色々な場面で必要になる。 近くの同僚だけにではなく、時には少し上の上司から信頼を得る必要がある場面というのも大いにある。
この信頼されるための方法というのはなかなか伝えづらく、言葉で伝えただけでは伝わりづらい。
そこでメンターがメンティーから信頼されるように行動する。実際にどうやって信頼されるかというのはメンターによって様々で十人十色だろう。 ここで大事なのはメンティーが当事者になって体験するということである。
メンティーがこういうことをされると信頼に繋がったという場面はそれ自体を意図的に意識させなくても経験・体験として刷り込まれる。
メンターがどういうことやったかというのをメンティーに伝える必要はない。あくまで体験していれば良い。
自分ならどうするか一緒に考える
メンティーがメンタリングを受けている期間の一番のメリットはメンターの頭を借りることができることである。 逆にメンターは積極的に自分の考え方や思考する順番などを伝えられるようにする。
この技術はこういう仕組みで、とかこういうバックグランドがあってといった知識はインターネットや書籍でも得られる。 だが 知恵 を教えてくれる書籍はほとんどないし、全く関係ない第三者よりメンターの方が教えやすい。
メンティーはメンターと一緒に思考することで知恵を学べるように仕向ける。
1on1
1on1 はフィードバックの場として用意しておいた方が良い。 毎週1回、特に話すことがなかったとしても時間を用意し実際に話しておく。
メンタリングしてる際にはネガティブなフィードバックをしなければいけない時もあるかもしれない。 そういう時に 1on1 の枠組みがあり定期的に行われているとフィードバックがしやすくなる。
突然呼ばれて話を始めると身構えてしまうので伝える方も伝えづらくなってしまうし、聞く方もしばらく緊張してしまう。 これを逆手に取ってポジティブなフィードバックに使うのは良いかもしれない。用法容量を守って使うことが前提だが、うまく使えば効果がより高くなるかもしれない。
メンタリングの直接的な話題がなかったとしても コーチング の時間としても使うことができる。
メンターとして
メンタリングの方法は初期の頃にかなり自己流で構築した部分が多く、先人たちが培ったフレームワークは少し時間が経ってから覚えることとなった。
なので今からメンターになろうという人は先にコーチングの方法などを覚えておくと良いと思う。きっとメンティーにとってより良いメンターになることができる。
またメンターとしての負担は結構あり、同時に何人もメンタリングするのは難しい。 体感上3人が限界で3人をメンタリングすると自分でエンジニアリングタスクをする余裕はなくなると思う。