恐竜本舗

エンジニアをしている恐竜の徒然日記です。

開発から少し距離をおいて、事業やプロダクト戦略の壁打ちをCursor に全力補助輪してもらってる話

cursor キャリア

仕事上の役割が変わってきた

今年に入ってから、立場としてはエンジニアリングマネージャーとして変わらないものの、「事業推進」に近い仕事をすることが増えてきた。

プロダクトの話だけでなく、事業戦略の方針立てや事業 KPI の目標値試算など、開発の人よりも営業組織の方々や経営企画といった方々とお仕事をともに仕事をする割合が多くなってきた。

世間の開発事情でいうと、Claude Code や Cursor、ClineといったCoding Agent が一気に普及していて、そのモデル性能も迅速な勢いで向上しているし、界隈でのAI Coding(Vibe Coding)のナレッジ、プラクティスも蓄積されてきている。

一方で、個人としては全く他業種に近い分野に触れ始めて、

  • 売上目標の試算
  • 販管費などの原価試算
  • 市場分析、エリア分析
  • ロードマップ策定
  • プロダクト戦略と営業戦略のアライン
  • 事業の立案、アライアンスの検討

などなど、「プログラム」 と「英語」を眺める時間よりも「数字」や「漢字」、普段使わない単語を多く耳にする事が一気に増えた。

開発であれば、AI の利活用などを含めた、「いま学ぶべきもの」が明確に山ほどある(イメージできる)し、パフォーマンスを出していくうえでの「ふるまい」「サイクル」がある程度過去の経験で言語化できる。

でも、全然お門違いなナレッジ持ちで、こうした新たな仕事への向き合いに対し、何を知ればいいのかがまず分からない。業務の型ともいえる、登り方からさっぱり分からない。

どうやって貢献していけばいいのだろうか？この分野でバリューを出していけるのだろうか？

と1, 2ヶ月ほど苦悩していた。

分からなすぎて、最初はGemini で事業や飛び交う言葉、P/L などの経営情報の理解度の底上げを行い、そのうち、ナレッジをローカルに貯め始めて、Cursor でプロダクト戦略や事業戦略の壁打ち、ざっくりな試算の議論などを行い、急ピッチに

  • 「事業企画」
  • 「経営企画」
  • 「事業推進」

といった職務の咀嚼を進めてきて、仕事・個人にかかわらず、そこそこ自分なりのAI 壁打ちの基盤みたいなものがまとまってきたので、整理してみる。

Cursor

事業の壁打ちをしていくために、Cursor を選択した。

www.cursor.com

開発で日常的に使っていたことや、VSCode をフォークして作られているため、VSCode 勢の自分にとっては既に扱いやすかったため。

普通にChatGPT やGemini などでの壁打ちでも良かったが、「整理した内容を整理し、次のナレッジに活かすために蓄積していく」という工程がほしくて AI Agent でやっていくようにした。

Claude Code なども考えたが、Cursor は

  • Claude Sonnet 4
  • OpenAI o3-pro
  • OpenAI GPT-4.1
  • Gemini 2.5 Pro

あたりがモデルとして使えて、事業の壁打ちに何が合うのか物によってカジュアルに変えて使いたかったので、Cursor の勝手があっていた。

Cursor でのディレクトリ構成

Cursor でどのようなディレクトリ構成にして普段やり取りしているかをまとめてみる。

.
├── .cursor
│   └── rules/ # 後述のスクリプトでまとめて生成
├── .daitasu.local/ # gitignore してる雑多メモ場所
├── docs/
│   ├── config.yaml 
│   ├── database/ # DB関係の情報を蓄積している箇所
│   ├── general/ 
│   │   └── common.md # AIの回答の基本ルールなどをまとめてる
│   └── knowledge/
│       ├── formats/ # 日報のフォーマット、MCP実行時のルール、定型文の生成ルールなど
│       ├── missions/ # 自身の目指したい姿、振る舞い、目標、期待役割など
│       └── services/ # 事業やプロダクトの構造、競合情報、ユビキタス言語など
├── package.json
├── packages
│   ├── data/ #csv 形式で整理したい情報などで出力したものはここに一旦羅列
│   ├── diary/  # 日報もCursor に書いてもらっている
│   ├── 2025/ # 情報としては蓄積したいが、フロー情報として扱いたいもの
├── pnpm-lock.yaml
├── pnpm-workspace.yaml
└── scripts/
  └── tsconfig.json

基本としては、monorepo 構成にしていて、場合によって自前の script を扱えるようにしている。

docs

Cursor に読ませる前提の情報群 はこの配下にまとめている。

  • database/
    • DB には基本的にMCP 経由でつなぎ、簡易なテーブル構造のみを伝えておいて、スキーマ情報などはよしなに咀嚼してもらってクエリを出している
    • とはいえ、プロンプトだけで伝えるには情報が薄いので、MUST で抑えてほしい情報などはここに保持している
  • general/
    • マークダウンでの出力が中心になるため、マークダウンの抑えたい基本ルールはここに置いている
    • その他、すべての応答の前提としたいようなルールを置く
  • knowledge/
    • formats/
      • 日報を生成してもらっており、その基本ルールなどをまとめている
      • MCP に繋ぐ場合の前提情報や基本的な段取りなどもこちら
    • missions/
      • AI に自分の思想をトレースしたい
      • そのため、自分が描く自身の期待役割、ミッションや目標、期待する振る舞いなどを綴っている
      • これを置いておくことで、「どんな視座」で「どんなアプローチ」を主として思考するか、精度が結構変わった
      • わかりやすくいうと、「話が噛み合う」ようになった
    • services/
      • 仕事、個人など色んなサービスを扱うので、この配下で分けている
        • (個人と仕事はそもそもリポジトリを分けていて、それぞれの色んなサービスをぶら下げている)
      • 下記のような情報を重ねている
        • 事業構造、収益構造、業界の課題
        • プロダクトの機能一覧、差別化・優位性
        • ユビキタス言語
      • 略語とか、言い回しとかをイチイチ丁寧にプロンプトに打つのが手間だったが、この辺が揃ってきて勝手に解釈してくれるようになった

packages

こっちが主に出力部屋。

AIのコンテキストにはする予定がない、自分に対して のフロー情報を置いていく場所。

  • data/
    • 洗い出した情報整理された内容を、csv ファイルなどで出しておきストックしておく
    • ある程度最終的なアウトプットイメージができてきたら、SpreadSheet などに連動させてそっちに置く
    • 過程情報を置くイメージ
    • TypeScript で整形処理系のスクリプトなどを置いていて、ものによっては下記の工程を取ってる
      • Cursor でcsv 出力 → スクリプトでデータクレンジング → SpreadSheet 等に反映
      • この辺はもっとMCP経由の割合増やしてうまくする方法がありそう
  • diary/
    • 日報を書いてもらっている
    • 書いた日報は、チームのデイリースクラムのスレッドにMCP経由で投稿するなどしてる
    • 日報のテンプレートは下記みたいな感じ
      • 📅 {{date}}
      • 📋 今日の活動
      • 💡 気づき・学び
      • 🔄 次のアクション
      • AI 先生のフィードバック
        • コメント
        • ネクストアクション・改善案の提示
    • 正直面倒くさくて「気づき・学び」は書かず、活動も雑に書いてるのでフィードバック精度は悪い
    • Slack MCP で自分の会話を掘るとか、Google Calendar連動してMTGの自動取得とかちゃんとすればいいものにはなりそう
  • 2025/
    • 2025/前半/ , 2025/後半/ みたいな半年粒度でどこにも該当しないようなものを置いている
    • ガイドラインとはしたくないが、「今現時点で得たナレッジ」など、過程の情報を蓄積してる
    • ここから昇華して、docs/ 配下へと移っていく

MCP の活用

MCP はまだあまり使いこなしていない。

  • Slack MCP
    • 色んな職種のチャンネルに入って、何かしらのテーマで顧客情報の蓄積があればざっと収集・整理したり
    • 一番使うのは、「日報」から 今日の作業内容をチームのデイリースクラム周知 なのであまりイケてはいない
  • PostgreSQL MCP
    • これは割と使っている
    • DB接続からスキーマ読解 → クエリ生成
    • 細かなカラムなどまだ自身もドメイン知識が全然ないので、整理できた情報はそのまま docs/ 側に流していく
  • Github MCP
    • 事業の壁打ちの観点だと、あまり使い所がない
    • チームマネジメントで、プロジェクトの Issue の大量生成などには使う
    • コードベース側からドメイン知識を吸い上げる、に繋げるのがいいんじゃないかなと思っている
      • この辺やるなら、 Claude Code のほうがガンガンやってくれて相性良さそうな気がする

docs 配下をまとめてmdc ファイルにするためのスクリプト構築

Cursor は、 .cusror/rules/ 配下の *.mdc という固有のマークダウンファイルをコンテキストファイルとして扱う。

docs.cursor.com

この *.mdc ファイルは、ヘッダーにRule Types を置くことで、

  • 常にこのRuleを読むのか
  • 特定のパターンマッチング(globs) の際にだけ読むのか

などを細かく指定できる。

これ自体は便利なのだが、Cursor 専用の .mdc の機構が他のAgent ツールを使うとなるととても乗り換えが面倒くさくなる。

それに、Document 自体は普通のマークダウンで、自前の階層構造で柔軟性を担保したかった。

そのため、docs/ 配下を特定のカテゴリごとに1つの .mdc ファイルとしてまとめてくれる CLI を作り、これを使うことで、どんな docs 構造でも 意図した .mdc の構成にまとまるようにした。

このスクリプトについては、npm で公開して、どこでも使えるようにしている。

https://www.npmjs.com/package/@daitasu/aicontextr

github.com

結果

こうした取り組みで、

  • 欲しいデータをCursor で収集する
  • 情報整理と壁打ちをCursor で実施
  • クエリの出力結果はその後csv 吐き出しでスプシでインポート
  • 全員で触れる形で整形して展開
  • 次の解像度上げが必要なものを見つけ、サイクルを回す

みたいなことを繰り返し、Bizdev ? Product Manager ? どういう表現が正しいか分からないが、

新しい期待や振る舞いをしていくうえでの基盤、実質 下駄履き に近い驚異的な補助輪を得ることができた。

色々と事前知識が入ってくると、またDocが育ち、AI とのやり取りの練度も上がるはずなので、もう少し研究を深めていきたい。

最近は開発まわりでも進めたい部分がまた色々出てきて、個人的には Claude Code に振っていきたいので、事業壁打ちもClaude Code に寄せれないかを模索中。