技術書を使った 1on1 とメンタリング - 後輩の成長を加速させる読書指導

この記事は約 10 分で読めます。

「この本読んでおいて」では人は育たない

後輩エンジニアに技術書を渡して「読んでおいて」と言う。よくある光景ですが、これだけでは学習効果は限定的です。

本を渡された側は、何を重点的に読むべきか分からない。読んだ後に何をすればいいか分からない。疑問が生じても誰に聞けばいいか分からない。結果として、本は積まれたまま放置されるか、義務感で読んで内容が定着しないまま終わります。

技術書を使ったメンタリングは、本を渡すだけでは成立しません。選書、読書中のサポート、読後のフォローアップまでを一貫して設計することで、後輩の成長を加速させる強力なツールになります。

メンタリングに技術書を使う 3 つの利点

1. 共通言語が生まれる

同じ本を読んだ 2 人の間には、共通の語彙と概念が生まれます。「あの本の第 5 章で説明されていたパターンを使おう」と言えば、長い説明なしに意図が伝わる。この共通言語は、日常のコードレビューや設計議論の質を大幅に向上させます。

2. メンターの負担が減る

すべてを口頭で教えるのは、メンターにとって大きな負担です。技術書に体系的な説明を任せ、メンターは「本に書いてあることと実務の橋渡し」に集中する。この役割分担により、メンターの時間を効率的に使えます。

3. 自走力が身につく

技術書を読む習慣が身につくと、メンターがいなくても自分で学び続けられるようになります。メンタリングの最終目標は「メンターが不要になること」です。技術書を使った学習は、その目標に直結します。

選書の技術 - 後輩に合った本を選ぶ

メンタリングの成否は、選書で 8 割決まります。自分が好きな本ではなく、後輩の現在地と目的地に合った本を選ぶことが重要です。

現在地を正確に把握する

後輩の技術レベルを把握するために、以下の質問を 1on1 で聞きます。

• 今の業務で最も苦労していることは何か
• 最近読んだ技術書は何か、どこまで理解できたか
• 半年後にどういうエンジニアになりたいか

これらの回答から、後輩の現在地 (知識レベル、経験、関心) を把握します。

「ちょうどいい難しさ」を選ぶ

最適な本は、後輩が「目次を読んで 5〜7 割理解できる」レベルの本です。5 割未満だと挫折し、8 割以上だと学びが少ない。この「ちょうどいい難しさ」の本を選ぶことが、メンターの腕の見せどころです。

薄い本から始める

最初の 1 冊は、200 ページ以下の薄い本を選びます。「読み切った」という成功体験が、次の本への意欲を生みます。分厚い名著は 2 冊目以降に回します。

エンジニア向けの入門書は、メンタリングの最初の 1 冊として適しています。

1on1 での技術書の使い方

読書前の 1on1: 期待値を設定する

本を渡す際に、以下の 3 点を伝えます。

なぜこの本を選んだか。 「今の業務で API 設計に苦労しているから、この本の第 3 章と第 5 章が直接役に立つ」。選書の理由を伝えることで、読む動機が生まれます。

どこを重点的に読むか。 全部読む必要はないことを明示し、重点的に読むべき章を 3〜4 章指定します。「第 1 章は飛ばしていい。第 3 章から読み始めて」。

いつまでに読むか。 期限を設定します。「2 週間後の 1on1 までに第 3 章と第 5 章を読んできて」。期限がないと、読書は無限に先延ばしされます。

読書中の 1on1: 理解度を確認する

読書期間中の 1on1 では、以下の質問で理解度を確認します。

「今どこまで読んだ？」 進捗を確認します。遅れている場合は、原因を聞いて対処します。業務が忙しいなら期限を延ばし、内容が難しいなら補足説明をします。

「一番印象に残った部分は？」 この質問で、後輩が何を重要だと感じたかが分かります。メンターが重要だと思う部分と後輩が印象に残った部分がずれている場合は、メンターの視点を補足します。

「分からなかった部分は？」 分からない部分を聞き出し、その場で補足説明します。本の説明だけでは理解できなかった部分を、実務の具体例を使って説明する。これがメンターの最も重要な役割です。

読書後の 1on1: 知識を実務に接続する

本を読み終えた後の 1on1 が、最も重要なセッションです。

「この本の内容を、今の業務にどう活かせると思う？」 この質問で、知識と実務の接続を促します。後輩が自分で接続点を見つけられれば理想的ですが、見つけられない場合はメンターが具体的な適用場面を示します。

「次に読むべき本は何だと思う？」 自分で次の本を選ぶ練習をさせます。後輩の選書が適切であれば承認し、ずれている場合は理由を説明して別の本を提案します。この繰り返しで、後輩の選書眼が育ちます。

読書課題の設計パターン

パターン A: 課題解決型

後輩が業務で直面している課題に対して、その課題を解決するための本を選びます。「テストが書けない」ならテスト本ガイドから 1 冊選び、「設計が分からない」なら設計本ガイドから 1 冊選ぶ。

読後の課題: 本で学んだ内容を使って、実際の業務コードを改善する。改善前と改善後のコードをレビューで比較する。

パターン B: 視野拡大型

後輩の専門領域の外にある本を選びます。フロントエンドエンジニアにインフラの本を、バックエンドエンジニアにデザインの本を読ませる。

読後の課題: 本で学んだ内容を 5 分で発表する。自分の専門外の知識を他人に説明する練習になります。

パターン C: 対比読み型

同じテーマの本を 2 冊選び、比較して読ませます。「A の本はこう言っているが、B の本はこう言っている。あなたはどちらに賛成か、理由とともに説明して」。

読後の課題: 2 冊の主張を比較し、自分の意見を文章にまとめる。技術的な判断力と論理的な文章力の両方が鍛えられます。

メンタリングで避けるべき失敗

失敗 1: 自分の好きな本を押し付ける

メンターが感銘を受けた本が、後輩にとって最適とは限りません。自分の好みではなく、後輩の現在地と目的地に基づいて選書してください。

失敗 2: 読書を強制する

「読まなければならない」という義務感は、読書の質を下げます。なぜこの本を読むと後輩自身にとって得になるのかを説明し、内発的な動機を引き出します。

失敗 3: 読後のフォローをしない

本を渡して終わり、読んだか確認して終わり。これではメンタリングになりません。読後の 1on1 で知識を実務に接続するステップが、学習効果の大部分を生み出します。

失敗 4: 一度に多くの本を渡す

「この 5 冊を読んでおいて」は、後輩を圧倒するだけです。1 冊ずつ、読み切ってから次の本を渡す。このペースを守ることが、継続的な学習習慣の形成につながります。

関連記事

• 技術書の読書会の始め方 - チームの学習文化を育てる実践ガイド
• 新人エンジニアに贈りたい技術書リスト - 先輩が選ぶ理由
• 技術書がキャリアを変えた話 - 読書とキャリアの関係

まとめ

技術書を使ったメンタリングは、「本を渡す」だけでは機能しません。後輩の現在地に合った選書、読書前の期待値設定、読書中の理解度確認、読書後の実務接続。この 4 ステップを 1on1 に組み込むことで、技術書は後輩の成長を加速させる強力なツールになります。メンタリングの最終目標は、後輩が自分で本を選び、自分で学べるようになることです。