みなさんスクラムやアジャイルでスプリントやカンバンを管理するとき、どのようなツールを使っていますか？
私は、以前は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」で追加してみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-
1.amazonaws.com/0/11128/6639cbfe-ff47-0fa0-e13e-174b02391fdb.png)

こうして作成された課題のStatusはBacklogになっていると思います。Backlogが課題であふれると作業量の多さに気の引ける思いもしてしまうので、私はStatusを外してNo Statusの課題とし、それを増やしていくようにしています。

作った課題は最初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の選択からやり直してみてください。。。

これで見通し良くなりましたね！

まとめ

Github Projectは簡単に課題管理・プロダクト管理が可能です。
地味に便利ですしなんと無料なので、お金のないスタートアップにはとてもおすすめなツールだと思います！

良い点

簡単に始められる
いろんなツールを行き来せずGithubでプロダクト管理が簡潔する
様々な組織を巻き込みやすい
Githubレポジトリとの親和性が高い

手間な点

事業側もGithubアカウントが必要になる
イテレーションの管理が手作業
Insightsがちょっとさみしい（難しい）
サービス連携が若干難しい

特にサービス連携についてはプラグインはありませんし、設定も少ないので、作り込みが必要になります。そのため他のツールと見劣りしてビジネスサイドから「スプレッドシートのほうがわかりやすいっすね」と言われかねない場合はあります。ミーティングやプロダクト開発のフレームワークでカバーするほうが良いかなと個人的には思います。