見出し画像

GitHub Projects を使用してissueとpullRequestの見える化に取り組んだ話

みなさん、こんにちは。ウイングアーク1stの いしま です。
React・TypeScript のアプリをGitHubを使用してチーム開発しており、GitHub Projects を使用してissueとpullRequestの見える化に取り組んできました。
その内容についてご紹介します。
※当記事は GitHubでの開発経験があるかたが前提の内容になっています。


アプリ開発の概要

アプリ開発のリリースサイクルは以下のようになっています。

  • 3週間単位のリリース

  • コードフィックスはリリース1週間前

issueとpullRequestは以下のような運用になっています。

  • 基本的にissueとpullRequestは1対1で、開発内容が大きすぎる場合はissueを分ける

  • コードレビュー・テスト観点レビューが通ったpullRequestがマージできる

GitHub Projects を使用した理由

当初GitHubのmilestone を使用して、コードフィックス毎にissue・pullRequestを管理しましたが以下の問題があり、GitHub Projectsを使用するようになりました。

  • issueに対して優先順位やメモを設定して一覧で確認することができなかった。

  • コードフィックス毎にどのようなissueがあるかを一覧で確認することができなかった。

  • milestoneはissueに1つしか設定できないため、中長期のmilestoneで開発を進める場合に、コードフィックス毎のmilestoneが適用しづらかった。

  • pullRequestについて、レビュー中かどうかの管理を簡単にしたかった。

GitHub Projectsの説明のリンク

issueの見える化の取り組み

issueについて以下の内容を実現できるように試行錯誤しながら、GitHub Projects の利用を進めてきました。

  • issueに優先順位を設定したい(効率よく開発作業するための指標)

  • issueの温度感やMVP(Minimum Viable Product)を設定したい

  • コードフィックス毎に対応するissueの状況をチームメンバー全員で理解して、アサインしたり調整できるようにしたい

結果として、次回・次々回など将来的なリリースも含めたissue管理が必要だったため、1つのGitHub Projects を作成して運用することにしました。

issue管理のGitHub Projects の設定①

GitHub Projectsでは、任意のフィールドの追加が可能で、issueの管理をしやすくするために、以下のフィールドを追加しました。

  • codefix(Date型):コードフィックスの日付を設定する

  • priority(Single Select型):issueの優先順位を設定する

  • delivery(Single Select型):issueの温度感やMVPを設定する

  • memo(Text型):issueのメモを設定する

issueの優先順位のフィールド
issueの温度感のフィールド

issue管理のGitHub Projects の設定②

表示対象のフィールドを以下の内容にしました。

  • Title:issueのタイトル

  • Assingees:issueの担当者

  • codefix:コードフィックスの日付

  • priority:issueの優先順位

  • Labels:issueのラベル

  • delivery:issueの温度感

  • memo:issueのメモ

  • Linked pull request:issueに対してのpullRequest

issue管理のGitHub Projects の設定③

以下のViewの設定を行いました。

  • Layout:Table

    • スプレッドシート形式での表示になります。

  • Group by: codefix

    • コードフィックスの日付単位にサマリーして表示します。

  • Sort by :Assingees

    • アサインしている担当者でソートすることで、担当者毎にissueがどれだけあるか分かりやすくなります。

  • 絞り込み:-status:Done

    • 終わっていないissueを対象とする

GitHub ProjectsのView設定

結果

上記の設定を行うことで、コードフィックス毎に終わっていないissue 一覧が確認可能になり、担当者別のissueの状況や、温度感が高いissueの残などを把握できるようになりました。
この一覧画面で設定を直接変更できるため、進捗会議などで、この一覧画面を共有しながら担当者・優先度・コードフィックス日付を、その場で調整して、チームメンバー全員がissueの状況を把握できるようになりました。


issueのリリース管理用のGitHub Projects

pullRequestの見える化の取り組み

pullRequestについて以下の内容を実現するために試行錯誤しながら、GitHub Projects の利用を進めてきました。

  • コードフィックス毎に対応した内容を把握できるようにしたい

  • pullRequest がレビュー前・レビュー中・マージ済みを把握できるようにしたい

結果として、コードフィックス毎にpullRequestを管理する必要があったため、コードフィックス毎にGitHub Projectsを作成する運用にしました。
コードフィックス毎に作成する GitHub Projectsの名前は、リリースバージョンとコードフィックスの日付を入れて、リリースターゲットが分かるようにしました。

pullRequest管理のGitHub Projects の設定①

レビュー管理が目的のため、ビルトインの Status フィールドで、
In Progress の選択肢を Review に変更しました。

ビルトインの Status フィールドの設定変更

pullRequest管理のGitHub Projects の設定②

表示対象のフィールドを以下の内容にしました。

  • Title:pullRequest のタイトル

  • Assingees:pullRequest の担当者

  • Status:pullRequest のStatus

  • Labels:pullRequest のラベル

pullRequest管理のGitHub Projects の設定③

以下のViewの設定を行いました。

  • Layout:Board

    • かんばん形式での表示になります。

  • Column by: Status

    • Statusの状態毎にかんばんが表示されます。

GitHub ProjectsのView設定

結果

上記の設定を行うことで、コードフィックス毎に、レビュー前・レビュー中・マージ済みのpullRequestが、かんばん形式でわかるようになりました。
リリースしたバージョン毎に、どの対応が行われたかも分かりやすくなりました。

かんばんでのレビュー管理

見える化による効果

  • 開発チームメンバー全員がissueの状況を把握できるようになったため、issueの対応漏れが無くなりました。

  • 開発チームメンバー全員が、アサインされたissueに対して、コードフィックスまでに間に合うかどうか?間に合わない場合にどうすれば良いか?ということを意識できるようになり、コードフィックス直前で実は終わっていなかったことが分かるなどのトラブルが無くなりました。

  • 各種実績報告の資料作成の時間を減らすことができました。

    • pullRequest に週単位の実績報告用の日付のカスタムフィールドを追加して、週末に完了したpullRequestに対して日付を設定しました。

    • この日付で絞り込みしたGitHub ProjectのViewを作成し共有することで、週単位の実績の資料作成を新たに行う必要がなくなりました。

GitHub Projects の便利な機能

GitHub Projectsを利用していて便利だと思う機能を紹介します。

インクリメンタルサーチができる

GitHub Projects の上部の検索バーで、インクリメンタルサーチができるため、探したいissueを簡単に見つけることができます。

「モバイル」でissue一覧をインクリメンタルサーチ

コピー&ペーストによるセルの一括設定

GitHub Projects の一覧表示(Table レイアウト)で、セルのコピー&ペースト機能を使用することで、複数のセルに一括設定ができます。

GitHub Projects のTableレイアウトでのセルの一括設定

既存の設定に影響なく簡単にViewを追加できる

既存のViewを選択して「Duplidate view」を実行することでViewをコピーできます。

Viewをコピーする

この機能を利用して、コードフィックス毎に以下のような観点でissueを一覧表示し、状況を把握するなどの応用が可能です。

  • 再現性が無いissueだけを対象にして、不確定なissueがどの程度、誰にアサインされているか把握する

  • OSのメジャーバージョンアップなどの外的要因に関するissueを対象として、いつまでに誰にアサインが必要かどうか、確認用の環境に問題はないかを把握する

  • 新人の方に割り当てたいissueだけを対象にして、どのように業務をこなしていけば、アウトプットを出しやすいか把握する

さまざまなViewを作成

最後に

GitHub Projects には、他にも様々な機能があり、さらに高度なことも可能です。
ただ、当記事で紹介した内容のように、誰もが理解しやすい形で、簡単に利用できるようにすると、チームにも浸透しやすくて良いのではないかと感じています。
この記事を見た方のお役に立てれば幸いです。

この記事が気に入ったらサポートをしてみませんか?