みなさんスクラムやアジャイルでスプリントやカンバンを管理するとき、どのようなツールを使っていますか？
私は、以前はJiraやTrello、Redmineあたりを仕事で使っていました。他にもBacklogやAsana、Notionを使ったことのある人もいるでしょう。
しかし、小さいチームの場合、開発はほぼGithubしかみない、ビジネスサイドもGithubで十分、Notionはドキュメントをまとめるだけにしたい（そもそも課金したくない）という様々な要因で、Github Projectsを使ったほうが色々助かるときも実はあるのです。
ということで、私のチームでのGithub Projectsの活用事例をご紹介します。
※基本的な使い方については、Qiitaの記事を参考にしていただけると助かります。
参考記事：
プロジェクト作成→カンバンを用意
アジャイルするために、まずは作業の可視化をします。
可視化にはカンバンがとても便利なのでGithub Projectの新規作成画面からカンバンのテンプレートを選んで作成してしまいましょう。
これだけでBacklog/Ready/In progress/In review/Doneというステータスのあるカンバンができました！
タスクは全部Issue化
つぎに作業対象の課題を作成していきます。
課題はTODOであれバグであれ改善であれ、すべてをGithub Issuesとして作成しましょう。
Backlogの下部「+ Add item」を押すか、「Team items」タブをクリックし、そこのBacklog以下にある「+ Add item」で追加してみましょう。
こうして作成された課題のStatusはBacklogになっていると思います。Backlogが課題であふれると作業量の多さに気の引ける思いもしてしまうので、私はStatusを外してNo Statusの課題とし、それを増やしていくようにしています。
あるいはカンバンのフィルターからbacklogを除去し、バックログはバックログ専用のリストを作るという方法もあります。個人的にはこっちもおすすめです。プロダクトマネージャーやオーナーはバックログリストを見ながら優先度を決め、エンジニアはスプリントプランニングで優先度の高い課題について説明を受けつつ実タスクをSub Issueとして切り出す( Sub Issueの活用 を参照ください )というプロセスが確立できるからです。
作った課題は最初Draft状態として作成されます（上図の破線の丸がついているテスト課題がそれです）。
とりえあず課題を作成していって、あとから適切なIssueとしてConvertすることをおすすめします。
Convert対象はGithub Repository単位で選べます。戦略としては以下です。
- 複数レポでプロダクトを管理している場合はそれぞれのIssueに変換する
- IssueをまとめるだけのGithub Repositoryを作成し、そこで一括管理する
（１）は各レポジトリ別でIssueが管理できるので、開発チームが他チームの余計な作業タスクやIssueをいちいちフィルターせずに除外できるメリットがあります。
（２）はぱっと見た感じは規模のでかいカンバンになりがちですが、Github Issueは別レポジトリのIssueへリンクできるしPull Requestにも関連付けできるので、開発チームとしてはフィルタリングで好きなように見え方を変えることで気にせず取り組めます。
加えて、PMやビジネスサイドからみると1つのボードにすべてがまとまっていたほうがロードマップの整理や事業全体の可視化が楽になるので、私は（２）をおすすめします。
チーム個別のタスクは、各Appのレポジトリか別Projectsを作ってもらってそれと課題リンクさせるという方法もとれるため、拡張性にも優れています。
項目追加
カスタム項目が設定できるので、例えばカテゴリを追加してみましょう。
上図のような感じで作っておけば、課題が1つのProjectにまとまっていてもどの組織（プロダクト）のタスクか判別しやすくなります。
これと似た項目に「Label」がありますが、これはGithub Issuesと関連づくので、Labelの追加は自由にさせず、承認制にすることが個人的好みです。（Jiraを触ったことのある人ならわかると思いますが、だいたい氾濫して似たようなタグが大量作成され収集つかなくなるやつです）
実装と関連付ける
課題を開くと右下に「Development」というものがあります。ここで既存のPullRequestやブランチと関連づけすることで、課題の実装状況を追うことが可能となります。
この関連をつけておくと、ProjectのWorkflowにより、Pull RequestがCloseになったタイミングで課題もCloseされます。この挙動が地味に便利なので私はお気に入りです。
Workflowはデフォルトで設定されていますが、自分で好きに変更することも可能です。が、正直デフォルトでもかなり優秀なので、手の込んだWorkflow（外部サービスと連携したりメール・Slack通知したり）がなければそのままで良いと思います。
イテレーションの作成
スクラムやアジャイルをするときには、たいてい1スプリントや開発の期間を作成することになります。
しかし、初期では存在しないので手作業で作成する必要があります。
前述のカテゴリの作成のように、イテレーションを作成します。
例えば2週間単位でのイテレーションは以下のように作成できます。
作成すると1、2、3までのイテレーションが作成されます。
あとは課題側で「この課題をいつどのイテレーションで実施するか」を割り当てしていく感じです。
注意点としては、このイテレーションは 自動では増えない のと 期日が来ても自動で次のイテレーションに切り替わらない という点があります。
例えばフィルターで「iteration:@current」と設定していると、設定日以降から急に課題が消えてしまって何がおきた？という状況になります。
なので、イテレーションを管理するための週次（隔週）定例か週次（隔週）タスクが必要になります。ただこれってスクラムで言うところのスプリントプランニングやリファインメントで代用可能なので、個人的にはフレームワークをチームの作業として強制させるという点では有益だなと思ってます。（忘れることも多いですが……）
Insightsの活用
InsightsはチャートやグラフでProjectの状況を可視化することができます。
初期ではStatus chartしかありませんが、Iterationの計測も作れます。
工夫は必要になりますが、ある程度の生産性や進捗管理に使うことは可能です。
ロードマップも作成可能
事業側としては開発内部の進捗の管理は不要なので、Pull Requestとの連携やイテレーションの消化率などよりもロードマップを見て「リリース期日に間に合うか」を確認したいところです。
こちらはロードマップ画面を使えば可能です。
ただし、通常の状態では上図のとおりガントチャートっぽく表示されるだけで味気ないですし、「期日いつだっけ？」とこの画面からは分かりません。そこで 「Milestone」 の出番です。
マイルストーンの設定
設定箇所が分かりづらいのですが、マイルストーンは各Github Repository単位で作成する必要があり、Github Projectからは作成できません。冒頭で私が「ProjectのIssueは全部1つのRepositoryでまとめたほうが良いです」と述べたのは、このマイルストーン機能の仕様にも関連しています。
早速作成してみましょう。
適当に課題を1つ別タブで開きます。課題選択後右上「...」からOpen in new tabをクリック。
開いた画面の左上「Issues」をクリック。
そうすると課題一覧画面になります。そこに「Milestones」というボタン領域があるのでそこをクリック。
そして「New milestone」で新しいマイルストーンを作る感じになります。ややこしいですね！
Due Dateは予定日を入れてください。
DescriptionにはNotionやその他プロダクト・プロジェクトドキュメントへのリンクを貼っておくとよいでしょう。
マイルストーンの作成が完了したら、そのマイルストーン内で対応する課題について、Milestoneを設定します。Github Projectから課題を開けば、右下にその枠が存在します。
その後、再度Roadmapタブで「Markers」をクリックし「Milestone」を選択すると緑色の縦線が表示されます。※何度やっても表示されない場合は一度画面をリロードしてサイドMarkersの選択からやり直してみてください。。。
これで見通し良くなりましたね！
Sub Issueの活用
2025年のいつ頃からかIssueにSub Issueが付与できるようになりました。(2025年1月17日のようです）
これによりプロダクトのバックログに対してスプリント用（開発用）のタスクを子としてもたせることができるようになりました。
応用するとこんな感じです。
まず親課題にある[Create sub-issue]をクリックして課題を作成していきます。
ここはエンジニアやプロダクトマネージャーが集まってワイワイしながら作るほうが建設的な議論もできるしあとから合意する必要がないのでオススメです。（リファインメントやスプリントプランニングとか）
ここで、親の課題はスプリントでは触れたくない（見える必要がない）ので、「これは実課題ではなくプロダクトバックログとしての親ストーリー/エピックです」というのを明確にするために、Labelsで適当なラベルを選んでおくと良いでしょう。画像ではデフォルトの「enchancement」を選んでますが、個人的にはJiraに倣って「Parent」とか「ストーリー」とか「エピック」みたいなラベルを作るか、あるいはCustom fieldsから「Type」みたいな項目を作ってそっちで同じように管理するかするとよいでしょう。
Relation shipsの活用
また、画像で「結合テスト」のアイコンに赤いマイナスアイコンが付いていることに気づいてもらえると思います。
これもいつのまにか（？）追加されたIssueのRelationshipsで定義できます。
※2025/8みたいです。
親→子の関連性は勝手にRelation shipsに追加されますが、せっかくなので他の関連も作ってしまいましょう。
結合テストのIssueを開き、右下から[Relationships]をクリック→「Add or change blocked by」を選択し、この課題をブロックする課題を選択するだけです。
Jiraを使ってる方なら感覚でわかると思います。
GithubでもJiraでも同様ですが、Blocked by自体は別にこの設定をしたところでなにかが制限されるわけではなく見た目だけの問題です。何かしらの制約をかけたい場合はGithub ActionsやJiraのインテグレーションツールを使うことで可能だと思いますが、視覚的にわかるだけでもかなり有効だと個人的には思ってます。
カンバンへの応用
Sub Issueをカンバンに応用するとなお見通しがよくなります。
まずフィルターで親となるIssueをカンバンから見えなくするようにしましょう。
カンバンのタブすぐ下のフィールドに「 -label:enhancement」と入力します。
これだけでIssueのlabelにenhancementが設定されているものがカンバンから消えます。
ここで注意点です。
Github Projectsのフィルターは 「特定のラベルでない or ラベルなし」は機能しますが、「特定のラベル or ラベルなし」という検索条件は機能しません。
具体的にはこんな感じです。
機能する⭕️: -label:enhancement no:label
機能しない❌️: label:enhancement no:label
フィルターの組み合わせも意識してlabelやcustom fieldを検討してください。
話をもとに戻して、今度は親タスクの存在をスライスで表示して見ましょう。
以下の画像を参考に設定してみてください。
カンバンの右アイコンをクリック→Slice by→Parent issueを選択します。
すると左に親課題が表示され子タスクの数と完了具合を表示してくれます。すごい便利ですね。
プロダクトマネージャーやオーナーは開発課題の具体的内容を見ることなく、カンバンのレーンとこの左側の表示さえ追えば、自分の課題が現在どのような進捗なのかをひと目で理解することができるわけです。
まとめ
Github Projectは簡単に課題管理・プロダクト管理が可能です。
地味に便利ですしなんと無料なので、お金のないスタートアップにはとてもおすすめなツールだと思います。
さらに気を抜いてるといつのまにか進化しているので、今後も目が離せないツールです。
良い点
- 簡単に始められる
- いろんなツールを行き来せずGithubでプロダクト管理が簡潔する
- 様々な組織を巻き込みやすい
- Githubレポジトリとの親和性が高い
手間な点
- 事業側もGithubアカウントが必要になる
- イテレーションの管理が手作業
- Insightsがちょっとさみしい（難しい）
- サービス連携が若干難しい
特にサービス連携についてはプラグインはありませんし、設定も少ないので、作り込みが必要になります。そのため他のツールと見劣りしてビジネスサイドから「スプレッドシートのほうがわかりやすいっすね」と言われかねない場合はあります。ミーティングやプロダクト開発のフレームワークでカバーするほうが良いかなと個人的には思います。