🗒️

ZenhubからGitHub Projectsに移行した話

7tsuno

2024/10/09に公開

ZenHub

GitHub Projects

tech

 TL;DR大体のことはGitHub Projectsでもできる
スクリプトを組まなくてもパワーで移行できる

 なぜ移行を検討したのかZenhubからGitHub Projectsに移行を検討したのは、以下の理由からです。

 GitHub Projectsがアップデートで使いやすくなったことGitHub Projectsは最近のアップデートにより、カスタムフィールドや柔軟なボードビュー、SubIssuesなどが追加され、使い勝手が大幅に向上しました。これにより、Issueの管理や進捗の可視化がより簡単に行えるようになり、ワークフローに適したプロジェクト管理が可能になりました。

 Zenhubのコストを削減できることZenhubを利用し続ける場合、個人単位でコストが発生し、チーム規模の拡大に伴いコストも増加し、ライセンス管理が煩雑になるという課題がありました。具体的には、ライセンスの追加や削除の際に都度手動で調整が必要で、利用者の増減に応じた管理が煩雑でした。また、各メンバーごとにライセンスを追跡し、利用状況を把握する手間が大きな負担となっていました。その点、GitHub ProjectsはGitHubの標準機能として提供されているため、追加費用が不要であり、コストと管理負担の軽減が期待できます。

 GitHubの標準機能であることGitHubの標準機能を利用することで、将来的な変更や他ツールとの統合が容易になります。例えば、CI/CDツールとの連携がスムーズに行えるようになり、リリース管理が効率化されることが期待されます。

 Zenhubで利用していた主な機能とGitHub Projectsでの代替手段の調査ZenhubからGitHub Projectsへの移行を進めるにあたり、移行によって業務に支障が出ないよう、現在使用しているZenhubの各機能がGitHub Projectsでどの程度代替可能かを詳細に調査しました。

 Zenhubで利用していた主な機能Zenhubを利用していた際には、以下のような機能を活用してプロジェクトを管理していました。

ボードビューでのIssue管理: IssueをPipelineを利用し「To Do」「In Progress」「Review」「Done」といったステータスに分けて管理していました。

エピックの管理: 大規模なIssueをエピックとして設定し、その中で細かなIssueに分割することで、全体の進捗を追跡していました。

ストーリーポイントとスプリントの管理: 各Issueにストーリーポイントを割り当て、スプリント単位での進捗管理を行うことで、チームの作業負荷や進捗を可視化していました。

複数プロジェクトのIssueを一つのボードで管理: Zenhubでは複数のプロジェクトのIssueを一つのボードに集約して管理していました。

 GitHub Projectsでの代替GitHub Projectsでも、上記のZenHubの機能であれば代替できます。
ボードビューでのIssue管理: GitHub Projectsでは柔軟なボードビューを設定でき、カスタムフィールドを使って「To Do」「In Progress」「Review」「Done」といったステータスでIssueを管理できます。

エピックの管理: GitHub Projectsでは「sub-issues」という機能を使って小Issueを管理することができます。「sub-issues」は組織向けのオプトインベータ版の機能です。詳しくは、公式ドキュメントを参照してください。
複数プロジェクトのIssueを一つのボードで管理: GitHub Projectsでも、複数のリポジトリからIssueを集約し、一つのボードで管理することが可能です。これにより、チーム全体のIssueを一元的に把握できるようになっています。
ストーリーポイントとスプリントの管理: ストーリーポイントとスプリントもGitHub Projectsのカスタムフィールドを利用して設定し、管理することが可能です。

 移行の手順
 GitHub Projectsのステータスを登録Zenhubで使用していたPipelineと同じ「To Do」「In Progress」「Review」「Done」などのステータスをすべてGitHub Projectsに登録します。具体的には、GitHub Projectsの「Settings」から「Status」を選択し、ステータスを定義します。各ステータスに対応するカスタムフィールドを作成することで、Zenhubと同様の進捗管理が可能になります。

 GitHub ProjectsへのIssueの登録GitHub Projectでは既存のIssueについては手動で追加する必要があります。(後から自動的にボードに追加する設定をすることはできます。)

ZenhubでもGitHubのIssueを扱っていたため、オープンされているIssueをすべて登録します。
ボードビューで適当なStatusの下に「+Add item」があるので押します。（Statusの紐づけは後でやります）
その後、「Add item from repository」を押して、Issueを選択します。
オープンしているIssueだけで良ければSearch欄に「is:open is:issue」と入力し、登録します。GitHub Projectsでは25件ずつしかIssueを登録できませんが、根気よく操作を繰り返してすべてのIssueを登録します。

 IssueにStatusを紐づけるZenhubのPipelineで管理していた「To Do」「In Progress」「Review」「Done」などのステータスを、各IssueのStatusとしてGitHub Projectsで結び付けます。
ZenhubのAPIとGitHubのAPIを使ってスクリプトで自動的に差し替える方法も検討しましたが、コストと労力を考慮し、手動での移行を選択しました。

下記の方法を使えば、少し手間はかかりますがスクリプトを使用せずに移行することが可能です。
GitHub Projectsでは現時点で一括操作がサポートされていないため、ラベルとボードを活用して移行を行います。

 1.各Statusに対応する一時的なGitHubラベルを作成各Statusに対応する一時的なラベルを作成します。例えば、「migrate-todo」「migrate-done」などのラベルを用意します。

 2.Zenhubのボードを開き、Pipeline内の全アイテムを一括選択しラベルを付与Zenhubのボードを開き、該当するPipeline内のすべてのIssueを一括で選択し、対応するラベルを付与します。例えば、「To Do」Pipeline内の全アイテムに「migrate-todo」というラベルを付けます。Pipelineに50件以上Issueがある場合、先頭50件のIssueにしかラベルを一度に付与できないため、「temp-todo」のような一時的なPipelineを用意し、50件ずつラベルを付与し、そのPipelineに移動させる作業を繰り返します。

 3.GitHub Projectsのボードを開き、ラベルで検索して該当するIssueを正しいカラムに移動GitHub Projectsのボードを開き、ラベルを使って該当するIssueを絞り込み、Issueを選択してドラッグすることで正しいStatusに移動させます。ここでも50件以上一気に移動させようとすると怒られるので空気を読んでちょっとずつ移動させます。

 4.移行用のラベルを削除「migrate-todo」などの移行用のラベルを削除すれば完了です。

 ストーリーポイントの設定コレに関してはひたすら入力するしかないです。ただ、基本的にスプリントの中の物以外はまた見積もりをすることにすればあんまり対象は多くないのかなと思います。

GitHub ProjectsのTable viewを使うと、Issueを開かずとも数値を入力することができるのでちょっと便利です。

 Auto-add to projectの設定GitHub Projectsでは新しいIssueを自動的にプロジェクトに追加する設定できます。これにより、手動で追加する手間を省くことができます。

Workflowsを使用して「Auto-add to project」を設定します。

これにより、特定のリポジトリから新しく作成されたIssueが自動的にプロジェクトに追加されるようになります。

 エピックに子Issueを登録コレもひたすら手作業でやる必要があります。頑張るしかないです。

 Zenhubで登録した画像や動画、リンクを置き換えZenhubのアカウントがなくなるとこれらの画像やリンクなどは見えなくなるので置き換えが必要です。

「is:issue is:open zenhub」などでGitHubの画面からIssueを検索すると画像やzenhubリンクをIssue本文とかコメントに含むIssueで絞れるので、画像は右クリックしてコピーして貼り直すなど、これもパワーで解決します。

 移行してどうだったか？
 移行の成果と課題移行後、GitHub Projectsの利用によりいくつかの成果と課題が見えてきました。

 良かった点
コスト削減: Zenhubのライセンス費用がなくなり、チーム全体のコスト削減に成功しました。

自由度が高い: GitHub Projectsはカスタムのボードビューやチャートを作成できるため、さまざまな使い方が可能です。例えば、スプリントごとのVelocityを可視化するチャートを作成したり、優先度ごとにIssueを整理するボードビューを設定することができます。まだ試行錯誤の段階ですが、これらの機能を使いこなせれば、Issue管理がより効率化されると期待しています。

 課題点
操作の手間: Zenhubでは自動的に行えていた部分がGitHub Projectsでは手動操作が必要になるケースがあり、例えば大量のIssueにまとめてラベルを付与するのが難しいという課題があります。しかし、スプリントのようなシングルセレクトのカスタムフィールドについては、その項目を軸としたボードビューを作成し、対象のIssueをまとめて移動させることで、一度にカスタムフィールドの値を付与することが可能です。

機能の不足: SubIssuesなどの一部の機能がベータ版であり、Zenhubで使い慣れていた機能に完全には置き換えられていない部分も見られました。

 今後の改善点GitHub Projectsの使い勝手をさらに向上させるために、今後は以下の改善を検討しています。

カスタムボードやチャートの設定: カスタムボードやチャートを設定し、チームの活動をさらによくする方法を模索してきます。

チームへの教育: チームメンバー全員がGitHub Projectsを最大限活用できるよう、ワークショップやドキュメントの整備を進められればと思います。