エンジニアのメンタリング：ジュニアをシニアに育てる方法

二人のマネージャーのことを考えてください——一人はあなたをより良くしてくれた人、もう一人はそうでなかった人。そうでなかった人はおそらくあなたを忙しくしておきました：割り当てられたチケット、承認されたレビュー、出席したスタンドアップ。あなたをより良くした人はおそらくより微妙なことをしていました。少し大きすぎる問題を与え、あなたが倒れたときにキャッチできるほど近くにいて、それからあなたが自力で解決するのを見ていた。それがメンタリングの全技術であり、そこに凝縮されています。

私はスタートアップとスケールアップで8〜11人のエンジニアリングチームを率いてきましたが、速く成長したチームと停滞したチームの違いは、ほぼ常に一つのことに帰着しました：シニアの人々がジュニアの人々に投資していたかどうか。彼らの面倒を見ることではありません。彼らの仕事をすることでもありません。投資——時間、信頼、慎重に設計された難しさを伴う投資。

この記事は、エンジニアのメンタリングを初めて試みる前に誰かが教えてくれていたら良かったと思うすべてです。また、正直に言えば、私が犯して修正しなければならなかった間違いの記録でもあります。メンタリングするエンジニアを任されたシニアエンジニアやチームを構築中のテックリードに、これがいくつかの教訓を節約することを願っています。

メンタリングがレバレッジである理由

誘惑があります——特に個人貢献者として育ってきた場合——メンタリングをコストとして考えることです。概念を説明するのに費やす時間はコードを書かない時間です。しかし、このフレーミングは数学をまったく逆にしています。

チームに8人のエンジニアがいる場合、チームとしての生産量は8人分の仕事です。60%の能力で動いていた人が80%になるのを助けた瞬間、チームの生産量に20%の一人分を追加したことになります——採用なしに、オンボーディングのオーバーヘッドなしに、新入りが効果的になるまでの三ヶ月なしに。チームを通じて一年間でそれを掛け合わせると、メンタリングは最も高いレバレッジのある投資の一つです。

天井を上げる効果もあります。私が最も良いと思ったチームはスタープレイヤーが最も多いチームではありませんでした——フロアが最も高かったチームでした。チームのすべてのエンジニアが難しい問題を独立して処理できると信頼できるとき、一〜二人のシニアにすべてを通わせるチームよりもはるかに速く動けます。メンタリングはそのフロアを上げます。

そして、人々が認めるより重要な定着率の側面があります。エンジニアは仕事を辞めるのではなく——停滞を辞めます。チームを去るエンジニアから聞いた最大の理由は「成長が止まった」というものの何らかのバリエーションです。シニアの人々がジュニアの人々に投資するカルチャーは、人々が留まるカルチャーであり、あなたの組織の知識が18ヶ月ごとに扉を出て行かないカルチャーです。

人々がいる場所で会う

私が見る——そして自分でも早い段階で犯した——最大のメンタリングの間違いは、間違ったレベルで課題を設定することです。眠りながらできるタスクを与えると退屈します。本当に手の届かないものを与えると溺れます。魔法は二つの間にあるバンドで起きます。

発達心理学者Lev Vygotskyはこれを最近接発達領域と呼びました。アイデアはシンプルです：独立してできることがあり、助けを借りてもできないことがあり、そしてその間に——適切なサポートがあればできそうなもの——があります。その中間地帯こそが学習が実際に起きる場所です。パニックなしのストレッチが存在する場所です。

実際には、これは彼らがこれまでやってきたことの一歩先のタスクを見つけることを意味し、十歩先ではありません。シンプルなAPIエンドポイントを処理したジュニアは、完全なシステムの再設計ではなく、中程度の複雑さの機能を所有する準備ができています。いくつかの機能を単独で届けたミドルレベルのエンジニアは、一夜でテックリードになるのではなく、チーム横断の調整が必要な機能をリードする準備ができています。

誰かのゾーンがどこにあるかをどうやって知るか？聞き、見る。タスクのどの部分が明確でどの部分が不明確かを尋ねましょう。ペアリングセッションでどこで遅くなるかを観察しましょう。彼らが尋ねる質問の種類に注目してください（大きなアーキテクチャ的な質問は通常端に近いことを示し；小さな構文的な質問は通常そうではありません）。注意を払っていれば、すぐにキャリブレートできます。

具体的な教えのツール

繰り返し戻ってくるいくつかのテクニックがあります。どれも目新しいものではありません。

ペアプログラミング、正しくやる

ペアリングは暗黙の知識を最も速く伝達する方法です——ドキュメントに住んでいない種類、問題が通常どこに潜むかについての本能、そのパターンが後で痛みを引き起こす理由。しかし、ペアリングはジュニアがドライビングするときにのみ教えます、シニアではなく。もし座って彼らが見ている間にタイプし始めたら、能力を実証しました。でも、彼らが何かを構築するのを助けていません。

実際に機能するペアリングのバージョン：キーボードを彼らの前に置き、隣に座り、気づいていることを語りましょう。「最初にエッジケースを見てみます——このリストが空の場合はどうなりますか？」待ちましょう。考えさせましょう。間違わせましょう。飛び込まない不快感は、実際に何かを教えるための入場料です。

コードレビューを教えのチャンネルとして

ほとんどのコードレビューはコードに焦点を当てています。良いメンタリングはそれを思考についての会話に変えます。関数が長すぎると指摘するだけでなく、なぜを説明しましょう——何が理解しにくくなるか、コードベースが成長するにつれて何が最初に壊れるか。このテーマをどのように優しく効果的にやるかについてより詳しくコードを優しくレビューする方法で書きましたが、メンタリングの角度はここで追加する価値があります：レビューは習慣になる前に誰かの推論をキャッチしてリダイレクトできる数少ない場所の一つです。

私が学んだ一つのこと：レビューで指摘するのではなく質問をする。「二つのリクエストが同時にこれに当たったらどうなりますか？」は「これはスレッドセーフではありません」より有用です。問題を考えさせます；答えを渡すのではなく。

推論を声に出して説明する

シニアエンジニアは圧縮された膨大な見えない知識を持っています——ただそれを持っていることを忘れているだけです。決定を下すとき、それを語りましょう。「このスケールではまだ余分な複雑さの価値がないので、Redisに手を伸ばすのではなくシンプルなインメモリのマップにします。」三秒かかるその一文は、ジュニアエンジニアが独自の試行錯誤で学ぶのに何ヶ月もかかることがあります。

すべてを語る必要はありません。でも、推論を見えるようにすること——特に答えが明白でない決定のポイントで——は、工芸を学ぶ人のためにできる最も高い収益のものの一つです。

セーフティーネット付きのストレッチタスク

私が知っている最も効果的な教えの動きは、少し大きすぎるものを割り当て、それから近くにいることです。監視ではありません——彼らは苦労するためのスペースが必要です——しかし利用可能です。自然なマイルストーンでチェックインしましょう。あなたが先取りするのではなく、彼らがブロッカーを持ってくるようにしましょう。目標は、セーフティーネットがそこにあっても、彼らが独立していると感じることです。

一つの重要な防護柵：ストレッチタスクには本物の期限と本物のステークスが必要ですが、失敗が壊滅的でないステークスではなければなりません。準備ができていなかったタスクのオンコールの週末を燃やすジュニアエンジニアは、より有能になるのではなく、よりリスク回避になります。ストレッチのサイズをシステムがどのくらい間違いを許容できるかに合わせましょう。

代わりに解決しない

これが最も難しいものです。誰かが行き詰まっていてあなたが答えを知っているとき、それを与えないのに本物の訓練が要ります。でも、与えた瞬間に、教えることからすることに切り替わっています。次に同様の問題に当たったとき、彼らは自分で乗り越えるのではなくあなたのところに戻ってきます。

代わりに機能するもの：正しい誘導的な質問をする。「エラーメッセージは実際に何と言っていますか？」「支払いモジュールで同様のケースをどのように処理したかを見ましたか？」目標は彼ら自身の考えの次のステップを与えることで、答えではありません。

自律性のラダー

メンタリングのために最も明確なメンタルモデルの一つは、自律性をラダーとして考えることです。ラダーのどこにいるかによって、与える必要のあるコンテキストの量、チェックインの頻度、割り当てるタスクの種類が決まります。メンタリングの目標は常に誰かを一段上に動かすことです——一夜でトップに引き上げることではなく、動き続けること。

ほとんどの新卒者は段1からスタートします。2〜3年の経験で採用されたほとんどのエンジニアは段2に着地します。そこからの旅はマネージャーとチームがどれだけ意図的に彼らを上に動かすことに投資しているかに大きく依存します。

最もよくある間違いは、誰かが稼いだより低い段にいるかのように扱うことです。誰かが段3で機能しているのに段1で管理されている——すべてのプルリクエントを詳細にレビューし、毎日チェックインする——なら、彼らを遅らせているのであり助けていません。信頼は漸進的に延長されるものです；誰かが決定的に「証明した」ときの報酬ではありません。

チケットを閉じるだけでなく、シニアを育てる

多くのメンタリングの注目はジュニアに向けられています——そして、ジュニアからミドルレベルへのデルタが急激でサポートの必要性が明白なので、それは正当です。しかし、チケットクローザーに停滞してシニアにたどり着けないミドルレベルのエンジニアは、エンジニアリングチームで最も一般的で最も防ぐことができる損失の一つです。

ミドルレベルとシニアの間のギャップは、ほとんどの人が思うよりテクニカルスキルについてではありません。技術的に強いミドルレベルエンジニアが停滞するのは、スコープが持つ判断力を開発する機会を持っていなかったからです。

シニアを育てることは彼らに以下を与えることを意味します：

• タスクではなく、スコープ。チケットのシーケンスを与えられたミドルレベルのエンジニアはそれらのチケットを完了し、それ以外のことはしません。問題を与えましょう——所有するシステムの領域、構築する機能——そして彼らはそれを分解し、シーケンスし、トレードオフを行う判断力を開発しなければなりません。その判断力がシニアを定義するものです。
• 見える所有権。彼らのエリアに関する決定が行われる部屋に入れましょう。ステークホルダーにアプローチを発表させましょう。挑戦されたときにそれを守らせましょう。最初は不快で、時間とともに非常に価値があります。
• メンタリングの責任。ミドルレベルのエンジニアをジュニアとペアにしてメンタリングすることは、彼らの成長の最良の促進要因の一つです。教えることはやることとは異なるレベルの理解を必要とします。また、直感的に行ってきた判断を明確に表現することを強制し、それがミドルレベルからシニアへのステップです。
• 即時の仕事を超えたテクニカルな影響。標準の決定を推進させ、ADRを書かせ、テクニカルな事後分析をリードさせること——これらすべてがシニアエンジニアが持つ必要のある幅広い影響力を構築します。

名前をつける価値のあるメンタリングの間違い

私はこれらのほとんどを犯しました。個人的に犯していないものは、気づかずに他の良いエンジニアが犯すのを見ました。

• 早すぎる救出。誰かが苦労した瞬間に飛び込むことは助けのように感じます。そうではありません。生産的な苦労こそ成長が宿る場所です。救出は誰かが前進する方法なしに長すぎるほど行き詰まっているときのためです——困難の最初の兆候ではなく。
• 曖昧なフィードバック。「これはよりクリーンにできる」は誰にも何も伝えません。「この関数は三つのことをしています——どれかにちなんで名前をつけると誤解を招き、テストしにくくなります」は行動できるフィードバックです。具体性は優しさです。
• 退屈な仕事だけを委任する。ジュニアエンジニアに手渡すタスクが常に最低リスク、最低可視性、最も機械的な仕事なら、面白い学習を自分のために取っておき、彼らに雑用のキャリアを与えています。彼らは気づきます。去ります。ストレッチタスクには良いものも含まれなければなりません。
• 本当に時間を投資しない。「質問があれば利用可能です」はメンタリングではありません。メンタリングにはスケジュールされた保護された時間が必要です——ステータスアップデートだけでなくメンタリングのアジェンダを持つ定期的な1対1；意図的なコードレビュー；意図的なペアリングセッション。正しくやっていれば、週2〜3時間かかります。コストゼロなら、おそらくやっていません。
• 自分のことにする。目標は彼らの成長であり、あなたが思慮深いメンティーを持つことへの満足ではありません。時として彼らにとって正しい動きは別のチームでの機会を含む場合や、あなたのコードベースには彼らの学習を難しくしている問題があるというフィードバックを含む場合があります。良いメンターはメンティーを最初に置きます。

異なる規模でのメンタリングの機能の仕方

核心的な原則は会社の規模では変わりませんが、周囲のインフラは大きく変わります。

私が参加したあるスタートアップでは、正式なメンタリングプログラムはありませんでしたが、チームの三人のシニアエンジニアは暗黙の合意を持っていました：すべてのジュニアエンジニアは最初の六ヶ月以内に少なくとも一つの重要な機能の主要オーナーになると。機能はサポートがあれば達成可能にスコープされていましたが、些細ではありませんでした。シニアは難しい部分でペアリングしてすべてを綿密にレビューしましたが、ジュニアがドライブしました。一年の終わりに、それらのジュニアエンジニアはタイトル以外のすべてでミドルレベルになっていました。

後に参加したより大きな会社では、非常に洗練されたメンタリングプログラムがありました——公式なペアリング、四半期ごとのチェックイン、目標のための共有ドキュメントテンプレート。そしてほとんど機能しませんでした、なぜならドキュメントテンプレートがメンタリングになったからです。ジュニアエンジニアが実際により良い仕事を得ているかどうか、またはより良い書類を得ているだけかを誰も追跡していませんでした。私がそこから取った教訓：関係と意図的な挑戦が重要なものです。その他はすべて足場です。

これはエンジニアリング文化に関する小シリーズの第二弾です。まだ読んでいなければ、コードを優しくレビューする方法についてのパート1は、士気を下げずに教えるフィードバックを与える仕組みをカバーしています——PRレベルで適用される同じスキルです。文化、採用、チームの実際の動き方についての執筆はさらに続きます。