はじめに
本記事は MOSH Advent Calendar 2025 の18日目の記事です。
みなさん、AI時代のスクラム開発、どうしていますか？
少し前まで、僕たちはこんな開発をしていました。
- バックログは Notion
- User Story は人間が分解
- プランニングポーカーは全員参加
- チケット作成は手作業
- 進捗確認はカンバンを目視
正直に言うと、プランニングだけで毎スプリント数時間は溶けていました。
でも、今は違います。
Notion から GitHub Projects に移行し、
タスク分解・見積もり・チケット作成・進捗分析を Claude Code に任せる ようになりました。
この記事では、
- なぜ Notion をやめたのか
- GitHub Projects × Claude Code で何が変わったのか
- 実際にうまくいったこと
を、実体験ベースでお話しします。
Before → After：何が変わったのか
Before（Notion時代）
| 作業 | 担当 | 時間 |
|---|---|---|
| User Storyの分解 | 人間（エンジニア） | 1〜2時間 / Story |
| タスク粒度の調整 | 人間（チーム議論） | 30分〜1時間 |
| プランニングポーカー | 人間（全員） | 30分〜1時間 |
| チケット作成 | 人間（手作業） | 15分 / チケット |
| 進捗確認 | 人間（目視） | 毎日15分 |
After（GitHub Projects × Claude Code）
| 作業 | 担当 | 時間 |
|---|---|---|
| User Storyの分解 | Claude Code | 5〜10分 |
| タスク粒度の調整 | 人間（AI出力のレビュー） | 10〜15分 |
| 見積もり | Claude Code提案 → 人間が調整 | 10分 |
| チケット作成 | Claude Code + GitHub API | 自動 |
| 進捗確認 | Claude Code + GitHub API分析 | 自動レポート |
体感では、プランニング時間は 1/3 以下になりました。
なぜ Notion → GitHub Projects だったのか
「Notionでも十分では？」という声もありました。
確かに Notion は優秀です。
でも、AI駆動開発をやるなら GitHub 一択でした。
メリット1：コードとタスクが一体になる
Notion時代のつらさ
- 「このIssue、どのPRで対応したんだっけ？」
- 「このPR、どのタスクに紐づいてる？」
常に 手動リンク。
コードとタスクが、別の世界にある感覚でした。
GitHubなら
PR #234
Closes #142
これだけで、
Issue → Branch → PR → Merge → Close
が一本の線でつながります。
Issue を見れば「今どうなっているか」が一目で分かる。
メリット2：GitHub API × Claude Code の相性が良すぎる
これが最大の理由かもしれません。
GitHub API は、
- ドキュメントが圧倒的に充実
- Claude Code が前提知識として持っている
僕「α版マイルストーンで、In Progress が3日以上続いているIssueを教えて」
Claude Code「GitHub APIを確認しました。
- #156: アセットアップロード（4日）
- #163: 目次自動生成（3日）
ブロッカー確認を推奨します。」
「聞けば答えが返ってくる」。
Notion API だと、ここまで手軽にはいきません。
メリット3：GitHub Actions との自動化が強力
GitHub Projects は Actions とネイティブ統合されています。
実際にやっている自動化例：
- Issue作成時：ラベル・マイルストーン自動付与
- PR作成時：関連Issue自動リンク
- PRマージ時：Issue Close & ボード移動
- 毎朝9時：停滞Issueを検出してSlack通知
# .github/workflows/stale-issues.yml
name: Stale Issue Alert
on:
schedule:
- cron: '0 0 * * *' # 9:00 JST
Notionでやると、Zapier や自前スクリプトが必要でした。
メリット4：開発者体験（DX）が劇的に改善
Notion時代
- Slackで「次のタスク何だっけ」
- Notionを開く
- バックログを探す
- ステータス変更
- GitHubに移動してブランチ作成
- PR作成
- マージ後、Notionに戻って更新
GitHub統一後
- GitHub Projectを開く
- Todoから1つ取る（自動で In Progress）
- 同じ画面でブランチ作成
- PR → マージ
- 自動で Done
コンテキストスイッチが激減しました。
メリット5：Claude Code が直接操作できる
僕「この設計ドキュメントからIssueを作って、α版マイルストーンに追加して」
Claude Code「以下のIssueを作成しました：
#170: [DB] MembershipSiteLicense テーブル作成
#171: [API] GET /creator/licenses
...」
自然言語で 作成・更新・検索・分析 ができる。
セットアップも gh auth login で完了。
GitHub API × Claude Code で進捗を「見える化」
これが一番「未来感」あるかもしれません。
Notion時代の進捗確認
- 「今どれくらい進んでる？」→ 目視でカンバンを数える
- 「何がブロッカーになってる？」→ 朝会で聞く
- 「このペースでα版間に合う？」→ 経験と勘
今の進捗確認
僕「α版の進捗状況を分析して」
Claude Code「GitHub Project を分析しました。
α版進捗サマリー（12/17時点）
━━━━━━━━━━━━━━━━━━━━━
Done: 23 issues (54%)
In Progress: 8 issues (19%)
Todo: 12 issues (28%)
ベロシティ分析
- 過去2週間平均: 12pt/週
- 今週のペース: 15pt（良好）
- 先週比: +25%
リスク検出
- Epic 3（コンテンツ管理）が遅延傾向。残り8 issueのうち5 issueが未着手
- #156（アセットアップロード）が3日間In Progressのまま停滞
- #163 と #165 に依存関係あり。#163 が遅れると #165 も遅延
予測
現在のベロシティを維持した場合、α版完了予定は12/26。
12月中リリースにはギリギリ。Epic 3 に集中することを推奨。」
数字に基づいた、客観的なフィードバック。
これが朝会の議論を変えました。「なんとなく遅れてる気がする」ではなく、「Epic 3が遅延傾向だから、今日はここに集中しよう」と具体的に話せるようになったのです。
レポートの自動生成
振り返りの時は、Claude Codeに「今週のサマリーを作って」と頼むと、こんなレポートが出てきます：
## 週次サマリー（12/9 - 12/15）
### 完了したIssue
- #142: 会員サイトCRUD（8pt）
- #145: フォルダ管理基本機能（5pt）
- #148: コンテンツ一覧画面（5pt）
合計: 18pt（目標: 15pt）
### 進行中
- #156: アセットアップロード（残り: フロントエンド実装）
- #160: タグ管理（残り: UI実装）
### 来週の注力ポイント
1. アセットアップロードの完了（ブロッカーなし）
2. ゲスト向け閲覧機能の着手
3. 目次自動生成のAI部分の設計
### 懸念事項
- 目次自動生成（13pt）は工数大きめ。分割を検討
Notionでは「人間が集計して書いていた」レポートが、自動で出てくる。この差は大きいです。
会員サイトチームの現状
僕たちは今、MOSHの「シン・会員サイト」を再構築しています。旧システムの「1サービス＝1会員サイト」という制約（社内では「1:1:1問題」と呼んでいます）を解消し、クリエイターが自由にコンテンツを届けられる基盤を作るプロジェクトです。
チーム構成は、エンジニア数名＋デザイナー＋PdMという小さなチーム。
スケジュールは α版（12月）→ β版（1月）→ MVP（2月）という段階的リリース。
つまり、スピードが命。でも品質も妥協したくない。
この矛盾を解決するために、僕たちはAIを「チームメイト」として迎え入れました。
1. タスク分解の革命 — AIが「叩き台」を作る
Notion時代の風景
以前は、User Storyを見ながらホワイトボードに向かって、みんなで「これは分けたほうがいい」「これは依存関係あるよね」と議論していました。楽しいけど、時間がかかる作業でした。
今の風景
僕「このUser Story、タスク分解して」
Claude Code「了解。以下のように分解しました：
□ [DB] MembershipSite テーブル作成 (2pt)
- id, creator_id, name, slug, is_published...
□ [API] POST /creator/membership-sites (2pt)
- バリデーション、slug自動生成ロジック
□ [API] GET /creator/membership-sites (3pt)
- 一覧取得、集計情報のJOIN
□ [Frontend] 会員サイト一覧画面 (5pt)
- カード形式、ケバブメニュー、Empty View
...
依存関係: DB → API → Frontend の順で実装推奨です。」
5分。
もちろん、AIの出力をそのまま使うわけではありません。チームでレビューして「これは分けすぎ」「ここはもう少し詳細に」と調整します。でも、ゼロから考えるのと叩き台をレビューするのでは、認知負荷がまったく違います。
2. AGENTS.md — AIエージェントへの「引き継ぎ書」
リポジトリのルートに AGENTS.mdを置いています。
# taiyaki リポジトリガイドライン
## プロジェクト構造
- packages/frontend: React + Vite + shadcn/ui
- packages/backend: Hono + Prisma + Cloudflare
## コーディング規約
- 日本語コメント推奨
- roleベースのDOM要素アクセス
- className直接拡張禁止（shadcn/uiのvariantsを使う）
これがあると、「このリポジトリで会員サイトの編集APIを作って」と言うだけで、プロジェクトの文脈を理解した上でコードを書いてくれます。
3. レビュープロセス — 「AIが書き、人間がレビューする」
僕たちのコードレビューフローは、ちょっと独特かもしれません。
1. AIが叩き台を生成
2. 人間がセルフレビュー（AIが書いたコードを理解する）
3. GitHub Copilot Code Review が自動レビュー
4. チームメンバーがレビュー
5. 最終判断は人間
ここで大事なのは 「AIが書いたコードでも、説明できるように理解してレビューする」 というルールです。
実際に感じている変化
1ヶ月ほどこの運用を続けて、実感している変化があります。
| 項目 | Notion時代 | GitHub × Claude Code |
|---|---|---|
| プランニング時間 | 3時間 | 1時間以内 |
| チケット作成 | 手作業15分/件 | 自動 |
| 進捗確認 | 毎日15分、目視 | 自動レポート |
| コンテキストスイッチ | Notion ↔ GitHub 往復 | GitHub完結 |
| レビュー効率 | 人間が全部見る | AIが一次フィルタ |
おわりに
Notionで人間がすべてやっていた時代から、
GitHub Projects × Claude Code で AIと走る時代へ。
AIは「代替」ではなく、仲間。
以上が、僕たちのAI駆動スクラムです。
Discussion