これは Livesense Advent Calendar 2023 DAY 14 の記事です。
マッハバイトでバックエンドエンジニアをしている今井です。
マッハバイトのエンジニア組織は、Webチームとアプリチームに分かれています。そのうち私が所属しているWebチームにて、チケット管理ツールをJIRAからGitHub Projectsに移行しました。
この記事では、どういった意図で移行を行なったか、また、変更の結果どのように環境が変わったかということについて紹介したいと思います。
移行に至るまで
前提
マッハバイトでは、8月にチケット管理ツールをJIRAからGitHub Projectsに移行しました。前提としてマッハバイトWebチームの開発体制・環境は以下のような状態でした。
- 開発体制
- アジャイル開発
- スクラムではない
- 任されるプロジェクトとタスクの粒度は比較的大きい
- プロジェクトにアサインされたエンジニアが個々人でステークホルダーとコミュニケーションを行い、スケジュールなどを調整する
- 個々人が、タスクを適切な単位に切り分け、チケットを起票する
- プロジェクト・タスク管理としては、比較的「ゆるい」管理となっている
- チケット管理ツール
- JIRA
- コード管理
- GitHub
- かつてはBitBucketをコード管理に利用していたが、ここ数年でほとんどのリポジトリをGitHubでの管理に移行した
しかしこの数年で、GitHub Projectsの機能拡充が進んだこと、そしてコード管理がGitHubへ移行したことで、GitHub Projectsがチケット管理ツールの選択肢の一つとして考えられるようになりました。
移行に関する判断
GitHub Projectsに移行する際の判断軸として、想定されたPros/Consは以下の通りです。
- Pros
- GitHubとの連携が容易
- PR（プルリクエスト）・Issue・リリースの紐付け
- 内部統制の観点から、チケット・コード上の変更（PR）・リリースの紐付けをワンプラットフォームで取得できることにメリットがある
- GitHub Actionsで自動化が可能
- GitHubとの連携が容易
- Cons
- JIRAの方が機能は多い
- 主にスクラム開発の際に便利に使うことができる機能
- エンジニア以外の職種ではJIRAを引き続き使っているため、人によってはJIRAとGitHubの両方を見る必要が出てくる
- プランナーのアカウント作成が一部新しく必要になる
- JIRAの方が機能は多い
その上で、マッハバイトでは前述の通りチケット管理については個々人の裁量に任せる部分が大きいです。 JIRAのチケットに関連した豊富な機能を利用する想定がなく機能としては十分なものがあること、そしてPR・issue・リリースの紐付けの管理をはじめとしたGitHubでのコード管理との連携が容易であることから、メリットがConsに挙げられた点のデメリットを上回ると判断し、GitHub Projectsへの移行を決めました。
移行と移行後
移行にあたっては、JIRAとGitHub Projectsの両方でチケット管理をする期間を2週間ほど設け、その期間で漸進的にチケットを移行していきました。
また、全ての種類のチケット管理を移行したわけではなく、運用業務に関連するチケットの一部では、チケット起票を行う関係者の数が多くそれぞれにGitHubのアカウントを作成・管理するコストが高いこと、その運用業務ではGitHubで管理しているコードの変更を行わないことから、引き続きJIRAでのチケット管理の運用として残したものもあります。
GitHub Projects移行後は以下のような機能を使い、管理を行なっています。
Project
Webチームで一つのProjectとIssue管理用のリポジトリを作成し、そこで管理を行なっています。
アイテムの管理
基本的には、Issueに対応するラベル、またはマイルストーンを作成し分類を行い、Projectのボード上で分類ごとにViewを作成し管理を行なっています。
また、GitHub Projectsではアイテムにユーザーが定義したフィールドを設定できる機能があります。自由度が高くかなり便利に使える機能ですが、現状はそこまで有効には使えていません。
自動化
GitHub ProjectsにはWorkflowsと呼ばれる機能があり、そちらを利用するとProject内のアイテムのステータス変化をフックに、行いたい処理を設定することができます。 こちらの機能を利用して、「PRがクローズされた際に対応するアイテムのステータスを変える」、また、「Issue管理用のリポジトリにIssueが作成されるとProjectに追加する」といった自動化を行なっています。 Projectを利用する中で最低限必要な機能については、Workflowsを利用することで実現できるように思います。
また、そのほかにもGitHub Actionsを利用して、Botなどが作成したPRをフィルタリングしてProject上に追加するといった自動化も行なっています。GitHub ActionsからIssueやPRをProjectに追加する場合は以下のActionを使うことが多いです。
利用して感じた課題
GitHub Projectsを利用して感じた機能面の課題としては以下の２つがありました。
- サブタスクの管理が難しい
- デフォルトで用意されているViewが少ない
大きめのタスクに取り掛かっている際、当初切っていたチケットに対して少し小さなサブタスクに切り分けて作業を行いたいことがあるかと思います。そうしたサブタスクを作成した際に、それを親チケットに紐付けプロジェクト上でわかる形で表示することが現状の機能上は難しく管理上の不都合があります。そのため、現状はタスク単位でラベルなどを作成し、全てのタスクに紐づけることで管理しています。 また、デフォルトで用意されているViewが少ない点については、Viewではユーザーがカスタマイズして適切なProjectの状態管理ができるという面はありつつ、自由度が高いためデフォルトでいくつかビューが用意されていると利用開始時から管理が楽にできるのではないかと感じました。
まとめ
GitHub Projectsに移行後、4ヶ月ほど運用を行なっています。前述のような課題はありつつも、移行に際して想定していたメリットを享受できており、移行して良かったと考えています。特に、以下の2点のメリットが大きいように思います。
- GitHubとの連携が容易
- GitHub Actionsで自動化が可能
PR・Issue・リリースの紐付けが容易であり情報を漏らさずに追い易いこと、またGitHubでのイベントをフックとしてGitHub Actionsで自動化が可能であることから、JIRAを利用していた際より管理の手間が少なくなったと感じています。
運用開始から日が浅く、GitHub Projectsで用意されている機能を十分に利用できているとは言い難いため、今後の機能追加やアップデートに追従しつつ運用をブラッシュアップし利用していきたいと思います。
