技術書の内容を実務に活かす方法 - 読んで終わりにしない

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

「読んだのに使えない」問題の正体

技術書を読んで「なるほど」と思っても、翌週には元のコードの書き方に戻っている。この経験は多くのエンジニアに共通しています。

これは意志の弱さの問題ではありません。「知識」と「スキル」の間には、意図的な実践というブリッジが必要なのです。自転車の乗り方を本で読んでも乗れないのと同じで、設計原則を本で読んでも、実際にコードに適用する経験なしにはスキルになりません。

知識がスキルに変わるプロセスは 3 段階です。

多くの人が段階 1 で止まっています。段階 2 に進むための仕組みが必要です。

技術書の内容を実務に活かす最もシンプルで効果的な方法は、「1 冊の本から 1 つだけ、明日の仕事で試せることを選ぶ」ことです。

全部実践しようとすると、何も実践できません。人間の注意力には限界があり、同時に複数の新しい習慣を身につけるのは困難です。1 つに絞ることで、その 1 つを確実に定着させられます。

選ぶ基準は「明日の仕事で試せるか」です。

「明日試せない」ことは選ばないでください。実践までの距離が遠いほど、実践される確率は下がります。

選んだ 1 つのことを、2 週間意識して実践します。2 週間という期間には根拠があります。新しい行動パターンが「意識しなくてもできる」レベルに近づくのに、最低 2 週間の反復が必要だからです。

2 週間の実践で重要なのは、「完璧にやろうとしない」ことです。10 回のプルリクエストのうち 3 回で意識できれば十分です。残りの 7 回は忘れていても構いません。意識する回数が徐々に増えていけば、それが成長です。

実践を忘れないための工夫として、デスクの付箋に「今週の実践: 関数は 1 つのことだけやる」と書いておく方法があります。シンプルですが効果的です。

エンジニアのスキルアップに関する本を参考にすると、実践のコツが分かります。

設計本やアーキテクチャ本は、今のプロジェクトですぐに試せないことがあります。既存のアーキテクチャを変えるのは大きな判断であり、「本で読んだから」という理由だけでは変更できません。

こうした場合の対処法は 3 つあります。

自分のコードに適用できなくても、他の人のコードをレビューするときに「この部分、こういう設計にすると変更に強くなりませんか」と提案できます。提案が採用されなくても、議論すること自体が学びになります。

業務コードでは試せない設計パターンやアーキテクチャを、個人プロジェクトで実験します。小さなアプリケーションを作り、本で学んだ設計を適用してみる。失敗しても誰にも迷惑がかからないため、思い切った実験ができます。

既存コードのリファクタリングは、設計本の知識を実践する絶好の機会です。「この関数は責務が多すぎるから分割しよう」「この依存関係は逆転させた方がテストしやすくなる」。リファクタリングは既存の動作を変えないため、設計の実験としてリスクが低いです。

リファクタリングの実践書は、既存コードの改善を通じて学びを実践できます。

2 週間の実践後に、5 分だけ振り返りの時間を取ります。

この振り返りは、ノートに 3 行書くだけで十分です。重要なのは「意識的に振り返る」という行為自体です。振り返りなしに次の本に進むと、前の本の学びが定着しないまま流れてしまいます。

技術書の内容を実務に活かすには「1 冊 1 実践」ルールが最も効果的です。1 冊から 1 つだけ選び、2 週間意識して実践し、振り返る。全部実践しようとせず、最も効果の高い 1 つに集中する。このサイクルを回すだけで、技術書は「読み物」から「実務ツール」に変わります。