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

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

ある設計会議での出来事

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

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

共通言語としての技術書

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

「この設計は開放閉鎖の原則に反している」と言えば、全員が同じ概念を共有しているので、原則の説明から始める手間が省けます。「あのリファクタリングの本に出てくる手順を当てよう」と言えば、手順の中身をいちから並べなくても伝わります。

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

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

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

レビューコメントに「この部分は凝集度が低い」「依存の向きが層の想定と逆になっている」と具体的な用語が使われます。指摘を受けた側も用語を知っているので、修正の方向性を合意するまでが短くなります。

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

「ここは技術的負債だが、今は意図的に残す。理由は○○」という判断を、チーム全員が同じ意味で受け取れます。負債がどこにあるかを言葉にできるチームは、返済の順番を決めるときに議論が空中戦になりません。

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

「まずこの 3 冊を読んでください」とリストを渡せます。新メンバーは本を読むことで、チームの設計思想と共通言語をまとめて受け取れます。

ただし、リストを渡すだけでは読まれないことが多いです。読む時間を業務時間の中に置くのか、それとも各自の時間に任せるのかを最初に伝えておかないと、新メンバーは「読んでいないことを言いにくい状態」に置かれます。渡す本の冊数を絞り、読んだ内容を最初のコードレビューで話す場を用意しておくと、リストが宿題ではなく会話の材料になります。

読書文化の育て方

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

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

押し付けではなく、実践で示します。「本を読んだ方がいい」と説くよりも、本の知識を使って良い設計を提案した方が、周囲は動きやすくなります。

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

オフィスの共有スペースに技術書を数冊置く。「自由に読んでください」と一言添える。本が目に入る場所にあると、読み始めるきっかけは作りやすくなります。

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

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

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

重要なのは続けられる形にすることです。文化として残りやすいのは、月 1 回の大きな読書会よりも週 1 回の小さな集まりの方だと感じています。間隔が空くと前回どこまで読んだかを思い出す手間が増え、参加そのものが重くなるからです。

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

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

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

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

一方で、共通言語が権威に変わってしまう副作用にも注意が必要です。「本に書いてあった」が議論を打ち切る言葉として使われ始めると、その本を読んでいない人は反論の足場を失い、黙るようになります。本の前提と自分たちのコードの前提が同じかどうかも、毎回確かめる必要があります。原則を持ち出したときは、それがこの設計のどこに当てはまるのかを一言添える。この習慣があるかどうかで、共通言語が議論を進める道具のままでいられるかが分かれます。

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

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

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

小さな行動の積み重ねが、チームの空気を少しずつ動かしていきます。

関連記事

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

まとめ

技術書がチームの共通言語になると、設計議論もコードレビューも新メンバーの立ち上がりも、話が通じるまでの時間が短くなります。文化を育てる順番は、まず自分が読んで実践で示し、本を目に入る場所に置き、小さな読書会を始めることです。ただし共通言語は、議論を打ち切る権威に変わった時点で価値を失います。「それ、本に書いてあったよ」が皮肉ではなく褒め言葉として飛び交い、そのうえで本の前提を確かめ直せる職場が、エンジニアにとって学びやすい環境です。