「それ、本に書いてあったよ」が最高の褒め言葉になる職場

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

ある設計会議での出来事

「この部分、Strategy パターンで書き直した方がよくないですか」。ジュニアメンバーの発言に、チームリーダーが笑顔で返した。「それ、デザインパターンの本に書いてあったやつだね。いい提案だ」。

この会話が自然に成り立つチームと、成り立たないチームがあります。違いは、チームに読書の共通言語があるかどうかです。

共通言語としての技術書

チーム全員が同じ本を読んでいると、設計の議論が格段に効率的になります。

「この設計は開放閉鎖の原則に反している」と言えば、全員が同じ概念を共有しているから、説明の手間が省ける。「リファクタリングの本の第 6 章のパターンを適用しよう」と言えば、全員が同じページを思い浮かべる。

技術書が共通言語になると、設計の議論が「感覚」ではなく「原則」に基づくようになります。「なんとなくこの方がいい」が「○○の原則に基づいて、こうすべき」に変わる。

読書文化があるチームの特徴

コードレビューの質が高い

レビューコメントに「この部分は凝集度が低い」「依存の方向が逆転している」と具体的な用語が使われる。指摘を受けた側も用語を理解しているから、修正の方向性がすぐに合意できる。

技術的負債の議論ができる

「ここは技術的負債だが、今は意図的に残す。理由は○○」という判断を、チーム全員が理解できる。負債の存在を認識し、返済の優先度を議論できるチームは強い。

新メンバーのオンボーディングが速い

「まずこの 3 冊を読んでください」とリストを渡せる。新メンバーは本を読むことで、チームの設計思想と共通言語を短期間で習得できる。

チーム開発に関する本をチーム全員で読むと、開発プロセスの改善が加速します。

読書文化の育て方

ステップ 1: まず自分が読む

チームに読書文化がない場合、誰かが最初の 1 人にならなければなりません。自分が本を読み、その知識をコードレビューや設計議論で自然に使う。「この本にこう書いてあった」と引用する。

押し付けではなく、実践で示す。「本を読んだ方がいい」と説教するより、本の知識を使って良い設計を提案する方が、周囲への影響力は大きい。

ステップ 2: 本を物理的に置く

オフィスの共有スペースに技術書を数冊置く。「自由に読んでください」と一言添える。物理的に本が目に入る環境は、読書への心理的ハードルを下げます。

リモートワーク中心なら、Slack に「今読んでいる本」を共有するチャンネルを作る。

ステップ 3: 小さな読書会を始める

週 1 回 30 分、2〜3 人で同じ本の 1 章を読んで感想を話す。大げさな読書会ではなく、ランチタイムの雑談レベルで十分です。

重要なのは継続すること。月 1 回の大きな読書会より、週 1 回の小さな読書会の方が文化として定着します。

「それ、本に書いてあったよ」の力

この一言が褒め言葉として機能する職場は、読書が学習の手段として認められている証拠です。

「本に書いてあった」は「お前の意見はオリジナリティがない」という意味ではありません。「お前は本を読んで学び、その知識を実務に適用できている」という意味です。

逆に、この一言が皮肉に聞こえる職場は、読書が軽視されている環境です。そういう環境では、本を読んでいることを隠す人が出てきます。

読書文化がない職場でできること

チーム全体の文化を変えるのは時間がかかります。まずは自分の半径 3 メートルから始めてください。

隣の席の同僚に「この本、面白かったよ」と貸す。コードレビューで「この本のこの章が参考になる」とリンクを添える。1on1 で後輩に「この本を読んでみて」と薦める。

小さな行動の積み重ねが、やがてチームの文化を変えます。

関連記事

• 技術書の読書会の始め方 - チームの学習文化を育てる実践ガイド
• 技術書の読書会で起きる面白い現象 - 同じ本を読んでも解釈が違う理由

まとめ

技術書がチームの共通言語になると、設計議論の質、コードレビューの精度、オンボーディングの速度が向上します。文化を育てるには、まず自分が読んで実践で示し、本を物理的に置き、小さな読書会を始める。「それ、本に書いてあったよ」が自然に飛び交う職場は、エンジニアにとって最高の学習環境です。