自称日本一GitHub Projectsを使っているのでどう使っているか紹介する

こんにちは。

自称日本一GitHub Projectsを活用している CEO兼VPoEの小笹です。
本稿では、株式会社アンチパターンにおいて、実際にどのようにGitHub Projectsを使っているのかについて共有させていただきます。

■目次

何故GitHub Projectsなのか
ISSUEラベル
イテレーション
Workflows
ビュー
Task lists(親子ISSUE)
マイルストーン
ISSUEテンプレート
Insights
今後やれるといいなと思っていること

何故GitHub Projectsなのか

ソースコードの管理と同じプラットフォームでネイティブに連携していること
複雑な要求に応えようとすると管理も複雑になるが、機能がシンプルなため思考の制限がかかってちょうど良かったから
定期的にアップデートがあって今後も期待できる

上記理由からGitHub Projectsをどこよりも活用してみるぞ！という意気込みで頑張りました。

ISSUEラベル

まずは基本となるラベルの設計です。

開発対象ラベル

フロントはモノレポになっていたりするので、 どの画面 かをラベルにしています。
APIは外部公開用と 外部向け を使って作られた 内部向け のAPIがあります。
加えて、OpenAPI定義 をするタスクもラベルで判断できるように設定しておきます。

サイズラベル

ISSUEは作る際にある程度のざっくり感でサイズを付与します。
これは S/M/L とあり、それぞれ1/4/8ポイントとして集計する際に利用します。
またサイズをつけるにあたり、S/Mサイズになるように意識してもらうようにしています。
※ポイントの集計よりこの分割への暗黙的な圧力のほうが効果的な気もしています。

アサインラベル

非同期で働きやすくするために対応するメンバーが決まっているものは担当をアサインしますが、そうでないISSUEには anyoneラベル を付与していつ誰がとっても良いようにしています。

資産計上判断ラベル

SaaSはソフトウェアを通じて収益を得ているという構造があるため、無形資産として計上する必要があります。
そのISSUEが 保守対応 なのか 新規機能開発 なのか判断しラベルを付与するようにしています。
http://kato-cpafirm.com/audit/files/No12-RD20141128.pdf

ISSUE種別ラベル

親ISSUE で 子ISSUE があるものか 独立したものか 、バグかを判別するためのラベルです。
これは主にあらゆるビューでフィルタする際に活用するものです。

このようなイメージです。
github-projects2023-01

イテレーション

1週間で区切っています。

当社の場合、副業のメンバーも多く、時間的に固定のコミットができないケースが多いため、Scrumではなく、カンバンに近い運用をしてアジャイル開発を実現しています。

1週間ごとにCloseしたISSUEに対してイテレーションを付与しています。つまり完全に実績ベースで活用している形になっています。

Workflows

Auto-archive itemsをアクティブにしています。
60日以上前にCloseされたISSUEはアーカイブされていきます。

アーカイブされるとビューやInsightsからも見えなくなるのですが、
それくらい前のものであれば特に影響ないなと思っています。

ビュー

カンバンビュー

作業の流れを見る際に使います。

リストビュー

任意の項目に値を入れたり、親ISSUEに紐づいた子ISSUEの状況を可視化しています。
このリストビューにおいてPoint列を追加しています。
これはISSUEの総量を定量的に可視化するために使っています。
サイズラベルをもとにそれぞれ1/4/8ポイントとして集計する際に利用します。

ロードマップ

本来的にはリリースターゲットなどの日付を入力し、将来に目を向けその進捗を追うのに活用するかと思うのですが、
当社では実績の管理に応用しています。
「ISSUEがCloseしたイテレーションの日付」から「リリースされた日付」をマイルストーンで可視化することで、
Closeされてからリリースされるまでの期間を可視化することができます。
この辺はDORAメトリクスなどを取っていけば、見る必要もなくなるかもなと思っていますが、今はまだ計測し始めていないので簡易的に見ている状況です。

github-projects2023-02

Task lists(親子ISSUE)

https://docs.github.com/ja/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists

これを活用することで親子ISSUEをトラッキングすることができます。
親は子ISSUEが紐づいて閲覧でき、子は親がどのISSUEか閲覧できます。
これはビューでも可視化できるのでとっても強力な機能になっています。

ISSUEの詳細はこちらです。
github-projects2023-06

カンバンビューだとこういった形で見ることができます。
github-projects2023-01

リストビューだとこういった形で見ることができます。
github-projects2023-07

マイルストーン

リリースの目標を管理しています。
目標バージョンごとに付与していきます。
これをリストビューで可視化することで、マイルストーンごとにどれくらいのポイントがかかるか分かります。
イテレーションごとのポイントの総計が分かっていますので、凡そのリリース時期を把握できます。

github-projects2023-05

ISSUEテンプレート

今までご紹介したようなラベルなどをフルに活用するためには、
ISSUEに十分な情報を記載されメンバーレベルでラベルの判断がつけられることが望ましいです。
なので、ISSUEのテンプレートを作成しました。ざっくり下記のようなイメージです。

機能開発
- 親ISSUE(parent / independent)
  - ユーザーストーリー
    - 誰として
    - 何をしたい
    - 理由
  - 期待される事業効果
    - 保守
    - 新規開発
      - 期待される収益
  - 受け入れ条件
  - 実装する上で考慮しておいて欲しいこと
  - ラベルを付与したか
  - 子ISSUE
  - 関連ISSUE
  - 関連リンク(Figma / Miro / Slackスレッド / Google Drive)
- 子ISSUE
  - 何をするのか
  - 何故か
  - 受け入れ条件
  - 実装する上で考慮しておいて欲しいこと
  - ラベルを付与したか
  - SizeについてなるべくS or Mに細分化するように注意文を追記
  - 親ISSUE
  - 関連ISSUE
  - 関連リンク(Figma / Miro / Slackスレッド / Google Drive)
バグ
- 何が起きたか
- どこで起きたか
  - アカウント
  - ユーザー
  - テナント
- どの画面 or API/SDK
- どうやって起きたか
- エラーログやキャプチャなど証跡
  - ない場合には正確な発生時間
- 何が問題でどうなることを期待していたか
- 環境情報

Insights

Burn up / CFD

作成されているISSUEとCloseしているISSUEの傾斜を大体把握できます。　　
作成されているISSUEの方が進みすぎると、ISSUEの作りすぎ、待ちの無駄になります。　　
Closeしていくほうが進んでしまうとプロダクトマネジメントでボトルネックになり、開発者の時間的待ちの無駄が発生します。

github-projects2023-03

ベロシティの可視化

イテレーションごとのポイント総計を集計し可視化しています。　　
ベロシティは未来の予想に使うもので評価などに使うものではないですし、細かいレベルで追っていく必要はないと考えています。　　
上がったり下がったりの理由は振り返って何が原因かはディスカッションします。　　
例えば、レビュー待ちの滞留が多い、Lサイズが大きすぎた問題、リリース前でみんなでテストしていたなどがあったりします。

github-projects2023-04 !

今後やれるといいなと思っていること

DORAメトリクスを計測したり、レビューが滞留していたらレビュアーにメンションするなどができるといいかなと思ってます。
何にせよ開発者体験を向上できるようにしていきたいと思っています。

調べているのはこういったSaaSです。
https://www.usehaystack.io/
https://linearb.io/

最後に

GitHub Projects最高！！
ミナサンもGitHub Projects最高と叫びなさい！！

こちらからは以上です。