ZenHubからGitHub Projectsへの移行検討と試験運用

はじめに

移行検討の背景

所属している開発チームでは、プロジェクト管理ツールとしてZenhubを利用しています。
Zenhubはスクラム開発の中で使いやすいツールですが、有料（ドル換算）のサービスであり、ユーザー数に応じて費用が発生します。
Github ProjectsはGitHubに統合されている無料のツールです。
移行を検討することで以下のようなメリットが考えられそうです。

1. コスト削減: Zenhubの利用料金を削減し、予算をより重要な領域に再配分ができる可能性がある
2. ライセンス管理の簡素化: 別途のライセンス管理が不要になり、管理コストを削減できます。
3. 長期的な安定性: GitHubの標準機能を利用することで、長期的なサポートと継続的な機能改善が期待できる

Zenhubの利用調査

アプリケーションチームが各機能毎に4チームに分かれて開発をしています。
各チームのワークフローや利用頻度の高い機能には共通点と相違点がありますが、全体的な傾向としてZenhubの多様な機能を効果的に活用していることが分かりました。

各アプリケーションチームのワークフロー調査

チーム共通で2週間のスプリントを採用しており、基本的なスクラムの流れ（スプリントプランニング、デイリースクラム、スプリントレビュー、振り返り）に沿って開発を進めています。
チーム間で若干の違いはありましたが、以下の様な共通点がありました。

1. スプリントプランニングとバックログリファインメント

   • Epicの作成と管理
   • イシューの見積もり（Estimate設定）
   • プランニングポーカーの活用
   • スプリントバックログへのイシュー割り当て

2. スプリント期間中の進捗管理

   • Boardを使用した日々の進捗確認と共有
   • イシューステータスの更新
   • GitHubのPull Requestとイシューの関連付け

3. 振り返りと計画

   • Velocity Reportの確認（利用頻度は各チームで異なる）
   • 次スプリントの準備

Zenhubの主要機能の利用状況

各チームで利用する機能をまとめると以下の様になります。

1. 高頻度で利用される機能
   • Board: 進捗の確認で日常的に利用している
   • Epic:大きな機能開発の管理に利用している
   • イシューの見積もり（Estimate）: スプリントプランニング時に利用している
   • Velocity Report: 振り返りなどで利用している
   • スプリント管理: スプリントの設定と管理に使用されています。
2. 中程度の頻度で利用される機能
   • プランニングポーカー:チームによって使用頻度が異なる
   • イシューの依存関係: Aチームで主に活用している
   • ロードマップ: 一部のチームで活用している

Zenhubの多くの機能が効果的に活用されていることが分かりました。
特にBoard、Epic、見積もり機能が開発プロセスに深く組み込まれていることが分かりました。
これらのことを考慮してGitHub Projectsへの移行を検討を進める必要がわかったので、
次のプロセスに進んでいきたいと思います。

GitHub Projectsの機能調査

ZenhubからGitHub Projectsへの移行を検討するにあたり、両者の機能を比較し、
チームのニーズに対する代替手段を検討しました。

ZenhubとGitHub Projectsの機能比較

共通点

1. ボード機能: 両システムともカンバンボードスタイルの視覚的なタスク管理が可能です。
2. GitHub連携: どちらもGitHubとの緊密な統合が可能で、issueやPRとの連携ができます。
3. カスタマイズ性: パイプラインの追加・変更・削除、ラベル管理など、柔軟なカスタマイズが可能です。

相違点

1. Epic管理: Zenhubではネイティブサポートがありますが、GitHub Projectsではカスタムフィールドやラベルで代替する必要があります。
2. プランニングポーカー: Zenhubの標準機能ですが、GitHub Projectsには組み込まれていません。
3. Velocity Report: Zenhubでは詳細なレポートが利用可能ですが、GitHub Projectsでは限定的な代替手段しかありません。
4. 依存関係管理: Zenhubではissue間の依存関係を明示的に設定できますが、GitHub Projectsでは標準機能としては提供されていません。

Zenhubで使用する機能の代替手段の検討

代替可能な機能

1. ボード管理
   • GitHub Projectsでもパイプラインの追加・変更・削除が可能で、ラベル管理も柔軟に行えます。

2. issueのEstimate設定
   • Number型のカスタムフィールドを使用して設定可能です。
     • ※Zenhubでは選択だったので若干使用感が変わります

3. Sprint設定
   • Iteration型のカスタムフィールドを使用して設定可能ですが、ZenHubと比べて機能が限定的です。
   • 手動でのSprint追加が必要で、複数Sprint設定はできません。
   • 未完了issueの自動移行機能はないため、手動での管理が必要になります。

Settingsからカスタムフィールドを追加

イシューに設定する

5. ロードマップ
   • Epicをラベルで設定し、表示をフィルタリングすることで代替可能です。
   • マイルストーン機能を活用して、プロジェクト管理を行うことができます。

代替困難な機能

1. プランニングポーカー
   • 標準機能では対応していないようでした。
     • コメントを使用した代替方法を検討する必要がありそうです。
     • team-pokerなどのツールも取り入れる必要もありそうです。

コメントで対応する場合はこのように入力してメンバー内で話す方法が考えられます

2. Epic管理
   • カスタムフィールドやラベルを使用して代替可能です

ラベルで設定する場合は、子イシューのリンクをを追加します

boardでも確認は可能です

カスタムフィールドでEpicを設定した場合の親子関係はboardのGroup byを設定することで
確認が可能そうです。
完了したEpicが表示される為、どうるかを考える必要がありそうです。

移行シミュレーション

まずは試験的にチームで運用を開始しました。
スクラムイベントを通して、使いづらい点があるかどうかは
レトロスペクティブを通して改善をしていくようにします。

開発プロセスの中で、大きな問題はありませんでしたが、
Velocity Reportの機能の代替は難しそうです。
プロジェクトではFindy Team+を利用しているため、代替として活用できそうでした。
こちらはまた別の機会に書こうと思います。

まとめ

ZenhubからGitHub Projectsへの移行検討を通じて、コスト削減と機能の最適化の可能性が明らかになりました。GitHub Projectsは多くの基本機能を提供しており、カスタマイズによってZenhubの主要機能の大部分を代替できることがわかりました。

プランニングポーカーやVelocity Reportなど、一部の高度な機能については完全な代替が難しい状況です。移行にあたっては、これらの機能の重要度を各チームと再確認し、必要に応じてワークフローの調整や追加のツール導入を検討を進めていくのが良さそうです。