なぜタスク管理をNotionからGitHub Projectsへ移行したのか - AI時代の開発効率を最大化する選択

こんにちは。PIVOTでソフトウェアエンジニア、スクラムマスターを務めている（た）@tawachanです。

この記事では、PIVOTのプロダクトチームがNotionからGitHub Projectsへタスク管理ツールを移行した経緯と、具体的な実装方法について紹介します。

背景：AIファーストチームへの変革

詳細な背景については、前回の記事「スクラムからカンバンへの移行——ソフトウェアエンジニアがマネージャーになる時代に」で、チームの思想やプロセスの変化について紹介しました。今回は、その思想を支える具体的なツールの変化に焦点を当てます。

前回の記事で紹介したように、私たちのチームはAI時代の開発に合わせてプロセスを見直し、スプリントベースからカンバン方式へ移行しました。しかし、プロセスを変えるだけでは不十分でした。

開発速度が上がると、次に見えてくるのはツール自体のボトルネックです。特に、タスク管理ツールとして使っていたNotionが、AI時代の開発フローに合わなくなってきました。

この記事では、私たちがNotionからGitHub Projectsへタスク管理ツールを移行した理由と、その実装方法について詳しく解説します。

Notionが抱えていた課題：AI時代の開発速度とのギャップ

Notionを積極的に活用してきた背景

私たちのチームは、これまでNotionを積極的に活用してきました。

Notionは全社で導入されており、チーム間の情報共有やコラボレーションがスムーズに行えていました。また、AI機能も搭載され、誰でもAIを手軽に活用できる環境が整っていたことも魅力でした。

さらに、情報統合の観点から、JIRAなどの専用ツールをあえて使わず、Notionでプロジェクト管理を運用してきました。ドキュメント、データベース、タスク管理を一箇所に集約できることで、情報が分散せず、チーム全体での認識合わせがしやすい環境を実現できていました。

AI時代の開発フローとのギャップ

一方で、AIを活用した開発が本格化すると、Notionには大きな課題が見えてきました。

起票時：転記コストが下がらず、ドキュメンテーションが進まない

最も大きな課題は、AIを活用しても起票コストが下がらなかったことです。

Claude CodeやChatGPTなどを使えば、議論の内容やコードの文脈から、タスクの内容自体はまとめられます。しかし、それを実際にNotionのタスクとして登録する際に、無駄な手間が発生していました。

• AIにNotionの体裁に合わせた形式で出力してもらう必要がある
• それでも、出力された内容を手動でコピー&ペースト
• NotionのUIを開いて、フィールドをポチポチと選択・入力

NotionにはModel Context Protocol (MCP)のサポートがあり、ラベル付けやスプリント割り当て、アサイン設定など、細かい設定値までAIに任せようとする試みもありました。しかし、読み取りは改善されてきた一方で、作成・更新系の操作はまだ精度が悪く実用に耐えませんでした。CLIから直接書き込むような操作もできませんでした。

AIで内容をまとめる作業はできても、Notionへの転記と各種設定の手間が残ってしまい、起票のハードルが下がりませんでした。

その結果、起票のハードルが高いまま残り、詳細なドキュメンテーションが進みませんでした。手間だから後でやろうと思って忘れたり、手入力で簡潔にだけ書いたり、Slackへのリンクだけ張って結局何が決まったのかわからないタスクになるといったことが発生していました。

活用時：実装との連携が弱い

また、AIに限った話ではありませんが、元々の課題として、NotionとPRの連携が弱いという点もありました。

一応、タスクにIDを付けてPRと紐づける運用をしており、タスクのステータス自動変更などの最低限の連携はできていました。しかし、PR上からタスクを操作したり、PRからNotionを確認するといった、シームレスな連携はあまり活用されていませんでした。専用ツールでないがゆえの歯がゆさが残っていました。

私たちが求めていたのは、Claude CodeなどのAIからサクッと起票でき、開発ワークフローとも密に連携できるツールでした。

GitHub Projectsへの移行

これらの課題を解決するため、私たちはタスク管理ツールをNotionからGitHub Projectsへ移行することにしました。

GitHub Projectsを選んだ理由は、以下の通りです。

AIとの親和性：CLIによる直感的な操作

GitHub Projectsの最大の強みは、gh CLIでの操作性です。

# Issue作成
gh issue create --title "タスク" --body "詳細"

# プロジェクトに追加
gh project item-add 1 --owner OWNER --url [ISSUE_URL]

# ステータス変更
gh project item-edit --id [ITEM_ID] --field-id [FIELD] --single-select-option-id [STATUS]

このシンプルなCLIのおかげで、Claude CodeやCodex CLIといった既存のAIツールから自然に操作できます。AIに「この議論をIssueにして」と指示すれば、ghコマンドを使って直接起票してくれます。Notionのような転記作業は不要です。

さらに、GitHub Copilot自身もCopilot CLIを公式リリースし、公式MCPサポートも発表されています^[1]。GitHub専用のAIツールも登場してきており、今後さらに統合が進むことが期待できます。

開発ワークフローとの統合

GitHub Projectsを使うことで、開発ワークフロー全体がGitHub上に統合されます。

最近では、PR上から@codexで呼び出せるようになるなど、GitHubの世界に留まれることの利点を実感する機会が増えてきました。こうした流れを考えると、Issueでのタスク管理もGitHubに寄せておくことが中長期的に良い選択だと判断しました。

また、地味に便利なのは、IssueやPRのコメントで#123のようにナンバリングで参照するだけで、バックリンク的にすぐ繋がることです。関連するコンテキストに自然にたどり着きやすく、これもGitHub上にタスク管理を置くメリットでした。

低い導入ハードル

開発者なら全員がGitHubアカウントを持っており、Issueの経験もあるため、新しい概念を学ぶ必要がありません。

一方、Notionでのプロジェクト管理は結構トリッキーなところがあり、誰にとっても初見なので、最初に慣れるまで時間がかかるという課題がありました。

さらに、運用改善のために自分たちでNotionの機能を駆使してガラパゴス仕様を作り込む必要があり、そのメンテナンスコストも地味にかかっていました。

GitHub Issues/Projectsなら、誰でも最低限の状況は理解できるため、新メンバーにとっても入りやすい環境です。環境設定もgh CLIの認証を通すだけで最小限です。

シンプルさと追加コストのなさ

前回の記事で紹介したように、私たちはカンバン方式に移行し、スプリント管理をしなくなりました。この背景から、シンプルなことしかできない、機能が限定的なツールでも困らない状況でした。

GitHub Projectsは、タスク管理に特化した必要十分な機能で、学習コストが低く、チーム全員がすぐに使えます。

また、追加コストなくサクッと導入できることも重要でした。JIRAなどの他の専用ツールではなく、既に使っているGitHubの機能として提供されているGitHub Projectsを選んだ理由の一つです^[2]。

実際の運用の全体像

タスク管理の統一

すべてのタスクを一つのリポジトリで管理する方針にしました。

各リポジトリ（iOS、Android、Server、Web等）にIssueを切ってProjectに入れていくのではなく、Issueを切る場所も専用リポジトリに統一しました。

その中で、専用のフィールドを作って、iOS、Android、Server、Web、Infra、CMS、QAなど、どの分野のタスクなのかを分類して管理しています。

Issueテンプレート

サクッとフォームに沿って起票したいときのために、GitHub Issueテンプレートを用意しています。

ただし、実際にはあまり使っていません。後述するAIでの起票の方が楽なためです。テスト用のタスク起票など、決まった形式で起票したいときには使っています。

.github/ISSUE_TEMPLATE/
├── general-task.yml          # 一般タスク用
├── bug_report.md             # バグレポート用
├── test-design.md            # テスト設計用
├── test-execution.md         # テスト実施用
└── release-task.yml          # リリース確認用

各テンプレートにはデフォルトプロジェクト設定が含まれており、Issue作成時に自動でプロジェクトに追加されます。

general-task.ymlの例（簡略版）：

name: 一般タスク
description: 通常の開発タスク用
body:
  - type: input
    id: title
    attributes:
      label: タスク概要
    validations:
      required: true
  - type: textarea
    id: description
    attributes:
      label: 詳細
projects: ["[your-org]/1"]  # デフォルトでプロジェクト追加

これにより、フォーム入力でもCLIでも柔軟に起票できます。

AGENTS.mdによるAI操作最適化

リポジトリにAGENTS.mdというドキュメントを配置し、AI（Claude Code/Codex CLI）が効率的に操作できるようにガイドを整備しています。

AGENTS.mdに含まれる情報（要点抜粋）：

## 現在のプロジェクト構成

### プロダクトチームタスクボード (Project #1)

- **ID**: `[PROJECT_ID]`
- **ステータス**: Inbox/Todo/In Progress/In Review/Done/QA/Next Release

### 重要なID・識別子

- **プロジェクトID**: `[PROJECT_ID]`
- **Status Field ID**: `[STATUS_FIELD_ID]`
- **Task Type Field ID**: `[TASK_TYPE_FIELD_ID]`

### よく使うコマンドテンプレート

```bash
# Issue作成とプロジェクト追加
gh issue create --repo [your-org]/[project-management-repo] \
  --title "タスクタイトル" \
  --body "詳細"

# ステータス変更
gh project item-edit --id [ITEM_ID] \
  --project-id [PROJECT_ID] \
  --field-id [STATUS_FIELD_ID] \
  --single-select-option-id [STATUS_OPTION_ID]  # Todo

AIが参照しやすい形で情報を整理しています。

team-members.mdでメンバー情報管理

チームメンバーの情報も構造化してリポジトリに配置：

# チームメンバー一覧

| GitHubユーザー名 | 本名 | ニックネーム・あだ名 |
|----------------|------|-------------------|
| @member1 | メンバー A | member1, Aさん |
| @member2 | メンバー B | member2 |
| @member3 | メンバー C | member3, Cさん |

これにより、AIに「Aさんにアサインして」と指示すると、team-members.mdを参照して適切に@member1にアサインできます。

実際の使い方：AIを活用したタスク管理

基本的なワークフロー

gh CLI認証設定

# GitHub Projectsを操作するためのスコープ追加
gh auth refresh -h github.com -s project

# 認証確認
gh auth status

タスク作成

# 専用リポジトリでIssue作成
gh issue create --repo [your-org]/[project-management-repo] \
  --title "新機能: ユーザープロフィール画面" \
  --body "## 概要
ユーザーのプロフィール情報を表示する画面を実装する"

# プロジェクトに追加
gh project item-add 1 --owner [your-org] --url [ISSUE_URL]

# アサイン
gh issue edit XX --repo [your-org]/[project-management-repo] --add-assignee [username]

AIを活用したタスク管理

Claude CodeやCodex CLIを使うと、自然言語でタスク管理ができます。

よくあるユースケースとして、以下のような使い方をしています。

Slackの議論からタスク作成

Slackで議論した結果、方針が決まったとき、Slackの内容を雑にコピペして、スレッドへのリンクを渡してまとめてもらいます。

ユーザー: 「このSlackの議論をまとめてIssueにして」

[Slackメッセージをコピペ]
[スレッドへのリンク]

AI: Issue #156を作成しました。Slackのリンクも含めて背景を記載しています。

議事録からタスクを分割

議事録などをベースにタスクを切る場合も、タスクを複数に分割する必要があるときも、柔軟に指示を出せばサクッと作れるので便利です。

ユーザー: 「この議事録から実装タスクを抽出して、DBスキーマとサーバー実装それぞれ分けて、相互にリンクを付けてタスク切って」

[議事録テキスト]

AI: 以下の2つのIssueを作成し、相互にリンクを設定しました。
- Issue #157: DBスキーマ設計（ユーザープロフィール機能）
  - 本文に「#158のAPI実装の前提となるスキーマ」と記載
- Issue #158: サーバーAPI実装（ユーザープロフィール機能）
  - 本文に「#157のスキーマ設計に依存」と記載

このように、AIがAGENTS.mdとteam-members.mdを参照して適切に操作してくれます。

移行後の変化

起票コストの劇的な改善

移行後、最も大きく変わったのは起票のハードルが下がったことです。

Claude CodeやCodex CLIからghコマンドを使って直接Issueを作成できるため、Notionのような転記作業が不要になりました。Slackの議論や議事録を渡せば、AIが文脈を理解してそのままIssueにしてくれます。

その結果、タスクに詳細な背景や文脈を記載するハードルが下がり、ドキュメンテーションが自然と充実するようになりました。後からチームメンバーが見ても、なぜそのタスクが必要なのか理解しやすくなっています。

GitHub上で完結する開発フロー

もう一つの大きな変化は、開発に必要なものがGitHub上に集約されたことです。

VSCodeなどよく使うツールで開発する流れで、すぐに備忘的なタスクやMVPから外したタスクを起票できるようになりました。PRにはCloses #123でIssueを自動リンクでき、レビューもタスク管理も全てGitHub上で完結します。

Notionを開く必要がなくなり、コードを書くために必要なところに基本留まれるようになりました。開発フローが途切れず、集中力を維持しやすくなっています。

PdM/QAEの起票ハードルも低下

普段開発・実装をメインでやっていないPdM/QAEも、すぐに起票できるようになったことも大きな変化です。

こうした人たちの文脈を適切にドキュメンテーションできるかが重要なのですが、以前は課題がありました。特にPdMは忙しく、丁寧にドキュメンテーションするのも大変なため、口頭説明やSlackでの簡単な説明にとどまり、それらが宙に浮くという状況が散見されていました。

しかし、GitHub Projects＋AI起票によって、PdM自身でも起票のハードルが下がりました。さらに、ソフトウェアエンジニア側が起票代行するハードルも低くなりました。その場で理解したことを忘れる前に、SlackのログをコピペしたりMTGの文字起こしを渡せば、ほぼゼロコストで起票できます。

QAEも、各プラットフォームごとに似た内容を起票するなどのトイルがありましたが、今では手間少なく情報量多く、バグの指摘や修正背景・内容を起票できるようになりました。情報ロストの回避にかなり役立っています。

まとめ：AI前提の仕事をいかに邪魔しないか

この記事では、NotionからGitHub Projectsへタスク管理ツールを移行した経緯について紹介しました。

移行の背景にある最も大きな理由は、AIを活用しても転記が必要で、起票コストが下がらなかったことです。AIで内容をまとめることはできても、それをNotionに転記する手間が残ってしまい、AI活用の阻害要因になっていました。

GitHub Projectsに移行したことで、CLIから直接起票でき、転記作業が不要になりました。その結果、タスクに詳細な背景や文脈を記載するハードルが下がり、ドキュメンテーションが自然と充実するようになりました。

ツール選定の判断軸が変わってきている

この経験を通じて感じたのは、AIありきの仕事をいかに邪魔しないかという視点でツール選定をする重要性です。

従来は、ツールの機能の豊富さや UI の使いやすさが重視されていました。しかし、AIを活用した開発が前提になると、CLIでの操作性やAIとの統合しやすさといった、異なる観点が重要になってきています。

ツールの良し悪しの基準が変わってきている感覚があります。今後も、この視点を意識してツール選定をしていきたいと考えています。

---

このツール変更の背景にある開発プロセスの変更については、前回の記事「スクラムからカンバンへの移行——ソフトウェアエンジニアがマネージャーになる時代に」も合わせてご覧ください。

この記事が、同じような課題に取り組むチームの参考になれば幸いです。

脚注

1. GitHub Copilot CLIは2025年9月に公開プレビューとしてリリースされました。ターミナル上で直接GitHub Copilotのエージェント機能を使え、リポジトリ、Issue、PRに自然言語でアクセスできます。MCPサーバーのサポートも含まれており、カスタムMCPサーバーで機能を拡張できます。参考: GitHub Copilot CLI is now in public preview

2. GitHub Projectsは開発者向けのツールであるため、エンジニア文化以外の人との連携が欠点になる可能性があります。Notionのような一般向けツールと比べると、非エンジニアにとってはハードルが高いかもしれません。ただし、私たちのチームでは現状同期的に仕事をする人たちは全員GitHubを使うため、この点は問題になっていません。チーム構成や協働する人々の範囲によっては、Notionのような汎用ツールの方が適している場合もあります。