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

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

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

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

その本は、チームの設計判断の共通基盤になっていることが多いのです。共通言語、明文化されていない設計基準、過去の失敗の教訓。この 3 つが 1 冊に集まっているとき、先輩は同じ本を何度も口にします。

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

共通言語の形成

チーム全員が同じ本を読んでいると、設計の議論から前置きの説明が消えます。「この部分、あの本の第 7 章で言っていたパターンですよね」と言えば、全員が同じ概念を共有できます。

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

暗黙の設計基準

多くのチームには、明文化されていない設計基準があります。「なぜうちのチームはこの設計パターンを好むのか」「なぜこのアプローチを避けるのか」。順序は逆で、チームがその本を読んで判断の型を決めた結果が、いまの設計基準になっています。本を読むと、規約の文面ではなく、その裏にある理由の側から基準を辿れます。

コーディング規約やアーキテクチャドキュメントには書かれていない、チームの設計哲学。1 冊の本を共有することは、その哲学の出どころを丸ごと渡す手段になります。

過去の失敗の教訓

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

本を読むことで、チームが過去に学んだ教訓を追体験できます。障害報告書より背景の説明が厚いため、なぜその対策が要るのかまで辿れます。

薦められた本の読み方

優先度を上げて読む

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

推薦が古びていないかを確かめる

推薦は更新されないまま残ることがあります。先輩がその本を読んだのが数年前で、扱っている言語やフレームワークの版が変わっていれば、コード例はそのままでは動きません。設計の考え方を扱う本は版が古くても価値が落ちにくい一方、特定の製品やバージョンに踏み込んだ本は、公式ドキュメントで現行の仕様を確かめながら読む必要があります。薦められた時点で「どの版を読みましたか」と聞いておくと、読むときにどこを疑えばよいかが分かります。

読んだ後に感想を伝える

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

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

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

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

自分が先輩になったとき

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

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

関連記事

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

まとめ

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