GitHub Projectでプロジェクト管理

最近は急に寒くなったり暑くなったりで、年々季節がおかしくなっている気がしていますが皆さんはどうでしょうか。

先日GitHubがリリースした新しい機能「Project」を弊社でも使用しています。
以前まではタスク管理にCode treeを使っていましたが、コード管理やチケット作成はGitHubで行っており、タスク管理もGitHubで出来るならもっと幸せになれるんじゃないかということで、早速利用することになりました。

弊社での使い方

弊社ではタスク管理はすべてGitHub上で行っています。
タスクをIssueとして登録し、そのIssueを解決するPull Requestを作成し、masterブランチにPull Requestをマージしていく、という開発フローです。
中長期的なゴールはGitHubのMilestonesで設定し、1週間毎の短期的なゴール設定の為にProjectを利用しています。

手順としては下記のようなフローです。

1. 各週毎のProjectを作成
2. 次週に取り掛かるIssueを決める
3. Issueに紐づくPull Requestを作成
4. ProjectにPull Requestを登録

※ 2, 3, 4を毎週末に行う。

UIもシンプルでGitHubっぽくていいですね！

現在は上記の運用をしているのですが、この運用を開始する時にプロジェクトチームでミーティングを行いました。
その際に、ProjectにPull Requestを登録するのかIssueを登録するのか、という議題が上がり、どちらがいいかで議論しました。

その時は、1週間ごとのタスクを週の初めや前週末に登録するので、すべてのPull Requestを作成して登録するわけではないので「Pull RequestをProjectに登録する運用」でいく、となりました。
しかし、最近Issueを登録したほうがいいんじゃないかなと個人的には思うようになってきました。

というのは、1週間毎のタスクを登録しているだけだと、中長期的なゴールに対してスケジュール通りに進んでいるのかが分かりづらいかな、と思ったからです。
中長期のゴール(Milestonesで設定)に対するIssueは、キックオフ時にすべて作成されているので、そのIssueを各週毎のProjectに落としこみ、週毎にスケジュール通りに進んでいるか確認したほうが、全体的に遅れが出ているのかスケジュール通りにいっているのかが分かりやすいかなと思いました。

Issueの規模が大きいタスクなどの場合は、子Issueを作らずに直接子Pull Requestを作って開発をしたりしていたのですが、その運用だと子Issueを作成しなければならないので多少煩雑さは増えるかもしれませんが。。

その他、Project機能への要望

これはみんな思っていることかもしれませんが、Projectとラベルと連携し、Pull RequestやIssueでラベルを変更した時などに、Projectの「In Progress」から「Review」に自動に移動してくれたらいいなぁと思っています。
IssueやPull Requestのラベルを変更する度にProjectのほうでも移動させないといけないので、毎回手間だなぁと思っています。
まだ始まったばかりの機能なので、今後の改善に期待しています。

まとめ

GitHubはUIが良くてすごい使いやすい大好きなサービスです。
今回のProject機能もどんどん改良されていってもっと使い勝手がよくなって欲しいです。
GitHubのProject機能は使い始めたばかりなのでこれからも試行錯誤していきますが、よりよいプロジェクト管理が出来るようにもっと良い方法を考えていきたいなぁと思います。

デロイト トーマツ ウェブサービス株式会社(DWS)

デロイト トーマツ ウェブサービス株式会社はアマゾン ウェブ サービス（AWS）に 専門性や実績を認定された公式パートナーです。