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

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

経験 10 年 vs 読書 2 年

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

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

2 年後、B さんの設計力が A さんを上回る場面が出てきます。これは珍しい話ではありません。

なぜ逆転が起きるのか

経験の限界

A さんの 10 年の経験は、A さんが所属したチーム、A さんが担当したプロジェクトの範囲に限定されています。見たことのないパターンには対応できません。

B さんは本を通じて、数十人の著者の経験を追体験しています。2 年間で 48 冊。各著者が 10〜20 年の経験を凝縮して書いた本を読むことで、B さんは自分の 2 年の経験をはるかに超える知見を持っています。

言語化の差

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

設計会議では、言語化できる人の意見が通ります。直感が正しくても、説明できなければチームを動かせません。

設計の本を読むことで得られる最大の武器は、知識そのものではなく「言語化する力」です。

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

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

B さんの知識は、本から演繹的に得たものです。「この原則に基づけば、この状況ではこうすべき」。原則を知っているため、未知の状況にも応用できます。

A さんが巻き返す方法

逆転された A さんに希望がないわけではありません。むしろ、A さんが本を読み始めたら、B さんより速く成長します。

なぜなら、A さんには 10 年分の経験があるからです。本で学んだ原則が、過去の経験と結びつく。「ああ、あのプロジェクトで苦労したのは、この原則に違反していたからか」。経験と原則が接続された瞬間、理解の深さは B さんを超えます。

経験 × 読書。この掛け算が最も強力です。経験だけでも読書だけでも、片方だけでは限界があります。

B さんに足りないもの

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

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

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

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

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

• 経験だけに頼ると、自分の経験の範囲でしか成長できない
• 読書だけに頼ると、理論と実践のギャップに苦しむ
• 経験と読書を掛け合わせた人が、最も速く、最も深く成長する

テックリードであれジュニアであれ、読書を習慣に加えることで、成長の天井を突破できます。

関連記事

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

まとめ

経験 10 年のテックリードを、読書習慣のあるジュニアが設計力で追い抜くことがあります。原因は、経験の範囲の限界、言語化の差、体系的知識と断片的経験の差。しかし、経験者が読書を始めれば、経験と原則の掛け算で最も強力な成長が起きます。経験と読書は競合ではなく補完関係。どちらか一方ではなく、両方を持つことが最強の戦略です。