プロダクトバックログ

弊社ではプロダクトバックログをNotionとリポジトリの.docsディレクトリで二重管理し、開発の計画と実行はGitHub Issueで行います。Notion・リポジトリ・GitHubの3つをそれぞれの得意な領域で使い分けることで、開発中の速度と製品管理の両方を確保します。

ツールの棲み分け

Notion — プロダクトバックログの管理

Notionはタイムライン、カレンダー、ボードなど複数のビューを持つため、プロダクトバックログの全体像を把握するのに適しています。一方でAPIが遅く、開発中にリアルタイムで参照するには不向きです。

Notionにはバックログの要約とメタデータのみを保持します。本文（仕様や背景の詳細）はNotionのブロック書き込みが遅いため管理しません。

リポジトリの.docsディレクトリ — バックログの本文

プロダクトバックログの本文はリポジトリの.docsディレクトリにMarkdownで管理します。各ファイルのfrontmatterにnotion-page-idとnotion-reference-idを記録し、Notionのレコードとの同期を可能にします。

---
notion-page-id: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
notion-reference-id: "TASK-002"
---

製品開発における意思決定やプロダクトバックログなど、コードから読み取れない情報をここに残します。開発の計画（Issueの内容）はリポジトリには残しません。

GitHub Issue — 開発の計画と実行

GitHub CLIは高速なため、IssueをデータベースとしてClaudeCodeから直接読み書きします。Issueには開発の目的と計画を記録し、セッションが変わっても作業が引き継がれるようにします。ローカルにファイルを増やす必要もありません。

IssueにはNotionのTASK-002のようなIDを含めます。プルリクにも同じIDを含めることで、Notion側で自動的にプルリクが関連付けされます。

開発の流れ

プロダクトバックログからIssueを作成し、1セッション1Issueで開発を進めます。

1. /notion-backlogでNotionからプロダクトバックログを取得する
2. /backlogでバックログをリポジトリの.docsディレクトリに作成する
3. コードや仕様を分析し、開発が衝突しないIssueを作成する
4. /issueで担当するIssueを参照し、開発を開始する
5. /prでプルリクを作成する。別セッションからプルリクを再開することもできる

計測結果

2026-02-21にIssue 77件、PR 30件のリポジトリで計測した結果です。

Issueの取得

PRの取得

Notion MCPとの比較

GitHub CLIの特徴

• 100件でも10件でも取得時間はほぼ同じ（0.5〜1秒）。APIのラウンドトリップが支配的で、件数による差は小さい
• body付きでもなしでも速度はほぼ変わらない。データ量は増えるが転送時間への影響は軽微
• --jsonオプションで必要なフィールドだけ取得できる