GitHub Projects でデザインチームのタスク管理をするノウハウ

こんにちは、松久です。

デザインチームでは、GitHub Projects でタスク管理しています。タスク管理する理由はいくつかあります。

「食べチョク」の改善を少しでも進めるため
- チームで効率的に改善を進めるため
他のチームと一緒に仕事をするため

チームで成果を出せているのかを確認するため GitHub Projects を使って「カンバン」を参考にして管理をしています。

なぜ GitHub Projects を使っているのか

GitHub が、職種関係なく導入されています。GitHub issue で、タスクを書き出して GitHub Projects に集約がある程度されている状況がすでにありました。もし、GitHub Projects を使い続けて問題が発生すれば移行することを検討することにしました。

現在の GitHub Projects の状態

いくつかのカラムに分けて運用しています。カンバンと同じで、issue は、inbox から始まり、Done で完了します。現在あるカラムと役割は下記のとおりです。

inbox
- issue ができたらまずはここに置く
- 担当が決まっていない
Talking
- デザインチームで検討したいことをここに置く
- 定期的に話す時間を設けて話して解決したり、具体的な取り組みになれば、あたらしく issue を作る
Backlog
- 取り組む担当を決めた issue
- 取り組める状態にするのもこの状態で行う
Expired Backlog
- リリース日が決まって動かせない issue
- 取り組む担当を決めた issue
- 取り組める状態にするのもこの状態で行う
In Progress
- 取組中
開発中・連絡待ち
- UI デザインが終わり、開発実装中
- 社外からの連絡待ちで、動かせない issue
マスターデータに反映待ち
- 開発も終わり、利用者に届けられた状態だが、デザインデータをマスターデータ（ Figma でブランチ機能が使えないため）に反映するの待ちの状態
Done
- 利用者に届けられたられた状態
icebox
- いつか優先度が上がる可能性のある issue

運用を始めて、少しづつ変化して現在の形になっています。今後も変化していきます。

GitHub Projects の運用ルール

運用しながら出来たルールがいくつかあります。

issue を左から右に進める
- チームで issue をゴール（完了/Done）に進めることを大切にしています
- issue が左から右に移動することで取り組む内容が具体的になります
Done に移動した（完了） issue をアーカイブするのは月曜日
- 一定期間にどれぐらい完了したかチームで確認するため
  - 大体、1 週間で 10〜15 ぐらいの issue がクローズされているのか肌感をもつようにしています。少ない時は、進めるための障害があった時だと気付けるからです
- Projects に置いておける issue には限りがある
並べる順位は、取り組む・期限が近いもの順
- 取り組む価値が大きいことを先にするのが基本です。ただし、取り組む内容が時間のかかるものの場合（例：冊子を作る）や、リリース日が近いのもあるので、取り組む順で並べています

GitHub Projects の運用ノウハウ

運用している中で、上手くいかなかったこともあります。

毎日見る
- チームでは月・水・金に見ています。取り組むことに困っていることはないかを確認しています
- 私は毎日見ています。急ぎの issue が登録されていることがあるためです
  - 急ぎの issue は、Slack のデザイン組織のチャンネルなどでメンションしてもらうなどの方法もありますが徹底は出来ていないです
- issue での連絡が途絶えたときは「いかがでしょうか」と連絡することから始めます
担当者別のカラムは作らない
- 担当者のことが知りたいわけではなく、issue がどんな状態なのかを把握したいので、担当者（アサイン）別のカラムは用意しません
  - 担当者の状態が知りたいときは、担当者別の View を作って対応しています
  - ラベル別で View も作れるので、ラベルの管理を大事にしています
カラムを増やしすぎない。
- カラムを増やしたいと感じる時は、1 つのカラムに issue が溜まっていて取りこぼすことが出てくる時のようです
- カラムを増やす前に、issue が止まっている要因を取り除くことを優先します
  - 「左から右」に issue を進める方法が他に無いか模索します。例えば、他のチームにお願いできないか、人を増やせないか、取り組み方やゴールを変えられないかを検討します

issue を作成する時のコツ

とりあえず issue にする
- issue にしないのは、プライバシーに関わることなど、秘匿性が高いものだけです
- デザイナー採用の資料作成など、プロダクトに関係ないことも issue にしています
- Slack やミーティングで取り組むことを決めたら、issue にします。特に、Slack で話して取り組むことを決めたら忘れずに、issue にします
完了を定義する
- 「バナーを作る。中身未定」という issue はよくあります。そのときは、要望がでてくるまで待ちます。もしくは、声をかけて、取り組みを具体的にするところから始めます
- 方法だけ決まっていて、何をすればいいのかわからないときは、わかるようにしていく取り組みをします。例えば、issue で質問したり、ミーティングしてみるなどをして結果を issue に記載します
issue の種類を把握する
- 急ぎ（ASAP）、Epic（複数の issue 達成で成立する）、不具合といった issue があり、別で管理できるようにラベルを付けています

GitHub Projects を運用してみて

運用していくなかで、大切にできていることは 2 つです。

見える化する
フローを重視する

チームがどれだけ改善を実現しているのか一週間ごとで確認できるようになりました。同時に、連絡待ちや、急ぎの発生回数があるかも把握できるようになりました。チーム外の人が見ても、詳しくは分からなくても、どのカラムにどれだけの作業があるのかはわかるようになっているハズです。

「左から右へ進める」ということを前提にしています。進めるための障害（デザインする時の悩み）が発生し、検知するためのイベントができ、検知したことを定例で話すようになってきたので、issue を進めることを大切にできるようになってきたと感じています。

もちろん、出来ていないこともあります。
また終わっていない issue があるのに、新しい issue に着手することがあります。取り組む issue を増やすのではなく、完了する issue を増やすことを優先できていないときがあります。終わらせることを優先したいのですが、確認待ちなどもあり、In Progress が増えている状態です。