はじめに
「技術書」の読書術』は、私が確認した時点ではKindle Unlimitedの対象となっており、Kindle Unlimitedの会員であれば追加料金なしで読むことができました。
それでも今回は、Kindle版ではなく、いわゆる物理本である紙の本を購入しました。
『「技術書」の読書術』について
本書は、IPUSIRON氏と増井敏克氏が、それぞれの経験をもとに技術書の読書術をまとめた本です。
大きく、次の3部に分かれています。
- 第1部 選び方
- 第2部 読み方
- 第3部 情報発信＆共有
単に本を効率よく読む方法だけではなく、技術書との出会い方から、読んだ内容をどのように実践し、他者へ共有していくかまで扱われています。
また、二人の著者がそれぞれの経験や考え方をもとに執筆しているため、すべての読書法が一つの考え方に統一されているわけではありません。
効率を重視する読み方もあれば、読書そのものを楽しみながら幅広く本を読む方法もあります。一見すると相反するような方法も、そのまま並べられています。
むしろ、異なる方法や価値観が共存していることが、本書のおもしろさだと感じました。
本書で紹介されている方法を、すべてそのまま取り入れる必要はありません。
自分の生活や仕事、読んでいる技術書の種類に合わせて、使えそうな方法を選んで試していく。そのための「読書法のカタログ」として読むことができます。
良書を選び続けるのは不可能
特に印象に残ったのが、第1部「選び方」の1-2でIPUSIRON氏が述べている、「良書を選び続けるのは不可能」という考え方です。
名著と呼ばれている本や、信頼している人がおすすめしている本であっても、実際に読んでみると、いまの自分には合わないことがあります。
私自身も、「あの人がおすすめしているから」「多くの人が名著だと言っているから」という理由で手に取ったものの、内容があまり刺さらないと感じる経験が何度もありました。
一般的に良書とされている本が、自分にとっても相性のよい本であるとは限りません。
技術書の場合は特に、読者の前提知識、現在の課題、知りたい内容、扱っている技術のバージョンなどによって、その本が役立つかどうかが変わります。
そのため、良書か悪書かを事前に正確に見極めようとするよりも、まずは手に取ってみる。合わなければ流し読みをしたり、必要な章だけを読んだり、別の本に切り替えたりする。
そのくらい柔軟に本と付き合うほうがよいのだと思えるようになりました。
この考え方については、翔泳社が公開している以下の抜粋記事でも読むことができます。
https://www.shoeisha.co.jp/book/article/detail/365
技術書は「読み切ること」が目的ではない
途中で読むのをやめると、「この本も読み切れなかった」と感じてしまうこともあります。
しかし、技術書を読む目的は、読了した本の冊数を増やすことではありません。
現在抱えている問題を解決すること、新しい技術の全体像を理解すること、実際に何かを作れるようになることなど、読書の先にある目的を達成することのほうが重要です。
目的が達成できるのであれば、必要な章だけを読んでもよいですし、現時点では理解できない部分を飛ばしてもよいはずです。
今後は技術書を開く前に、次の一文を書くところから始めてみようと思います。
この本を読むことで、何ができるようになりたいのか。
できれば、知りたいことを3つほど具体的な問いにしておきます。
たとえば、次のような問いです。
- この技術は、どのような問題を解決するために生まれたのか
- 現在担当しているシステムへ適用できるのか
- 導入した場合、どのようなトレードオフが発生するのか
読む目的が明確になっていれば、読むべき章と、いまは読まなくてよい章を判断しやすくなります。
一度で理解しようとしない
もう一つ印象に残ったのが、同じ本を何度も読むという考え方です。
技術書を一度読んだだけで、内容をすべて理解し、実務で使えるようになることは簡単ではありません。
そこで、一回の読書ですべてを済ませようとせず、読むたびに目的を変える方法が紹介されています。
たとえば、次のような読み方です。
- 一度目は、全体像を把握するために読む
- 二度目は、サンプルコードを動かしながら読む
- 三度目は、ノートやブログにまとめながら読む
- 実務で関連する問題が起きたときに、必要な部分を読み返す
一度目では理解できなかった内容も、実務経験を積んだあとに読み返すと、以前とは違う意味で理解できることがあります。
再読は単なる復習ではなく、以前の自分と現在の自分との違いを確認する機会でもあります。
その意味でも、気になったページへすぐ戻り、以前に貼った付箋や書き込みを確認できる紙の本は、今回の目的と相性がよいと感じました。
読書と実践を分けない
プログラミングやシステム設計に関する本は、文章を読んで理解しただけでは、実際に使える知識にならないことがあります。
サンプルコードを読んでいると、その場では理解できたように感じます。しかし、自分でゼロから書こうとしたり、条件を変更して応用しようとしたりすると、細部を理解できていなかったことに気づきます。
そのため、技術書を読むときは、少なくとも一つは自分の手を動かすことにします。
サンプルコードを実行するだけでもよいですし、一部を書き換えて挙動を確認するだけでも構いません。
設計に関する本であれば、自分が担当しているシステムに当てはめて図を書いたり、既存の設計との違いを整理したりする方法もあります。
重要なのは、本を読み終えてから実践するのではなく、読みながら小さく実践することだと思います。
本書の考え方については、以下の抜粋記事でも「よいコードより動くコード」という言葉で紹介されています。
技術書で本当にスキルアップできる読み方とは？ 『「技術書」の読書術』の著者は「動くコードを自分で書く」
現在なら、技術書・公式ドキュメント・生成AIを使い分ける
本書が刊行された2022年以降、技術書を読むための環境は大きく変化しました。
特に生成AIの登場によって、分からない用語を別の表現で説明してもらったり、前提知識を整理してもらったり、サンプルコードの変更案を考えてもらったりすることが簡単になりました。
現在の環境で本書の読書術を実践するなら、私は次のように役割を分けたいと考えています。
- 技術書：技術が生まれた背景や、体系的な知識、設計思想を理解する
- 公式ドキュメント：現在の仕様、API、対応バージョンを確認する
- 生成AI：疑問点を言語化し、理解できていない部分を見つける
- 実装や検証：本当に理解できているかを自分の手で確かめる
生成AIは、「本を読まなくても済むようにする道具」ではなく、本を深く読むための補助線として使うのがよさそうです。
たとえば、次のような使い方が考えられます。
- 分からない概念を、別の具体例で説明してもらう
- 自分の理解を文章にして、誤解していそうな部分を指摘してもらう
- 読んだ内容から理解度を確認するための問題を作ってもらう
- サンプルコードの一部を変更したときの挙動を予想してもらう
- 本に書かれている内容と、現在の公式ドキュメントとの差分を整理する
ただし、生成AIの回答が正しいとは限りません。
特に、ライブラリやフレームワークの仕様、セキュリティ、料金、サポート状況など、変化する可能性がある情報は、必ず公式ドキュメントや実際の動作で確認する必要があります。
技術書で全体像を学び、生成AIで疑問を整理し、公式ドキュメントと実装で確認する。
道具が増えても、最後は自分の手で確かめるという部分は変わらないのだと思います。
紙で読み、デジタルには再利用したい情報だけを残す
紙の本で読んだからといって、すべての記録を紙だけに残す必要はありません。
紙の本は、全体の厚みや現在地を感覚的に把握し、前後のページを行き来することに向いています。
一方、あとから検索したり、ほかの本と関連付けたり、チームへ共有したりする情報は、デジタルで残すほうが便利です。
そこで、紙とデジタルを次のように使い分けたいと思います。
紙の本には、付箋や簡単な書き込みを残します。
デジタルには、本の内容をすべて転記するのではなく、次の3つだけを記録します。
- ページ番号
- 自分が気づいたこと
- 次に試すこと
たとえば、次のように記録します。
124ページ
iPadのペンで思考が広がらないのは、11、13インチのビューしか入ってこないからなのかもしれない。
数学などは、手書きで紙とペンを持ってProject Paperなどを用いて数式を書いて覚える。
本の要約ではなく、自分の判断や行動が変わった部分を記録することで、あとから読み返す意味が生まれます。
要約を否定してる訳ではなく、要約のWebサービスも本書では紹介されていましたし、昨今では本を要約の動画をアップしているユーザーも散見されています。
ちなみに、インプットの手段は様々使うと良いとも書かれていました。
アウトプットまでを読書に含める
このブログ記事を書くことも、本書で紹介されている読書方法の実践の一つです。
読んでいるだけでは、自分がどこまで理解しているのかを判断しにくいものです。
ところが、誰かに説明しようとすると、言葉にできない部分や、曖昧に理解していた部分が見えてきます。
完成された知識でなければ発信してはいけない、ということはありません。
「この方法を試してみた」「この部分は理解できなかった」「自分の仕事ではこう応用できそうだ」といった、学習の途中にある記録にも意味があります。
私は、本ブログで書評を書いていくことで、アウトプットを一つ増やすことにしました。
また、技術書を読んだあとのアウトプットは、ブログ記事だけではありません。
たとえば、次のようなものもアウトプットになります。
-
サンプルコードを動かしたリポジトリ
-
開発やレビューで使用するチェックリスト
-
社内勉強会の資料
-
オンボーディング用の推薦図書リスト
-
実際の開発プロセスに加えた変更
一冊読んだら一記事を書く、と決める必要はありません。
その本を読んだことで、コード、設計、判断、説明のどれか一つでも変われば、それも十分なアウトプットです。
今後は、読了した冊数を増やすことよりも、一冊につき一つ、何かを変えることを意識したいと思います。
個人だけでなく、チームの読書にも活用する
本書の内容は、個人の読書だけでなく、チームで技術書を選ぶ際にも応用できそうです。
チームの推薦図書を単に一覧にするだけでは、新しく参加したメンバーは、どの本から読めばよいのか判断できません。
「おすすめの本です」と共有するだけでなく、それぞれの本について、次のような情報を付けておくとよさそうです。
- どのような人を対象にした本か
- 何を理解するための本か
- 読むために必要な前提知識は何か
- 最初から読むべきか、必要な章だけでよいか
- 入社時に読んでほしい本か、必要になったときに読む本か
- どの技術やバージョンを対象としているか
- 内容を最後に確認したのはいつか
- 読んでいないと困る本か、読んでいると理解が深まる本か
技術書には、その時点では正しかったものの、現在では仕様が変わっている内容もあります。
そのため、推薦図書リストにはタイトルだけでなく、対象バージョンや最終確認日も残しておくと、より実務で使いやすくなります。
単に本を共有するのではなく、「誰に、何のために、どこまで読んでほしいのか」を共有することで、技術書をチームの共通言語として活用しやすくなりそうです。
まとめ
『「技術書」の読書術』を通じて、技術書には一つの正しい読み方があるわけではないと感じました。
最初から最後まで読む方法もあれば、必要な章だけを読む方法もあります。
短時間で全体像をつかむこともあれば、何度も読み返しながら手を動かすこともあります。
また、一般に良書とされている本が、現在の自分にとっても最適な本であるとは限りません。
合わない本を選ぶことまで避けようとするのではなく、合わなければ読み方を変えたり、別の本や資料で前提知識を補ったりすればよいのだと思えるようになりました。
本書が刊行されたあと、生成AIをはじめ、読書を補助するための道具も増えました。
しかし、便利な道具を使って要約を得ることと、自分で理解し、判断し、行動できるようになることは別です。
今後は、次の流れで技術書を読んでみようと思います。
- 読む前に、その本で解決したい問いを決める
- 目次を見て、読む範囲と読まない範囲を決める
- 紙の本へ付箋や書き込みを残す
- 変化しやすい情報は公式ドキュメントで確認する
- 生成AIを使って疑問点や理解不足を言語化する
- サンプルコードや設計を一つ実際に試す
- ページ番号、気づき、次の行動を記録する
- ブログ、コード、資料などの形で一つアウトプットする
- 実務で必要になったときに、もう一度読み返す
今回、Kindle Unlimitedで読める本をあえて紙で購入したのも、一度読んで終わりにするのではなく、何度も開き、付箋や書き込みを積み重ねていく本にしたかったからです。
本書は「選び方」「読み方」「情報発信＆共有」の区切りが小口から見ても分かりやすく、必要な場所へ物理的に戻りやすい構成になっています。
紙の本と電子書籍のどちらが優れているということではありません。
体系的に理解するための技術書、現在の仕様を確認するための公式ドキュメント、疑問を整理するための生成AI、そして、自分の理解を確かめるための実践。
それぞれの役割を意識しながら、自分に合った読書術を作っていきたいと思います。
Kindle版にはないことを確認しましたが、カバーのそでの部分には著者の紹介に加え、このような言葉が綴られていました。
技術書を血肉にする術を教えます。
（個人的にカバーのそでは小説を読む時とかに、親切だと登場人物の紹介などが書かれていたりするので、必ず確認しています。）
そして最後に、この文章を書くことを、本書を読んだあとの最初のアウトプットにします。