GitHub ProjectとMilestonesでロードマップ設計

リポジトリ作った、次は何する？って時に一番やるべきなのがプロジェクト管理の仕組み作りです。
今回はGitHub ProjectとMilestonesを使って、wagtail-reusable-blocksのロードマップをどう設計したかを振り返ります。

KEY TAKEAWAYS

この記事でわかること

GitHub Projectの作り方と活用方法
MVP→機能→改善の3フェーズでMilestonesを設計する考え方
実プロジェクトのv0.1.0〜v0.4.0設計の生々しい判断基準

用語の定義

TERM 01

GitHub Project

Issue・PRをカンバンボードで管理するGitHubの標準プロジェクト管理ツール。TrelloやJiraのようにドラッグ&ドロップでタスクを整理できる。

TERM 02

Milestones

リリースバージョンやスプリント単位でIssueをグループ化する機能。進捗率とdue dateで開発ペースを可視化。

TERM 03

ロードマップ

プロジェクトの開発計画を時系列で示したもの。「どの機能をいつまでに作るか」をコミュニティやステークホルダーに伝える。

TERM 04

MVP (Minimum Viable Product)

最小限の機能で動く製品。まず「これだけあればとりあえず使える」を作り、フィードバックを得てから機能を追加していく開発手法。

なぜプロジェクト管理が必要？

前回リポジトリは作ったけど、「で、何から作ればいいの？」ってなりますよね。私もなりました。

実はこれ、OSSでも企業プロジェクトでも同じ問題なんです。コードを書く前に、何をどの順番で作るかを決めておかないと...

問題1

機能を作りすぎて、いつまで経ってもリリースできない

問題2

チームメンバーが「今何やればいい？」で迷子

問題3

「いつリリース？」に答えられない

解決策: GitHub ProjectとMilestonesでロードマップを可視化すれば、この3つ全部解決します。

wagtail-reusable-blocksでは最初の1時間でこれをやりました。結果、「v0.1.0で最小限を作って、v0.2.0でスロット機能追加」みたいな見通しが立ちました。

ステップ1: GitHub Project作成

まずはプロジェクト管理の「箱」を作ります。GitHubには他にもWikiとかDiscussionsとかあるけど、タスク管理はProjectが圧倒的に便利。

なぜGitHub Projectを選んだか

他のツールとの比較

ツール	メリット	デメリット	判断
GitHub Project	・Issue/PRと完全連携・追加料金なし・外部ツール不要	・機能はシンプル・高度な分析ツールなし	採用
Trello	・UIが分かりやすい・カスタマイズ自由	・GitHubと別管理・同期の手間	不採用
Jira	・機能が超豊富・エンタープライズ向け	・高い（有料）・設定が複雑・OSSには過剰	不採用
Notion	・ドキュメント統合・柔軟性が高い	・GitHubと別管理・リンク切れリスク	不採用

決め手になったポイント

IssueとProjectが同じ画面で見られる → 情報が分散しない
Issueを作ったら自動でProjectに追加される → 手間ゼロ
コミットやPRからIssueに飛べる → トレーサビリティ完璧
無料 → コスト気にせず使える

ツール分散の罠（超重要）

10数個の案件に参加してきた身として、これだけは絶対に言いたい。

分ける必要のないツールを分けるな

こういうケース、めちゃくちゃ多い：

GitHub使ってるのに、わざわざBacklog契約 → GitHub Projectで十分なのに
Gmail使ってるのに、Zoom契約 → Google Meetでいいのに
Slackあるのに、Teamsも導入 → どっちに書けばいいか混乱
GitHub Discussionsあるのに、別途Discordサーバー → 情報が分散

なぜこうなるのか

よくある理由（言い訳）

「前のプロジェクトでBacklog使ってたから...」
「Jiraの方が高機能だから...」
「◯◯さんがZoomに慣れてるから...」
→ でも、そのコストを誰が払うのか考えてない

ツール分散の3つの問題

問題1: 技術的ハードル

外部サービス連携 = API統合の手間。標準サポートされてるはずのことができなくなる。

問題2: 情報の分散

「あれどこだっけ？」が増える。検索しても見つからない。リンク切れ。

問題3: オンボーディング地獄

新規参入者がツールの存在自体に気づかない。探せない。

問題3が一番ヤバい

古株と若手の情報格差が生まれます。

よくある光景

古株: 「Backlogに書いてあるだろ！」（頭に入ってる）
若手: 「え、Backlogって何ですか...」（存在を知らない）
古株: 「最近の若手は使えない」（若手を責める）
若手: 「知らないとは言えない...」（言えない環境）
→ トラブルの原因がツール分散なのに、誰も気づかない

だから、プラットフォームをまとめる

GitHub使うなら、GitHub Projectで完結させる
Gmail使うなら、Google Meet/Docs/Driveで揃える
Microsoft365なら、Teams/SharePoint/Plannerで揃える
例外: お客さんの都合でしょうがない時はある（それ以外は避ける）
→ 新規参入者が「ここ見ればOK」と分かる状態を作る

OSS vs 企業プロジェクトでの違い

実は目的が違うので使い方も変わります。

透明性重視

wagtail-reusable-blocksはこっち。開発状況を全部公開します。

Project設定のポイント:

Public Projectにする → 誰でも進捗を見られる
Project READMEを充実させる → Visionを明示
Milestone進捗を常に最新に → 「開発止まってる？」の不安を消す
ロードマップをMermaid図で可視化 → 次に何が来るか分かる

効果:

コントリビューターが「どこを手伝えばいい？」を判断できる
ユーザーが「この機能いつ来る？」を自分で確認できる
透明性がコミュニティの信頼につながる

効率重視

社内システムやクライアントワークの場合。チームの生産性が最優先。

Project設定のポイント:

Private Projectで管理 → 社内のみアクセス可
Sprint単位でMilestones → 2週間〜1ヶ月サイクル
カスタムフィールド追加 → Priority、Effort、Assigneeなど
ステータス自動化 → PRマージで自動クローズ

項目	OSS	企業PJ
Visibility	Public	Private
Milestone期間	2〜3ヶ月（機能単位）	2週間〜1ヶ月（Sprint）
優先度管理	ラベルで軽め	カスタムフィールドで厳密に
ロードマップ	長期（半年〜1年）	短期（1〜3ヶ月）

ポイント: 企業プロジェクトでは納期とリソース管理が最重要。Due dateは必ず設定して、週次で進捗レビューします。

実装: Projectの作成

方法1: GitHub UIでの作成（推奨）

自分のプロフィールページ → 「Projects」タブ
「New project」→「Table」テンプレート選択
プロジェクト名: wagtail-reusable-blocks
Short description: Wagtail CMS extension for reusable content blocks with slot-based templating system
「Make public」にチェック（OSSの場合）

方法2: gh CLIでの作成

コマンドライン派はこっち。ただしProject READMEはUI経由で後から追加する必要あり。

注意: GitHub CLIのproject機能はまだベータ版なので、UI使う方が確実です。

Bash

# Project作成（ベータ機能）
gh project create \
--title "wagtail-reusable-blocks" \
--owner kkm-horikawa

Project READMEの活用

wagtail-reusable-blocksではProject READMEにVisionとロードマップを書きました。これがめちゃくちゃ効果的。

Project READMEに書いたこと:

Vision: 「なぜこのプロジェクトを作っているか」
Origin: 「どういう課題から生まれたか」の引用
Core Concept: Mermaid図でアーキテクチャ説明
Use Cases: 具体的な利用シーン
Milestones: v0.1.0〜v0.3.0の概要

実例:wagtail-reusable-blocks ProjectのREADMEタブを見てみてください。Mermaid図使ってるのでビジュアルで分かりやすいです。

ステップ2: Milestones設計

Projectの箱ができたら、次はロードマップを設計します。「何を・いつまでに・どの順番で作るか」を決める、超重要なステップ。

Milestone設計の考え方

MVP → 機能 → 改善の3フェーズ戦略

wagtail-reusable-blocksでは「まず動くものを作る → 独自機能を追加 → 品質上げる」という順番にしました。

Phase 1

v0.1.0 MVP

基本的な再利用ブロック機能

目標: とりあえず使えるものを作る

Phase 2

v0.2.0 Slot

スロットベーステンプレート

目標: 差別化機能を追加

Phase 3

v0.3.0 Polish

パフォーマンスと運用機能

目標: プロダクション対応

なぜこの順番？

Version	やること	判断理由
v0.1.0	・ReusableBlockモデル・ChooserBlock ・基本的なレンダリング	「動くものがないと何も始まらない」まず最小限で使えるものを作る。フィードバックもらうため。
v0.2.0	・SlotPlaceholder ・SlotContent ・循環参照検出	このプロジェクトの「本命機能」 MVPで基礎ができてるから実装できる。ここで他のツールと差別化。
v0.3.0	・キャッシュ機能・使用箇所トラッキング・バージョニング	実運用で必要な機能パフォーマンス問題が出てから対応。早すぎる最適化は避ける。
v0.4.0	・REST API ・GraphQL対応・Headless CMS対応	ニーズが出てから最初は不要。 Headless需要があれば追加。

よくある失敗

v0.1.0で全部やろうとする → いつまで経ってもリリースできない
機能を先に全部詰め込む → 使われない機能だらけになる
パフォーマンスを最初から気にする → 早すぎる最適化で時間浪費

実装: Milestonesの作成

1. v0.1.0 - MVP (Reusable Blocks)

目標: 基本的な再利用ブロック機能

ReusableBlockモデル
ChooserBlock実装
管理画面UI
PyPI公開準備

Due date: 2026-01-31（2ヶ月）

Bash

gh api repos/kkm-horikawa/wagtail-reusable-blocks/milestones \
-X POST \
-f title="v0.1.0 - MVP (Reusable Blocks)" \
-f state="open" \
-f description="## Phase 1: Core Reusable Blocks

Basic implementation of reusable content blocks for Wagtail.

### Goals
- [ ] ReusableBlock model with StreamField support
- [ ] ReusableBlockChooserBlock for page integration
- [ ] Admin UI for managing reusable blocks
- [ ] Basic documentation
- [ ] Unit tests
- [ ] PyPI package setup" \
-f due_on="2026-01-31T00:00:00Z"

2. v0.2.0 - Slot System

目標: スロットベーステンプレート機能

SlotPlaceholder実装
SlotContent実装
循環参照検出
管理画面プレビュー

Due date: 2026-03-31（2ヶ月）

Bash

gh api repos/kkm-horikawa/wagtail-reusable-blocks/milestones \
-X POST \
-f title="v0.2.0 - Slot System" \
-f state="open" \
-f description="## Phase 2: Slot-based Templating

Advanced slot/placeholder system for component composition.

### Goals
- [ ] SlotDefinition model for defining named slots
- [ ] SlotPlaceholder block for marking insertion points
- [ ] SlotContent block for injecting content into slots
- [ ] Circular reference detection and prevention
- [ ] Slot preview in admin editor" \
-f due_on="2026-03-31T00:00:00Z"

3. v0.3.0 - Performance & Polish

目標: プロダクション対応

キャッシュ戦略
使用箇所トラッキング
バージョニング対応
パフォーマンスベンチマーク

Due date: 2026-05-31（2ヶ月）

Bash

gh api repos/kkm-horikawa/wagtail-reusable-blocks/milestones \
-X POST \
-f title="v0.3.0 - Performance & Polish" \
-f state="open" \
-f description="## Phase 3: Performance & Production Ready

Optimization and production-ready features.

### Goals
- [ ] Caching strategy for reusable blocks
- [ ] Cache invalidation on block updates
- [ ] Revision/versioning support
- [ ] Usage tracking (where is this block used?)
- [ ] Bulk operations in admin" \
-f due_on="2026-05-31T00:00:00Z"

4. v0.4.0 - Headless & API Support

目標: Headless CMS対応

REST API実装
GraphQL対応
Slot解決のAPI
Headless統合テスト

Due date: 2026-07-31（2ヶ月）

Bash

gh api repos/kkm-horikawa/wagtail-reusable-blocks/milestones \
-X POST \
-f title="v0.4.0 - Headless & API Support" \
-f state="open" \
-f description="## Phase 4: Headless & API Support

Enable headless CMS usage with comprehensive API support.

### Goals
- [ ] REST API endpoints for ReusableBlock CRUD
- [ ] GraphQL support (wagtail-grapple compatible)
- [ ] Slot resolution in API responses
- [ ] Reference vs expanded content modes" \
-f due_on="2026-07-31T00:00:00Z"

Due date設定の考え方:

各Milestoneは2ヶ月間隔で設定（ソロ開発の場合）
チーム開発なら1ヶ月でもOK
「絶対守る」より「目安として見える化」が目的

ステップ3: Project Boardの設定

ProjectとMilestonesができたら、最後にカンバンボードでタスクを可視化します。

Status フィールドの活用

シンプルな3ステータス

wagtail-reusable-blocksではTodo / In Progress / Doneの3つだけ。これで十分。

Todo

未着手のタスク。Issueを作成したら自動でここに入る。

In Progress

作業中。PRを開いたら自動でここに移動。

Done

完了。Issueをクローズしたら自動でここ。

カスタムフィールドの追加

デフォルトのフィールドだけでも使えるけど、カスタムフィールドを追加すると更に便利。

フィールド名	タイプ	用途
Status	Single select	Todo / In Progress / Done
Milestone	Built-in	v0.1.0 / v0.2.0 / v0.3.0
Labels	Built-in	implementation / documentation / bug
Parent issue	Built-in	親子Issue構造
Sub-issues progress	Built-in	子Issueの進捗率

ポイント:

GitHub Projectは自動でIssueを追加してくれる（リポジトリとリンクさせると）
PRをマージすると関連IssueがDoneに自動移動
複雑にしすぎない → 最初はシンプルに、必要になったら追加

親Issue・子Issueの活用

大きなタスクを親Issue → 子Issue（atomic）に分解すると管理しやすい。

実例: v0.1.0の構造

📋 [v0.1.0] MVP - Reusable Blocks (親Issue)
├── 🔹 Setup test environment and CI workflow (atomic)
├── 🔹 Implement ReusableBlock model (atomic)
├── 🔹 Implement ReusableBlockChooserBlock (atomic)
├── 🔹 Create default template and template override system (atomic)
├── 🔹 Implement settings system (atomic)
├── 🔹 Customize admin UI for ReusableBlock (atomic)
├── 🔹 Implement nested rendering and circular reference detection (atomic)
└── 🔹 Write documentation for v0.1.0 (atomic)

メリット:

親Issueで全体進捗が一目で分かる（7/8 completed）
子Issueごとに担当者を割り振れる（チーム開発）
小さいタスクなので完了しやすい → モチベーション維持

こちらの記事もおすすめ

#1 OSSプロジェクト立ち上げ初日の4つの設定 - PythonOSS開発記録

記事を読む

#3 コミュニティヘルスファイルで参加障壁を下げる - Python OSS開発記録

#2 GitHub ProjectとMilestonesでロードマップ設計 - Python OSS開発記録

karrinn

目次

この記事でわかること

用語の定義

GitHub Project

Milestones

ロードマップ

MVP (Minimum Viable Product)

なぜプロジェクト管理が必要？

ステップ1: GitHub Project作成

なぜGitHub Projectを選んだか

他のツールとの比較

ツール分散の罠（超重要）

なぜこうなるのか

ツール分散の3つの問題

問題3が一番ヤバい

OSS vs 企業プロジェクトでの違い

実装: Projectの作成

方法1: GitHub UIでの作成（推奨）

方法2: gh CLIでの作成

Project READMEの活用

ステップ2: Milestones設計

Milestone設計の考え方

MVP → 機能 → 改善の3フェーズ戦略

なぜこの順番？

実装: Milestonesの作成

1. v0.1.0 - MVP (Reusable Blocks)

2. v0.2.0 - Slot System

3. v0.3.0 - Performance & Polish

4. v0.4.0 - Headless & API Support

ステップ3: Project Boardの設定

Status フィールドの活用

シンプルな3ステータス

カスタムフィールドの追加

親Issue・子Issueの活用

こちらの記事もおすすめ

参考リンク

プロジェクト関連

公式ドキュメント

参考記事

関連トピック

記事をシェア

karrinn

コメント (0)

コメントを投稿

検索

最近の投稿

#4 Git Flowブランチ戦略でチームの混乱を防ぐ - Python OSS開発記録

#3 コミュニティヘルスファイルで参加障壁を下げる - Python OSS開発記録

#1 OSSプロジェクト立ち上げ初日の4つの設定 - PythonOSS開発記録

【GitHubActions × Claude】完全自立開発サイクルを実現する

Pythonプロジェクトの長期運用で本当に必要なこと - 環境・品質・型の3本柱

カテゴリー