※この記事は、2026年1月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
susiyaki
株式会社TimeTree
フロントエンドエンジニア/スクラムマスター
佐世保高専、九州工業大学 情報工学部卒業後、Web系企業でフリーランスとして複数社の開発を支援する中で、チームビルディングの重要性を実感し正社員に転向。現在は株式会社TimeTreeでフロントエンドエンジニア／スクラムマスターを務めている。
Susiyaki：本日は「NotionからGitHub Projectsへのバックログ管理ツール移行とその効果」というテーマで発表させていただきます。
本セッションでは、なぜ私たちがバックログ管理ツールを移行する必要があったのか、チームへの負担を最小限にするためにどのような工夫をしたのか、そして移行によってどのような効果が得られたのか。この3点を中心にお話しします。特に「ツール移行でチームを混乱させないための具体的な戦略」については、他のチームでも応用できる内容だと思いますので、ぜひ参考にしていただければと思います。
サービス紹介
本題に入る前に、私が所属している「TimeTree（タイムツリー）」について紹介させてください。
TimeTreeは、誰かと予定を共有することに特化したカレンダーアプリです。個人の予定管理だけでなく、家族、チーム、友人などとの共有カレンダーとして利用されています。ユーザー数はグローバルで7,000万人以上、国内でも3,100万人以上の方にご利用いただいています。
私たちのミッションは「誘おう」をつくるです。大切な人との予定を共有することで、ユーザーさんの明日を少しでも良くしたいという思いで日々運営しています。
なぜツール移行が必要になったのか
本日のセッションは7つのパートで構成していますが、まずは「なぜ移行が必要になったのか」という経緯から順を追って説明します。
Notionがチームにフィットしていた背景
初期のチームにとって、Notionは非常に適したツールでした。理由は主に3つあります。
- 高い自由度でチームに最適化
TimeTreeでは全社的に「施策・要件・タスク」という3つの階層構造で管理を行っています。Notionはこの組織の共通言語を柔軟に表現できたため、チームの開発フローに非常にフィットしていました。 - 全社ナレッジベースとの連携
全社でNotionを使っていたので、要件定義、技術仕様書、議事録、そしてタスク管理まで、すべてをシームレスに繋げて利用できました。情報を探すために複数のツールを行き来する必要がありませんでした。 - 非エンジニアも含めたタスクの一括管理
エンジニアだけでなく、デザイナーやプロダクトマネージャーも全員同じ場所でタスクを確認し、コメントでコミュニケーションを取れました。これにより透明性の高い開発が実現できていました。
当時はチームの規模が小さめで、全員が運用ルールを深く理解していたからこそ、Notionの柔軟性が最大限に発揮されていました。
環境の変化によって顕在化した課題
しかし、環境の変化によって課題が顕在化していきました。大きく分けて「組織的」と「技術的」な2つの側面があります。
組織的な課題
大規模なチーム再編があり、運用ルールを深く理解していたシニアメンバーの多くが別のプロジェクトに移動してしまいました。暗黙知を持つ人材が減少した一方で、毎月1〜2名の新メンバーの受け入れが続き、チーム規模は半年で約1.5倍に拡大しました。
ここで問題になったのが、Notionの「高いカスタマイズ性」です。最適化されていた運用ルールが属人化し、新メンバーにとっては「秘伝のタレ」のような理解しづらい仕組みになっていました。多数のカスタムプロパティが存在し、「下手に触ると壊してしまいそう」という心理的ハードルをメンバーに与えていたのです。
結果として、オンボーディングに時間がかかり、既存メンバーの説明コストも増大していきました。
技術的な課題
1つはNotion AIの登場です。他のツール（GitHubやSlackなど）を横断した検索が可能になったことで、「Notionにすべてを集約しなければならない」という必然性が低下しました。
もう1つは、コード生成AIとの連携です。コード生成AIは、コードとコンテキスト（タスク情報など）が近い場所にあることで真価を発揮しますが、Notionだとその距離が遠く、参照しにくいことが開発効率向上のボトルネックになっていました。
移行先の選定要件とProjectsを選んだ理由
これまでの課題を踏まえ、新しいツールの選定において私たちが最も重要視したのは、以下の2つの要件でした。
- 移行後の学習コストが低いこと
新メンバーが継続的に加わる状況で、ツールの学習に時間を取られては本末転倒です。オンボーディングコストの急増を防ぐため、誰でもすぐに使いこなせるツールである必要がありました。 - AI活用がしやすいこと
コード生成AIとの連携におけるボトルネックを解消し、エンジニアが最大限のパフォーマンスを発揮できる環境を目指しました。
これらを満たす候補として選んだのが、GitHub Projectsです。具体的なメリットは4点あります。
- エンジニアフレンドリーなUI/UX
普段から使い慣れているGitHub上で完結するため、新しいツールの学習コストがほぼゼロになります。 - メンバーが自律的にカスタマイズ可能
構造がシンプルなため、以前のような「触ると壊してしまいそう」という心理的ハードルがなく、メンバーが自らビューを整えるなど、自律的な運用が可能です。 - 既存の管理構造を踏襲可能
私たちの共通言語である「施策・要件・タスク」という構造を崩さずに移行できる目処が立ちました。 - 追加コストが不要
会社ですでにGitHub Enterpriseを契約していたため、金銭的な負担増がなかった点も大きなメリットでした。
チームの負担を最小限にするための移行戦略
移行を成功させた3つのステップ
ツール移行は現場の混乱を招きがちです。私たちは、日々の開発業務への影響を最小限にするため、以下の3つのステップでアプローチしました。
STEP 1：小さく始める
まずは一つの施策に絞って試験運用を開始しました。このステップで特に重要視したのは、「運用の断捨離」です。Notion時代に複雑化していたカスタムプロパティや計算フィールドを整理し、本当に必要なものだけに絞り込みました。また、GitHub Projects上での構造マッピング（後述）の基本方針をここで確立しました。
STEP 2：知見を蓄積・共有
試験運用で得られた知見をテンプレート化し、「Notionのこの項目は、Projectsのここに対応している」といった比較情報を整備しました。チーム全体に共有することで、後から移行するメンバーの不安を払拭し、スムーズな展開を実現しました。
STEP 3：過去データを切り捨てるという決断
これは思い切った判断でしたが、大きな価値がありました。過去の膨大なチケットはあえて移行せず、「進行中の案件と新規案件のみ」をProjectsで管理することにしました。
過去のデータはNotionに残したままですが、Notion AIを使えばツールを跨いで検索できるため、運用上の問題はありません。この決断により、過去の複雑なルールに縛られることなく、ゼロからシンプルで使いやすい構造を設計することができました。
共通言語を崩さないためのアプローチ
この3つのステップの中で、特に効果的だったステップ1の構造マッピングについて説明します。具体的には、共通言語を崩さないという点を意識したアプローチを取りました。
施策、要件、タスクというすべての構造をGitHub Projectsにそのまま移行するわけではなく、マネージャーとエンジニア、それぞれの役割に適したツールを使い分けるハイブリッドな構造をとりました。
- Notionに残したもの： 施策レベル（マネージャー層が管理する背景や詳細ドキュメント）
- GitHub Projectsへ移行したもの： 要件・タスクレベル（エンジニアが日常的に触る実務単位）
この棲み分けにより、マネージャー層に新たにGitHubアカウントを発行したり操作を強いたりする負担を避けつつ、エンジニアはコードと同じ場所でタスク管理ができるようになりました。
両者の繋がりは、ProjectsのマイルストーンにNotionの施策ページへのリンクを貼ることで表現しています。この仕組みにより、AIもマイルストーン経由で施策の背景情報を参照でき、コンテキストの把握もスムーズに行えています。
移行後の効果とプロジェクトからの学び
チームの自律性を高めた3つの成果と教訓
移行の結果、以下の3つの成果が得られました。
- オンボーディングコストの削減と運用の自律化
「秘伝のタレ」のような複雑なルールが消え、新メンバーが即座にタスク管理を開始できるようになりました。また、メンバーが自らフィールドをカスタマイズする文化が生まれ、チーム全体の自律性が向上しました。 - 開発効率の向上とAI活用の加速
GitHub上でコードとタスクが統合されたことでコンテキストスイッチが減り、レビュー作業などの効率が上がりました。AIとの親和性も高く、開発効率の向上を実感しています。 - 移行を成功に導いた2つの戦略的判断
「すべてを移行しようとしない」「過去を切り捨てる」といった戦略的な判断が成功の鍵でした。チームが今必要としているものに集中したことが、混乱を最小限に抑える結果に繋がりました。
チームへの満足度調査でも「移行してよかった」という結論が得られ、ツールの移行を通じてチームの自立性を高めるという大きな成果を得ることができました。チームに必要なものを見極めることが成功の秘訣かと思います。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
