GitHub Projectsでスクラム開発は快適だけど物足りなさもあるよ

# 著者の自己紹介

著者の名はイナバくん。:robot:
フロントエンドエンジニア。
プライベートでは、登山家・禁煙家。:angel:
某アパレル企業に常駐していて、自社プロダクトをスクラム開発しています。

# この記事で話すこと

- スクラム開発におけるGitHub Projectsの便利なところ:ok_hand:
- GitHub Projectsでまだ出来ないこと:crying_cat_face:

※ スクラム開発の各用語(スプリント, PBI, SBI など) が分かる方向けの解説になります。

# GitHub Projectsを導入する前の課題

主にMiroの愚痴になります。
(※ Miroはホワイトボードとしては素晴らしいツールです:clap:)

## 課題1: タスクとPull Ruquest(以下PR)を紐付けできない

PRをMergeした自動でタスクのステータスがDoneになる、みたいな事をパッと設定できない。。:cold_sweat:

## 課題2: タスクをMarkdown形式で書けない

Miroには付箋やカードはあり、リンクや太字は使えるのですが、Markdownは使えず、画像も貼り付けできません。:cold_sweat:

![スクリーンショット 2023-09-22 16.21.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2319754/0dda1678-39b4-7175-7165-ea8891922150.png)


## 課題3: タスクの見積もりの合計を自動算出できない

スクラム開発において、スプリント内の見積もり数の合計や、増減値を出す機会が多いです。
Miroだと他ツールのように自動算出ができません。。:cold_sweat:


## 課題4: ホワイトボード故に自由度が高すぎてカオスになる

PBI・SBI・undone task などスクラム開発の全てをmiroで管理していたので、付箋だらけでカオスになっていました。:cold_sweat:

![chaos.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2319754/f5fbc568-e6c0-2058-112f-234c22c63357.png)



# いざ、GitHub Projectsを導入！

GitHub Projectの始め方は[公式ドキュメント](https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects)を参照してください。

まず、スクラム開発でProjectsを使うにあたって、設定からカスタムフィールドをいくつか追加します。

## カスタムフィールドを追加する

- Sprint: スプリント期間を設定する(カレンダーから開始日・終了日・期間を設定できる)
- Status: PBIのステータス
    - idea box: アイディア置き場
    - ice box: what, whyが明確になっていて見積もり可能
    - ready: 見積もり済で着手可能
    - selected: スプリントにて進行中
    - PO review: タスク完了していて、POレビュー可能
    - done: 完了
- Task Status: タスクのステータス
    - to do: 未着手
    - doing: 進行中
    - reviewing: レビュー中
    - done: 完了
 - Task Size: タスクの見積もり(1, 2, 3, 5, ... のようにフィボナッチ数列の数値で入力する)

![project_setting.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2319754/b57d1d4e-445a-5790-7f59-7287775b7156.png)

## ビューを作成する

GitHub Projects では、アイテムを様々なレイアウトで並べることができます。
(このレイアウトをビューと言います)

1. テーブル形式
2. カンバンボード形式
3. ロードマップ形式

僕らのチームでは、2 を使ってタスク管理をしていました。

### ビュー 1. プロダクトバックログ(PBIのステータス管理)

まず、ステータスをカラムしてカンバンを作成します。
PBIをステータス管理したいので、SBIなどのPBI以外のカードが表示されないようにフィルター設定します。

![product_backlog.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2319754/377ea1a5-db08-ccec-f169-cb78f3e9e474.png)


### ビュー 2. スプリントバックログ(開発者のタスクボード)

SBIでも同様に、ステータスをカラムにして、カンバン作成します。

PBIとSBIは、Group(A, B, C, ...)によってグループ化して、1レーンにまとめています。
(このタスク同士の紐付け・親子設定ができないことがGitHub Projectsの弱点であり、後ほど詳しく解説します)

![sprint_backlog.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2319754/06173025-1ffe-1864-2dce-91a9e9db6094.png)


# 便利なところ


## 便利1: タスクをPRと紐付けられる:sunglasses:

GitHub Projects のアイテムは、レポジトリのissueに変換できます。
issueとPRが紐づいていると、PRがスプリント内の何の活動なのかが一目瞭然なので便利です。

また、PRがmergeされたら自動でissueのステータスをdoneにできます。

※ issueとPRの紐付け方法: [公式ドキュメント](https://docs.github.com/ja/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)

## 便利2: バーンアップチャートを自動生成できる:sunglasses:

スプリント中のタスクの増減や、消化スピードなどを計測できます。
グラフの種類や、縦軸・横軸はカスタマイズできます。

![スクリーンショット 2023-09-23 2.00.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2319754/a7f42b94-e490-3477-1665-9ff9ec18a27d.png)

## 便利3: そもそもUIがシンプルで見やすい:sunglasses:

スクラム開発をする上で、他にもJiraなど多機能なツールもありますが、多機能ゆえにUIがゴチャゴチャしていて見にくい印象を受けます。。

その点、GitHubはエンジニアなら見慣れたUIなので、ツール自体の学習コストが低いです。

また、スクラムのイベント手続きと開発作業を、どちらも同じツールでできるため、スイッチングコストも減らすことができます。

## 便利4: viewを自由にカスタマイズできる:sunglasses:

テーブルやカンバンなど見た目を自由に変えることができます。

また、好きなカスタムフィールドをカラムやグループなどにセットできて、フィルターも使えるので、一般的なスクラムチームにおける必要なViewはカスタマイズして作ることができます。

# GitHub Projectsでまだ出来ないこと

GitHub Projectsは導入しやすい上に、とても便利で素晴らしいのですが、2022/07 に出来た機能なので、まだまだ物足りなさもあります。

## できないこと 1: 自由なworkflow設定:tired_face:

GitHub Projectsのworkflowを使うと、日々のタスクアイテムやPR・issueの操作を自動化できます。

例えば、
- PR を「ready for review」にしたら、PRに紐づくタスクのアイテムのステータスを「reviewing」にする
- PRをmergeしたら、PRに紐づくタスクのアイテムのステータスを「Done」にする

などを自動化したいです。

ですが、まだworkflow設定では、デフォルトのカスタムフィールドについてのプログラムしかできません。:cold_sweat:

なので、上記のような自動化をするにはGitHub Actions を作成する必要があります。

※ [Actions を使用した Projects の自動化](https://docs.github.com/ja/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions
)

## できないこと 2: PBIとSBIの紐付け:tired_face:

GitHub Projectsのアイテムやissue同士には、まだ依存関係や親子関係を設定することはできません。:cold_sweat:

なので、スクラム開発においては、PBIの子タスクであるSBIを表現することができません。
(僕らのチームでは、Groupを使ってPBI・SBIをまとめています。)

ただ、こちらはGitHub が機能の追加予定があるそうです。


# まとめ

GitHub にレポジトリがあるプロジェクトで、気軽にタスク管理をしたい時はGitHub Projectsがオススメです。
導入しやすく、学習コストも低く、開発との相性もGoodです。:sunglasses:

ただ、まだ足りない機能もあるので、足りない部分はGitHub Actions で補完するか、諦めて他のツール使いましょう。