こんにちは！ものづくり部でスクラムマスター兼エンジニアをしている おはぎ(@ohagi_dev) です。
私のチームでは、スクラム開発を実践する上でタスクや進捗の管理にGitHub Projectsを活用しています。
GitHub Projectsを導入した当初は私自身もチームとしてもスクラムやGitHub Projectsの理解が浅く、うまく活用できないこともしばしば。試行錯誤しながら1年ほど運用を続けてきました。
改善を繰り返して形になってきたので、この記事では、そんな私たちの実際に使用しているGitHub Projectsの設定ついて紹介します。
モチベーション
スクラムには「プロダクトバックログ」や「スプリントバックログ」と呼ばれる作業やその情報源の入れ物となる概念が存在します。
こうしたバックログをチームで共用することで、メンバー間での作業に対する透明性を得たい狙いが一つ。
加えて、そうした透明性を得ることで作業やその計画の妥当性や変化、問題に気づきやすくなり、プロセスの改善に繋げられることが最終的に実現したい状態です。
つまり、単に作業を管理をするだけではなく、スクラムの三本柱「透明性」「検査」「適応」を実行に移すために十分な情報源になっているかを意識しました。
プロジェクトの設定（カスタムフィールド）
Status
ステータスは元々存在する単一選択フィールドです。
ここではPBI(プロダクトバックログアイテム)やSBI(スプリントバックログアイテム：PBIに対する具体的な作業)に対する進捗を示す状態として定義しています。
- Unready：作業内容が不明確で、詳細化（リファインメント）が必要な状態
- Todo：着手可能だが、まだ着手していない状態
- In Progress：着手中の状態
- In Acceptance：開発が完了し、受け入れ検証を行っている状態（開発作業とは区別するために設けています）
- Blocked：何らかの障害により作業を中断している状態（チームの計画とは別に対応すべき課題があることを明確に示すために設けています）
- Release Pending：リリース待ちの状態
- Done：作業が完了し、価値のあるインクリメントとなった状態
- Canceled：価値を提供することなく中止した状態（スクラムでは価値創出を重視するため、Doneとは明確に区別しています）
Sub-issues progress
こちらも元々存在するフィールドです。
私たちはPBIに対する具体的な作業タスクをSub-issuesとして表現しているので、PBI全体の進捗を見るためにこのフィールドを活用しています。
Optionsは見栄えが変わるだけなので何を設定しても問題ありません。
Sprint
スクラムにおけるスプリントを表現するイテレーションフィールドとして追加しています。
Currentなどの状態を判別できるのでビューでの絞り込みに便利です。
Classification
スクラムには直接関係しませんが、PBIの分類を示す単一選択フィールドとして追加しています。
例えばFeatureであれば、新しい機能が増えることをユーザーに知ってもらわないと使ってもらえない（= 価値が生まれない）ので、リリース報告やドキュメントの更新などの作業が発生すると認識することができます。
分類をすることでPBIやその作業に対する認識をそろえやすくなる意味で透明性に繋がると考えています。
- Feature：新機能 - これまで実現できなかった価値を提供し、ユーザーの行動に変化をもたらすもの
- Enhance：機能改善 - 既存機能の利便性を向上させ、ユーザー体験を洗練させるもの
- Refactor：リファクタリング - ユーザーの行動や機能に直接的な影響を与えず、内部的な保守性や品質を向上させるもの
- BugFix：不具合修正 - ユーザーに悪影響を与える問題点を解消するもの
- Spike：調査・技術検証 - 不確実性の高い技術的な課題を調査し、開発方針を明確にするためのもの
- Chore：雑務・運用 - 開発活動や運用を円滑に進めるための支援作業
また、このフィールドを内訳として、GitHub ProjectsのInsightsにてベロシティのチェックもしています。
Feature・Enhanceにあたる直接ユーザーに価値を届ける活動に専念できることが望ましいですが、そうは言っても継続的な改善や価値を生むための準備、運用など間接的な活動も必要です。
どちらかに偏ると開発に支障を来たしたり、一向に価値を生めない状況になってしまうため、この配分が安定するように日々モニタリングしています。
目安としては直接的な活動7割、間接的な活動3割となるように意識しています。
緊急度の高い運用タスクが入ってきた、リファインメントが十分に追いついていない、不具合によるトラブル発生など、このバランスが崩れる理由はいくつかあります。
このベロシティ内訳を追っていることで、それらの原因に対する振り返りがしやすくなり、改善に向けた行動をとりやすくなると考えています。
Estimate
PBIの規模感を示す数値フィールドとして追加しています。
ストーリーポイント形式で表現しており、Number形式なので合算が可能なので、PBI一つ一つの見積もりだけではなく、スプリント全体のベロシティとしても活用できます。
Actual
対応後の所感としての規模感を数値フィールドとして追加しています。
Estimateが必ずしも正確につけられるとは限らないので、予実のずれを認識するための情報源として活用しています。
Due Date
ステークホルダーからの問い合わせや依頼によって生じるタスクや時期に影響する課題は締め切りを設ける場合があります。
基本的にはバックログ上で優先度を評価して並び替えるのですが、アイテム間の相対的な優先度しか判断できないため、こうした締切日を示すために日付フィールドとして追加しています。
Release Date
PBIがインクリメントとしてユーザーに届けられた日付を示す日付フィールドとして追加しています。
Start Date と End Date
主にSBI(PBIに対する具体的なタスク)の計画を表現するために開始・終了日を示すDateフィールドとして追加しています。
プランニングで大まかな計画を立てる際に仮で入力するのですが、実績を更新するのはなかなか手間で忘れがちです。
そのため、Statusに連動して自動で入力されるようにカスタマイズしています。以前に記事を書いておりますので、そちらもぜひご覧ください！
Target
スクラムでは、スプリントゴールがスプリントにおける唯一の目的です。ただ、そうは言っても現実的には色々やらないといけないことはあります。
必要なことは対応しつつも、スプリントゴールを意識するために、ゴールに直接関係するPBIを示すフィールドを追加しています。
パッと見で目につければ十分なので、単一選択フィールドで「★」をつけるようにしています。
ビューの設定
プロダクトバックログ
スクラムにおけるプロダクトバックログに対応するようなビューで、リファインメントやプランニングでのPBI選択に利用します。
レイアウトは以下のことを意識して調整しました。
- 親Issueのみに絞ることでPBIだけが表示されるように（用途的にPBI以外が表示されるとノイズになるため）
- StatusのDone,Canceledを除外することで未来のアイテムに焦点を当てられるように
- EstimateやStatusを左側に寄せ、リファインメント時に見積もりがついていないUnreadyなアイテムに気付きやすいように
設定は以下のようにしています。
- Layout：Table
- Fields：Estimate, Status, Target, Due Date, Milestone, Classification, Sprint
- Group by：Sprint
- Field sum：Count,Estimate
- Slice by：Milestone
- フィルター：no:parent-issue -status:Done,Canceled
スプリントバックログ
スクラムにおけるスプリントバックログに対応するようなビューで、デイリースクラムをはじめ、スプリント中に進捗を確認する際に利用します。
レイアウトは以下のことを意識して調整しました。
- Sub-Issues progressでPBIの進捗が見えるように
- スプリント中に関心がないステータスを除外し、計画の検査に集中できるように
- Targetで絞り込めるようにし、いつでもスプリントゴールを意識できるように
- In ProgressにSet limitを設定し、WIP制限を実現することで、実装で止まらずインクリメントの作成まで進めることを意識できるように
設定は以下のようにしています。
- Layout：Board
- Fields：Assignees, Sub-issues progress, Classification, Estimate, Due Date, Target, Milestone
- Column by：Status
- Filed sum：Count, Estimate
- Slice by：Target
- フィルター：sprint:@current -status:Unready,Canceled no:parent-issue
計画実績
スプリントバックログにおける計画の部分を可視化するビューで、プランニング時に大凡の計画をたて、過去分の実績を振り返るために利用します。
レイアウトはとにかく視覚的にスプリントの全体像を俯瞰でき、進捗に対する問題を察知しやすい状態を意識して調整しました。
プランニングにおける計画は1日以内のタスクに細分化することが理想的です。後から実際の期間を振り返ることで、タスク分解の粒度に対する是非を議論することができます。
設定は以下のようにしています。
- Layout：Roadmap
- Group by：Parent issue
- Markers：Sprint
- Sort by：Start Date(ASC), End Date(ASC)
- Dates：Start date→Start Date, Target date→End Date
- Filed sum：Count
- Slice by：Sprint
予実管理
ストーリーポイント形式の見積もりの妥当性を評価するためのビューで、見積もりの精度を改善するために利用します。
設定は以下のようにしています。
- Layout：Table
- Fileds：Title, Estimate, Actual, Start Date, End Date, Classification, Milestone, Assignees
- Group by：Sprint
- Sort by：End Date(ASC)
- Field sum：Count, Estimate, Actual
- Slice by：Sprint
リリース実績
Release Dateが入ったアイテムだけ表示しているビューで、リリース頻度やサイクルを改善するために利用します。 予実管理と見栄えは同じようなビューなので省略します。
終わりに
今回は私たちのスクラムチームにおけるGithub Projectsの設定を紹介しました。
スクラムのプラクティスに背くような使い方もあれば、チームとしてスクラムの実践自体にまだまだ課題もあります。
しかし、チームの実情に合わせた落とし所を見つけ、改善に向き合うための情報源を貯める側面としては十分に実用性のあるフォーマットだと自負しています。
というのも、例えば、デイリースクラムで進捗を検査する時、何も見えるものがなければ状況の確認はタスク作業者の感覚に頼りがちでしたが、ロードマップ形式のビューがあるおかげで作業者以外でも計画の遅れや懸念に気づけるようになってきた等、チームのコミュニケーションの変化を感じているからです。
アジャイルソフトウェア開発宣言では「プロセスやツールよりも個人と対話を」とも言われていますから、こうしたチームの変化を感じながら、ツールに依存しすぎず、よりメンバーが課題に向き合えるように形を変えながら運用を続けていこうと考えています。
参考になりましたら幸いです。ご覧いただきありがとうございました！
