この記事について
私がエンジニアとして働く中で、後輩エンジニアと一緒にプログラムを書いたり、1on1をしたりする場面が多くありました。
その中で実践して感じたことについて紹介します。
想定読者
・最近、後輩やエンジニア歴の浅いメンバーと開発することが多い
・1on1のメンターを担当しているが、どうコミュニケーションを取ったらいいか分からない
なぜ書こうと思ったか？
・一般社員（マネージャー以外）が育成のノウハウやスキルを学ぶ場が少ない。
が、実際にはほとんどの社員が何らかの形で誰かの育成に関わっている。
→マネージャーでなくても、育成のノウハウやスキルを身につける必要がある。
（前提）3つのコミュニケーション技術
ティーチング
→相手の知らないことや足りないことを教える
コーチング
→相手に質問をし、気づきを与え、導く
（答えは相手が自分で出す）
フィードバック
→相手が気づいていない客観的な事実を伝える
（結構厳しめの指摘）
コーチングとメンタリング
コーチングとは
・質問や問いかけにより、相手が自分自身で答えを出す。
・相手の答えの良し悪しを評価しない（正解は1つとは限らない）
メンタリング
・（コーチング的な進め方で）自分の思考を一時的に貸しながら、相手の問題解決を手助けする。
自転車の補助輪のような存在で、問題解決を補助する。
・正解が1つはっきり決まっていることもある。
例えば
上記のようなエラー画面が出て困っているメンティーに対して
ティーチング的な声かけ
「departmenというメソッドが未定義だからエラーになってます。タイポですね。」
（答えを直接教えてしまっている。）
メンタリング的な声かけ
「どんなエラーメッセージが出ていますか？」
「エラーの原因は何が考えられそうですか？」
（問題を解決するためのプロセスや考え方を伝える。問いかけによって解決できる方向に促す。）
なぜメンタリングが大事なの？
「他者説得」ではなく「自己説得」が成長につながる
他者説得
他者から教えてもらって理解する。
（特徴）
・他人が答えを伝える
・体感を伴わない
・理解できたかを他人が確認できない
自己説得
自ら今まで分からなかったことを理解する。
（特徴）
・他人が質問で促す
・体感をともなう
・行動の変化が発生しやすい（理解できたかが他人が確認しやすい）
自立型人材を育てるため
| 人材タイプ | 特徴 |
|---|---|
| 依存型人材 | ・問題を与えられてから考える ・問題と解決策を渡されてから動ける |
| 自立型人材 | ・自ら問題を発見し解決することができる ・問題について、自分事として捉えている |
（引用: 「エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング」）
実際の感想
メンタリングは時間がかかる
→まとまった時間をあらかじめ確保するのが大事。
→今すぐ時間が確保できない時は、「18時からカレンダーに予定を入れて、そこでちゃんとみましょうか？」のように時間の枠を確保する。
状況、事柄によってティーチングの方が向いていることもある
例えば
・メンティーが対象の事柄についての知識が少なく、自力での問題解決が難しい場合。
・時間がなく、すぐに問題解決を進める必要がある場合。
→状況によって使い分ける必要がある。
新卒社員に対しては、ティーチングの割合が多くなってもいい
コーチングやメンタリングは、メンティーが自力で問題解決できるように、思考の補助をしたり、障害になっている認知の歪みを取り除いたりする手法。
（本来であればメンティーが1人で解決できるくらいの知識やスキル、問題解決の経験を持っているという前提がある。）
→新卒社員の場合、前提になる知識、スキル、問題解決の経験がないこともあるので、ティーチングで導くことが多くなっても良い。
「こういう場面では、こうした方がいいよ」とはっきり教える方が、安心感もあっていいと思う。
新卒の方に聞いた意見
概念や全体像が全く分かっていない事柄は、ティーチングで教えてもらえる方がいい。
前提が分かっていない状態でメンタリングをされると、逆に前提について質問しづらくなる。
メンタリングで相手を「試している」みたいになる問題について
メンティーが「この人は本当は答えを分かっているのに、自分を試そうとしてすぐ教えてくれないのか」みたいに思われてしまう問題。
＜考えられる解決策＞
・確認するような問いかけの仕方をする（例「◯◯ってどうなってるんでしたっけ？」）
・「問題解決のプロセスを身につけてほしい」とはっきりと日頃から伝える
新卒の方に聞いた意見
メンタリングされる側も、メンタリングされていることが分かっていることが多いと思う。
そこは割り切ってやれると思う。（人によると思うけど）
多少は誘導尋問っぽくなってもOK
※これはかなり個人的な意見です。
（コーチングにおいては誘導尋問は基本NGですが、）技術的なことを伝えるメンタリングであれば、多少は誘導尋問っぽくなってもいいと思います。
参考書籍
①エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング
この記事は主にこの本の内容をベースにしています。
https://gihyo.jp/book/2018/978-4-7741-9605-3
著者の方のこのQiita記事もおすすめ。
「新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック」
https://qiita.com/hirokidaichi/items/2e8e731acfd7b6c7e02f
②ヤフーの１on１
コーチングや1on1の入門書。
https://www.diamond.co.jp/book/9784478069783.html
③急成長を導くマネージャーの型～地位・権力が通用しない時代の“イーブン”なマネジメント
3つのコミュニケーション技術（ティーチング、コーチング、フィードバック）について詳しく解説されています。
https://gihyo.jp/book/2021/978-4-297-12385-7
エンジニア/デザイナー大募集のお知らせ
株式会社Relicでは、エンジニア・デザイナーを積極的に採用中です。
北海道から沖縄まで地方拠点が10以上ありますので、U・Iターンも大歓迎です！🙌
少しでもご興味がある方は、Relic採用サイトからエントリーください！
https://relic.co.jp/recruit/#categories