エンジニアの読書が続かないのは当然！ジャンル別の挫折理由

【技術書】小説のように「1ページ目から最後まで」読破しようとしている

プログラミング言語やツールの解説書は1ページ目から読むのではなく、読める部分や必要な部分を確認し、全体像を把握しながら読む事が大切です。技術書は小説とは違い物語ではありません。それにもかかわらず、1ページ目から順番に読もうとすると、今の自分には不要な情報や理解が難しい部分に必ずぶつかります。

「ここが理解できないと次に進めない」と立ち止まってしまうのではなく、まずは読める部分や必要な部分を確認し、全体像を把握するようにすると読書の負担が軽くなり、継続できるようになります。

【ビジネス書】概念が抽象的すぎて、日々の業務と結びつかない

ビジネス書の場合、コードのような絶対的な正解がないので抽象的な内容になりがちな上、日々の業務と結びつけられないと途中で飽きてしまいます。そのため、自分が直面している課題や将来的に身につけたいスキルや知識を把握し、それらに結びつくビジネス書を選ぶのが理想です。

例えば「PMとして活躍したいからプロジェクトマネジメントの概念を説明している本を読んでみよう」「現場メンバーのマネジメントで知りたい事があるから実践ノウハウについて記載している本を読んでみよう」など目的と結びつけて選ぶ事で読書に意味を見出せるので、格段に読書効率が上がります。

【共通】日々の業務で、すでに「目」と「脳」のエネルギーが尽きている

エンジニア全員に共通する読書が続かない大きな理由の1つは日々の業務で目と脳が疲れ切っている事です。エンジニアは1日中PCモニターを睨み、複雑なロジックを組み立て、バグと戦っています。業務が終わる頃には、目も脳も疲れ切っています。その状態で、さらに細かい活字を追おうとするのは、フルマラソンの後に筋トレするのと同じぐらいハードな行動です。

お風呂に入った後に読書の時間をとる、寝る前の30分を読書時間にするなどリラックスできている状態で読書に臨む事で読書して疲れるという状態を打破できます。

「読む」のではなく「使う」！今日から試せるエンジニア向け読書術

目的は「本を読み切ること」ではなく「実務での課題解決」と心得る

本は最後まで読み切る事をゴールと考えがちですが、実際には実務で直面している課題や将来的に身につけたいスキルを1つでも身につけ、アウトプットに活かせるかが重要です。たとえ1つの章、数ページを読んだだけでも、今まで書けなかったコードが書けるようになったりチーム会議がスムーズに進んだりすれば、その本の価値は十分に回収できたと言えます。読み切る事を目的にせず、実務の課題を解決する事を目的にして読書に臨む意識が大切です。

まずは「目次」と「索引」だけを見て、本の全体マップを頭に入れる

本を買ったら本文を読む前に「目次」と「索引」だけをじっくり眺めてください。まずは「どこに・何が・どのくらいの粒度で書いてあるか」というインデックスを脳内に作るイメージで全体像を把握しましょう。これは速読でも使われるテクニックで、本の全体像を頭に入れる事で必要な情報を引き出しやすくする効果を得られます。

全体像を頭に入れておく事で後日実務でエラーや課題に直面したとき、「あ、あの本の3章あたりに解決策が載っていたな」とすぐに引き出せるようになり、本を有効活用できます。

目次と結論から読み、解決策を逆引きする

ビジネス書などで特に有効なのが逆引きです。各章の「まとめ」や「結論」から読み、結論を知った上で「なぜそうなるのか？」と気になった部分だけを遡って読むことで、短い時間で効率よくインプットできます。あくまで知りたいのは解決策であるため、そこに至るまでの仮定や筆者の考えの中には不要なものも混じっているケースもあります。無駄な読書を省くという意味でも逆引きは有用です。

基本的に言いたい事の8割は結論部分を読めば把握できるので、読書を効率的に進めるのに最適な方法と言えます。

難しくて理解できない章は「今の自分には不要」と潔く飛ばす

読んでいて「難しい」「頭に入ってこない」と感じる部分は、あなたの能力不足ではなく、今の業務に関係がないか、前提知識が足りていないだけです。そこで立ち止まらず、「今の自分には不要」と割り切って付箋だけ貼り、読み進めましょう。

読み終わった後に付箋部分を読み返す事で理解できたり、他の本を読んだ後に再読した際に理解できたりと、どこかで理解できる時が来ますので、読書が止まるぐらいであれば読み飛ばしてください。

目で追うだけでなくエディタで手を動かす「写経」で眠気を防ぐ

疲れた目で活字を追っているとどうしても眠くなります。技術書を読むときは、サンプルコードを実際にエディタで打ち込んで動かしてみる「写経」を取り入れましょう。アウトプットする事で実際に目の前でコードが動くため、理解が深まります。また、手を動かすことで脳がアクティブになり、眠気を防いでくれるため、一石二鳥です。

Qiitaや社内会議でのアウトプットを前提に必要な箇所を重点的に読む

「今週末にQiitaに備忘録を書く」「次の社内会議で提案する」など、先にアウトプットする場を決めてしまいましょう。すると、漫然と文字を追う受け身の読書から、記事や資料を作るために「本の中から必要な情報を探しに行く」という能動的な読書に切り替わり、集中力や理解力が格段に高まります。

インプットはアウトプットありきで考えると大幅な効率アップにつながりますので、ぜひ取り入れてみてください。

検索すれば解決する時代にエンジニアが本を読む3つのメリット

なぜ動くのか？の原理原則が理解できる

本は、体系的に書かれているため「なぜこの設計なのか、裏側でどう動いているのか（Why）」という原理原則を学べます。

一方でネット上の記事は「この記事のコードを使えば動きます（How）」という情報に寄りがちです。実務の中では動かすことは確かに重要ですが、それで終わっていては応用力が身につきません。根本的なエンジニアとしての実力を身につけたいなら、本で原理原則を身につけるべきです。

コードだけでないビジネス視点が得られる

ビジネス書や概念系の本を読むことで、単に「要件通りにコードを書く」だけでなく、上流工程の意図やチーム開発を円滑にするための視点が得られます。「プロダクトをどう成功させるか？」というビジネス視点を持つことは、シニアエンジニアへとステップアップする上で不可欠です。

ネット記事はどうしてもコードや設定方法などの技術的な内容に寄りがちなため、本でビジネス視点を得て将来的なキャリアアップに繋げましょう。

著者と編集者の厳しいチェックを通った信頼性の高い情報を得られる

商業出版された本は専門家である著者が執筆し、編集者や技術レビュアーの厳しいチェックを経ているため、情報の信頼性と普遍性が圧倒的に高いのが特徴です。

一方でネット上の情報は誰でも手軽に発信できる分、内容が古かったり、特定の環境下でしか動かない偏った情報であったりと条件が限定される事も多いため、利用場面が限られるケースも多くなります。

エンジニアとしての基礎を固め、将来的にも使える知識を得たい場合の有用性は読書が勝ります。

「積読」を資産に変える！読書ハードルを下げる環境づくり

本のタイプで紙と電子を使い分ける

本のタイプによって紙の本と電子書籍を使い分ける事で利用場面や読書できるシーンも自然と決まってくるため、どの本をどちらで読むか決めましょう。使い分ける事で家や職場など広いスペースを使える時は紙の本を中心に読む、電車や外出時の待ち時間などの隙間時間では電子書籍の本を読むといった読書のルールが定まります。

読書時間を短時間で決めてハードルを下げる

読書時間を「タイマーをセットして1日25分だけ読む」「風呂上がりの30分だけ読む」「電車に乗っている15分は読書」といった短時間で読むルールを作りましょう。逆に「休日にまとめて3時間読もう」とまとまった時間で読もうとすると早々に挫折する可能性が高いです。短時間で良いのでハードルを極限まで下げることで、結果的に読書の習慣が定着しやすくなります。

通勤時間や家事の合間はオーディオブックを活用する

なかなか時間をとれない人は耳学習を取り入れてみてください。PC作業で疲弊した目を休ませるのにも最適です。コードの記載がないビジネス書やマネジメントの本であれば、Audibleなどのオーディオブックを活用する事で耳から直接インプットできます。通勤電車の中や散歩、家事の合間に「ながら聴き」するだけで良いので、時間がない人や何かをしながら読書をしたい人にも最適な方法です。

まとめ

本を最後まで読めない自分を責める必要はありません。技術書もビジネス書も「読み切るもの」ではなく、エンジニアとしての実力やキャリアアップに繋げる道具として使いましょう。

今日からは「全部読まなくていい」と割り切って、まずは本棚で眠っている積読本の「目次」だけでも眺めてみてください。 その小さな一歩が、読書を続けるきっかけになり、将来のキャリアアップに繋がっていきます。