ZubeとGitHubの組合せはプロジェクト管理の相棒的存在な話

はじめに

こんにちは、CTOの大神です。Confitの開発では主にプロジェクトマネージャーを担当しています。アトラス内の開発は継続して複数のプロジェクトを同時進行しており、プロジェクトマネージャーは複数のプロジェクトを並行して担当しています。
1人のプロジェクトマネージャーが複数のプロジェクトを並行してプロジェクト管理しているので、タスク登録や進捗確認などの作業は、より手間が少ない方が望ましいです。

また、プロダクトのソースコードはGitHubで管理しており、タスク管理もGitHubのIssueで管理しているので、Issueに機能仕様や改修の目的などを記載することで、プロダクトに関する全ての変更は、Issueとソースコードを関連付けして管理しています。
プロダクトの変更管理は上記のやり方で良い状態になっていますが、アトラス内では150以上のリポジトリがあり、GitHub Issueはリポジトリ単位にIssueを登録するので、変更対象のリポジトリにそれぞれIssue登録していくのは、とても手間がかかります。

これらの課題を解決するために、現在はGitHub IssueのマネジメントサービスであるZubeを使用することで、複数のGitHubリポジトリを1プロジェクトとして管理しています。さらに開発プロセスに沿った進捗管理などもできるので、プロジェクトマネージャーの手間は大幅に軽減されています。
今回は、GitHubとZubeを利用したプロジェクト管理を紹介します。

Zubeとは

ZubeはGitHub Issueのマネジメントサービスです。
アジャイル開発のプラクティスをサポートする機能があり、ユーザが登録したプロジェクトにGitHubのリポジトリを登録することで、Zubeの1プロジェクトで複数のGitHubリポジトリのIssueを管理できます。
アトラスでは、Zubeを2016年ごろから利用していて、Zube自身の進化もありますが、アトラス内での使い方もあわせて進化しており、プロジェクト管理の相棒的存在になってます。
Issueに関することやIssue対応後のコードレビュー時は、Zube上でのコメントもGitHubのコメント機能で一元管理されるので、開発に関するコミュニケーションも円滑に進められます。

プロジェクト管理で実現したいこと

GitHubを利用することで、Gitリポジトリの管理やIssueの改修フローにコードレビュー必須とするなど、それだけで多くのメリットがありますが、プロジェクト管理するうえで以下のことを実現できるようにしています。

• プロジェクト管理の本質的ではない事務的な作業は極力なくすこと
• プロジェクト内の作業タスクを一元管理できること
• 開発チーム内のプロジェクトを横断してタスクを管理できること
• スプリント単位(チーム内の1つの作業期間単位)やマイルストーン単位（プロダクション反映する機能拡張の単位）でも進捗管理できること
• システムへの全ての変更を追跡・調査できるようにしておくこと

プロジェクト管理

プロダクト管理のプロダクトバックログから、開発に着手する機能拡張をZubeに登録してプロジェクト管理を開始します。プロダクト管理はエンジニア以外の社内のメンバーとも共有しているので、Notionを利用しています。プロダクト管理については、「Notionでプロダクト管理すると情報共有のための手間が減って開発に集中できるようになった話」に記載してますので、ご参照ください。

プロジェクト管理の流れ

プロジェクト管理での実施項目は数多くありますが、GitHubとZubeでのプロジェクト管理の主な流れは下表の通りです。

No.	実施項目	実施時期	内容
1	Epicの登録	プロジェクト開始時	プロジェクト管理開始時に機能拡張単位にEpicを登録して管理を開始します。
2	Issue登録	主にプロジェクト開始時	Epicに機能拡張対象の開発対象のIssueを登録します。
3	スプリント計画会議	毎週	プロジェクトメンバー全員で先週の進捗と今週の実施タスクを計画します。
4	進捗状況確認	随時	プロジェクトの進捗状況をEpic単位、全プロジェクト単位などの視点で確認します。

Epicの登録

ZubeにはEpicという機能があり、Epicとはプロダクトバックログの1つの機能拡張項目を指します。プロジェクトで開発する機能の開発目的や全てのドキュメントを機能拡張情報としてEpicに登録します。

EpicにIssueを登録

Epicに作業単位のIssueを登録します。プロジェクトで開発対象とするIssueをEpicに登録することで、Epic単位でIssueを確認できるようになります。
ZubeでIssueを登録する際に、GitHubのリポジトリを選択して登録すると、実際にGitHubにIssueが登録されます。複数リポジトリの作業項目でもZubeでは1プロジェクトとして扱うことができます。
リポジトリに関連付かない要件定義や仕様書作成などの、プロダクトを改修しないタスクは「Only on Zube」を選択するとZube内にIssueを登録できるので、リポジトリに関係ないIssueをGitHubに登録せずに済みます。

スプリント計画会議

Epic担当のプロジェクトマネージャーと開発担当のエンジニアが週1回の計画会議で、前週のIssueの対応状況と今週対応するIssueをZubeのSprint機能に登録して、次週の進捗を確認します。

先週対応したIssueと今週対応予定の計画

アトラスではスプリントは1週間単位に設定して、今週作業予定のタスクを「Milestone」レーンからスプリント内の「Ready」レーンに移動させます。次回のスプリント計画会議で先週の作業の進捗状況と今週の作業タスクを決めることをプロジェクト完了まで繰り返します。

プロジェクト内の課題管理

開発中に出てくるプロダクトの課題などはGitHubのIssueに「00.課題」ラベルをつけて登録しておくことで、対応方法や実施時期を決めて対応します。
課題もプロダクトの変更が伴うケースが多いのでIssueで管理します。

進捗状況確認

Zubeでは複数のビューでGitHubのIssueの状況を確認できるので、必要に応じてビューを切り替えて進捗状況を確認します。スプリントのビューでスプリント計画を確認する以外にも以下のビューで、簡単に確認できます。

EpicのIssueのタイムラインでプロジェクト状況を確認

プロジェクト単位の稼働状況の確認は、Epicのページにタイムラインが表示されるので、Issueのステータスが変更されたり、新たなIssueが登録されたりなどの進捗状況をリアルタイムに確認できます。

カンバンボードでのEpicのIssueの進捗確認

Epic内の全Issueの進捗状況は、カンバンボードのFiltersでEpicを絞り込んで全体の対応状況を確認したり、アサインしたメンバーで絞り込みして確認したりします。必要に応じてタスクのアサインを変更します。

Epic全体の進捗状況確認

Epicはカンバン形式で表示され機能拡張項目単位に進捗状況を管理でき、Epic内のIssueの進捗状況もプログレスバーで確認できます。
ここで、マイルストーン（複数のEpicのリリース単位）毎にリリース対象の全てのEpicの進捗状況を確認しています。

変更管理

他プロジェクトでの同一機能の変更状況やプロダクション環境で不具合があった場合や、変更状況、不具合原因、変更時期など、全てこの機能で調査できます。
ZubeのIssueManagerを利用すると、フィルターでマイルストーン単位のIssueを確認したり、キーワード検索で「参加登録」など検索すると、参加登録機能関連のIssueを絞り込めたりします。
IssueManagerはIssueの一括更新にも対応しているので、一括で複数のIssueのマイルストーンを変更したり、完了したIssueをアーカイブしたりできます。プロジェクト管理とは直接関係ない登録作業や更新作業は手間なく完了できます。

まとめ

GitHub+Zubeの組合せで利用する以前は、登録・更新・進捗確認の手間が多く、時間がかかっていました。プロジェクトマネージャーは並行して多くのプロジェクトを担当するので、プロジェクト管理以外の登録や確認の作業が手間なく簡単に完了できると、本来の管理業務に集中できるようになり、ストレスも軽減できます。
GitHubにはコーディングやコードレビューのための機能も多く、恩恵を受けていますが、プロジェクト管理もZubeと組み合わせることで、多くのことが効率化されます。
同じようにプロジェクト管理の本来の管理以外の作業の手間に困っている方がいれば、Zubeはおすすめです。