この記事はand factory.inc Advent Calendar 2025 19日目の記事です。
前回の記事は @MatsuNaoPen さんの SlackからClaudeCodeに実装指示をできるようになったので試してみた でした
はじめに
最近、弊社ではエンジニアリソースの最適化に取り組んでいます。複数プロダクトにまたがる多種多様な開発タスクを横断的に管理し、エンジニアの工数を柔軟に配分できる体制を目指しています。
現状の課題
最大の課題はプロダクト間でのタスク管理方法の不統一です。
どのプロダクトもNotionでタスク管理を行っているものの、以下のような差異が存在しています。
- 優先度や影響度などの評価指標がプロダクトごとに異なる
- 開発フローや運用ルールに統一性がない
- エンジニアがプロダクト専属で業務を行っており、横断的なリソース配分が困難
GitHub Projectsを選んだ理由
上位レイヤーとの連携はもちろん必要ですが、「開発タスクを効率的に捌く」という点に焦点を当てれば、エンジニア組織内だけでもある程度の最適化は可能と考えました。
複数リポジトリのissueを横断的に管理できるGitHub Projectsなら、この課題を解決できる可能性があると思い、実際に触ってみることにしました。
あとは以前触った時、使いにくかったので今どうなんだろうと思い選びました。
GitHub Projectsの良かった点
基本的な機能については公式ドキュメントや他の記事をご参照いただくとして、ここでは実際に使ってみて「Notionと比較して良いな」と感じた点を紹介します。
1. 無料で利用できる
GitHub Projectsは無料プランでも十分な機能が使えます。予算に制約のあるベンチャー企業にとっては大きなメリットです。
2. 既存のタスク管理ツールと同等の使いやすさ
Board viewやRoadmap viewなど、Notionなどで慣れ親しんだビューが揃っており、学習コストが低いです。
おすすめの使い方: Milestoneでのグルーピング
リポジトリ単位でMilestoneを設定してタスクをグルーピングもしくはスライスすると管理しやすくなります。さらにMilestoneに期限を設定することで、Roadmap View上にMarkerを引くことができ、締切を視覚的に把握できます。
| Board View | Roadmap View |
|---|---|
![]() |
![]() |
3. GitHub Projectsの自動ワークフロー
GitHub Projectsには、プロジェクト作成時に自動的に設定される便利なワークフローが用意されています。これらを活用することで、手動でのステータス更新作業を大幅に削減できます。
デフォルトで用意されているワークフロー
プロジェクト作成時には、以下のような実用的なワークフローが自動で設定されます。
- Auto-add sub-issues to project: サブissueの自動追加
- Auto-add to project: 新規issue/PRの自動追加
- Auto-close issue: PRマージ時のissue自動クローズ
- Item added to project: 追加時の初期ステータス設定
- Item closed: クローズ時のステータス自動更新
- Pull request linked to issue: PR紐付け時のステータス変更
- Pull request merged: PRマージ時のステータス更新
これらのワークフローはそのまま利用できますが、必要に応じてプロジェクトの「Settings」→「Workflows」からカスタマイズも可能です。
4. issue駆動による開発自動化
issueに紐付けるブランチを指定しておけば、PRマージ時に自動でissueがクローズされ、Projects上のステータスも更新されます。手動での状態管理が不要になり、作業漏れを防げます。
| issue作成時のdevelopment branch作成 | PR作成時のdevelopment issue紐付け(PR説明文で自動紐付け可能) |
|---|---|
![]() |
![]() |
※ただし、PR作成時にissue紐づけるにはマージ先をdefaultブランチ設定することとclose #{issue番号}をPR説明文で記述しないと紐付けされないです。参考: Linking a pull request to an issue
まとめ
GitHub Projectsを導入するには、プロダクト間での開発ルールの統一(PRテンプレート、コミットメッセージ規約、ブランチ運用など)が必要です。また、上位レイヤーでのタスクの切り方による差異が残る可能性もあり、課題はまだあります。
しかし、エンジニア組織内で完結するタスク管理という観点では、GitHub Projectsは非常に適したツールだと感じました。将来的には上位レイヤーのステークホルダーも巻き込んで活用できれば、さらに効果的な開発体制を構築できると考えています。




