README を書くように本を読む - エンジニアのための構造化読書法

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

エンジニアには読書ノートより README が合う

読書ノートを書こうとして挫折した経験はないでしょうか。「感想を書く」「要約する」と言われても、何をどう書けばよいのかわからない。結局、白紙のノートだけが残る。

エンジニアには、読書ノートより README の方が合います。README は「このプロジェクトは何か」「どう使うか」「注意点は何か」を構造化して書くフォーマットです。この構造をそのまま読書に転用すると、本の内容が驚くほど整理されます。

本を 1 冊読んだら、以下の 3 セクションで整理します。

1〜2 文で、この本が解決する問題を書きます。「テストの書き方がわからないエンジニアに、テスト設計の基本パターンを教える本」のように、対象読者と提供価値を明確にします。

ライブラリの README で最初に書く「Overview」と同じです。この 1〜2 文が書けない場合、本の核心を掴めていない可能性があります。

本から学んだ知識を、実務でどう使うかを箇条書きで 3〜5 項目書きます。抽象的な概念ではなく、具体的なアクションに落とし込みます。

- テストを書くときは AAA パターン (Arrange-Act-Assert) で構成する
- モックは外部依存 (DB、API) にだけ使い、内部ロジックにはモックを使わない
- テスト名は「何を」「どんな条件で」「どうなるか」の 3 要素を含める

README の「Usage」セクションと同じ発想です。読んだ人がすぐに手を動かせるレベルまで具体化します。

本の内容をそのまま適用すると問題が起きるケースや、本が触れていない限界を書きます。

- この本のテスト例は Java 前提。動的型付け言語では型チェックのテストが不要になる場面がある
- カバレッジ 100% を推奨しているが、UI テストでは費用対効果が合わないことが多い
- 2018 年出版のため、最新のテストフレームワークの機能には触れていない

README の「Limitations」や「Known Issues」に相当します。このセクションがあることで、本の知識を盲信せず、批判的に活用できるようになります。

README 式が効く理由は、エンジニアが普段から使い慣れた思考パターンだからです。新しいライブラリを評価するとき、「何ができるか」「どう使うか」「制約は何か」の 3 点を確認するはずです。同じフレームワークで本を評価すると、自然に構造化された記録が残ります。

もう 1 つの利点は、再利用性の高さです。半年後に「テストの書き方どうだったっけ」と思ったとき、感想文を読み返しても答えは見つかりません。しかし README 式なら「How」セクションを見るだけで、具体的なアクションがすぐに思い出せます。

エンジニア向けのノート術の本も参考になりますが、まずはこの 3 セクションだけで始めてみてください。

最初の 1 冊は、最近読み終えた本で試してください。本を開かずに、記憶だけで What・How・Caveats を書いてみます。書けない部分が、理解が浅い箇所です。そこだけ本に戻って確認すれば、効率的な復習になります。

フォーマットは Markdown ファイルでも、Notion のページでも、紙のノートでも構いません。大切なのは 3 セクションの構造を守ることです。構造があるから書ける。書けるから続く。続くから知識が積み上がる。

README を書くように本を読む。What (何の本か)、How (どう使うか)、Caveats (注意点) の 3 セクションで整理するだけで、読書の記録が実務で再利用できる資産に変わります。エンジニアが毎日書いている README のスキルを、そのまま読書に転用してください。