はじめまして、ゴミ回収の業務効率化のプロダクトでサステナビリティやサーキュラーエコノミーにインパクトを与えようとしているWOOMSの徳増こと @koheitokumasu です。Githubを本格的に使い始めたのは半年前ですが、今ではSaaS界で最もGithubを使いこなしている気がしています。
Githubというと、一般的にはバージョン管理ツールとして理解されているかと思いますが、WOOMSではその他に以下の目的・使用用途で使っています。
- Wiki
- タスク管理(Issue)
- マイルストーン管理(Roadmap)
- 振り返り習慣(KPT)
- 目標設定(OKR)
1. なぜGithubをタスク管理に使っているのか？
チームのタスク管理をどのように行うのか？というのは非常に難しい問題です。チームで強い人が慣れているツールがあれば、そっちに流れたりもします。
Notionのつらさ
WOOMSではプロジェクト立ち上げ時はNotionを全面的に使用して、ドキュメンテーションにも利用していました。しかし、Notionは本来タスク管理ツールというよりドキュメント管理ツールのため、Issueの取り扱いの難易度の高さや、検索性の悪さなどがあり、断念するに至りました。
Asanaの失敗
次に、Asanaを使用してロードマップを作成し、細かいIssueの管理などもすべてAsanaで管理するように変更しました。しかし、ソースコード上の修正などは結局GithubでIssueを書くため、2重管理が発生してしまいました。
Githubの発見
そこで、既にソースコード管理に利用していたGitHubの機能を最大限に活かし、プロジェクト管理からタスク管理、レビューまでをGitHub上で一元的に行うようになりました。
2. 具体的に行っている内容
プロジェクト管理
プロジェクト単位でボードを作成し、そこにIssueを割り当てることで、開発ロードマップや進捗を一覧で確認できます。プロジェクトボードはカンバン的にカラムを作ることができ、カードを左から右へと進めることで、タスクの状況が一目でわかります。
カラムは"To Do"、"In Progress"、"Done"といった汎用的な名前を使うことも、開発フローに合わせてカスタマイズすることもできます。例えば"設計中"、"レビュー中"、"テスト中"といった具合です。
各カードには関連するIssueの番号と概要が一覧表示されるので、クリックですぐにIssueの詳細を確認できて便利です。
ロードマップ管理
Milestoneを活用してプロジェクトのロードマップを設定しています。Quarter1、Quarter2のようにMilestoneを時期で切っておき、その中にスケジュール通りにIssueを割り当てます。
Milestoneごとのバーンダウンチャートを見れば、その期間の開発進捗がひと目でわかります。期限の近いMilestoneに含まれるIssueが多ければ、作業が後半に集中していることがわかり、工数の分散を検討する必要があることがわかります。
タスク管理
Issueを活用してタスクの詳細を記録します。Issueにはタスクの概要、詳細仕様、期待する動作、関連リソースへのリンクなど、様々な情報を記載できます。
親Issue、子Issueの関係を設定できるので、大きな機能開発Issue の下に細かいタスクをネスト化して可視化できます。子Issueに作業を割り当て、親Issueの完了をコントロールできるようになります。
また、Issueにはストーリーポイントやスケジュールなどの見積もり情報、優先度、割り当てられているプロジェクト、関連するMilestoneを設定することもできます。プロジェクトボードにカードを置く際に、これらの情報が確認できるのでタスクの優先順位付けや進捗管理に役立ちます。
ステータス管理
プロジェクトボードのカラム(レーン)でIssueのステータス(ToDo、インプログレス、レビュー待ち、完了など)を設定することができます。ボード上でIssueのカードを操作するだけで、その進捗ステータスを簡単に更新できます。
例えば、設計が完了してコーディングを始めたらIssueのカードを左から2番目の列に移動させることで、そのタスクが作業中状態であることをすぐに可視化できます。
レビューの巻き戻しがあれば、右から2番目のレーンに再度カードを移動させるなど、フローに応じたレーンの設定とステータスの更新を行えば、全体の進捗をリアルタイムで把握可能です。
イテレーション開発
プロジェクト単位で2週間や4週間のイテレーションごとにプロジェクトボードを用意しています。各イテレーションで対応するIssueをボードに設定し、イテレーション期間中にIssueを消化していきます。
イテレーション開発を導入したことで、開発作業がスプリントサイクルに乗せられ、継続的な改善を意識できるようになりました。イテレーション終了時にレビューを行い、次のスプリントで改善すべき点をIssueに書き留めておくことで、スパイラルに開発プロセスを回せるようになりました。
優先度管理
プロジェクトの優先度に応じてIssueにラベルを割り当てています。例えば「プライオリティ:高」と付けられたIssueがプロジェクトボードの上の方に設置されるよう、ラベルとレーンの関連付けをしています。
優先度の高いIssueを先に見ることができ、プルリクのレビュー優先順位も合わせて判断できるようになっています。優先度の判断指標についても、チーム内で共有ルールを決めています。
マイルストーン
製品のリリース時期でマイルストーンを設定し、そのリリースに必要なIssueをグループ化して割り当てています。マイルストーンのバーンダウンチャートを見れば、そのリリースに向けた全体の開発進捗が一目でわかるようになっています。
プルリクの時も、そのコードの変更がどのマイルストーンに含まれているかを確認でき、影響範囲を見極められます。要件やリリースが変更になった際には、マイルストーンから関連のIssueを編集できるため、変更対応もスムーズです。
ラベル
Issueに様々なラベルを割り当てることで、用途別にIssueを分類できます。例えばバグ報告なら"Bug"ラベルを、UIの変更作業なら"UI"ラベルを付けるなどです。ラベルは自由に設定でき、用途に合わせてチームで運用ルールを決めることができます。
以下のルールでやっています。
- 00_親Issue: 複数のIssueをまとめた管理用のIssue
- 01_子Issue: 親Issueに紐づく最小単位のIssue
- 02_独立Issue: 親Issueが存在しない単発のIssue
- 10_バグ: 問題のあるプログラムに対処するタスク
- 11_機能: 機能を追加するためのタスク
- 12_自動テスト: 自動テストに関するタスク
- 13_リファクタリング: リファクタリング系のタスク
- 14_インフラ: インフラ、環境構築系のタスク
- 15_DevOps: DevOps系、最適化などのタスク
- 16_調査: 調査・リサーチ系タスク
- 17_ドキュメント: ドキュメント作成タスク
- 20_検討: どのように機能を実現するかの検討ステータス
- 21_要件: 機能要件の整理をするステータス
- 22_仕様: 仕様を策定するステータス
- 23_実装: 実装を行うステータス
- 24_検証: テスト、自動テスト、テスト用ドキュメント、検証のステータス
- 99_未設定: スケジュールが未設定のもの
ラベルを組み合わせることで、優先度、対象製品、状況などの多角度からIssueを抽出したり、ボード上のカードの色分けをしたりと、視覚的にも情報が把握しやすくなっています。
これらの情報を組み合わせて、必要なビューを作ることができ、状況に応じてIssueをスムーズに特定できます。また、多くの観点から開発状況を確認でき、より適切な意思決定と課題の可視化ができるようになりました。
3. イケている部分
2重管理がなくなった
プロジェクト管理ツール、タスクツール、レビューツールがGitHub 1つで完結するため、ツールを行ったり来たりする手間がなくなりました。さらにデータの同期の必要もなくなり、無駄な重複作業がなくなりました。
タスクのぬけもれを防げる
Issueにラベルを付けたり、マイルストーンでグルーピングしたりと、きめ細かくタスクを管理できるので、重要なタスクが見落とされるリスクが下がりました。全てGitHub上で閲覧できるので、進捗の自己確認やメンバー間の共有が手軽にできます。
楽しい
何かと慣れ親しんだGitHubの画面とマークダウン記法で作業できるので、違和感がありません。むしろ、プロジェクトボードにカードを設置したり、PRにコメントをする作業は開発の延長線上にあり、ゲーミフィケーション的な楽しさがあります。
4. イケてない部分
親子Issueの関連性
親Issueと子Issueの関係づけができるものの、子Issueがすべて終わっても親Issueが自動的に完了したり、子Issueの進捗率を表示したりができないです。また、親Issueのスケジュールをずらすと子Issueも引っ張られてずれる、みたいなことができません。このへんはAsanaのほうがイケてました。
Wikiの検索性の低さ
Github Wikiは検索性が低く、求めている情報になかなかたどり着けないという悩みがあります。また、目次を自動作成してくれないために、読みやすいWikiとしての運用維持が難しいです。
5. 今後やりたいこと
見積もりとベロシティ
これまではストーリーポイントなどの見積もり機能を活用していませんでしたが、今後は残作業の正確な見積もりを行い、ベロシティも算出してスプリントプランニングに活かしていく予定です。
開発項目の精査
現状は開発者主体で新規開発項目を立ち上げていますが、今後は経営サイドとのすり合わせを密にし、プロダクトの機能要件を事前によく検討したうえで開発項目を精査していく必要があります。
WorkflowやGitHub Actionsによる自動化
手作業での運用で非効率な部分があれば、GitHubのWorkflowやGitHub Actionsで自動化していく予定です。例えば、マイルストーンを達成するとSlackに通知するなどが考えられます。
GitHubの機能をフル活用して、さらにスムーズな開発プロセスを実現していきたいと考えています。