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

理由は、ツールの操作と思考の構造化が分離しているから。タスクを書くたびにブラウザを開き、見た目を整え、タグを貼る。そのオーバーヘッドが積もると、忙しいときほどタスク管理を後回しにしてしまう。

この記事でわかること（私が辿り着いた「Claude Code＋Markdown＋GitHub」の個人PMO）：

  • 既存タスク管理ツールが個人副業に合わない理由
  • 部門別＋履歴分離のディレクトリ設計
  • SSoT原則と、CLAUDE.mdによる自律ワークフロー
  • 続けるための実運用Tips

エンジニアで複数領域の副業を並行していて、既存ツールに疲れている人向けです。

なぜClaude Code＋Markdownなのか

乗り換え続けた既存ツールの不満をエンジニア視点で整理すると：

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

どれも「複数領域を1箇所で見渡す」目的に合わず、さらにAIエージェントとの相性が悪い。ChatGPTやClaudeに状況を共有するには毎回コピペかAPI連携が要ります。

そこで発想を転換し、AIに「PMO担当者」をやってもらいます。

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

本質は、タスク管理を「ツール操作」から「ファイル編集」に降ろすこと。エンジニアは普段からエディタとgitを触っているので追加の認知コストがほぼゼロです。そして何より、AIエージェントが状況を完全に把握した状態で対話を始められる。「今週何やるんだっけ」を聞くと、リポジトリを読んだ上で正確に答えてくれる——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   # 各部門の作業実績ログ（追記専用）
│   └── ... （部門ごと）
├── dashboard/                   # Cockpit（Streamlit）アプリ
└── CLAUDE.md                    # AIエージェント向け運用ルール

「部門」という単位は大袈裟に見えて、運用すると効きます。コンテキストの局所化（「ココナラの話」と「資産管理の話」が混ざらない）／横展開の可視化（部門横断キャンペーンで各部門の現状を並べられる）／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を徹底しています。

原則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.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. スプリントのステータス更新（`## 4. 現在のスプリント` のチェックボックス）
2. 作業ログへの追記（`logs/{部門}.md` に1行）

運用して効果が高かったコツは3つ。

  • 報告だけで閉じない — AIに任せると「やっておきました」「ありがとう」で終わりがちだが、それだと記録に残らず翌週には人もAIも忘れる。完了時はスプリント更新とログ追記の両方を義務化すると、後から振り返れる粒度が劇的に上がる
  • 継続事項は必ずバックログへ昇格 — 「申し送り」「次回」「〇〇待ち」は未完了タスク。チャット本文で閉じるとダッシュボードから見えなくなる。徹底すると「気づいているのに着手できていないこと」がスプリントから漏れない
  • 思考は英語、応答は日本語 — Claude Codeは内部で思考トークンを消費する。英語の方がトークン効率が良いので、そう指定すると同じ予算でより深く考えてくれる体感がある

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

複数部門を横並びで一目で把握したいときのため、dashboard/ 配下にStreamlitアプリ（通称Cockpit）を作り、各部門ファイルからスプリント完了率・直近1週間のログ追加件数・SNS投稿ドラフト本数・バックログ蓄積数を集計しています。ローカルで bash dashboard/start.sh を叩くとport 8501で起動します。「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 で起案を分離（部門に組み込むか未定のアイデアはここに溜め、スプリントを汚さない）

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

この運用は、突き詰めるとタスク管理ツールの操作コストをゼロに近づけ、思考の構造化そのものに集中できる環境を作るアプローチです。エンジニアにとっての強みは3つ。

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

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

ーー

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

関連記事