NotionからGitHub Projectsへバックログ管理を移した話

はじめに

これはTimeTree Advent Calendar 2025の3日目の記事です。

この記事では、長年チームでバックログ管理に使っていたNotionからGitHub Projectsへ移行する際に特に気をつけたことについて紹介します。

ツールの機能比較というより、チームの負担を最小限にしながら段階的に移行を進めた工夫にフォーカスした内容になっています。

移行前の状況

Notionでバックログ管理をしていた理由

TimeTreeではナレッジベースとしてNotionを利用しています。

Notionに集約しておくことで、仕様や設計を見やすくリンクできたり、過去の実装の経緯などを検索しやすいといったメリットがありました。
また、高いカスタマイズ性を活かして、Mermaidを使ったバーンダウンチャートなども作成していました。

10人弱のチームで長く運用しており、メンバーもNotion前提の運用に慣れていた状態でした。

環境の変化と直面した課題

長年運用されていたNotionのバックログでしたが、この1年で大きな変化が2つありました。

1. チームの再編があり、運用に慣れたメンバーが半分以上入れ替わった
2. AI機能の発達で、Notion以外のデータソースからも検索できるようになった

これらの変化により、いくつかの課題や要望が顕在化しました。

まず、新メンバーのオンボーディングコストが増加し、長年積み重ねたNotionのカスタマイズが「触ると壊れそうな秘伝のタレ」になっていたことが浮き彫りになりました。
また、コード生成AIをもっと活用したいというチームからの要望もあり、ツールの選定をする必要性を感じるようになりました。

GitHub Projectsへの移行を決めた理由

移行先の検討にあたり、以下のポイントを重視しました。

• すでに開発でGitHubを利用しており、追加の課金が不要
• エンジニアフレンドリーで、オンボーディングコストを下げやすい
• メンバーが自律的にカスタマイズできる（Notionの「秘伝のタレ」化を避けられる）
• 既存のバックログ構造を踏襲しやすい設計

また、Notionのナレッジベースとしての運用も継続でき、Notion AIを使えば両方のデータソースを参照できる点も決め手になりました。

移行アプローチ：チームの負担を最小限にする工夫

段階的な移行計画

移行にあたって、まずは小さく試してみることから始めました。

チーム内で複数の施策が並行して動いていますが、まずは1施策（関係メンバー4〜5人）だけをGitHub Projectsでの運用に切り替えました。
そこでは、既存と遜色なく使えているか、メンバーが自主的にカスタマイズしやすいかを確認しながら進めました。

試験運用の結果、問題なく運用できることが確認できたため、その知見をもとに全体へのオンボーディング資料を作成し、他の施策にも展開していきました。

バックログ構造の維持

既存のバックログでは、施策 > 要件 > タスクという3階層でチケット管理をしていました。
このうち施策は主に非エンジニアが管理し、要件以降はエンジニアが主に管理する役割分担になっていました。

移行後もこの構造を維持するため、以下のように対応させました。

• 施策 → Milestone（NotionリンクをMilestoneの説明に記載）
• 要件 → type: Feature
• タスク → type: Task

こうすることで、チームの共通言語である「施策・要件・タスク」という概念をそのまま使い続けられ、「どこに何を書くか」という思考パターンを変えずに済みました。

また、施策の詳細はこれまで通りNotionに記載し、要件以降の詳細はGitHub Projectsのissueに記載する運用にしました。

既存のチケットの扱い方

これまでNotionで管理していた過去のチケットは一括移行せず、現在進行中の施策と今後発生するチケットからGitHub Projectsに移していくことにしました。

理由は、不要な移行コストを避けることと、NotionAIを使えば両方のデータソースを検索できるため、わざわざ重複させる必要がなかったためです。
必要になったタイミングで個別に移行すれば十分、という判断でした。

メンバーへのオンボーディング

試験運用で出た疑問点を取り入れ、GitHub Projectsのテンプレート説明に運用イメージと各ビューの使い方を簡単に記載しました。
ドキュメントは最小限に留め、実際に使いながら理解してもらうスタイルを意識しました。

また、一度チームで集まって施策のブレイクダウンを実施し、実際にGitHub Projects上でissueを作成しながら運用の流れを体験してもらいました。

それ以外の特別なサポート体制は用意しませんでしたが、GitHub Projectsの直感的な操作性とエンジニアの馴染みやすさもあり、オンボーディング後は各メンバーが自律的にカスタマイズや運用を進められる状態になりました。

これまでのミーティングで使用していたNotionページのリンクをGitHub Projectsに差し替えるなど、既存の業務フローへの統合も段階的に進めました。

移行後の効果と学び

得られた効果

移行後、いくつかの具体的な効果を実感しています。

まず、オンボーディングコストが大幅に下がりました。GitHub Projectsのエンジニアフレンドリーな操作性と、バックログの構造（施策→要件→タスク）を変えなかったことで、新メンバーの認知負荷を増やさずに済みました。

また、Notionの「触ると壊れそうな秘伝のタレ」から解放され、各メンバーが自律的にProjectsをカスタマイズできるようになりました。これにより、チームごとに必要なビューやフィルタを自由に追加できています。

さらに、GitHub上でタスク・PR・コードが近くなったことで、コード生成AIが文脈を拾いやすくなり、開発効率の向上にも一役買っています。

移行から学んだこと

今回の移行で最も重要だったのは、段階的に小さく始めたことと既存の構造を維持したことでした。

カスタマイズ性の高いツールは便利ですが、シンプルさを保ちながら拡張していかないと、それ自体が新しいメンバーにとって大きな壁になってしまいます。

また、過去データを無理に移行せず、現在進行中のものから始めたことで、不要なコストを避けられました。大きな変化があるときこそ、いかに小さなコストで移行できるかを意識することの重要性を実感しました。

おわりに

今回、NotionからGitHub Projectsへの移行を通じて、段階的に小さく始めることと既存の構造や文化を尊重することの重要性を改めて実感しました。

チームのメンバーややることが変化すると、チームが求めるものももちろん変化していきます。
ツールの移行は手段であり、大切なのはチームが今何に困っていて、何を必要としているかを見極めることだと思います。

もし同じようにバックログ管理ツールの移行を検討している方がいれば、「一気に全部移行しなければ」と気負わず、小さく試してみることをおすすめします。

スクラムマスターとして、現状維持バイアスに流されず、チームに必要な変化を提案し続ける姿勢を今後も大切にしていきたいです。