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

著者の自己紹介

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

この記事で話すこと

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

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

GitHub Projectsを導入する前の課題

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

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

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

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

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

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

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

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

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

いざ、GitHub Projectsを導入！

GitHub Projectの始め方は公式ドキュメントを参照してください。

まず、スクラム開発で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, ... のようにフィボナッチ数列の数値で入力する)

ビューを作成する

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

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

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

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

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

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

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

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

便利なところ

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

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

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

※ issueとPRの紐付け方法: 公式ドキュメント

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

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

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

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

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

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

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

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

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

GitHub Projectsでまだ出来ないこと

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

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

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

例えば、

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

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

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

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

※ Actions を使用した Projects の自動化

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

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

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

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

まとめ

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

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