こんにちは！Backlogブログ編集部です。
連載企画「ヌーラボのエンジニア・クリエイターが実践する、Backlog活用術」の第4弾をお届けします！開発や制作の最前線に立つヌーラボのメンバーたちが、日々の業務でBacklogをどう使い倒しているのか——リアルなノウハウをお届けするシリーズです。
第4回となる今回は、Growth Productsユニットの小林による、「Backlog × GitHub の二重管理を防ぐ役割分担と移行のコツ」です。
「GitHub Issuesにもタスクが溜まって議論が散逸してしまう…」「BacklogとGitHub、どう使い分けるのが正解？」とお悩みの開発チームやテックリードの方は、ぜひ参考にしてみてください！
目次
はじめに
「全体のプロジェクト管理を Backlog で行っているかたわら、 Git のリモートリポジトリのホスティングには GitHub を利用している」——そんな開発チームは少なくないのではないでしょうか。しかし、このような運用を進めていくと、以下のような問題に直面してしまうかもしれません。
- GitHub Issues にもタスクが溜まり始め、Backlog 課題と二重管理になってしまう
- PRのコメントとBacklogの課題コメントで議論が分散し、後から追えなくなる
- 開発に関わらないメンバーに「GitHubも見てください」とお願いするのが申し訳ない
しかし、これらは適切な役割分担のルールを決めることで、ほとんど防ぐことができます。コツさえつかめば、Backlog と GitHub はお互いの強みを引き出し合う強力な組み合わせになるのです。
この記事では、Backlogをタスク管理の中心に置きつつ、GitHubの強力な開発機能を活かす運用のコツを紹介します。
対象読者
この記事では社内でのみ扱うリポジトリに焦点をあてています。OSS 活動など、社外コントリビューターが関わるケースでは GitHub の流儀に合わせた運用が適切な場合もあるからです。
また、GitHub を利用しているメンバーも含めて全員に Backlog のアカウントが割り当てられている、もしくは割り当てることができるものとします。スタンダードプラン(新ビジネスプラン)以上*であれば Backlog のユーザー数は無制限ですから、気軽に追加していくことができます！
*2027年1月1日から、Backlogのプランが新しくなります。詳細はこちらのページをご確認ください
https://backlog.com/ja/blog/new-plans-2027/
以下のいずれかに当てはまる方に特に参考にしていただけると思います。
- Backlog・GitHubのどちらかをすでに使っていて、もう片方の導入を検討している
- 両方を使っているが、運用がうまく回っていないと感じている
なぜ GitHub を使うのかを明確に
「主なタスク管理ツールとして Backlog を使っていて Git 機能があることも知っているが、その上でリポジトリのホスティングには GitHub を採用している」という方もいらっしゃるのではないでしょうか。あるいは、何らかの理由で Backlog と GitHub Issues でタスク管理が分散していることもあるかもしれません。
Backlog にも Git 機能はあります。単なるリモートリポジトリの配置場所としてだけでなく、ブラウザ上でコミット履歴を参照したりプルリクエストを作成することもできます。機能が Backlog 内で完結しているため、課題との連携もシームレスに可能です。
それでもなお、ソースコードのホスティングサービスとして GitHub を選択すること自体は十分にありえます。特に、 GitHub Actions は CI/CD を構成する上で非常に強力な機能です。重要なのは、タスク管理の機能まで GitHub に分散させてしまわないようにすることです。
GitHub には PR だけを残す
GitHub のリポジトリでは、 Issues / Discussions / Projects を無効化することをおすすめします。これは、情報が集まる場所をできるだけ Backlog に統一することが最大の目的です。Backlog はもとよりプロジェクト・タスク管理のためのツールですから、GitHub でのタスク管理のフローやそのための機能も自然に移行することができます。
代表的なものを以下に示します。
| GitHub でできること | Backlog に対応する機能 |
|---|---|
| ラベル | 課題種別・発生バージョン |
| タグ・マイルストーン | カテゴリー・マイルストーン |
| プロジェクトボード | ボード・ガントチャート |
| Wiki | ドキュメント |
Pull Requests (PR) はコード管理の都合上有効なまま運用するのがバランスがよいと考えています。コードレビューはファイルの差分に紐づいたコメントが欠かせず、また Actions 等によるテスト等の自動化の点でも GitHub 上で行うのが自然だからです。ただし、PR に紐づく議論はそのまま GitHub 側に残りやすい点には注意が必要です。あくまで「実装の細部に関するやりとり」を PR のコメントで完結させ、「仕様の決定や背景の共有」は Backlog 課題に残す、という使い分けを意識すると、情報の散逸を防ぎやすくなります。
開発以外の課題も一元管理するのは実は便利
「タスク管理をBacklog に一本化すると、開発関連とそれ以外の課題が混ざってしまい不便なのでは？」と思われるかもしれませんが、決してそんなことはありません。検索条件を適切に設定することで、担当者やカテゴリー、課題種別などで「今自分に関係ある課題」を効率的に絞り込めます。
むしろ、開発関連とそれ以外のタスクが別々のプラットフォームで管理されている方が困る場面も多いです。例えば GitHub Issues に書かれているからといって、その内容が開発に関わるメンバーにしか関係ないとは限りません。逆に開発においても、 GitHub Issues に書かれていない議論を参照したくなることはあるはずです。このようなシチュエーションで、Backlog と GitHub を往復するのは効率が悪いですね。
また、最近リリースされた関連課題機能も便利です。GitHub では Issues/PR の番号を書くと、リンク先のページに言及された旨と言及元へのリンクが表示されますが、Backlog でも課題キーをコメントに書くことで自動的にリンク先の課題で課題詳細にリストアップされるようになりました。「親子関係にはないが話題として関連性がある課題」といったものも認識しやすくなりますので、積極的に利用していきましょう。
GitHub Issues から Backlog 課題への段階的な移行
先述したように、理想的には最初からタスク管理を Backlog で行うのがベストですが、既に GitHub Issues でそれなりの数のタスクが管理されている場合もあるでしょう。
段階的に Backlog へ移行したい場合、まずは「新しい議題は Backlog に起票する」というルールから始めると取り組みやすいです。その先のステップとしては、一例になりますが、
- Issues にあるものは完了までそちらを使う
- Issues にある議題に更新が発生したタイミングで Backlog に移行する
- Open 状態の Issues を全て棚卸しし、残す必要があるものを Backlog に移行する
というように進めるのがよいかもしれません。
移行対象が多くなければ、Backlog の一括登録機能で一気に Issues から移行することもできるでしょう。GitHub CLI を利用すると JSON 形式で Issues のデータを構造化された状態で取得できるので、これを整形して一括登録用の CSV ファイルを生成すれば一気に登録できます！
# 現在 Open 状態の Issue の情報を JSON で取得する # 以下の例では タイトル、説明文、ラベル、作成日時、Issue URL を取得している gh issue list --json title,body,labels,createdAt,url > issues.json
GitHub のイベントを Backlog に通知する
より発展的な連携として、GitHub で発生したイベントに合わせて Backlog 側に自動で課題・コメントを作成するというものがあります。
GitHub Actions で PR 作成やコメント作成に反応する Workflow を作成してから Backlog API にアクセスするかたちで実装するのが最も手軽です。また Backlog 側では、GitHub 連携専用の bot ユーザーを作成しておくことで、GitHub 由来の自動操作であることがわかりやすくなります。
なお、API キーの配置などセキュリティーには注意しましょう。API キーの本体はリポジトリの Secrets に登録し、workflow からはシークレット変数として記述する (例: ${{ secrets.BACKLOG_API_KEY }}) のをおすすめします。
まとめ
Backlog と GitHub の併用を成功させるコツは、まさに役割分担を明確にすることです。
- GitHub: コードのホスティングと CI/CD に専念させる
- Backlog: タスク管理やナレッジをすべて集約し、チームワークを円滑に進められるようにする
今の運用に煩わしさ・ハードルを感じている、なんとなく疑問を持っている方は、ぜひ一度この指針に照らして見直してみてください。