README を書くように本を読む - エンジニアのための構造化読書法
この記事は約 4 分で読めます。
エンジニアには読書ノートより README が合う
読書ノートを書こうとして挫折した経験はないでしょうか。「感想を書く」「要約する」と言われても、何をどう書けばよいのかわからない。結局、白紙のノートだけが残る。
エンジニアには、読書ノートより README の方が合います。README は「このプロジェクトは何か」「どう使うか」「注意点は何か」を構造化して書くフォーマットです。この構造をそのまま読書に転用すると、何を書けばよいかで迷わなくなります。書く枠が先に決まっているので、感想を絞り出す必要がなくなるからです。
README 式読書フォーマット
本を 1 冊読んだら、以下の 3 セクションで整理します。
What (この本は何か)
1〜2 文で、この本が解決する問題を書きます。「テストの書き方がわからないエンジニアに、テスト設計の基本パターンを教える本」のように、対象読者と提供価値を明確にします。
ライブラリの README で最初に書く「Overview」と同じです。この 1〜2 文が書けない場合、本の核心を掴めていない可能性があります。
How (どう使うか)
本から学んだ知識を、実務でどう使うかを箇条書きで 3〜5 項目書きます。抽象的な概念ではなく、具体的なアクションに落とし込みます。
- テストを書くときは AAA パターン (Arrange-Act-Assert) で構成する
- モックは外部依存 (DB、API) にだけ使い、内部ロジックにはモックを使わない
- テスト名は「何を」「どんな条件で」「どうなるか」の 3 要素を含める
README の「Usage」セクションと同じ発想です。読んだ人がすぐに手を動かせるレベルまで具体化します。
Caveats (注意点)
本の内容をそのまま適用すると問題が起きるケースや、本が触れていない限界を書きます。
- この本のテスト例は Java 前提。動的型付け言語では型チェックのテストが不要になる場面がある
- カバレッジ 100% を推奨しているが、UI テストでは費用対効果が合わないことが多い
- 2018 年出版のため、それ以降に入ったテストフレームワークの機能には触れていない
README の「Limitations」や「Known Issues」に相当します。このセクションがあることで、本の知識を盲信せず、批判的に活用できるようになります。
3 セクションの早見表
書くときに迷わないよう、3 セクションの役割を一覧にします。
| セクション | README の対応箇所 | 書く内容 | 分量の目安 |
|---|---|---|---|
| What (この本は何か) | Overview | この本が解決する問題を、対象読者と提供価値がわかる形で書く | 1〜2 文 |
| How (どう使うか) | Usage | 学んだ知識を実務でどう使うか。抽象的な概念ではなく、すぐ手を動かせる具体的なアクションに落とす | 箇条書きで 3〜5 項目 |
| Caveats (注意点) | Limitations / Known Issues | そのまま適用すると問題が起きるケースと、本が触れていない限界 | 気づいた分だけ箇条書き |
3 つのうち書けないセクションが、その本で理解が浅い箇所です。
なぜこのフォーマットが効くのか
README 式が効く理由は、エンジニアが普段から使い慣れた思考パターンだからです。新しいライブラリを評価するとき、「何ができるか」「どう使うか」「制約は何か」の 3 点を確認するはずです。同じフレームワークで本を評価すると、自然に構造化された記録が残ります。
もう 1 つの利点は、再利用性の高さです。半年後に「テストの書き方どうだったっけ」と思ったとき、感想文を読み返しても答えは見つかりません。しかし README 式なら「How」セクションを見るだけで、具体的なアクションがすぐに思い出せます。
このフォーマットには失敗の型もあります。How セクションが本の見出しの写しになってしまうときは、実務のどの場面で使うかを書き足せていません。「AAA パターンを学んだ」ではなく「次にテストを書くときは AAA の順に並べ直す」と書けているかで見分けられます。
始め方
最初の 1 冊は、最近読み終えた本で試してください。本を開かずに、記憶だけで What・How・Caveats を書いてみます。書けない部分が、理解が浅い箇所です。そこだけ本に戻って確認すれば、効率的な復習になります。
フォーマットは Markdown ファイルでも、Notion のページでも、紙のノートでも構いません。効くのは置き場所ではなく 3 セクションの構造の方です。何を書くかが先に決まっているぶん、白紙を前にして手が止まる場面が減ります。
関連記事
まとめ
README を書くように本を読む。What (何の本か)、How (どう使うか)、Caveats (注意点) の 3 セクションで整理しておくと、読書の記録が半年後に引き直せる形で残ります。エンジニアが毎日書いている README の書き方を、そのまま読書に転用してください。
この記事は役に立ちましたか？
関連用語
関連記事
技術書の余白に書いた走り書きが、半年後の自分を救う
技術書の余白に書いたメモや走り書きは、半年後に読み返すと驚くほど役に立ちます。余白メモの効果的な書き方と、過去の自分との対話を通じた学びの深め方を紹介します。
技術書の読書ログを GitHub で管理する - エンジニアらしい記録法
技術書の読書記録を GitHub リポジトリで管理する方法を紹介します。Markdown で読書ノートを書き、コミット履歴で読書の軌跡を残す、エンジニアならではの読書ログ術です。
技術書の読む順番戦略 - 複数冊を組み合わせて理解を加速させる
技術書を 1 冊ずつ読むのではなく、複数冊を戦略的に組み合わせることで、1 冊では届かない理解の深さと広さに達する方法を解説します。
バグを生むのは知識不足ではなく想像力不足である
バグの多くは、コードを書いた時点で「こういうケースもありうる」と想像できなかったことが原因です。想像力を鍛える読書法と、エッジケースへの感度を高める方法を解説します。
技術書のレビューを書くと理解が 2 倍深まる - アウトプット読書術
読んだ技術書の感想を数行書くだけで、内容が記憶に残りやすくなります。3 行レビューの書き方と、書く場所の選び方、ネット書店のレビュー欄に書く効果を紹介します。
1 万行のコードより 1 冊の設計書が勝つ場面
大量のコードを書く力と、適切な設計を選ぶ力は別物です。コード量では解決できない問題に直面したとき、設計の知識がどう効くのかを具体例で解説します。