見出し画像

プロダクト開発に必要なもの全部繋げたらCursorが最強のプロダクトマネージャーになった

Ubie株式会社で病気のQ&Aのプロダクトマネージャー(PdM)を務めている、田口(@guchey)です。
Cursorをプロダクトマネジャーが活用する記事を見て、自分もプロダクトマネジメント業務の中心をCursorにしてみることにしました。

威力

すごい。各所にあった知識を集約した結果、自分の認知限界を超える相棒になりました。

現在のスプリント、バックログアイテム、OKR、ユーザーストーリー、主要メトリクスを把握したAIは、プロダクトの現在地から未来の姿まで詳細に把握したAIプロダクトマネージャーだった。

ディレクトリ構成

今はこんな構成にしています。

cursor_pdm/
├── .cursor/              # Cursor AI 用の設定ファイル
│   ├── mcp.json          # MCP設定ファイル
│   └── rules/            # Cursor AIルール
│       ├── 000_general.mdc
│       ├── 001_github.mdc
│       ├── 002_jira.mdc
│       ├── 003_notion.mdc
│       └── 004_statistics.mdc
├── knowledge/            # プロダクト固有のドメイン知識
│   ├── JIRA.md           # 利用しているJIRAボードに関する知識
│   ├── OKR.md            # チームOKRに関する知識
│   ├── ユーザーストーリー.md
│   ├── ダッシュボード.md
│   └── PBI作成ガイド.md
├── repo/                 # 各種リポジトリの参照用コピー
│   ├── xxx/             
│   └── yyy/            
├── workflows/            # 型化されたワークフロー定義ファイル
│   ├── PBIプランニング.md
│   ├── PBIリファインメント.md
│   └── スプリントレビュー.md
└── tmp/                  # 一時ファイル用ディレクトリ

まず、knowledgeに格納したデータにはメンションするだけでChatから簡単にアクセスできます。普段利用しているSaaSのURLを羅列します。
JIRA.mdはこんな感じで書いてます。

# JIRA

以下が利用しているJIRAのボードです。
https://xxx.atlassian.net/jira/software/projects/XXXX
Cursorが情報にアクセスできるようになる

OKRの進捗の確認をするようなユースケースであれば、単にそのページを見ればよかったのですが、各所に散らばったドキュメントを掛け合わせたいときに真価を発揮しました。
OKRとユーザーストーリーと掛け合わせた壁打ちなどが簡単にできます。

OKR壁打ちの開始

型化された資料作成などの業務はワークフローに事前にやるべきことを書いておけばワンパンで完了します。
例えば、スプリントレビュー用の資料の作成ワークフローを(スプリントレビュー.md)のような名前で作成しておけば、内容に従って各所に散ったデータを統合してnotionに書き出してくれます。

テンプレに従って、集めた情報を整理してnotionに出力

ワークフローの実行は、作成したワークフローファイルをメンションするだけです。スプリントレビュー.mdはこんな感じで書いています。

# スプリントレビュー資料作成

<workflow>
1. ユーザーストーリー.mdを読んで内容を理解する。必要に応じてMCPを実行する。
2. OKR.mdを読んで内容を理解する。必要に応じてMCPを実行する。
3. JIRA.mdを読んでスプリントゴールやPBIの内容を理解する。必要に応じてMCPを実行する。
4. ./tmp/sprintreview/goal.mdにスプリントの内容として理解したこととOKR、ユーザーストーリーの内容と紐付けて出力してください。
5. JIRA.mdを読んで完了レーンのPBIの課題キーを取得します。
6. githubのPRを完了レーンの課題キーで検索して、課題に紐づくPRを取得します。
7. ./tmp/sprintreview/pr.mdに完了レーンのPBIとPRの主要な変更内容と注意するべき点を出力します。
   1. 出力する際はPBIタイトル、PBI URL、PRタイトル、 PR URL、PBI担当者、PR担当者、主要な変更、主要な注意するべき点をリストで出力して下さい。
8. ダッシュボード.mdを読んで主要なメトリクスの変化を理解する。必要に応じてMCPを実行する。理解したことを./tmp/sprintreview/metrics.mdに出力してください。
9. <template>タグで指定したテンプレートに従って、./tmp/sprintreview/template.mdを作成してください。
10. ./tmp/sprintreview/goal.md、./tmp/sprintreview/pr.md、/tmp/sprintreview/metrics.mdに出力したことを理解して./tmp/sprintreview/template.mdを更新してください。
    1.  <okr>ブロックにはOKRの進捗状況を出力します。
    2.  <lightdash>ブロックには主要メトリクスの状況を出力します。ABテストに関する言及がある場合、統計的な分析を行なってください。
    3.  <jira>ブロックにはスプリントゴール、PBIとOKR、指標の関係を記載します。
    4.  <demo>ブロックには完了レーンの完了レーンのPBIとPRの主要な変更内容と注意するべき点を出力します。
11. ./tmp/sprintreview/template.mdの内容をユーザーにレビューしてもらってください。
12. 内容がOKであればnotionに出力するための空のページをユーザーに依頼してください。
13. notionに出力します
    1. 見出しは背景色をグレーにしてください。
    2. 箇条書きリスト、番号付きリストを適切に使ってください。
    3. GitHub、JIRAのURLはEmbedしてください。
</workflow>

<template>
```markdown
# チェックイン、目的の共有
まず、簡単にスプリントレビューの目的やタイムボックスやワーキングアグリーメントを説明します(例えば、携帯電話をマナーモードにする、アプリの通知をオフにする、発言時以外はマイクをオフにする、など)
開発者にとってはステークホルダーとの数少ない接点なので、そのステークホルダーが初参加なのであれば、参加者がそれぞれ名前や役割などを自己紹介します

# プロダクトとプロダクトゴールの紹介
<okr>OKRの進捗を紹介</okr>

# プロダクトを取り巻く状況の共有
<lightdash>主要指標の確認</lighdash>

# スプリントの概要の共有
<jira>スプリントの内容をまとめます</jira>

# インクリメントのデモとフィードバック、Q&A
<demo>完成したインクリメントのデモを行います。人間が書くので完成したインクリメントを列挙してください。</demo>

# 今後の見通しや直近のスプリントでやろうとしていることの共有
TBD

# まとめ
TBD
```
</template>

## 注意点

指定されたファイルが見つからないときは検索して実行してください。
事前定義したスプリントレビュー用ワークフローをメンションして実行
必要に応じて各SaaSからプロダクトにまつわる情報を自動収集

PBIリファインメントの際は主要なメトリクス、ユーザーストーリー、OKRなども一緒にコンテキストとして与えることで、PBIの背景情報や得たい成果物が誰がみてもわかりやすいものになりました。作業完了時にJIRAのPBIも自動更新してくれます。
ハイコンテキストなPBIを書いてしまいがちだった自分としては、とてもありがたいです。

いいアイデアはその場でリファインしてPBIまで作成してもらう
Cursorが作成したPBI

プランニングの際はPBIとリポジトリをコンテキストで与えています。リポジトリの内容を把握してプランニングしてくれるので見積もりのブレが少なくなります。

ここまでくると、AIが建てたプランニングが完璧であれば、そのまま依頼して作業完了してしまうケースも多くあります。
チームメンバーの意見や他のステークホルダーの確認が必要なものだけ、持ち帰って検討してプランニングが完了したら、再びPBIのURLを与えて実装をお願いします。

プロダクトマネージャーやエンジニアといった人間の仕事は、重要で難易度の高いものだけになりそうです。
もっと早く全部の情報をCursorに集約すればよかった。

MCPサーバー

社内の散らばった情報を集約して、Cursorに知識を与えるためにMCPサーバーは不可欠です。
今回は社内で使っているSaaSに合わせて以下のものを設定しました。

JIRA(スクラム)

Notion(ユーザーストーリー・OKR・ドメイン知識)

Lightdash(分析)

Git/GitHub

Git/GitHubに関してはMCPサーバーもあるのですが、CLIをCursorに許可させた方が無駄にアクセストークンを払い出す必要がないので使いませんでした。単にproject rulesにCLIの使い方を書いておくだけでいいのでMCPサーバーの設定よりも簡単かもしれません。
また、CLIも選択肢に入ってくるとMCPサーバーの有無を問わなくなってくるので連携できるサービスが増えます。

まとめ

CursorはAIコードエディタにあらず。AIプロダクト開発エージェントです。

最後に

今後も生成AI関連の情報を発信するのでよろしければぜひフォローお願いします!

いいなと思ったら応援しよう!