GitHub の Issue を活用した社内の進行管理
こんにちは、GajiLabo 横田です。受託で HTML+CSS コンポーネント・JavaScript・Rails view等フロントエンド開発をお手伝いしています。
社内メンバーやパートナーさんとチームを作って、わたしが社内の進行管理をする時は、GitHub の Issue でタスクを管理することが多いです。今回は GitHub の Issue で社内の進行管理をする時に実践していることを紹介します。
Issues でタスクを可視化する
チーム内のタスクはなんでもかんでも全て Issues にします。プロジェクトのスタート時にはやるべきことが見えているタスクだけでなく、まだ詳細は見えていないが調査する必要があるタスク、作業が必要かどうかから精査するタスク、不明点が多く確認が必要なタスクなど、全貌が見えないタスクも存在します。それらを認識した時点で Issue に残すことで、後々とりこぼさないように注意できるし、チームにタスクの存在を可視化できます。
分からないことは分からないとメモして、その場で Issue にする。チーム共通の TODO リストのような使い方です。
そしてプロジェクトが進むに従い、見えていなかった点を把握できると、具体化した内容に書き換えています。スタート時に作成した Issue では着手するタスクとして粒度が大きすぎるので、Issue を新たに作り直すこともあります。
ドロップダウンメニューの Reference in new issue を使うと元の Issue への参照が分かりやすいので使っています。
![ドロップダウンメニューのReference in new issue](https://wp.gaji.jp/wp-content/uploads/2020/06/20200616-1-740x214.png)
title と comment でタスクの内容を簡潔に伝える
プロジェクトの進行具合で Issue の具体性や粒度が変わってくるので、title だけでタスクの内容がチームに伝わることを第一に考え「コンポーネント作成:」「修正:」「バグ:」等、タスクの種別を先頭に書いています。
comment も同様に、着手に必要な情報や参照元を簡潔に分かりやすく残すことに注力しています。
例えば HTML+CSS コンポーネント実装にはまず設計が必要ですが、Issue だけで概要を把握でき、設計に着手しやすくなるよう、下記のような内容を書くことが多いです。
- デザインファイルへのリンク
- 対象画面
- 共通の見た目をデザインからピックアップしたスクリーンショット添付
- Slack での議論内容や他の場所に書かれた注意メモなど決定事項をまとめて転載
プロジェクトの進行具合で comment を書き換える時は、経緯を追える形で編集したり、追加 comment にしたり、チームへの共有という視点でその時々の最適解を模索しています。
また、 Issue Template を使って 「バグ」「機能開発」「カスタム」と用途別に Issue のテンプレートを設定することもあります。
![Issue Templateの例](https://wp.gaji.jp/wp-content/uploads/2020/06/20200616-2-740x196.png)
Issue の粒度を考える
Issue にする時のタスクの粒度が適切かどうかの判断としては、Assignees の数と Issue に紐づく Pull Request の数を基準のひとつにしています。
ひとつのタスクでも調査と実装など担当者や作業工程で Issue を分けることもありますし、逆にひとつの Issue に複数の担当者や作業工程をまとめた方が流れが分かる場合もあるので、こまめに Assignees を変更して都度メンションしたり、マークダウンのチェックリスト形式を使ってタスクの進捗や着手漏れを把握しやすくしています。
Issue とカンバン機能のProjectsを紐づける
GitHub の Projects で進捗共有をしたいので、Issue を作成したら右カラムの Projects と連携させるのを忘れないようにしています。
![Projectsの例](https://wp.gaji.jp/wp-content/uploads/2020/06/20200616-3-740x183.png)
Issue をクローズする基準をはっきりさせる
Issue に紐づく Pull Request がマージされたらクローズするのは分かりやすいですが、Issue をクローズする基準が曖昧だと進捗や残タスク、新たな課題が見えにくくなるので、何を達成すれば Issue をクローズできるのか基準をあらかじめ記載しています。
まとめ
プロジェクトの性質によっても工夫できるポイントは変わるので、毎回振り返りながら、チームの形に合わせて引き出しをどんどん増やすことも大事です。
試行錯誤しながらですが、こうした小さな工夫の積み重ねを実践して、パートナーさん含めチームのみんなが各々のタスクにパッと集中できる環境をより良くしていきたいです。
開発のお悩み、フロントエンドから解決しませんか?
あなたのチームのお悩みはなんですか?
「バックエンドエンジニアにフロントエンドまで任せてしまっている」
「デザイナーに主業務以外も任せてしまっている」
「すべての手が足りず細かいことまで手が回らない」
役割や領域を適切に捉えてカバーし、チーム全体の生産性と品質をアップするお手伝いをします。
フロントエンド開発に関わるお困りごとがあれば、まずは一度お気軽に Gaji-Labo にお声がけください。
オンラインでのヒアリングとフルリモートでのプロセス支援に対応しています。
リモートワーク対応のパートナーをお探しの場合もぜひ弊社にお問い合わせください!
お悩み相談はこちらから!