はじめに — タスク管理ツールに疲れた人へ

副業や個人開発を複数領域で進めていくと、いつの間にか抱える「やること」の数が爆発します。私の場合、本業以外に 資産管理（高配当株）／ココナラ副業／キャリア（職歴管理）／SNSマーケ／創作／コンテンツ販売／バックオフィス／家庭課題 と8つの領域を並行で動かしている状態。これを Notion・Trello・Todoist と渡り歩いてきたのですが、どのツールでも長続きしませんでした。

理由はシンプルで、「ツールの操作」と「思考の構造化」が分離している からです。タスクを書くたびにブラウザを開き、リッチエディタの見た目を整え、タグを貼り、優先度を選ぶ。そのオーバーヘッドが積み重なると、忙しいときほどタスク管理を後回しにしてしまう。

この記事は、そこから抜け出すために私が辿り着いた 「Claude Code＋Markdown＋GitHub」を組み合わせた個人PMO（プロジェクト管理オフィス） の運用方法を、ディレクトリ設計から日常オペレーションまで具体的に書き残したものです。エンジニアで、複数領域の副業や個人プロジェクトを並行で進めていて、既存のタスク管理ツールに疲れている人を主な読者として想定しています。

なぜClaude Code＋Markdownなのか

既存タスク管理ツールが個人副業に合わない理由

私が乗り換え続けてきた既存ツールの不満点を、エンジニア視点で整理するとこうなります。

ツール 強み 個人副業視点での不満
Notion リッチな表現力 DB設計を凝りすぎて「ツールの管理」が目的化する／検索が遅い
Trello カンバンが直感的 部門が増えるとボードが散らかる／長文のメモに弱い
Todoist 軽量で速い プロジェクト横断のコンテキストを持てない／履歴がフラット
GitHub Issues 開発と密結合 非エンジニアタスク（家計簿・創作）と相性が悪い

どのツールも一長一短で、結局 「複数領域を1箇所で見渡す」 という目的に合わない。さらに重要な点として、これらのツールは AIエージェントとの相性が悪い。ChatGPTやClaudeにタスク状況を共有しようと思ったら、毎回コピペするか、API連携を組まないといけない。

Claude Codeを「PMO担当者」として雇う発想

ここで発想を転換します。タスク管理ツールを使うのではなく、 AIに「PMO担当者」をやってもらう。具体的には、以下のような構造にします。

  • タスクや進捗は すべて Markdown ファイル に書く（プレーンテキストなのでAIが直接読める）
  • ファイルを 部門ごとに分割 して、領域横断の見通しを保つ
  • すべてを GitHub のプライベートリポジトリ にpushして、複数端末・将来のCIから参照できるようにする
  • Claude Code に 「セッション開始時に必ず最新版をpullしてダッシュボードを読む」 と命じておく

この設計の本質は、 タスク管理を「ツール操作」から「ファイル編集」に降ろす ことです。エンジニアは普段からエディタとgitを触っているので、追加の認知コストがほぼゼロになる。

そして何より大きいのが、 AIエージェントが状況を完全に把握した状態で対話を始められる ことです。「今週何やるんだっけ」「ココナラの記事執筆ってどこまで進んだっけ」を聞くと、Claude Code がリポジトリを読んだ上で正確に答えてくれる。これは Notion でも Trello でも実現できなかった体験でした。

ディレクトリ構造 — 部門別＋履歴分離の二段構成

私が実際に運用しているリポジトリの構造はこうなっています。

docs/management/
├── 00_master_dashboard.md      # 全部門サマリ（毎セッション最初に読む）
├── 01_asset_management.md       # 資産管理部
├── 02_coconala.md               # ココナラ副業部
├── 03_career.md                 # キャリア管理部
├── 04_sns_marketing.md          # SNSマーケティング部
├── 05_entertainment.md          # 創作部
├── 06_content_sales.md          # コンテンツ販売部
├── 07_backoffice.md             # バックオフィス
├── 08_home_tasks.md             # 家庭課題管理部
├── 99_proposals.md              # 起案中・未確定アイデア
├── logs/
│   ├── 01_asset_management.md   # 各部門の作業実績ログ（追記専用）
│   ├── 02_coconala.md
│   └── ... （部門ごと）
├── dashboard/                   # Cockpit（Streamlit）アプリ
└── CLAUDE.md                    # AIエージェント向け運用ルール

「部門」という単位の効用

仕事と副業の文脈で「部門」という単位を切るのは、最初は大袈裟に感じるかもしれません。けれど運用してみると、これが思いのほか効きます。

  • コンテキストの局所化: 「ココナラの話」と「資産管理の話」が混ざらないので、その日のフォーカスが明確になる
  • 横展開の可視化: 「BIスキル習得」のような部門横断キャンペーンを設計するとき、各部門の現状を並べて見渡せる
  • AIへの指示が短くなる: 「04部のスプリントを更新して」で済む。ファイル名が短い指示語になる

各部門ファイルのテンプレート

部門ファイルは以下の4セクションで統一しています。

# 04. SNSマーケティング部

## 1. ロードマップ (Milestones)
**ビジョン:** ...
- Phase 1: ...
- Phase 2: ...

## 2. 担当プロジェクト
- リポジトリ・本番URL等の参照先

## 3. バックログ (Backlog)
- [ ] 未着手の中長期タスク

## 4. 現在のスプリント (Current Sprint)
**目標:** 今週やること
- [ ] Task X: ...

ポイントは 「ロードマップ→バックログ→スプリント」の階層を全部門で揃える こと。形式が揃っていると、AIが部門をまたいで読み比べたり、ダッシュボードに集約したりするのが格段に楽になります。

SSoT（Single Source of Truth）の設計原則

複数のドキュメントを運用していると、必ず 「どっちが最新だっけ問題」 が発生します。チャットの送り合い・メモアプリ・コードリポジトリ・スプレッドシート、情報があちこちに散らばって、結局どれを信じればいいか分からなくなる。

これを防ぐために、私は SSoT（Single Source of Truth） という考え方を徹底しています。

原則1: 領域ごとにSSoTを1ファイル決める

たとえばこんな対応です。

領域 SSoT
全体の進捗管理 docs/management/00_master_dashboard.md
各部門のタスク docs/management/{部門}.md
創作の世界設定 ~/sandbox_toromaru/project_hybrida/world_bible.md
商材のドラフト ~/docs/coconala_knowledge/{商材名}_draft.md
ナレッジ全般 ~/docs/TofuVault/（Obsidian）

「この情報はどこを見れば正解か」が一意に決まっていれば、二重管理は起きません。

原則2: 「現在形」と「履歴」を別ファイルに分ける

これは特に重要なので強調します。

  • {部門}.md = 現在形のみ（バックログ・スプリント）。完了済みタスクはここから削除
  • logs/{部門}.md = 追記専用の業務実績ログ。過去行は絶対に編集・削除しない

なぜ分けるかというと、 AIエージェントがファイルを読むとき、長すぎると本題のコンテキストが薄まる からです。スプリントの判断をしてほしいときに、半年前の完了タスクを延々読ませるのは無駄。一方で、過去の実績は「あのとき何をどう判断したか」を後から振り返るために残しておきたい。

このトレードオフを、 物理的なファイル分割で解決する のが運用上の肝です。

原則3: 必要なときだけログを参照する

logs/ 配下のファイルは、Claude Code のセッション開始時には読まない設定にしています。「先月の判断を確認したい」というユーザーからの明示的な依頼があったときだけ、ピンポイントで読む。これでコンテキストウィンドウの消費を最小限に抑えられます。

CLAUDE.mdで自律ワークフローを定義する

Claude Code には CLAUDE.md という特別なファイルがあって、リポジトリ直下に置いておくとセッション開始時に必ず読み込まれます。これはAIエージェントへの 「常駐指示書」 として機能します。

私は以下のような自律ワークフローを定義しています（抜粋）。

## PMO & Autonomous Workflow

- 本プロジェクト群のSSOTは `docs/management/` である。
- **GitHubリポジトリ:** `https://github.com/.../personal-pmo`（プライベート）
- **セッション開始時:** 必ず `git -C ~/docs/management pull` を実行してから
  `00_master_dashboard.md` を読むこと。
- **docs更新後・タスク完了後:** 必ず以下を実行してGitHubに反映すること：

git -C ~/docs/management add -A git -C ~/docs/management commit -m “docs: <変更内容の要約>” git -C ~/docs/management push

- タスク完了時は、ユーザーへのチャット報告だけでなく、以下の両方を必ず更新すること：
1. **スプリントのステータス更新:** `docs/management/{部門}.md` の
   `## 4. 現在のスプリント` のチェックボックスを更新する。
2. **作業ログへの追記（義務）:** `docs/management/logs/{部門}.md` に1行追記する。
   形式: `| YYYY-MM-DD | プロジェクト名 | 実施内容 | 判断・知見 |`

- **【継続事項のバックログ昇格（必須）】** タスク完了報告に「申し送り」「次回」
「〇〇待ち」「後で」「今後」「課題」等の継続事項を含める場合、その項目を
必ず該当部門の `## 3. バックログ` または `## 4. 現在のスプリント` に
`- [ ]` 形式で登録してから報告を完了する。

自律ワークフローを書くときに効く3つのコツ

実際に運用してみて、効果が高かったルールはこの3つでした。

コツ1: 「報告だけで閉じる」を禁止する

AIエージェントに任せると、つい チャット返信で完結しがち になります。「やっておきました」と言われて、こちらも「ありがとう」で終わる。けれどそれだと 記録に残らない ので、翌週には全員（人もAIも）が忘れる。

そこで「タスク完了時はスプリント更新とログ追記の 両方を義務化する」というルールを明示しました。これだけで、後から振り返れる粒度が劇的に上がります。

コツ2: 「継続事項」を必ずバックログに昇格させる

「申し送り」「次回」「〇〇待ち」のような言葉が出てきたら、それは 未完了タスク です。チャット本文に書いて閉じてしまうと、ダッシュボードからは見えなくなる。

このルールを徹底すると、 「気づいているのに着手できていないこと」がスプリントから漏れない ようになります。私の場合、ここをサボっていた時期は「気づいたら3週間後に同じ問題で詰まっている」みたいなことが頻発していました。

コツ3: 思考は英語、応答は日本語

Claude Code は内部で思考トークンを消費します。日本語よりも英語の方がトークン効率が良いので、 「思考は英語で、ユーザー応答は日本語で」 と指定すると、同じ予算でより深く考えてくれる体感があります。

Cockpit — Streamlitでダッシュボード化する

Markdownだけでも十分回るのですが、複数部門の状況を 横並びで一目で把握したい タイミングは出てきます。私は dashboard/ 配下に Streamlit アプリ（通称 Cockpit）を作って、各部門ファイルから以下を集計しています。

  • スプリント内タスクの完了率
  • 直近1週間のログ追加件数
  • 今日以降のSNS投稿ドラフトの本数
  • 部門ごとのバックログ蓄積数

ローカルで bash dashboard/start.sh を叩くと port 8501 で起動するシンプル構成。Cockpit を見て「あ、SNS部のドラフトが今週分0件だ」と気づいて、cron稼働確認のタスクを切る、みたいな使い方になります。

ここで重要なのは、 Cockpit はあくまで読み取り専用ビュー にしている点です。タスクの追加や更新は必ず Markdown ファイルを直接編集する。GUI から書き込めるようにすると、結局「Notion で挫折したパターン」に戻ってしまうので、あえて編集はテキスト＋AI に閉じています。

実運用Tips — 続けるための7つの習慣

最後に、半年以上運用してきて効いている細かい習慣を箇条書きでまとめます。

  1. セッション開始時に必ずgit pull — 複数端末で更新するなら必須。AIエージェントにルール化させると忘れない
  2. コミットメッセージは Conventional Commits — docs: feat: fix: を徹底するとログが資産化する
  3. ファイル名は数字プレフィックス＋スネークケース — エディタでアルファベット順に並んだとき、優先順位が視覚化される
  4. Markdownのチェックボックス記法を活用 — - [ ] と - [x] だけで未完了/完了が表現できる。AIが読み書きしやすい
  5. 打ち消し線で完了履歴をスプリント末尾に残す — ~~タスク名~~ → 完了日・PR番号 の形式で残しておくと、翌週の振り返りがしやすい
  6. 作業ログは1行で書く — | 日付 | プロジェクト | 実施内容 | 判断・知見 | の表形式に統一すると、grep で検索可能になる
  7. 99_proposals.md で起案を分離 — まだ部門に組み込むか決まっていないアイデアは、専用ファイルに溜める。スプリントが汚れない

まとめ — タスク管理を「思考の構造化」に戻す

Claude Code＋Markdown＋GitHub による個人PMO運用は、突き詰めると 「タスク管理ツールの操作コストをゼロに近づけ、思考の構造化そのものに集中できる環境を作る」 というアプローチです。

エンジニアにとっての強みは大きく3つ。

  • 既存スキルの転用: エディタ・git・Markdown はすでに毎日使っている
  • AIとの完全な相性: ファイルベースなので、AIエージェントが余計な変換なしに読み書きできる
  • 将来の自動化基盤: GitHub Actions・cron・自前のBIパイプラインに自然に接続できる

「副業や個人開発が散らかってきた」「Notion がいつの間にか博物館になっている」と感じている人は、ぜひ一度 docs/management/ のような Markdown ベースの構造を試してみてください。Claude Code をPMO担当者として雇った瞬間から、タスク管理は劇的に軽くなります。

ーー

本記事の運用は、私の本業（データエンジニア）で培った SSoT・スプリント設計・BIダッシュボード の発想を、個人プロジェクトに転用したものです。同じ発想で副業・キャリアログ・資産管理を一元化する記事も今後書いていく予定なので、興味があれば本ブログのRSSやXアカウントをフォローしてもらえると嬉しいです。