ジュニアメンバーが 3 時間つまずいている画面を、後ろから眺めている。
自分なら 10 分で終わる作業だと分かっているだけに、口を出したくなる時間でもあります。
テックリードという役割に近づくと、この場面に立つ回数が急に増えるようです。
厄介なのは、正解が「すぐ教える」でも「放っておく」でもないという点。
先回りすれば相手は育たず、放置すれば期日が飛びます。
その間にある距離感をどう取るのか、というのがメンタリングの核心なのでしょう。
私自身もテックリードを目指して学んでいる立場なので、ここでは公開されている一次情報を頼りに整理してみました。
メンタリングは「時間を使う」と決めることから始まる
まず前提として、メンタリングはやる気だけで成立しません。
Google のエンジニアリング文化をまとめた『Software Engineering at Google』の第 5 章「How to Lead a Team」は、メンターに必要なものとしてチームのプロセスとシステムの経験、他人に説明できる力、相手がどれくらい助けを必要としているかを見積もる力の 3 つを挙げています。
3 つ目の「見積もる力」が、いちばん厄介な部分。
同章は、ジュニアエンジニアが自分なら短時間で終わる作業に何時間もかけているのを見るのは難しいことだと認めたうえで、それでも人に教え、自分で学ぶ機会を与えることは効果的なリーダーシップに欠かせない要素だと書いています。
つまり「もどかしさ」は避けられない前提として扱われている、ということ。
だとすれば、必要なのは我慢の精神論ではなく、時間の確保になります。
メンタリングを善意の残業に押し込めると、忙しい週から先に消えていく。
スプリントや月の計画に「メンタリングの時間」を明示的に置いておくほうが、結局は続けやすいでしょう。
答えを渡す前に、問い返す
距離感の取り方で参考になるのが、Gergely Orosz 氏が The Pragmatic Engineer で公開しているメンタリングの実践記事です。
同記事は、効率のよいメンターであることは他人の問題を解いてあげることではないと言い切っています。
解決策を渡すのを意図的に遅らせ、「いま何を考えている？」のような問いかけで相手自身に考えさせる。
人は自分で自分を助けるときにいちばん学ぶ、という整理でした。
これは現場感覚とも合います。
答えを先に渡すと、相手の頭の中には「結論」だけが残り、そこへ至る道筋が残らない。
逆に問い返すと、相手の中に「次に似た問題へ当たったときの手がかり」が残ります。
もっとも、問い返しは万能ではありません。
期日が明日に迫っているタスクで延々と問答を続けるのは、教育ではなく事故。
締切までの距離を見て、今日は答えを渡す日なのか、考えてもらう日なのかを先に決めておくと迷いが減るはずです。
日常業務そのものを教材にする
改まった時間を取らなくても、メンタリングの機会は毎日そこらじゅうに流れているもの。
同記事はメンタリングを 4 つの形に分けていて、新しく入った人を助けるオンボーディングメンタリング、コードレビューや日々の共同作業から学ぶインフォーマルメンタリング、定期的に会う形のフォーマルメンタリング、そして距離を越えて行うリモートメンタリングが並びます。
このうちコードレビューは、経験の浅い開発者が日々のフィードバックを通じて自然に学ぶ、頻度の高い非公式な場として位置づけられていました。
わざわざ「メンタリングの時間です」と宣言しなくてよい、というのは気が楽になる話でしょう。
ただし、レビューが教材として機能するかどうかは書き方次第。
「ここは違う」だけのコメントは判定であって、教材にはなりません。
なぜそう書くのか、代わりに何を選ぶのか、そして今回は直さなくていいのか。
指摘に「理由」と「優先度」を添えるだけで、レビューは教材に変わります。
レビュー運用そのものをどう設計するかは、それだけで別の論点になりますね。
最初の 1 か月で、目標を 1 つだけ決める
継続的な関係にするなら、入口で握るものを絞っておきたいところ。
先の記事は、キックオフで「これから 1 か月で伸ばしたい領域はどこですか？」と尋ねて短期の勝ちを設定し、面談のあいだの進捗を共有ドキュメントで追う形を勧めています。
短い期間で 1 つだけ、というのが実際的でしょう。
3 つ並べると、忙しい月に全部が止まります。
もうひとつ、同記事は「時間がない」「専門外だ」という理由でメンタリングを断ってよいとも書いていました。
引き受けたのに関われない状態がいちばん相手を傷つける、と考えれば納得のいく話。
メンティー側にも準備の責任があり、準備なしで来られるとメンターの時間が無駄になる、という指摘もあります。
つまり関係は片側の善意では成立しない、ということですね。
つまずきやすい落とし穴
先の Google の章には、リーダーのアンチパターンが名前つきで並んでいます。
Hire Pushovers（言いなりの人を雇う）、Ignore Low Performers（成果の出ていない人を放置する）、Ignore Human Issues（人の問題を無視する）、Be Everyone's Friend（全員の友達になろうとする）、Compromise the Hiring Bar（採用基準を下げる）、Treat Your Team Like Children（チームを子ども扱いする）の 6 つ。
メンタリングと特に噛み合うのが、放置と子ども扱いの 2 つです。
任せたつもりの放置と、手を出しすぎる子ども扱い。
冒頭で書いた「教えすぎと放置」の話は、そのままこの 2 つのアンチパターンの間を歩くことだったわけです。
同章は失敗を扱う節で、心理的安全性を自分自身でいられて、そのことで否定的な結果を受けないと感じられる状態だと説明しています。
質問できない空気の中では、そもそも問い返しも成立しません。
土台を作るほうが先、という順番も覚えておきたいところ。
なお、シニアエンジニアから役割が変わる地点で「自分でやったほうが速い」とどう付き合うかは、境界線を扱った記事で整理しました。
最後に
メンタリングの距離感は、答えを渡す速度を意図的に落とし、そのぶん理由と優先度を渡すことで作られるものでした。
時間を計画に置く、問い返してから答える、レビューを教材にする、目標は 1 か月に 1 つ。
どれも派手さはありませんが、続けられる形になっているかどうかが分かれ目になりそうです。
着任直後にいきなり全部を回そうとすると崩れるので、最初の数十日で何を置くかという話とも地続きになります。
以上です。
コメントを残す