🗓️
エンジニアもGitHub ProjectでPMしてみる方法

nogahighland
2024/10/23に公開
プロジェクトマネジメント
githubproject
tech
PMといいつつ、ここでは予算とか工数とか品質まで管理するわけではなくプロジェクト進行を漏れなくやってみるというお話です。

 背景私がFinatextのインシュアテック事業で携わっているクライアント向けの開発では保険クラウドサービスInspireの機能をフルに使った保険商品が販売されており、今後もスピーディな商品展開が行われていきます。既存商品に対しても様々な設定変更・確認依頼が行われつつ新規開発も進行しています。
しかしながら経緯的にこのプロジェクトはPMが配置されていないため、スピードアップする機能開発でエンジニアだけでノウハウを蓄積したり、どうすれば管理コストをなるべく掛けずに取りこぼしを防げば良いかを工夫したりした結果、現在私たちが運用している方法を紹介します。

 既存のGitHub Projectを使用するインシュアテック事業ではIssue専用のGitHubリポジトリが存在し、ここにクライアント案件のIssueを粒度の細かい管理ができるようGitHub Projectで管理する運用を行っています。

 何が複雑なのかクライアントとは毎週1-2時間の定例ミーティングを行い、クライアント提供の以下のようなエクセルを元に要件や開発アイテムの進捗状況を確認し、日々タスクが生まれ消化されています。
日々発生するタスクは、以下のように相互に依存関係がある複数の情報を正確に評価したうえで取り組む必要があります。
商品のサービスイン状況
既存商品か新規商品か両方か

環境
ステージング環境か本番環境か
開発を終えるとステージング環境にデプロイしてクライアントがテスト開始し、その後他タスクに着手すると本番環境への反映に待ちが発生する

実装箇所
Inspireコアなのかクライアント個別対応なのか。
Inspireコアは週1のリリースサイクルがあるが個社はクライアントのタイミングで反映する。両方が混じったタスクもある

いつ必要か
即時か時限式か。サービスイン状況や保険契約の期間によって変わってくる

どの処理に関することなのか
機能や設定値が大小無数に存在する

計画の変更
予め伝えられていた仕様や設計から変更が生じることがある

これらはシステムで取り扱う商品数が少なく、職人メンバー数名で対処しているうちは阿吽の呼吸で対処できるものだと思いますが、開発・運用規模が大きくなってくると変数の掛け合わせ（依存関係あり）の情報量は人間の認知限界を突破してきます。
例えば、いくつかのコンポーネントがセットで反映されることでリリースが完了するべき機能が、どこかがステージング環境までしか上がっていなかったとか、意図せず本番まで上がってしまっていたとかがちょこちょこ発生してしまいます。
他の例としては（発生していませんが）、タスクとして上がった際は必要になるのは先と思っていたが、気がついたら必要な時期が近づいていた、などもありえます。

 どうやってがんばるかそれらをしっかりどのように管理しようとしているか一つずつ紹介します。

 0. 議事録をとるまずはGitHub Project外のことですが、きちんと議事録を取ります。ここでは言った言わないの言質を取る目的ではなく、限られた時間で交わされた情報を取りこぼさず記録するのが目的です。
これによって、以下の材料が残ります。
情報を元に正確にTODOに落とし込む
将来的に立ち返る決定の根拠
試してきた経緯
Slackのスレッド
その場で残していくログ。
他人が書いた文章を編集できなかったり、会話も一緒に残ったりする
最終的な決定事項までは残っていないこともある

Slack Canvas
リアルタイムで同時編集できるので、一つのドキュメントを複数人で書けるようになった
スレッドでポスト間の関連性が複雑化していたのが、該当箇所に肉付けできるようになったので情報のまとまりが良くなった
自然と議事録とそれに関する会話が区別されるようになった

Google Docs
社内のスタンダードな議事録ツールのため、ここに落ち着いた

こんな感じで、本文はGoogle Docsに書きながらプロジェクトチャンネルのCanvasに定例ログを残しています。

 1. GitHub Projectの仕組みを構築するここからが本題ですが、まずは先に述べた複雑性の要因をGitHub Projectで使える属性に分解してIssue/PR一つ一つに属性を付与できるようにし、ひとつひとつのIssue/PRのライフサイクル状態を意味のあるまとまりとして把握できるようにしています。

 ステータスGitHub Projectのステータスはデフォルトで Todo In Progress Done ですが、ここを一工夫しました。


デフォルト
私のプロジェクト





デフォルトの Todo は「いつかやったほうがいい」のか「実施時期が決まっている」のか区別ができていなかったので ReadyToDo を追加しました。

InCodeReview はあまり強い思いは無いですが、レビュー待ちの数がわかると良いかなと思って作りました（workflowで自動でここに入ります）
デフォルトの挙動ではIssueのクローズやPRのマージが Done になってしまっていましたが、これはPRでいうとDEV環境にデプロイされただけで、その後ステージング環境や本番環境へのリリースは管理されていません。実際に、これによって反映がマズりかけてしまったケースがありました。なので、 InDemo と ToRelease を追加しました。
マージしたら勝手に完了するわけではない、ということから Done は手動で明示的に行うようにしました

 カテゴリタスクのカテゴリには具体的なプロジェクト名（≒商品単位）と「調査」「その他運用」のようなプロジェクト横断タスクのカテゴリを作成しました。後ほど出てくるスライス機能で可視化する時に便利になります。

 マイルストーン商品や機能のリリースタイミングを管理するために、マイルストーンを作成し、Issue作成時にマイルストーンに紐づけて管理しています。
商用環境で実際にユーザーに影響する日をマイルストーンの期日にし、マイルストーンの詳細にはInspireへのステージング環境/本番環境への反映日時などを記載する運用をしています。
ステージング環境/本番環境反映用にマイルストーンを切る作業が煩雑だったため簡略化して今に至ります。
リリース準備時には、マイルストーンに消化したタスク一覧から他に漏れが無いかなど確認を行うことができます（ ToRelease のstatusで絞れば同じかもしれません）

 Workflowを設定するGitHub Projectへの追加とか、ステータスを変更する面倒な作業をできるだけ減らします。
IssueリポジトリにIssueを作成すると、勝手にGitHub Projectに追加される
PRや他のagoraのIssueは追加されないので要手動対応

PRがオープンすると InCodeReview に入る
PRがマージされると InDemo に入る
Doneは4週間以上経つとアーカイブされる
ステータスを DoneにするとIssueがクローズされる
Issueのクローズは、必ずしも完了状態ではないのでステータス変更しない

 Issue/PRに情報を紐づける自分で言うのもなんですが、正直面倒です。
タスクが発生したらやっちゃってクライアントに連絡したら早いときもあります。けど、それでは知見が溜まらないし、頭で管理してるつもりでいてあとで取りこぼすより100倍マシかなと思っています。目先のラクより後のラクをとるつもりで。
gh issue create でIssue作成画面を開くワンライナー
bin/create-issue.sh
#!/usr/bin/env bash

template=${1:-.github/ISSUE_TEMPLATE/general.md}
gh issue create \
  -b "$(cat ${template})" \
  -p 'project-name-1,project-name-2' \ 
  -a @me \
  --web
また、調査状況や検討状況をSlackスレッドだけではなくIssueに残すように推奨しています。Slackにメモするのは手軽で便利ですが、あとから探す人にとっては情報が断片化されているのがSlackにメモする上での弱点だと思うので、ある程度のまとまりが出てきたあとはIssueにまとめるのが良いのではないかと思っています。
背景・期日・機能要件・実装要件などをまとめているのが下記の例です。
ここまでで整備した各種属性はその特定要素を選ぶ手間をなくし、素早く詳細な情報にたどり着くことができます。

 2. GitHub Projectを運用するただのIssueの羅列だけとは違うのがGitHub Projectです。ここまでで（面倒な思いをして）付加した属性を意味のあるまとまりとして多角的に確認することができるようになりました。
このように管理できるようにしておくと、開発規模が大きくなってきても情報をマクロでもミクロでも把握できるようになります（ちゃんとIssueに設定・記載すればですが！）

 ロードマップビューロードマップビューはこんな感じです。どんなタスクがいつまでにあって、誰が担当していて、そのうちどれが終わっているのか/終わっていないのかがひと目で分かります。
ロードマップビューには以下のような設定項目があり、情報のまとまり Group by や左カラムのワンクリックのフィルター（ Slice by ）などが設定できます。
設定は固定しなくても、自分の手元で見たいビューを一時的に見たり（右上のSaveを押さなければ他人のビューには反映されない）、新しいレビューを作ればよいので柔軟に色んな角度からタスク一覧を俯瞰できます。

 カンバンビューこちらはステータスだけに特化したビューです。あまり使ってないですが、縦の長さで積み具合がわかりやすいので、今後もうちょっと使っていっても良いかもと思いました。

 まとめ事前の情報整理
情報量が多いクライアントとは、議事録をしっかり取る

GitHub Projectの整備
ステータス（Backlog, ReadyToDo, Doing, InCodeReview, InDemo, ToRelease, Done）
カテゴリ（商品別、または商品横断）
マイルストーン（リリース日を期日に設定し、中身に細かい日程を書く）
担当者
（開始日、終了日）
Workflow

Issue/PRに上記属性を紐づける
複雑な情報はIssueにまとめ、GitHub Projectから探しやすくする

日常的にステータスをチェックし、漏れないようにする
目先のラクより後のラクをとる