はじめに
こんにちは。 STORES のリテール事業部でソフトウェアエンジニアをしている id:phayacell です。
2023 年 8 月 31 日にリリースされた STORES ネットショップ・レジ・ブランドアプリの連携機能を作っていました。
ネットショップとレジはリテール事業部、ブランドアプリは CRM 事業部が管轄するプロダクトであり、この連携機能の開発は 2 つの部署を横断するプロジェクトでした。
事業部を横断する本プロジェクトのバックログ管理に役立ったのが GitHub Projects です。
本記事では、実際のバックログ管理に GitHub Projects を使ったときに良かった機能を紹介していきます。
想定読者
GitHub Projects とは
まずは GitHub Projects のかんたんな紹介です。
公式の GitHub Docs より引用します。
プロジェクトは、作業の計画と追跡を効果的に行えるように GitHub 上の issue および pull request と統合できる、適応性のあるスプレッドシート、タスク ボード、ロード マップです。 issue と pull request をフィルター処理、並べ替え、グループ化することで複数のビューを作成してカスタマイズしたり、構成可能なグラフを使って作業を視覚化したり、team 固有のメタデータを追跡するためのカスタム フィールドを追加したりすることができます。 プロジェクトには、特定の手法を適用するのではなく、チームのニーズやプロセスに合わせてカスタマイズできる柔軟な機能があります。
雑に要約すると GitHub の Issue と Pull Request を使って管理、可視化しやすくしてくれる便利ツールということですね。
GitHub Projects には classic がありますが、これは以前サービス提供されていた古い方の GitHub Projects です。
本記事で指す GitHub Projects は classic ではない方の GitHub Projects です（classic に代わる名称がないので表現が難しい）。
わたしたちについて
事業部横断の連携チームでは複数のスクラムチームが協力して開発する LeSS のエッセンスを導入しました。
わたしたちのチームが取り入れた LeSS のエッセンスについては、以下の記事をご参照ください。
わたしたちのチームでは、プロダクトオーナーがバックログを起票する際も、開発チームがスプリントでタスクを運用する際も GitHub Projects を使いました。
特に便利だった機能 3 選
統一管理されることによって得られたメリットは大きかったです。
その中でも特に GitHub Projects を使って良かった、便利だったと思った機能を 3 つ紹介します。
1. 複数の Repository を横断する Custom Fields
GitHub Projects 内だけで自由に設定できる Custom Fields があります。
詳細は以下の GitHub Docs をご覧ください。
この Custom Fields が便利だと感じたのは、複数の Repository を横断する属性を付与できた点です。
GitHub Issue および Pull Request には Label があり、同一 Repository の Issue および Pull Request であれば Label によって管理することは容易でしょう。
しかし、わたしたちのチームは事業部を横断するプロジェクトチームであり、それぞれの事業部が主管する Repository は別でした（Organization は同じです）。
GitHub Projects にはフィルター機能があり、これを利用してタスクの絞り込みができます。
下図は Label を限定してフィルターするときのサジェストです。
このように Label でも絞り込みできますが、Label は Repository 単位で管理されるデータであるため、複数の Repository を横断して使うことができません。
横断して使うなら Repository ごとに同じ Label を登録しなければならず（しかも表記揺れのないように）、メンテナンスコストが掛かるでしょう。
また、当該プロジェクトしか使わない Label を作成する場合、その Repository を使う別プロジェクト、別チームのノイズになってしまう懸念もあります。
そこで活躍したのが Custom Fields です。
これは GitHub Projects で管理される設定であり、その Project の Issue および Pull Request に付与できます。
加えて Project に閉じた設定情報となるため、別の Projects に対して影響を与えることもありません。
わたしたちのチームでは、以下のような Single select の Custom Field を作成して、連携チーム内の個別チーム割当を可視化していました（画像はイメージです）。
また、以下のような Iteration の Custom Field を作成して、スプリントの管理をしたり。
以下のような Number の Custom Field を作成して、ストーリーポイントの記録・集計に役立てました。
複数の Repository を横断して、とても柔軟にチームのやりたいことに即した属性を付与できますね。
先に Label と比較する形で Custom Fields について紹介しましたが、サンプルで載せた後者の 2 つは Label では表現できない属性になります。
Iteration はスプリントの管理を容易にしてくれますし、Number は数値として扱えるため集計しやすい便利さもありました。
2. 自由にカスタマイズした複数の View
GitHub Projects は View と呼ばれる単位でタスク群の可視化方法をカスタマイズできます。
詳細は以下の GitHub Docs をご覧ください。
わたしたちのチームは事業部を横断する LeSS のエッセンスを取り入れたプロジェクトチームでした。
バックログは統一して管理されますが、開発チームは 2 つに分割されており、スプリントバックログの管理はそれぞれで行われます。
ここで活躍したのは複数の View です。
各チームのタスク向けに View を作成しました。
ボードレイアウトを使い、先述の Custom Fields で管理されているチームの属性によるフィルターをしました。
以下のようなイメージです。
View ごとに表示方法をカスタマイズできるので、各チームにとって最適な設定を自由に行えるメリットがありました。
カスタマイズできる内容は多岐にわたります。
- Fields で、ボード上に表示するフィールドを選択できたり
- Column by で、ボード内を分割する列フィールドを選択できたり
- Field sum で、Number の Custom Fields を使ってカラムごとの合計値を可視化できたり
- etc
また、テーブルレイアウトを使えば一覧性を高めた可視化ができますし、ロードマップレイアウトを使えばタイムラインに沿った可視化もできます。
チームごとに最適化された View が作成できますし、目的に最適化された View も作成できる柔軟性がとても便利でした。
3. 可視化された分析情報（今後の期待も含めて）
GitHub Projects はInsights と呼ばれる分析情報をグラフにする機能を提供しています。
詳細は以下の GitHub Docs をご覧ください。
GitHub Projects で管理されているタスクについて、さまざまな切り口からグラフにして可視化できます。
たとえば、直近スプリントのストーリーポイントの合計値をグラフにして、スプリントプランニングの予測に役立てたり。
スプリント内のタスクアサイン状況に偏りがないか可視化したり。
分析したい用途に合わせてレイアウト、X 軸および Y 軸、グルーピングや集計方法をカスタマイズできるのはもちろん、GitHub Projects で扱えるフィルター機能を Insights 内でも同等に利用できるのが特に便利な点です。
上図に載っていますが、Iteration の Custom Fields であれば @current や @previous などの相対値指定ができますし、さらに @current-2..@current のように範囲指定もできます。
グラフの Y 軸で「Sum of a field」を選択すれば、特定のフィールドの値を合計できるため、先述のストーリーポイントの合計値を可視化できました。
しかし、容易に可視化できる便利さはある一方、もうちょっとだけかゆいところに手が届かない感じもあります（個人の感想です）。
具体的には 履歴グラフ の使い勝手が惜しいなと感じており、時間軸で可視化できても扱える情報が Issue および Pull Request の Open / Close / Not Planned だけで、他に比べてカスタマイズ性が少なく惜しい感じでした。
「This is a preview feature」と記載されている機能であるため、これからの改善が待ち遠しいです。
また、Insights ではアーカイブ、削除したタスクは除外されてしまう点には注意してください。
スプリントで完了したタスクをアーカイブ、削除すると GitHub Projects 内に表示されなくなるため見た目がスッキリしますが、Insights による分析対象はアーカイブ、削除されていないタスクに限られているようです。
おわりに
GitHub Projects には他にも便利な機能はたくさんありますし、気がつけば提供されている新機能が増えている開発の活発さもあります。
多機能になるほど利便性は良くなりますが、一方で使いこなすための学習コストが増えたり、そもそも使ってみるモチベーションが上がりにくくなるかもしれません。
本記事では、いまも便利、これからはもっと便利に使えるであろう GitHub Projects について、わたしたちのチームで使ってみた上で便利に感じた機能を選別する形で紹介させていただきました。
GitHub Projects を触ってみる、もしくはよりカスタマイズしてみるきっかけになれば幸いです。
以上、わたしたちのチームで GitHub Projects を利用したときに特に便利だと感じた機能の紹介でした。
