先輩が「あれ読んだ？」と聞いてくる本には理由がある

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

繰り返し薦められる本には組織の文脈がある

「あの本、もう読んだ？」。先輩やテックリードから、同じ本を何度も薦められた経験はないでしょうか。最初は「また言ってる」と流してしまいがちですが、繰り返し薦められる本には、個人の好みを超えた理由があります。

その本は、チームの設計判断の共通基盤になっていることが多いのです。

推薦図書が組織で果たす役割

共通言語の形成

チーム全員が同じ本を読んでいると、設計の議論が格段にスムーズになります。「この部分、あの本の第 7 章で言っていたパターンですよね」と言えば、全員が同じ概念を共有できます。

先輩が本を薦めるのは、あなたにこの共通言語を身につけてほしいからです。その本を読んでいないと、チームの設計議論についていけない場面が出てきます。

暗黙の設計基準

多くのチームには、明文化されていない設計基準があります。「なぜうちのチームはこの設計パターンを好むのか」「なぜこのアプローチを避けるのか」。その答えが、先輩が薦める本に書かれています。

コーディング規約やアーキテクチャドキュメントには書かれていない、チームの設計哲学。それを最も効率的に伝える手段が、1 冊の本を共有することなのです。

過去の失敗の教訓

先輩が特定の本を強く薦める場合、その本の内容に関連する失敗をチームが過去に経験している可能性があります。「テストの本を読んでほしい」と言われたら、過去にテスト不足で障害を起こした経験があるのかもしれません。

本を読むことで、チームが過去に学んだ教訓を追体験できます。同じ失敗を繰り返さないための、最も効率的な知識伝達です。

薦められた本の読み方

優先度を上げて読む

先輩が薦める本は、自分で選んだ本より優先度を上げてください。自分で選ぶ本は自分の関心に基づいていますが、先輩が薦める本はチームの文脈に基づいています。チームで成果を出すには、後者の方が即効性があります。

読んだ後に感想を伝える

本を読んだら、薦めてくれた先輩に感想を伝えてください。「第 5 章の依存性逆転の話が、今のプロジェクトのあの部分に当てはまると思いました」のように、具体的な感想を伝えると、そこから設計の議論が始まります。

設計の本を読んだ感想を先輩と共有することで、本の内容がチームの実務に結びつきます。

わからなかった箇所を質問する

本の中でわからなかった箇所を先輩に質問すると、先輩はその箇所をチームの実務に即して説明してくれます。本の抽象的な説明が、チームの具体的なコードベースと結びつく瞬間です。

自分が先輩になったとき

いつか自分が後輩に本を薦める立場になります。そのとき、「とりあえずこれ読んで」ではなく、「この本のこの章が、今のプロジェクトのこの課題に直結するから読んでほしい」と伝えてください。

なぜその本を薦めるのかの文脈を添えることで、後輩の読書の動機と理解の深さが変わります。

関連記事

• 技術書を人に薦める技術 - 相手のレベルに合った本を選ぶ方法
• エンジニアの本棚に必ずある本 - 定番技術書が並ぶ理由

まとめ

先輩が繰り返し薦める本は、チームの共通言語、暗黙の設計基準、過去の失敗の教訓を凝縮した 1 冊です。薦められたら優先的に読み、感想を伝え、わからない箇所を質問する。この一連の流れが、チームへの最速のオンボーディングになります。