はじめに
こんにちは。Musubi の機能開発チームでフロントエンドを主に担当しております、井上です。どうぞよろしくお願い致します。
カケハシではスクラムによる開発を推進しており、その運用はあるていど各チームの裁量に任されています。
今回は私が所属しておりますチームがスクラムを運用をしていく中で使用している GitHub Projects について触れていきます。
どうぞお付き合いのほど、よろしくお願い致します。
ご注意
- 上記でも触れておりますが、本記事における GitHub Projects の運用は Musubi の機能開発チームにスコープしたものです
- カケハシ全体で GitHub Projects を用いたスクラム運用を行っているものではありません
GitHub Projects とは
GitHub が提供するプロジェクト運用のためのツールです。
ドキュメント では次の記載があります。
(公式ドキュメントから引用) Projects は、GitHub での作業を計画および追跡するための、適応性のある柔軟なツールです。
日々の業務を行うなかで発生する「作業のチケット化」「作業状況」「検討結果やメモ」といった動きや情報を、この GitHub Projects を使って共有しています。
なぜ GitHub Projects なのか
もともとは Trello を使ってタスク管理を行っていました。
Trello でもチケットドリブンによる開発タスクの管理を行えていましたが、次の点を実現したいという欲求がありました。
- スプリントを設定したい
- GitHub とのシームレスな連携が行いたい
- ベロシティを計測したい
- 進捗状況を視覚化させたい
- チームの透明性を確保したい
これらの解決にあたり、JIRA や ZenHub も選択肢に挙がったのですが
- 追加費用が発生することなく利用開始できる
- 求める機能がまぁまぁ揃っていた
この 2 点から GitHub Projects の利用を決めました。
まず 1. ですが、 GitHub Projects は利用しているプラン上で利用できます。利用にあたり追加で料金が発生することはありません。
次に 2. について。 Insights という機能を用いて分析情報を視覚化することができます。また GitHub から提供されているので、 Issue と PR の連携もスムーズに行えます。
どう運用しているか
では実際にスプリントを回すにあたり、どのように運用( 利用 )しているかについて触れていきます。
1. Custom fields の設定
画面右側の 「...」 から 「Settings」 を開き Custom fields
を設定していきます。
( 画像上部の棒線は個人アイコンを隠すため )
Estimate の設定例.
Sprint の設定例. これは Iteration
を指定しているので、対象となるアイテムを追加していくことが出来ます。
この画面からそれぞれ設定していくのですが、デフォルトで用意されているフィールドだけで足りない場合は + New field
から追加します。( ↑ の画面はすでに後述のフィールドを追加した状態です )
なお Field type
は一度設定すると変更できないようですのでご注意ください。誤って Field type
を設定した場合はフィールド名の右にある 「...」 から Delete field
で削除し、再度作成します。
ちなみに、現在は次のフィールドを設けて運用しております。
フィールド | 内容 | 備考 |
---|---|---|
Status | チケットの状態を表します | かんばん方式で Issue を見る際に各ステータスにチケットが配置されます |
Estimate | チケットの作業ポイントを表します | |
Function | チケットが受け持つ機能を表します | チケットが実現する機能ではなく Web App, API といった大きな括りでの機能を設定します |
Epic | チケットが実現する内容を包括的に管理する項目です | 後述の「残念な部分」でも取り上げますが, Epic としてチケットを発行できないのでフィールドで管理しようという試みです |
Type | チケットが Epic なのか実作業としての Task なのかを区別します | |
Sprint | チケット対応を行うスプリントを表します | 後述の Insights で分析する際に重要です |
Remarks | チケットがプランニング時に対応予定となっていたものかどうかを表します | こちらも Insights で分析する際に重要です |
ここで設定した項目を実際の Issue 作成時に埋めていきます。
そしてその内容が後述の Issue 管理にも影響します。
2. チケット管理
チケットは GitHub Projects の Add item
から作成すると便利です。
作成直後はチケットが Draft
状態で配置されます。その後、チケットの詳細を埋めていく中で適切なリポジトリを選択して Issue にコンバートします。
- 追加したいステータス上で
Add item
を押します
- チケットタイトルを入力します
1.
で選択していたステータス上にDraft
でチケットが配置されました
- チケットを開いて詳細を記入していきます( Issue へのコンバートもここで行います )
枠で囲った Edit
からは OverView が編集できます。
その右側の枠で囲った項目からは、先述の Custom fields
に対して情報を設定していきます。
Convert to issue
で Draft
から Issue
にコンバートされます。このとき、 Issue
を配置するリポジトリを選択します。
3. Issue 管理
Issue 管理は目的に応じて「かんばん方式」か「テーブル方式」が選択できます。
現在は主に次の 3つ のビューを用意して Issue の進捗状況の確認に役立てています。
目的 | 方式 |
---|---|
俯瞰して確認 | かんばん方式 |
スプリント単位で確認 | テーブル方式 |
担当者単位で確認 | テーブル方式 |
- かんばん方式
- ステータスごとに「列」が配置され、チケットはそのステータスに応じた列に配置されます
- 各チケットの状況が一目で分かるので状況の把握に役立ちます
- テーブル方式
- 前掲の
Custom fields
で設定したフィールドで グルーピング することで、フィールド単位のチケット把握に役立ちます - 私達の運用では上記表のとおり
スプリント
と担当者
単位の把握に利用しています
- 前掲の
4. ワークフロー
簡素・単純ではありますが、Issue や PR の状況に応じたワークフローも利用できます。
現在用意されているワークフローは
- Item added to project
- Item reopened
- Item closed
- Code changed requested
- Code review approved
- Pull request merged
- Auto-archive items (Beta)
があります。
これらは各ステータスに応じたワークフローで、Issue か PR, またはその両方が
- (
When
)- 指定されたステータスになったとき
- (
Set
)- どうするか
程度の設定しかできません。
また任意でワークフローを追加することはできないようです。より柔軟なワークフローを運用したい場合は GitHub Actions の利用が必要になります。
というわけで、いまのところ
- Item added to project
- Item closed
- Code changed requested
- Pull request merged
の 4つ のワークフローでシンプルに 「チケット追加」「チケット終了」「PR発行・レビュー依頼」 「PR マージ」 時にチケットを指定のステータスに移動させる運用としています。
5. 分析
さて、GtiHub Projects を利用する最大のメリットである 分析 です。
GitHub Porjects では Insgihts という機能から作業状況の分析が行なえます。
次のチャートを作成してスプリントの振り返りに活用してしています。
目的 | 要約 | 説明 |
---|---|---|
スプリントの作業状況を確認 | 各ステータスの積み上げを折れ線グラフで分析 ( バーンアップチャート ) | ポイントを プランニング時, 差し込み, トータル でそれぞれ分析する |
スプリントの作業量を確認 | 消化ポイントを棒グラフで分析 ( ベロシティ ) | スプリント単位で計測し、1スプリントあたりに消化できるポイントを把握する |
Epic ごとのポイントを確認 | Epic の積み上げを棒グラフで分析 | Epic の割合を把握する |
スプリントの作業状況を確認( バーンアップチャート )
スプリントの作業量を確認( ベロシティ )
Epic ごとのポイントを確認
( 塗りつぶしていますが、各 Epic に対応するポイントを出力してます )
6. チームの透明性の確保
ここまでに触れてきた内容がそのまま「チームの透明性の確保」につながるのですが、
- メンバ各人が何をやっているのか
- 対応している案件はどの程度進んでいるのか
- トラブルが発生していないか、もしくはトラブルになりそうな気配はないか
- 等々...
こうした「チーム・メンバの置かれた状況を相互に理解しやすくする環境づくり」ということを「透明性」という言葉で表しておりまして、その実現が GitHub Projects の運用を通して期待する効果の一つなのですが、実際にその効果は少しずつ見えてきました。
次は一例ですが、
- 疑問
- スプリント中にプランニングで決めた作業( ポイント )の消化が低いのはなぜか
- 原因
- プランニング外の割り込み作業が発生している
- 単にそのタスクを担当しているメンバの進捗が遅れている
- 対策
- 割り込み作業に対して
- ベロシティを計測することでスプリント辺りのポイントから予め割り込み作業分を確保しておく
- もしくは割り込み作業を次スプリントに回せないかの調整をする
- 個人の進捗遅れについて
- ペアプログラミングやモブプログラミングを通じて遅れとなっている原因の解決に臨む
- 割り込み作業に対して
という具合に、疑問・課題に対するアクションを取りやすくなりました。
この辺はチケット発行して対応にあたるという、タスクをチケット化しただけの運用では得られなかった効果であると思いますので、導入の意義が充分にあったといえる点です。
番外. Issue と PR の紐付け
GitHub Projects の利用目的の一つが Isseu と PR の連携でした。
とはいっても、GitHub Projects を利用して特別な何かをすることはありません。
公式のドキュメント Pull RequestをIssueにリンクする に従い PR を作成することで両者を紐付けます。
ただこれだけの作業ですが、これによって GitHub Porjects 上で Issue と PR を見ることができるのは日々の業務を行う上でかなり便利になります。
残念な部分
- バーンダウンチャートが利用できない
- Epic チケットが発行できない
1. バーンダウンチャートが利用できない
GitHub Projects ではバーンダウンチャート機能はまだ提供されていないようです。
こちら のように GitHub Projects からデータを取得して自前でバーンダウンチャートを作成することもできるようですが、そこにコストをかけることは目的から外れますので対応していません。
いまのところは前掲のようにバーンアップチャートで代替していますが、スプリント単位でのポイント消化 という点においては視覚化できております。
バーンダウンチャートについては今後の GitHub Projects のアップデートに期待したいところですね。
2. Epic が発行できない
チケットを Epic として発行できない のが GitHub 導入当初は歯がゆいと感じておりました。
とはいえ、前掲したように現在は「Custom fields に Epic を設定」することで運用できております。
むしろ
- Epic チケットを発行しなくても現在の運用で「どの案件に紐づくチケットは把握できる」
- Epic チケットに Issue チケットを紐付ける作業のほうが面倒ではないか
という向きもあり、Epic チケットは無いままでも良いかな、という感じで回っています。
今後のアップデートで Epic チケットについても提供されるかもしれませんが、そのときにまた改めて使用するかを検討したいと思います。
まとめにかえて
まとめにかえて、というところで GitHub Projects を使ってみての所感を述べたいと思います。
ここまで簡単ではありますが、ざっと GitHub Projects での運用について触れて来ました。内容の繰り返しにはなりますが、改めて GitHub Projects を採用したことで良かった点について挙げていきます。( 残念な点については前項で触れたので割愛します )
- 良かった点
- スプリントを設定できる
- スプリントにおける進捗状況や作業分析を視覚的に訴えることができる
- Issue と PR の紐付けが簡単できる
- 上記に関連して Issue や PR との UI/UX の乖離がない
- ワークフローによるステータスの自動変更
- チームの透明性の確保
上記は課題として解決したいと思っていたことですが、これらは GitHub Projects を導入することで解決できました。
そのなかでも、やはりスプリントの状況を視覚化できたというのは大きな点です。
作業状況がグラフとして見えるというのは直感的に理解しやすいということでモチベーションの向上に繋がります。もちろん進捗が悪いときも如実に反映されるので落ち込むこともありますが、そこは反省点として振り返り次のスプリントに臨む、という切っ掛けにもなります。
また先の項目( 6. チームの透明性の確保 )にて触れましたとおり、作業状況の相互理解を進めたいという目的の元に、トラブルの早期発見・早期解決に向けた対策の実施、というメリットが得られました。
もうひとつ触れておきたいと思います。
GitHub Projects, Issue, PR といずれも GitHub で提供されているものなので、これらの連携がスムーズに行えるというのは狙いの一つではありました。
が、 UI/UX が統一された( Issue や PR との UI/UX の乖離がない )点は意図していないメリットでした。
感覚的な話になってしまいますが、UI/UX が統一されたことで、チケット管理の際のストレスが個人的には軽減されたと感じております。
特に意識したこともなかったのですが PR は GitHub, Issue は別のツールで管理 と、見た目や操作感といった部分で大きな違いがあるというのは意外とストレスになるのだということに気付かされました。今後、またツールを選定するようなときには要件として頭の片隅に置いておこうと思った点です。
少し話が逸れました。そろそろまとめに入ります。
繰り返しになりますが、解決したいと思っていた課題は概ね対応できました。
残念な点で挙げたようにちょっと物足りないなという面はあります。ですがそれらは ( 今のところは ) 運用でカバーできていることもあり、取り立てて問題視するほどのものではありません。
スプリントを運用するにあたり、「まず何かツールを使ってみたい」とか「導入コストをかけたくない」といったときに GitHub Projects は良い選択肢となるのでは、と思います。
ZenHub や JIRA といった有料の管理ツールを使用する前の管理ツールの入門的な意図で使ってみるというのも良いのではないでしょうか。