GithubのProject(Beta)を本気で使ってみた(+考えてみた)
お詫び
Qiitaの元記事にて、区切り線を「---」で書いている場所があり、これがZennの記法に干渉して一部うまく表示できない記事がある事を認識しています。
全ての記事を精査しきれていないため、お手数ですがお見かけの際は教えていただけると大変喜びます。
最初に
どこかのアドベントカレンダーに使って欲しいので、ご提案・ご相談募集中です。
個人的には結構良質なノウハウが得られたと思っていますので、記事または実際に運用中のプロジェクトをご覧になっていただいて、よかったと思ったらぜひお声かけいただけると嬉しいです。
結論
- Githubで完結させるという意味であれば非常に便利
- 既存のマネジメントツールの代替となるかは微妙なところ
- 実務に取り入れるべきではない（Beta版なので、正式リリースされたりされなかったりするリスクもあるし、この記事がそのまま使えない可能性もある）
Github Project(Beta)とは
Beta機能はさておき、Github Projectを使っている人が読者の対象になりますので、Github Project機能を知らない人はまず使ってみましょう。
個人開発者の方向け
Issue書いたりPR出したり、といった本来のGitの用法をあまりやらない人がほとんどだと思います。私もそうでした。
が、昨今Githubアカウントで就活・転職する方（またはエージェント）も多いので、ご自身のGithubアカウントは充実させておいたほうが良いです。
Qiitaでどんな記事を書いて、どういう層からリアクションがあって、というお話を面接官にするのも良いですが、そこに至るまでにどういった事があったのか、の方が（私が面接官であれば）興味が惹けるので、Qiitaでドキュメンテーションする前に、Githubを実践的に使ってみてスキルアピールする事もお忘れなく！[1]
今までのProject機能と比較する
ここからは使っている方向けのお話になります。
一言で
従来のProject機能はそれぞれのリポジトリで使いやすかった印象がどうしても拭えませんでしたが、今回のBeta版の対応によって、リポジトリを横断するプロジェクトの管理がしやすくなり非常に好印象です。
しっかり比較
- リポジトリではなく、ユーザーに紐づいたプロジェクトであるため「あのプロジェクトはどのリポジトリだっけ？」といったような状況に陥らなくなった
- 既存のプロジェクトもそのまま使えます
- 既存のプロジェクトはボード形式（看板）のみ表示できたが、テーブルで一覧できることでより多くの情報がぱっと見で得られるようになった
- 【激アツ】検索機能やフィルター機能が強化され、ステータス（カラム）やフリーワード以外にもアサイン・ソートに対応した
- カラムの自動設定はPresetで設定できる内容に制限されていたが、制限がなくなって自由に使えるようになった
と、自由度が非常に高くなった印象です。
使ってみた
まずカラムは以下の通り作成しました。
以下のような運用を想定しています。
| カラム名 | IssueのOpen/Close(PR時は使わない) | 投入される条件 | 自動or手動 | カラムを見るべき人 | 必要な作業 |
|---|---|---|---|---|---|
| [Issue/PR]検討/振り分け中 | Open | Issue/PRを起票した時[2] | 自動 | Issue:スクラムマスター[3] / PR:起票者 | スクラムマスターはIssueがタスクかバグか保留か判断し振り分ける |
| [Issue]タスク:優先度中 / [Issue]バグ:優先度高 | Open | スクラムマスターがIssueをタスクかバグか、優先度などを考慮し振り分ける[4] | 手動 | 開発チーム(アサイン者) | 開発しPRを出す |
| [PR]レビュー依頼 | - | 開発を行いPRを出し、「検討/振り分け中」のPRを移動させた時[2:1] | 手動[2:2] | レビュアー(アサイン者) | レビュー |
| [PR]差し戻し | - | レビュアーがRequest changesを出した時 | 自動 | レビュイー(アサイン者) | 修正後、手動でレビュー依頼に戻す |
| [PR]レビューOK | - | レビュアーがapprovedを出した時 | 自動 | スクラムマスター | mergeする |
| [Issue]完了 | Close | IssueをCloseした時[5] | 自動 | プロダクトオーナー | ステークホルダーに報告できるようにする |
| [Issue]保留:優先度低 | Close | 対応者が移動させた時 | 手動 | プロダクトオーナー | 必要に応じて検討に戻す |
| [Issue]不対応 | Close | 対応者が移動させた時 | 手動 | プロダクトオーナー | なぜ不対応なのかヒアリングする |
| [Issue]検索用/Project | Close | (後述) | 手動 | 誰でも | 基本的にさわらない |
※ここでは説明を簡略化するため、テストを考慮していません。(後述)
検索用のカラム(ステータス)について
これはProject画面で見た検索ではなく、リポジトリから見た検索の話です。
本来、リポジトリでIssueツリーを作りたい場合はリポジトリにProjectを作って個別で管理すべきですが、ユーザープロジェクトとリポジトリプロジェクトは完全に独立してしまい管理が煩雑になりかねません。
従って、「プロジェクト画面で見たときは何も意味はないけど、必要なIssueがある」ことを明示するために検索用カラム(意味のないステータス）を追加しました。
これにより、
- プロジェクト画面で関連するIssueを検索したい場合: 検索用カラムを見る or 検索機能を使う
- リポジトリのIssue画面で関連するIssueを検索したい場合: Project画面へ遷移して↑をする
という措置が取れます。
（ただし、意味のないIssueが一つ増えてしまうという問題があるので、ある程度容認する必要がありそうです。
→解決策として、検索用に作ったIssueはすぐにCloseしてしまい、とはいえ見えなくなったら困るのでピンしておくといいと思います。
例： is:openを表示しているのに、クローズしたIssueが目立って見えるようになっている
テストを考慮したProjectを設計する場合
私も色々やってみたんですが、開発とは別のプロジェクトを立てて、それぞれのIssue/PRを割り振った方が良いかもしれません。
既存プロジェクトにテスト用のカラムを追加して運用する方法もありますが、開発の完了とテストの実施（テストNGだった場合も）は扱いが異なると思います。
なので、開発でCloseしたPRをReopenして、テストの根拠を示すIssueなりをリンクさせる方がわかりやすいように思います。
この辺りは実際にチーム内で活用してみてからの話になると思いますが、今現在運用されているマネジメントツールを捨ててまでGithubProjectを使うメリットがあるかは分かりません。
総評
- Githubで完結させるという意味であれば非常に便利
- 既存のマネジメントツールの代替となるかは微妙なところ
- 実務に取り入れるべきではない（Beta版なので、正式リリースされたりされなかったりするリスクもあるし、この記事がそのまま使えない可能性もある）
小ネタ
Project画面でリポジトリの検索ができるので、Issueのタイトルに[リポジトリ名][プロジェクト名]みたいな検索文字列を入れる必要はありません。
が、リポジトリ検索に切り替えるために一手間いるので、面倒くさくなってIssueテンプレートに組み込むことで手間を削減する方法を採用しました。
ちょっとIssueタイトルが見づらいですが、テーブルビューを使えばある程度何とかなるので気にしていません。
注釈
今回、注釈が盛り沢山です。
-
【スキルアピールの仕方】ここでは面接官目線で書きましたが、私はフリーランスなので面接するというよりは「周りにいいエンジニアの人いません？」と相談された時に紹介しやすいぐらいです。 ↩︎
-
【PR出した時の挙動】現状だとIssueを書いた時(Open/Reopen)とPRを出した時(Open/Reopen)のタイミングが同じになってしまっているため、手動対応が必要です。これも切り分けられるようにしてほしいですね。 ↩︎ ↩︎ ↩︎
-
【Issueを起票した時に対応する人】そもそもIssueが妥当なものかを検討する必要があるかも知れないので、プロダクトオーナーも見た方がいいかもしれません。 ↩︎
-
【タスク・バグの対応】看板などをみた時に、この項目に入っているとすぐに作業をしたくなる場合があるので、作業前に誰が対応するのかはしっかりコミュニケーションをとった方がいいです。運用して慣れていったらIssueにアサインするだけの運用でも回ると思います。 ↩︎
-
【IssueをCloseした時の挙動】一つのIssueは一つのPRで解決できれば理想ですが、現実はなかなかうまくいかない事も。その場合は、運用対処として後出しでIssueを書いて流すか、複数のPRを一つのIssueに集める方法があります。 ↩︎
Discussion