はじめに
とにかく経験年数を重ね、とにかくコードを書きまくって、たくさんエラーを踏んで解決していくことこそが成長の唯一の道だと思っていました。当時の私は技術書を読むことが時間の無駄だと思っていました。技術書を読んだところですぐにコードが書けるようになるわけではないし、今直面している課題の答えが書いてあるとも限らない。何より、本を読む時間そのものが苦痛でした。
そんな私が本をたくさん読むようになったのは、転職がきっかけでした。
新しい職場のエンジニアたちは、圧倒的に強い人たちばかりでした。ソフトウェア設計の議論には全くついていけず、焦って相談すると、彼らは口を揃えて「この本を読むといいですよ」「この本は必読書ですね」と、いろんな本を紹介してくれました。
本を読むのは嫌いでしたが、実務についていくためには読むしかありませんでした。
数ヶ月は、ただ嫌々本を読んでいた
最初の数ヶ月は、まさに苦行でした。
体系的な知識はなんとなくついた気はしましたが、実務で直面する課題とは別物に見えて、本当にためになっているのか分かりませんでした。ただ紹介された本を、義務感だけでめくる日々。
読むのも理解するのも遅く、気づけば別のことを考えてしまっている。全然頭に入っていない自分に嫌気がさし、本を読むことがどんどん嫌いになっていきました。
そんな時、役員の方から「本を読んでいて偉いですね。本を読むことはとても大切ですよね」と声をかけられました。私が「読むスピードも遅いし、理解もあまりできなくてうまく読めていないんです」と正直に伝えると、その役員の方は金言を贈ってくれました。
「読む速さなんて、気にしなくていい。遅くても、全部理解できなくてもいい。大事なのは、本を好きになれる一冊に出会い、本を読むこと自体を楽しめるようになること。そうやってたくさん読んでいれば、自然に速く読めるようになるし、理解もスラスラできるようになりますよ」
「勉強」から「趣味」へ
この言葉で、私の向き合い方は一変しました。
「勉強しなきゃ」という義務感を捨て、速度を気にせず、ただ楽しむ。そう決めた途端、焦りが消えて集中できるようになり、驚くほど内容が頭に入るようになりました。
変化はすぐに現れました。本で得た体系的な知識をもとに、少しずつ設計の議論に参加できるようになったのです。
ある時、知人に実務とは別で過去に自分も携わっていたtoCアプリケーションのパフォーマンス改善という課題の設計が上手くいっていない。今は妥協してこういう構成になっているということを相談されました。私にはその領域の知見はなかったのですが、以前読んだ本の一節を思い出し、思考をフル回転させて解決策を提示したところ後日、無事に改善できましたという連絡をもらいました。
やったことがないはずなのに、本で学んだ知識をもとに解決できたことで読書の本当の価値を痛感しました。
先人が残した「攻略済みの地図」
パフォーマンス改善に興味が出た私は、次に『システム設計の面接試験』という本を手に取りました。
すると、最初の章に、あの日私が必死に考えて出した「答え」がそのまま書いてありました。「この本を読んでいれば、もっと早く解決できたのか。。。」と、その凄さに言葉を失いました。
さらに読み進めている『大規模サービス技術入門』には、これからサービスが成長する過程で直面するであろう問題の解決策が、メモリやOS、インフラの観点から解き明かされていました。
結局のところ、私たちが今もがき、苦しんでいる難題の多くは、すでに先人たちが解決して「地図」にしてくれていたのです。
彼らが長い時間をかけて切り拓いた知恵を、わずか数千円で買うことができる。これほど賢い投資は他にないと確信しました。自力で暗闇を彷徨うか、それとも地図を手に最短距離を走るか。
今の私にとっては読書は苦行ではなく、先人達が苦労して解決した歴史を感動しながら学べ、現在取り組んでいる複雑で難解なアプリケーション開発に活かせる知識を得られるとても楽しい趣味と呼べる時間になりました。
強いエンジニアやベテラン役員の方たちが「とにかくコードを書きまくれ」ではなく「本を読め」と言ってくれた意味が少しずつわかってきた今日この頃です。
