一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

GitHub Projects を利用したタスク管理

宿泊開発チームでエンジニアをしている @itinao です。
昨年の10月に入社しました。

今回は GitHub Projects を利用したタスク管理について記載します。

なんとなーく GitHub Projects 使うと、KANBANにしてみたり

リストにして使ってみたり

で終わってしまいます。

もっと色々できるんだよってことが伝えられればと思います。

背景

一休ではチームごとにタスクの管理方法が違い、
Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法が異なっています。

各ツールの印象は、、

  • Google Spreadsheet
    • 作り込めば便利なんだけど、壊れやすい...
  • Jira
    • 過去に使って、エンジニア目線だと操作感とかそんな好きになれなかったなあという印象があった..
  • GitHub Projects
    • エンジニアだととっつきやすいのと、ツールをアレコレ移動しなくて済む

個人的には Jira か GitHub Projects を使いたくて、
できれば GitHub Projects を選択したいという気持ちがありました。

そのモチベーションでやり方を考え、現在はこの記事の管理方法で落ち着いています。

どんな機能があるか

この4つを抑えておけば良いです。
Custom Fields / Views / Workflows / Insights

ざっくり概念。

Custom Fields

下記の種別でパラメータを作成でき、Draft / ISSUE / Pull request に値をセットすることができます。

docs.github.com

種別 設定できる内容
Text テキスト
Number 数値
Date 日付
Single select 決められた項目のみ選択できる
Iteration 決められた間隔の時間ブロックを作り、その時間ブロックを選択できる

★ 自身のチームではこのようなパラメータを作って運用しています。

名前 種別 設定内容 例
Status Single select タスクの状態 Backlog / In progress / In review / Done
Epic Single select 作業階層の最上位の単位で、チームが目指す大きなゴールのようなもの Epic1 / Epic2 / Epic3 / 改善 / ...
Estimate Number 見積もり 1, 2, 3, 5, 8, 13, ...
→ フィボナッチ数列で運用しているため、Single selectにしたいところだが Insights で積算を表示させたいので Number
Sprint Iteration 区切りになる開発期間 Sprint1, Sprint2, Sprint3, ...
Function Single select どこの機能か
リポジトリに近いイメージ 		管理画面Backend, 管理画面Frontend, ユーザー画面Backend, ...
Priority Single select 優先順位 高, 中, 低
→ 普段は使わないが、バグチケットなどで目印が欲しいときに使う

Views

Table / Board / Roadmap のLayoutで、Draft / ISSUE / Pull requestを表示することができます。

Group by, Slice byが良い感じです。

Group by

設定した項目でグルーピング化し、表示してくれる

Slice by

設定した項目でフィルタリングし、左にメニューが表示される

★ 自身のチームでは、ざっくり、、4つの Viewを良く使っています。

種別 イメージ 説明 利用シーン
プロダクトバックログ GitHub Projects全体のチケットをEpic単位で絞り込めるようにしている 全体のタスクを眺める時
見積もりをする時
スプリントバックログ 現在のSprintのタスクをAssignees単位で絞り込めるようにしている 朝会/夕会で各々の作業を報告する時
自身のタスク 自身がアサインされているタスクをSprint単位で絞り込めるようにしている 自身でアサインされているタスクを確認する時
ADR タスク管理という軸ではないが、議論したことを書いておく
・専用のリポジトリのISSUEを表示している
・GitHub Discussionsでも良い 		議論の場

Workflows

自由度は低いですが、
Draft / ISSUE / Pull request の操作をHookとして、特定のアクションを行うように設定ができます。

★自身のチームでは、このような設定をしています。

  • ISSUE / Pull requeset をProjectsに追加した時、Statusを Backlogに設定する
  • ISSUE / Pull requeset をクローズした時、Statusを Doneに設定する
  • Pull requeset をマージした時、Statusを Doneに設定する
  • ADRのリポジトリに ラベル: ADR のISSUEを作成した時、このProjectsに設定する

→ チケットの整理をしたくなるフェーズで Auto-archive items を設定する

ISSUEと Pull requestの紐づけ

ISSUEと Pull requestを紐付けることができ、
これを設定するとマージされたタイミングで紐づいている ISSUEがクローズされます。

Workflowsとセットで使うことで、自動的にステータスをDoneに更新することができます。
★ Pull requestのマージ → ISSUEのクローズ → Custom Fieldsのステータスが Doneになる

※ 注意点としては複数のPull requestを ISSUEに紐づけている場合、1つでもマージされるとISSUEがクローズされてしまう

Insights

Draft / ISSUE / Pull requestの状態を参照し、グラフを作ることができます。

★ 自身のチームではこのような設定をしています。

種別 イメージ 説明
Burn Up 作成されているISSUEとクローズされているISSUEの傾向を確認できる
EPIC Epicごとのタスク量を確認できる（縦軸はチケットの合計）
Velocity Sprintごとの進行速度を確認できる（縦軸はEstimateの合計）
Plan Sprintごとに割り当てられているタスク量を見ることができる（縦軸はEstimateの合計）

タスクの進め方

自身のチームでは、このようなステップでタスクを進めています。
まずはタスクの洗い出しと見積もりです。

  1. タスクの洗い出し
  2. 見積もり

↓ スプリントごとにタスクのアサイン〜開発〜整理を繰り返す

  1. タスクのアサイン
  2. 開発
  3. タスクの整理

タスクの洗い出し

スムーズに見積もりを行うために、何をどこまでやるかが整理できてると良いです。

なのでチケットに概要、どこまでやるかなどを書くルールにしています。
タスクの範囲が曖昧だと見積もりがブレがちになります。

## 概要
◯◯を設定できるようにしたい

## やること
- ◯◯が設定できるようになってる
- backendと疎通し、DBにデータが保存できるようになっている
- mainブランチにマージできている

## 補足
- GraphQLスキーマは決定している状態からスタート

見積もり

下記のようなルールで決めていきます。

  • チケットの重さは 1, 2, 3, 5, 8, 13, .. （フィボナッチ数列）で書き、人日では表さない
  • チケットの重さは 相対評価
    • タスクA が 2で、タスクB が 8だった場合、B の工数は A の工数の 4倍あると見積もる ○
    • タスクCが 2よりもかかりそうだけど、5まではいかないなあ。。と思ったら 3を設定 ○
      • タスクをこなしていくと徐々に成熟していくイメージ
      • 最初のうちはマトリクスを作って意識統一する
        • 1: 数分で終わり、やる内容は明確、リスクがない
        • 2: 数時間で終わり、やる内容は明確、リスクがない
        • 3: 1日で終わり、やる内容は少し整理が必要、リスクがほとんどない
        • 5: 数日で終わり、やる内容は整理が必要、リスクを考慮
        • 8: 1週間で終わり、やる内容は複雑、リスクがある
  • 個人の裁量で決めず、チームで決定する
    • あの人だったら慣れてるから 1日で終わりそうだけど、、自分はもっとかかるかも ×
      • （ブラウザでプランニングポーカーをするサービスがあるので、そちらを活用する）
  • できる限り小さい数字にする
    • 小さくするのは手間だったりするので、手間にならない程度に分解する
      • 分解することでタスクの解像度が上がる ○

チームで決められた値を見積もりに使うことで、
スプリント内でチームがどれくらいチケットを消化できるかが見えるようになります。

現状の課題と今後の展望

運用していると下記のような課題点が出てきました。

  • サブタスクを作りたい
    • 少し大きなチケットを消化する際にチケットを分けたくなることもあるが、現状サブタスクが作れない
  • バーンダウンチャートが見たい
    • いまの進行速度だといつごろ開発が完了するのかを見たくなるが、現状見れない

Slice byは2023年8月に追加されて使いやすくなったように、今後の進化に期待です。 github.blog

今後の展望としては Qaseのようなテスト管理ツールと連携し、
自動テストの実行と絡めた バグチケットの連携まで出来るようになれれば良いなと思っています。

qase.io

まとめ

タスクのチケット化・見積もりをする癖をチームに作るのが最初の課題かなと思います。

  1. スプリントごとにやることを決め、そのチケットを見ながら朝会などで会話する
  2. スプリントでどの程度タスクをこなせたのかを測り、いつ頃までに開発が完了するのかが分かるようになる

このようなフローになればチームの透明性も確保できて良い感じです◯

GitHub Projectsで 小中規模の開発に十分耐えられるので、ブラッシュアップしながら継続して使っていきたいと思います。

さいごに

一休では、ともに良いサービスをつくっていく仲間を募集中です！

www.ikyu.co.jp

カジュアル面談も実施しているので、お気軽にご応募ください。

hrmos.co

Copyright© 株式会社一休®, All Rights Reserved.