本を読まないテックリードと、本を読むジュニアの逆転劇

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

経験 10 年 vs 読書 2 年

テックリードの A さん。経験 10 年。現場で叩き上げたスキルで、どんな問題も力技で解決する。本は読まない。「現場で学ぶのが一番」が口癖。

ジュニアの B さん。経験 2 年。毎月 2 冊の技術書を読み、学んだことをコードに反映している。設計の語彙が豊富で、コードレビューでの指摘が的確。

読書を続けて 2 年、B さんの設計力が A さんを上回る場面が出てきます。設計の議論に限れば、これは十分に起こり得ることです。

なぜ逆転が起きるのか

経験の限界

A さんの 10 年の経験は、A さんが所属したチーム、A さんが担当したプロジェクトの範囲に限定されています。見たことのないパターンに出会ったとき、判断の手がかりが手元に少なくなります。

B さんは本を通じて、数十人の著者の経験を追体験しています。2 年間で 48 冊。10 年以上の実務を凝縮して書かれた本も少なくないため、B さんは自分の 2 年間だけでは出会えない範囲の知見を手元に持っています。

言語化の差

A さんには「なんとなくこの方がいい」という直感がありますが、それを言葉にできません。B さんは「単一責任の原則に基づいて、この関数を分割すべきです」と、原則を引きながら説明できます。

設計会議で通りやすいのは、理由を言葉にできる意見です。直感が正しくても、説明できなければチームを動かすのは難しくなります。

設計の本を読んで手に入るもののうち、会議で効いてくるのは知識そのものよりも「言語化する力」です。

体系的な知識 vs 断片的な経験

A さんの知識は、経験から帰納的に得たものです。「前にこうしたらうまくいった」。しかし、なぜうまくいったのかの原則を知らないため、状況が変わると応用できません。

B さんの知識は、本から原則の形で受け取ったものです。「この原則に基づけば、この状況ではこうすべき」と演繹的に運用できます。原則を持っているため、未知の状況にも当てはめて考えやすくなります。

A さんが巻き返す方法

逆転された A さんに希望がないわけではありません。むしろ、A さんが本を読み始めたときの伸び幅は大きくなり得ます。

なぜなら、A さんには 10 年分の経験があるからです。本で学んだ原則が、過去の経験と結びつく。「ああ、あのプロジェクトで苦労したのは、この原則に違反していたからか」。経験と原則が接続されると、本を読んだだけの状態よりも深いところまで理解が届きます。

経験 × 読書。この掛け算がよく効きます。経験だけでも読書だけでも、片方だけでは届かない範囲が残ります。

B さんに足りないもの

一方、B さんにも弱点があります。本で学んだ原則を、実務で適用した経験がまだ少ない。

「教科書どおりの設計」は、現実のプロジェクトでは制約 (納期、チームのスキル、既存コードとの整合性) によって修正が必要です。この修正の勘は、経験からしか得られません。

B さんが次のレベルに進むには、本で学んだ原則を実務で試し、「原則どおりにいかない場面」を経験する必要があります。

教訓: 経験と読書は補完関係

この逆転劇から学べる教訓は明確です。

• 経験だけに頼ると、自分の経験の範囲でしか成長できない
• 読書だけに頼ると、理論と実践のギャップに苦しむ
• 経験と読書を掛け合わせると、どちらか一方では届かない速さと深さに手が伸びる

テックリードであれジュニアであれ、読書を習慣に加えれば、経験の量だけで決まっていた成長の上限を動かせます。

関連記事

• 「とりあえず動く」で 5 年過ごしたエンジニアの末路
• Pull Request が通らない人に足りないのは、たいてい語彙力

まとめ

経験 10 年のテックリードを、読書習慣のあるジュニアが設計力で追い抜くことがあります。原因は、経験の範囲の限界、言語化の差、体系的知識と断片的経験の差。しかし、経験者が読書を始めれば、経験と原則が結びついて理解が一段深くなります。経験と読書は競合ではなく補完関係。どちらか一方ではなく、両方を持っておくことが結局は近道です。