エンジニアならではの話
メンター制度を導入する会社が増えているように感じます。特に、Webサービスを自社開発で運営する事業会社など。
メンター自体のお話は、世の記事でたくさん語られているので、そもそもメンターがわからない方はそちらをぜひ。(ググるとすぐに出てきます)
メンターとは？メンターの意味と役割はなんなのか？
| bizhint
メンター制度を企業が導入する目的、メリット・デメリットとは？
| robertwalters
ここでは、jfluteが色々な現場で、メンター制度のファシリテーターをやってきた経験から、ITエンジニア (プログラマー) におけるメンターのあれこれをちょっと書きたいなと。
※注: メンターとは？というのも厳密な定義があるわけではないと思います。なので、ここで書く内容も、多くはjfluteの経験からの見解なので、人によって色々と解釈は変わるかもしれません。また、まだ思考中の案件ではあるので、まだまだまとまった内容にはなっていません。 ただ、言葉の厳密な定義が重要なわけではなく、メンター制度のスムーズな運営などの足しになるようなヒントが一つでもあればというところです。
前提: コーチや上司とは違う
まず、エンジニアの世界でメンターと言うとすぐにありがちなのが、コーチや上司のような存在との勘違いです。
...
コーチは技術的な指導を行い、直接的にスキルを高める存在です。
メンターは技術的な支援というよりも、「行動や考え方など精神的な導き」に重きを起きます。技術ごとではない悩みもたくさん抱えるはずです。つまり、メンターとエルダーは違うということですね。
...
上司は、会社として管理・評価する人です。後に触れますが、上司がメンターっぽいことをすることもあると思いますが、少なくともここでは "役割" として分けて考えます。
..
これを最初に書いておかないといけないのは、実際に勘違いして話が進むことが多いからです。
「自力で技術を追求するべきだ！だからメンターは...」
「上下関係は作りたくないんだ！だからメンターは...」
「いやいやそうじゃなくて...」
という会話が生まれてしまわないようにと。
メンターが求められる背景
冒頭で紹介した記事にもありますが、やはり、人手不足は大きな要因でしょう。
「会社に合わなければ新しい人を採ればいい」
という理論が成り立たなくなってきました。いまいるエンジニアを、しっかりと現場に適応させつつ、ハイスキラーへと成長させていくことが、会社の中長期的な効率性として求められます。
些細なことから会社に対しての不信が芽生えたり、会社の中で居場所がなくなってしまったりして...
そして、辞めていってしまう...
というのを大勢見てきました。とても悲しいことですし、会社としてもったいないことです。
「少しでも相談できる人がいれば結果は変わってかも!?」
もともとの原因は様々ですが、それをリカバリせず(会社として)放置してしまったことで、些細な問題が解決がされずに手放してしまったと。
...
一方で、逆に会社の中の立場が安定してくると、ほとんど成長がなくなってしまう中堅も見てきました。
「行動を起こすきっかけを与えてくれる人がいれば、変わるかも!?」
単純に、給料が高い、とか、やりたい技術がある、とかだけで、会社の価値を測れるわけではないのでしょう。
...
また、「チーム開発としての効率性」が求められるようになりました。
縦割り役割分担で事務的な手続きでの組織運営ではなく、わりと互いにフラットな関係性の中での共同作業で、プラスアルファな成果を目指す現場が多いです。その方が「全体への意識や責任感」が生まれ、発想力や献身的な行動につながると考えられるからです。(1+1=2ではなく、1+1=3になるような関係性と言えます)
その促進の一環として、メンター制度が着目されています。特にITエンジニアは放っておいてもコミュニケーションがなかなか生まれない体質(!?)を持ちがちですから、メンター制度でメンターもメンティーも、コミュニケーションスキルのアップにつながり、チームとしての潤滑油が期待されるのです。
...
人を大切にする会社の象徴かもしれませんね。(もちろん、他にも人を大切にする施策はたくさんありますが、メンター制度もその大きな一つのものと言えるでしょう)
別職種の人がメンターをやる？
さて、じゃあ誰がメンターをやるのか？冒頭の紹介記事から様々なパターンがあるようですが、別職種の人がメンターをやるとどうでしょう？
先程、コーチと上司とは違う！という話をしました。では、全然違う人が本当に良いでしょうか？実際に、そのように運用してみた現場もありました。営業の先輩が若手エンジニアのメンターになると。なので上下関係もないですし技術支援もできません。
...
実際にjfluteがファシリテーターをやっていたのですが、難しいところもありました。
普段の業務を知らないので、状況を把握するのにじっくりと話をする時間が必要ですし、悩みもなんだかんだ技術に絡んだものも多いので、営業の方 (メンター) が理解するのが大変です。そのためにエンジニア (メンティー) がたくさん話をしていかないといけないですが、なかなかそこがスムーズにいきません。営業の方もエンジニアと接する機会は少ないですから、どう接していけばよいのか戸惑ってしまったりします。
...
ただ、良いところも出ました。以下のような想定通りの効果もあったようです。
同じチームのエンジニアや同業者であるエンジニアには、話づらい話を聞いてもらうことができたり...
自分の仕事領域とは違う場所に自分のことを知ってくれようとしてる人がいる、という安心感が得られたり...
全然違う発想のアドバイスをもらえたり...
別職種の方の知り合いが増えて、チーム間連携にプラスに働いたり...
...
効果は大きいけど運用していくのは大変という感じですね。壁が多いですから、放っておいても活性化しないので、この運用自体のファシリテーションが不可欠なので、会社としての支援が必要になるでしょう。
コーチや上司とのグレーゾーン
メンターはコーチとは違うという話をしましたが、コーチングの中でメンタリング的なことが自然発生することもあります。また、エンジニアはエンジニア同士でこそわかりあえる、というところもあれば、技術的に尊敬できる人じゃないとオープンに話できない、というエンジニアのわがままで仕方のない特性もあります。
なので、コーチがメンターを兼任することもあるでしょう。自然とそうなっている現場も多いのではないでしょうか。
ただ一方で、そもそも上司とコーチが分かれてないことも多いので、そうなると実質的に上司が結局メンターということにもなりがちです。
冒頭の紹介記事にもありましたが、別に上司がメンターをやっていけないわけではなく、それはそれでメリットもちゃんとあります。ただ、デメリットも出やすいものではあるので、それをちゃんと踏まえてメンタリングすることが大切です。
...
究極、誰がやろうがメリット・デメリットはあるので、メンターが、それをちゃんと踏まえた上で、メリットを最大化してデメリットを最小化するための努力をし、また会社がその支援を行うことが大切なのでしょう。
jfluteは、実際に "メンターのメンター" のようなお仕事もしたことがあります。そういった役割の人を設けるというのも、ひとつの施策と言えるでしょう。
とはいえ人次第なので...
と、色々と書きましたが、ぶっちゃけ、うまくいくorうまくいかないの境界線は、メンターとメンティーの力量次第と言えるでしょう。
...
メンターには、圧倒的に人間力が求められるところです。信頼関係を築くことが大前提となります。信頼関係こそが成果物だと言っても過言ではありません。
ただ、最初からそれを発揮できるメンターもいませんから、実質的にメンターもメンティーなのです。
メンタリング自体がうまくいったりいかなかったりするでしょう。うまくいかないことを誰も責めることはできません。それよりも、メンター自身が成長していけるかどうか？がポイントです。
メンターが成長する姿をメンティーが見ている、それ自体がメンタリングにもなる
からです。
メンターは完璧よりも成長を。
...
メンティーも単に待つだけではいけません。もちろん、そうならないように促進をする役割がメンターですが、当然のことながら、ある程度はメンティーの元々の性格も関係します。矛盾しているようですが、現実だと思います。最低ラインのところを採用で判断するかどうかは、会社によって考えるべきところでしょう。
メンターよりもメンタリング
さて、メンターの話をしてきましたが、これまた究極...
メンターという役割が大事なのではなく、メンタリングがされることが大事です。
極端な話、メンターという特定の人がいなくても、メンタリングがされていれば別にいいわけです。
...
新卒の同期、これもメンターになる可能性があります。また、"歳とキャリアの近い" 親しみやすい新卒入社の先輩もメンターになる可能性があります。(そういう意味でも、事業会社が新卒採用を頑張るのも、すごく理にかなっていると思います)
人間力の高い上司であれば、自らそのデメリットを把握し排除して、メンターを兼務することにもなるでしょうし、コーチもその可能性が十分にあります。
別職種の方と仲が良い組織であれば、"別職種のメンターから得られるメリット" を自然と享受できるかもしれません。
...
究極、社員同士が仲が良く接する機会が多ければ、互いにメンタリングが自然と発生して、大きな問題が発生しづらいという面があると思います。
「社員同士が仲が良くする、接する機会を作る」というのを会社として大いに促進するようにして、メンターというのを明示的に作らない現場もあるでしょう。(もしくは、ライトなメンター制度で済ませたり)
なので、メンタリングを発生しているかどうかに注目し、会社としてどんなファシリテーションをしていけば良いのか？
o それがメンター制度なのか？
o 全社的なコミュニケーション促進なのか？
o 両方なのか？
o 他にもあるのか？
そういったことを考えるのは大切かもですね。
メンタリングに年齢は関係ない
メンタリングは若い人に対してやるもので、中途社員やある程度のキャリアの人には要らない...
という感覚ありませんでしょうか？量の差はあるとは思いますが、要らないと言い切るのは賛成できません。
30,40,50になった人が完璧な人間かどうか？まったくそうは思わないからです。(ちなみに、jfluteは全然完璧ではありません)
...
jfluteは、実際にエンジニア組織を束ねるような方のメンタリングもさせて頂く機会もあります。(別途、組織作りのアドバイザーをしつつ、その一環としてという感じではありますが)
別にそれは自分の方が優れてるからとかではなく(どちらかというと、その方めっちゃ優秀な方です)、「視野を広げて間違った判断をしないため」に、気持ちの面も含めて相談をしてくださっているという感じです。
jflute自身も、それが同時に逆メンタリングになって成長するので、"互いに成長のためにオープンに話をする" という感じでしょうか。
...
まあ、それはちょっと極端な例ではありますが...
少なくとも、成長が止まって安定思考になった中堅ほど、さらなる高みのためのメンタリングが必要なんじゃないかと。
また、何かあったらすぐに転職に進んでしまう中堅ほど、会社としてのファシリテーションが必要なんじゃないかと。
そう思うことも多々ありますし、会社のエンジニア人材のネックってどこなんだ？って考えると、大いに無視できないことだと思います。
メンタリングもSL理論
さて、メンタリングの内容自体も、SL理論とつながるところがあると思います。
// SL理論は、組織作り・チーム作りでも通じるか？
http://d.hatena.ne.jp/jflute/20180820/slteambuilding
上記のブログは、組織作り・チーム作りのことでしたが、SL理論を考える上で参考になるかもしれません。
...
メンタリングの答えは、そもそも導きづらいものですし、常に一定のメンタリングになるわけでもないでしょう。しっかりと段階を見極めて、アドバイスする内容を変えて行かないといけないと思います。
難しいことですが、少しでも精度を高めるためには、まずはそのこと自体を知るところが第一歩だと。
まとまらないですが...
まだまだいくらでも悩み続けそうなことですが、ひとまず色々と考えてみたことをブログにしてみました。
...
「メンタリングが必要って情けない！」
そういう先入観が、メンターにもメンティーにも存在していないでしょうか？なんだかんだ、まだまだ根性論が染み付いている、21世紀前半のような気がします。(根性論も悪いわけではないですが、程度の問題ですね)
その障壁を取り払って、どんどんオープンに人と人がつながっていく方が、チームとして良い結果を出せるじゃないかと思います。
...
jfluteは、特殊技術コーチや組織作りアドバイザーしながら、その中で自然発生的にメンターもやりつつ、時にメンター制度自体のファシリテーションもしたり、一方で、メンタリング自体をメインに依頼されることもあります。
「自由と責任の組織」を目指す会社が多くなったことで、メンタリングのニーズも増えているのかもしれません。
これからも、もっと議論していきたいですね。
