30 代エンジニアが読書で取り戻す「設計の言語化力」

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

「なんとなく」で設計してきた 10 年

20 代のころは、先輩のコードを真似て、動くものを作ることに集中していました。30 代になり、自分が設計を主導する立場になると、ある壁にぶつかります。

「なぜその設計にしたのか」を聞かれたとき、うまく説明できない。

頭の中には「こうした方がいい」という直感がある。経験に裏打ちされた判断で、結果的に正しいことも多い。しかし、その判断の根拠を言葉にできない。設計レビューで「なんとなくこの方がいいと思った」としか言えず、後輩を納得させられない。

これが「暗黙知の壁」です。

暗黙知はなぜ言語化できないのか

10 年の経験で蓄積した設計の勘は、無数の成功と失敗のパターンマッチングです。「この構造は前にも見たことがある。あのときはうまくいった (あるいは失敗した)」。この判断は瞬時に行われるため、本人も判断の根拠を意識していません。

問題は、暗黙知のままでは他人に伝えられないことです。チームリーダーやテックリードとして設計判断を説明する場面、採用面接で技術力を示す場面、技術ブログで知見を共有する場面。いずれも、暗黙知を形式知に変換する「言語化力」が求められます。

技術書が言語化の触媒になる理由

技術書を読むと、自分が「なんとなく」やっていたことに名前がついていることに気づきます。

「あ、自分がいつもやっていたのは Strategy パターンだったのか」「この設計判断は開放閉鎖の原則に基づいていたのか」「自分が嫌だと感じていたコードは、凝集度が低い状態だったのか」。

名前がつくと、説明できるようになります。「この設計は Strategy パターンを採用しています。理由は、決済方法の追加が今後も見込まれるため、新しい決済方法を追加するときに既存コードを変更せずに済むようにするためです」。

デザインパターンの本は、暗黙知に名前を与えてくれる最も効率的な手段です。

30 代に効く読書の仕方

「答え合わせ」として読む

20 代の読書は「知らないことを学ぶ」インプットが中心です。30 代の読書は「自分の経験を体系化する」答え合わせが中心になります。

設計の本を読みながら、「これは前のプロジェクトで経験した」「この失敗パターン、まさに自分がやった」と照合していく。この読み方をすると、本の内容が自分の経験と結びつき、記憶に深く定着します。

「反論」しながら読む

経験がある分、著者の主張に対して「いや、現場ではそう簡単にいかない」と感じることがあります。この反論こそが学びのチャンスです。

「著者はこう言っているが、自分の経験ではこうだった。なぜ違うのか」を考えることで、自分の経験の特殊性と一般原則の関係が見えてきます。

読んだ内容を「使う」場面を意識する

30 代の読書は、翌日の仕事で使えなければ意味がありません。本を読みながら、「この概念を次の設計レビューで使おう」「この用語を次のドキュメントに書こう」と具体的な使用場面を想定してください。

言語化力が上がると何が変わるか

設計レビューの質が変わる

「なんとなくこの方がいい」が「○○の原則に基づいて、こう設計した。トレードオフとして△△があるが、このプロジェクトでは許容できる」に変わります。

後輩の育成が変わる

暗黙知を言語化できれば、後輩に「なぜそうするのか」を説明できます。「見て覚えろ」ではなく、原則と根拠を伝える指導ができるようになります。

キャリアの選択肢が広がる

テックリード、アーキテクト、技術顧問。これらの役割は、技術的な判断を言語化して組織に伝える能力が求められます。コードが書けるだけでは就けないポジションに、言語化力が道を開きます。

最初の 1 冊の選び方

30 代エンジニアが言語化力を鍛えるなら、以下の順序がおすすめです。

1. SOLID 原則の解説書: 自分の設計判断に最も頻繁に名前を与えてくれる
2. デザインパターンの本: 構造の選択肢と、それぞれの適用場面を体系的に学べる
3. アーキテクチャの本: システム全体の設計判断を言語化する力がつく

1 冊目で「自分の暗黙知に名前がつく」体験をすると、2 冊目以降の読書が加速します。

関連記事

• リーダブルコードの次に読む本 - ステップアップの読書ルート
• なぜあの人は説明がうまいのか - 言語化力を鍛える読書

まとめ

30 代エンジニアの「設計はできるが説明できない」問題は、暗黙知に名前がついていないことが原因です。技術書は、経験で蓄積した直感に用語と原則を与え、言語化可能な形式知に変換してくれます。答え合わせとして読み、反論しながら読み、翌日使う場面を想定して読む。この読み方で、10 年の経験が言葉になります。