TL;DR
- PMのチケット作成～整理業務をNotion MCP x Claudeで約30分→5分程度に短縮できた
- チケットが自動生成されることで、一次情報収集にリソースを再投下し意思決定の質が上がり、実装時のコミュニケーションコストも低くなる
- Notion MCPの仕様で、API callが長大になるためチケットを作るまでの時間が1~2分かかり、rate limitにも達しやすいなど一部欠点もある
- アウトカムを出すために重要なのは、「何を作るか」ではなく「何を作らないか」を見極めることなので、人間はそこに注力すべき
自己紹介
カミナシ StatHack カンパニーCEOの松葉です。
6月にカミナシからリリースした「AIラベル検査」のプロダクトマネジメントを担当しています。
プロダクト開発、情報整理よりも一次情報収集にリソース割きたい
カミナシでは「現場ドリブン」のバリューの元、顧客の一次情報を最重要視してプロダクト開発をしています。 プロダクトマネージャー（PM）の役割の一つは、「顧客の一次情報を集め、それを適切に整理・分析し、売れるプロダクトの仕様を決める意思決定を継続的に行うこと」だと私は考えています。
しかし、現実には顧客の意見をユーザーストーリーへと整理し、開発チームが議論可能な状態にまとめる作業に多くて1回の打ち合わせにつき最大30分ほど時間がかかっていました。
そもそも、プロダクト開発は不完全情報ゲームであり、情報を整理し頭の中で考えるだけでは答えは出ません。限られた時間を既存知識の整理に費やすのではなく、一次情報の収集に最大限フォーカスする必要があると感じていました。
具体的には、以下の課題に直面していました。
- 顧客インタビューの内容をユーザーストーリーへと整理し、優先順位をつける作業に時間がかかる。
- インタビュー内容の一部しかユーザーストーリーに反映されないため、実装段階で追加のコミュニケーションコストが発生する。
- 顧客の要望を漏れなくユーザーストーリー化する作業が煩雑。
- ユーザーストーリーの数が増えると優先順位管理が難しくなり、声が大きい顧客や直近の顧客の要望が優先されやすくなる。
ユーザーストーリーの整理・構造化を自動化したい
こうした状況を解決するため、「ユーザーストーリーの整理・構造化」をNotion公式MCPを活用して自動化し、PMのリソースを本来注力すべき仮説検証と意思決定に再配分できる仕組みを構築することを目指しました。
※ユーザーストーリーとは、「誰が、何を、なぜ」したいのかを短く表した、ユーザー視点の要件記述です。私のチームでは、ユーザーストーリーを起点として優先度の議論、開発チケットの整理を行なっています。
NotionのAPIキー取ってきてMCP設定するだけで設定完了
構成の全体像は以下の通りです。
- NotionのIntegrationsからシークレットキーを作成します。
- 作成したシークレットキーを
claude_desktop_config.jsonに設定します。
{ "mcpServers": { "notionApi": { "command": "~/.volta/bin/npx", "args": [ "-y", "@notionhq/notion-mcp-server" ], "env": { "OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer ntn_xxxxx\", \"Notion-Version\": \"2022-06-28\" }" } }, }, "globalShortcut": "" }
- Claude DesktopでMCPツールとして利用可能になります。
コツ：プロンプトはしっかりめに書いた方が良い
プロダクトの内容を把握してチケットを起票してもらうために、かなりの情報をインプットする必要があったので、Claude ProjectとGitHubを活用してコンテキストを提供しています。
Claude Projectの中のメッセージは全て、プロジェクトのナレッジがコンテキストとして参照された状態で回答されます。
実際に使っているプロンプトは以下の通りです。
1つ目のチケットの起票ルールについては、やってほしいことをただ書いてあるだけです。
2つ目は、目的とするDBにNotion APIを用いてどのようにアクセスすればいいかを書いています。DBにどのようなプロパティがあって、それらにどのように値を入れるのかを整理しておかないと、存在しないプロパティを読もうとしてリトライし続けるので以下のように事前にインプットしておく必要があります（重要）
ちなみにこれは0から書いたわけではなく、数回試行錯誤してうまく行った後に、「やり方まとめて」とドキュメント化してもらったものです。（なのでコピペしただけ）
# チケット起票ガイドライン ## 基本ルール - **既存チケットの確認**: 新規チケット作成前に既存の類似チケットを確認する - **統合検討**: 類似チケットがある場合は統合を検討する（迷った場合は相談） - **要件確認**: 要件について不明点がある場合は、Notionに記載する前に相談する ## チケット構成 チケットには以下の要素を含める： ### 1. 背景と課題 - 現状の問題点 - なぜそれが課題なのか - 解決する必要性 ### 2. 要求仕様 - 項目ごとに記載 - 必須項目とオプション項目を明確に区別 - （必須）必須の要求仕様項目 - （できれば）あると望ましい要求仕様項目 - 各要求の要望者情報を記載 例： > （必須）検索機能の実装（XX食品） ### 3. 残存論点 - このチケットを実装するにあたって、追加でどのようなことが明らかになっている必要があるかを考え、論点として残してください - 優先順位・トレードオフを把握するために必要な問いを立ててください
# チケットボードへのユーザーストーリーと内容記載方法ガイド ## 概要 このドキュメントは、Lobsterチケットボードに新しいユーザーストーリーを登録し、その詳細内容をページ本文に記載する方法を説明します。Notion APIを使用して新しいページ（チケット）を作成し、コンテンツブロックを追加する手順を詳細に記載しています。 ## API リクエスト構造 ### エンドポイント API-post-page ### リクエストパラメータ #### parent (必須) データベースIDを指定します。 json { "database_id": "1211b6030685802ba525d71f243c42d2" } #### properties (必須) 以下のプロパティを設定します。 | プロパティ名 | 説明 | 形式 | | --------------- | ------------------------------------ | ------------ | | title | チケットのタイトル（達成したいこと） | title配列 | | チケットタイプ | ユーザーストーリーかタスクか | select | | 起案者 | 要望を出した人や組織 | rich_text | | 役割[~として] | ユーザーの役割 | select | | ステータス | チケットの状態 | status | | 対応時期 | いつ対応するか | select | | 理由[なぜなら~] | 要望の理由 | rich_text | | カテゴリ | 機能カテゴリ | multi_select | | 優先度 | 高・中・低 | select | ### プロパティ値の例 #### title (必須) json { "title": { "title": [ { "text": { "content": "検査結果の変更履歴を記録する" } } ] } } #### チケットタイプ json { "select": { "name": "ユーザーストーリー" } } #### 起案者 json { "rich_text": [ { "text": { "content": "顧客" } } ] } #### 役割[~として] json { "select": { "name": "管理者は" } } #### ステータス json { "status": { "name": "未着手" } } #### 対応時期 json { "select": { "name": "優先度順にやる" } } #### 理由[なぜなら~] json { "rich_text": [ { "text": { "content": "現状では検査結果を変更した際の履歴が残らないため、誰がいつ変更したのかわからないため" } } ] } #### カテゴリ json { "multi_select": [ { "name": "管理画面" }, { "name": "UI" } ] } #### 優先度 json { "select": { "name": "高" } } （以下略）
使い方：打ち合わせの議事録を貼り付けてチケットを自動起票
実際の運用方法はシンプルです。打ち合わせの議事録を貼り付けて送信すると、Notionのデータベースにユーザーストーリーが自動起票されます。
起票時には、AIが類似のチケットを検索し、内容が重複している場合には統合して登録します。
また、要求仕様と受け入れ条件も、要望から推論して叩き台として記載するようにしています。
Notion上では新しいページとして追加され、プロパティも自動的に埋められるため、チケット管理の手間が削減されます（ここは非常に便利。自明なプロパティをぽちぽち埋める時間ほど退屈な時間はないので）。
導入してみて：非常に便利だが遅い
良かった点として、暗黙知として存在していた仕様や細かな背景情報まで丁寧に記録してくれるため、結果的にローコンテキストで明確な仕様説明が作成できるようになりました。これにより、後から振り返る際や外部とのコミュニケーションが円滑になりました。また、AIが詳細に背景や想定仕様を記述することで、チームとのコミュニケーションコストも低下し、（実装時にAIにそのまま頼んだりして）迅速に実装が実現するケースもありました。
どれくらい期待に沿うアウトプットが出るか？についての所感は以下の通りです。
- 重複した要望があれば探して統合してくれるのはとても便利。人間が整理すると思いつくままに追加されていて重複チケットが大量に発生してしまい管理しにくくなるので。
- 会話履歴やプロジェクトナレッジから「どのようなプロダクトなのか？」を解像度高く理解して記載してくれるので、適切な粒度の要件を提案してくれることが多い
- 仕様を過剰に書く時がある。多めに書いてもらって後で消せばいいので問題はない。
- 打ち合わせ文字起こし全体を投げて要望を拾うタスクの精度は微妙なので、自分で「この要望とこの要望をユーザーストーリーに起こして」と指示してしまった方が早い
苦しかった点
一方で苦しかった点は以下の通りです。
処理速度が遅い
Notion APIがページをブロック単位で追加していく仕組みのため、ページが作成されるまでに約1〜2分待たされる。GitHub - karaage0703/notion-mcp-lightを利用すると約6倍速で処理できる可能性があるため、改善余地はある。
APIトークン消費量の制限
Notion APIのPost Request を送るために消費されるtokenが非常に多く、2〜3回のチャットでClaudeのメッセージ上限に達してしまい、作業が中断される。
そもそもNotionの以下の仕組みそのものが結構AIに不向きだなと感じました。
- ブロックごとにデータを持っており、全てのページの情報を取ってくるなどの操作がやりにくい
- APIのRequestで指定すべきプロパティが膨大で、Requestを送るたびに膨大なtokenが消費される
長期的にAI Drivenなプロジェクトマネジメントを目指すのであればNotion以外で管理した方が良いなと感じました（が、人間も操作することを考えるとNotion は使い続けたいので悩ましい）
アウトプットの速度と量は増えるがアウトカムを出すのは人間
この仕組みで楽になった部分は多いのですが、AIの限界と人間が注力すべきことも見えてきたので、最後にその点についても触れておきます。
そもそも入力するヒアリング議事録、つまり顧客の話した内容に意味のある（=プロダクトの価値を上げるための）情報が含まれていなければ、そこから価値のある示唆は何も得られないという点です。Garbage in, garbage out です。
結局重要なのは顧客から何を引き出すか？であり、「疑問」「問い」の質が重要だと考えています。
例えば我々のAIラベル検査開発初期にぶつけてきた疑問、問いには以下のようなものがあります。
- ラベル印刷機のバーコード読み取り機能を使えば、商品選択を間違えることはあり得ないのに、なぜさらに3重チェックをやっているのか？（→問いを突き詰めることでどうしても間違えてしまうシチュエーションを把握しそこを防ぐことに注力できた）
- 表示原本と印刷ラベルが違う表記になってしまうミスが発生するのは、既存ソフトのCSVインポート機能で解決しないのか？（→実際大部分が実は既存の仕組みで解決することが判明し、作る必要は無くなった）
探索・開発の中で、このような問いをぶつけていくことで、「顧客が真に必要としている解決策」が見え、最短で価値を出すことができたなと実感しています。
AIを活用することで、アウトプットの量とスピードは向上しますが、アウトカムを出すために重要なのは、「何を作るか」ではなく「何を作らないか」を見極めることなので、やる必要がないこと、やらなくていいことを適切に情報を集めて意思決定していくのは、まだ人間が意志を持って行わなければならないと再認識しました。
