技術書の読書ログを GitHub で管理する - エンジニアらしい記録法

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

なぜ GitHub で読書ログを管理するのか

技術書の読書記録をどこに残すか。ノートアプリ、読書管理サービス、紙のノート。選択肢は多いですが、エンジニアにとって最も自然な場所は GitHub です。

GitHub で読書ログを管理する利点は 3 つあります。Markdown で構造化された記録が書ける。コミット履歴が読書の継続を可視化する。そして、公開リポジトリにすればポートフォリオの一部になる。

リポジトリの構成

シンプルな構成から始めます。

reading-log/
├── README.md          # 読書リストの一覧
├── 2026/
│   ├── 01-clean-code.md
│   ├── 02-design-patterns.md
│   └── 03-refactoring.md
└── templates/
    └── book-note.md   # 読書ノートのテンプレート

年ごとにディレクトリを分け、1 冊につき 1 ファイルを作成します。ファイル名は連番とスラッグの組み合わせにすると、読んだ順序がわかりやすくなります。

読書ノートのテンプレート

各書籍の Markdown ファイルには、以下の項目を記録します。

# Clean Code

- 著者: Robert C. Martin
- 読了日: 2026-01-15
- 評価: ★★★★☆

## 読んだ動機

コードレビューで指摘される内容を体系的に学びたかった。

## 要点 (3 行)

1. 関数は 1 つのことだけをする
2. 命名に時間をかけることは無駄ではない
3. コメントは失敗の証拠。コードで意図を伝える

## 実務に活かしたこと

- PR #142 で関数の分割を実践した
- チームの命名規則ドキュメントを更新した

## 引用・メモ

> "You know you are working on clean code when each routine
> you read turns out to be pretty much what you expected."

第 3 章の関数の長さに関する議論が特に参考になった。

ポイントは「要点を 3 行に絞る」ことと「実務に活かしたこと」を記録することです。要点を絞る作業は理解の確認になり、実務への適用を記録することで読書が行動に結びつきます。

引用を書き写すときは、出どころまで正確に残します。上の例で引いた一文は著者本人の言葉ではなく、『Clean Code』第 1 章で引用されている Ward Cunningham の言葉です。誰の発言かを取り違えたメモは、後から自分の理解ごと狂わせます。

また、公開リポジトリに原文を長く写すのは引用の範囲を超えます。地の文は自分の言葉で要約し、原文の引用は必要な最小限に留めてください。

コミットメッセージの工夫

読書ログのコミットメッセージにもルールを設けると、後から振り返りやすくなります。

読了: Clean Code (Robert C. Martin)
メモ追加: Clean Code 第3章 関数
読書中: デザインパターン (GoF) - 第5章まで

読了、メモ追加、読書中 のプレフィックスを使い分けることで、コミット履歴が読書の進捗ログになります。

README.md を読書リストにする

リポジトリのトップに置く README.md は、読書リストの一覧として機能させます。

# Reading Log

## 2026

| # | タイトル | 著者 | 読了日 | 評価 |
|---|---------|------|--------|------|
| 3 | リファクタリング | M. Fowler | 2026-03-20 | ★★★★★ |
| 2 | デザインパターン | GoF | 2026-02-10 | ★★★★☆ |
| 1 | Clean Code | R. Martin | 2026-01-15 | ★★★★☆ |

この一覧があると、年間の読書量が一目でわかります。GitHub のプロフィールにピン留めしておけば、面接や転職活動で話の材料にもできます。ただし人に見せる前提なら、上に書いた引用の扱いだけは確認しておいてください。

GitHub の機能を活用する

コントリビューショングラフ

読書ログへのコミットは、条件を満たせば GitHub のコントリビューショングラフに反映されます。数えられるのは既定ブランチ (プロジェクトサイト用の gh-pages ブランチも可) へのコミットで、コミットに使うメールアドレスがアカウントに登録済みであることも条件です。fork したリポジトリへのコミットは数えられず、反映まで最大 24 時間かかります (2026 年 8 月時点の GitHub 公式ドキュメント)。作業ブランチにメモを溜めても草は生えないので、読書ログは既定ブランチへ直接コミットする運用が簡単です。

非公開リポジトリで運用する場合、他人に見えるのはプロフィールの設定で非公開の活動を表示にしたときの匿名化された記録だけで、リポジトリ名や内容は出ません。

Issues で読みたい本を管理する

読みたい本を Issue として登録し、読了したら Close する運用も効果的です。ラベルで「読書中」「積読」「読了」を管理すれば、カンバンボードのように使えます。

GitHub Actions で自動集計

年間の読了冊数や評価の平均を自動集計するスクリプトを GitHub Actions で動かすこともできます。ただし、最初からここまで作り込む必要はありません。まずは Markdown ファイルを 1 つ作るところから始めてください。集計を自動化しても、読んだ本が増えなければ出力は変わりません。

関連記事

• 読書メモは未来の自分への手紙である
• 技術書の読書メモ術 - 読んだ内容を確実に定着させる記録法

まとめ

技術書の読書ログを GitHub で管理すると、記録が構造化され、継続が可視化され、ポートフォリオにもなります。テンプレートを 1 つ作り、最初の 1 冊を記録するところから始めてください。コミット履歴が積み上がると、続けた分がそのまま目に見える記録になります。