はじめに
株式会社DIGITALIOのぐり（@_guri3）です。
現在自分が所属するチームでは日々取り組むことを管理するツールとしてGitHub Projectsをメインに利用しています。大体3クォーター分くらいの期間を試行錯誤しつつ運用して来た結果として、自分たちのチームの利用方法を一例として紹介していこうと思います。
元々、GitHub Projectsではない別のプロジェクト管理ツールを使っていたのですが、日々行われる開発の大部分の情報が集約されるGitHubとプロジェクト管理ツールの中で二重管理になる情報やどちらに書いてあるべきか迷う情報が出て来てしまうなどといった問題がありました。少しでも日々の開発を妨げる要因は無い方が良いため、自分たちの使い慣れたツールであるGitHubで完結するようにプロジェクト管理を行いたいというのが大きなモチベーションとしてありました。
全体像
ステータスを用意してそれに沿ってカンバンやガントチャートを確認するのがベースです。自分たちのチームでは週2回チーム全体で今やっていることを確認する時間を取っています。
用意しているステータスは以下の通りです。どのIssueがどのステータスに当たるかをちゃんと判断できるように、それぞれ説明を追加しておくと良いです。追加した説明はカンバンでも表示されます。
エンジニアがIssueに対応した後に効果検証などを行う期間が設けられるIssueも多く、このようなIssueに対して新たなステータスを用意した方が良いのではないか？という話も出ました。しかし、ここは管理工数とのトレードオフなので、まずは対応中にまとめてみるという運用をしています。この辺りはチームの規模感などで対応中のIssueが増えてわかりづらいなどの問題が起きたら分けるのもありだと思います。
タスクを追加する時の流れ
まず何かやることが発生した時には起票ステータスとしてIssueを追加します。（これはワークフローの定義で自動でそうなるようにしています。詳しくは後述します。）GitHub Projectsを確認する定例の基本的な流れは、まずは各々が対応中のIssueに関しての情報共有をしてから、新たに起票になったタスクを確認します。次空いた人がやろうか、くらいの温度感のものは「未着手」に移動し、その場で担当者を決めて「対応中」まで移動させることも多いです。
「対応中」にするときはAssigneesを設定する運用にしています。基本的には起票したタイミングにもAssigneesを登録してもらうことになっているので、エンジニアとビジネス上の相談事や意思決定を一緒にやる人がセットでIssueに紐付き、Issueのオーナーや今ボールを持っている人がわかりやすい状態になるようにしています。
Projectsに用意している項目
GitHub ProjectsにはCustom fieldsを用意することができ、現状用意しているのは以下の通りです。
いくつかの項目について解説します。
プロジェクトは、チーム内で走っている仕事のまとまりをいくつか追加しています。
Issueを作るときに付けておくことで、後から振り返った時に大体これ関連はこういうことやったよね、というのがわかるので便利です。また、プロジェクト自体の規模が大きくなってきた場合は別Viewとして切り分けて管理したりもすぐに対応できます。以下は一つのプロジェクトのみ別Viewに切り出しているものです。全体Viewの検索条件から除外し、専用Viewで絞り込んで表示するように設定しています。また、Viewは複数作成することができるのでプロジェクトだけではなくAssigneesなどの観点でもチームの状況を確認するためのViewを用意しています。
フェーズは、プロジェクトの中でもさらにマイルストーンを用意して何かに取り組む時用に用意しています。GitHubにはマイルストーンという機能が存在するのですが、これは特定のリポジトリに紐づいていて複数リポジトリにまたがるIssueをまとめられませんでした。チームが複数のサービスをみていたり複数のサービスにまたがる機能の開発などもあるため、リポジトリをまたがってIssueを管理する必要がありGitHub Projects上でCustom fieldsとして用意することにしています。
あとはガントチャートで利用する日付系やチームでこういうの欲しいよねというのがあった時に随時追加したり削除したりしつつ運用しています。適切なCustom fieldsを用意すればプロジェクト管理で欲しいなという機能は大体実現できそうと思いました。
運用方針をまとめておく
こういった運用に関する話はGitHub ProjectsのREADMEにまとめることができます。ひとまずここにまとめておけば、後から人が増えたりした時でもまずはこれ読んでみて〜としやすいので良いです。
細かいプラクティス
大まかな方針は以上の通りですが、他にもGitHub Projectsを活用するための細かいプラクティスがいくつかあるので紹介します。
GitHub Projectsのテンプレート
一度作ったプロジェクトはテンプレートとして保存できます。自分のお気に入りのテンプレートを用意しておけばまた他のプロジェクトでも同じフローをすぐに利用できます。
保存したテンプレートは他の人も見られるので、良いテンプレートを持っている人がいればすぐに真似して使い始めることもできそうです。
ワークフローの定義
GitHub Projectsでは、特定のアクションが起こった時に自動的に処理を行うワークフローを定義することができます。自分たちのチームはIssueにプロジェクトが紐づけられた時に自動で起票ステータスにするのと、Issueがクローズされた時に自動で完了ステータスにするワークフローを定義しています。
カンバンのカードに表示する内容の調整
カスタムフィールドをいくつか用意していると、微妙に一目で状況が把握しづらくなってしまうことが起きます。そのような場合は、Viewごとに表示するFieldsを設定できるのでここから調整すると良いです。
参考画像は少しわかりづらいかもしれませんが、Issueが紐づいてるリポジトリやSub Issuesの状況なども一目でわかるように表示を調整することができます。
ステータスの上限設定
各種ステータスに設定されているIssueの上限値を設定することができます。「なんか対応中のもの多くない？ちょっとみんなで確認しようか」といったアクションをとる基準として利用することができます。
ドラフトItemの作成
まだIssueにするまでも無いけれど、忘れないようにちょっと置いておきたいんだよなぁというのはGitHub Projectsに紐づくドラフトItemとして作成することができます。まずはざっと作業の洗い出しみたいなことをやりたい時もGitHub Projects上で完結できて便利です。
Insights
日々OpenされたりCloseされたりしたIssueの数を可視化することができます。バーンアップチャートなどを普段から利用しているというよりは、クォーターごとの振り返りなどでざっくりとこういう感じでIssueに取り組んでいたといったことを確認するときなどに利用しています。
おわりに
元々別のツールを利用していたプロジェクト管理をGitHubプロジェクトに移行し、試行錯誤しながら運用して来ました。取り組むことの二重管理を減らしシンプルにすることで、よりプロダクトの改善に集中できる状態を目指しています。ちゃんと使ってみると最初に触った時（多分GitHub Projects出てすぐの頃）よりも機能が増えたりしていて意外といい感じに使えるなという印象で、普段仕事をしていく中であまり困り事もありません。今回は触れなかったイテレーションといった機能もあるのでぜひ自分たちの運用に合わせてGitHub Projectsを活用してみてはいかがでしょうか。
