Cursorで要件定義がエラいスムーズになった話

Cursor擦り倒すシリーズ

1. Cursorで要件定義がエラいスムーズになった話　←本稿こちら
2. （続）Cursorで「詳細設計→ガントチャート草稿」作成がめっちゃ楽になった話
3. 「Cursor」×「A5:SQL Mk-2」でテーブル定義書をリッチにする
4. 「Cursor」×「Obsidian」内部リンク生成＆最適化プロンプト

はじめに

AI搭載エディタCursorを色々と試しているのですが、これが非常に興味深いです。
普段の開発業務はもちろん、少し工夫することで、要件定義のような上流工程も大幅に効率化できるのではないか？という気づきがありました。

本日はその試みについて、私が行った具体的なプロセスと合わせて共有できればと思います。

概要

不動産テック業界に限らず、SaaS開発などに携わっていると、日々さまざまな要望が寄せられますよね。
「ここにこんな機能を追加したい」「あの画面のここをこう変更してほしい」といった具合です。

そして、それらを適切に実現するためには、まず要件定義をしっかりと行う必要があります。
これがまた、なかなか骨の折れる作業です。

• そもそも、その要望は本当に実装すべきなのか？
• 実装するとして、既存システムへの影響範囲はどこか？
• 影響範囲を正確に特定し、必要な工数を見積もり…
• 関係各所との合意形成を図り…

といったプロセスには、かなりの時間と労力がかかります。
さらに、担当者によってアウトプットの質にばらつきが出たり、考慮漏れが発生したり… 頭を抱えるような場面も少なくないでしょう。

特に、私のようなエンジニアリングマネージャー（EM）の立場では、複数の開発プロジェクトを俯瞰したり、メンバーの相談に対応したりしながら、こうした要件定義に関連する業務も期待される場面が少なくありません。

そこで、Cursorの活用を思いつきました。

このツールの大きな利点は、ローカルのコードベースを理解した上でAIが開発をサポートしてくれる点です。
これこそ、要件定義プロセスと非常に相性が良いのではないかと考えた次第です。

まずは「プロジェクトの前提」をインプット：プロジェクトルール設定

最初に取り組んだのは、Cursorに対して**「このプロジェクト固有のルールや背景」を教え込むことです。
AIに対する初期設定**、あるいはコンテキストの共有と言えるでしょう。

### 💡 Cursor Prompt : RULES_SET
# チャットが冗長になるため、コア情報以外のスクリリプト・サンプルコードは出力しないでください。

以下を Markdown でまとめ、Cursor の `rules` に上書きしてください。

- 目的： {{ 例: 顧客満足度向上と業務効率化のための機能改善 }}
- 背景： {{ 例: 特定のユーザーセグメントからの要望が多い、競合と比較して機能が不足している }}
- ゴール： {{ 例: ○○機能により、△△業務の所要時間を××%削減する }}
- スコープ： {{ 例: 管理画面の○○機能のみ、API連携は含まない }}
- 制約条件： {{ 例: リリース日はYYYY/MM/DD厳守、既存DBスキーマへの影響は最小限に }}
- 判断基準（優先順位）： {{ 例: 1. 法令対応, 2. 重大バグ修正, 3. KGI/KPIインパクト大, 4. 顧客要望（複数社）, 5. 工数小 }}

これを rules に設定しておくことで、以降のAIとの対話において、常にこの**「プロジェクトの前提」**を考慮した回答を引き出しやすくなります。
毎回「このプロジェクトでは…」と説明する手間が省けますし、判断基準の統一にも繋がると考えました。

「対応すべきか？」を迅速に判断：要件定義（単発要望版）

次に、具体的な要望が寄せられた際のフローです。
例えば、ビジネスサイドから「管理画面に検索フィルタを追加したい（取引ステータスで絞り込みたい）」といった要望が来たと仮定します。
ここで、以下のプロンプトをCursorに入力します。

### 💡 Cursor Prompt : REQUIREMENT_GATHER_SINGLE
# コア情報以外のスクリプトは不要。表ではなく項目列挙で出力してください。

【入力データ】
- 要望ID　　　：{{ REQ-1234 }}
- タイトル　　 ：{{ 例: 管理画面に検索フィルタを追加 }}
- 概要　　　　：{{ 取引ステータスで絞り込みたい }}

【タスク】
1. リポジトリを静的解析し、影響箇所を推定
   - 画面 / クラス・メソッド / DB テーブル
2. **要件ジャッジ** を Markdown で出力
   - やるべきか？（Yes / No / 要検討）
   - 優先度（高 / 中 / 低）
   - 影響範囲メモ
   - 判断理由 or 追加ヒアリング事項
3. 「要検討」の場合は **営業 / クライアント向けヒアリング依頼文** を生成

ここでのポイントは以下の3点です。

• コードベース（リポジトリ）を静的解析し、影響箇所をリストアップしてくれること。
  • これを手動で行うのは時間がかかり、見落としのリスクも伴います。AIの得意分野と言えるでしょう。
• 事前に設定した rules （特に判断基準）と影響箇所情報に基づき、**「要件ジャッジ」**のドラフトを作成してくれること。
  • 対応要否、優先度、その根拠といった初期アセスメントをAIが支援します。もちろん最終判断は人間が行いますが、判断材料が整理されているだけで効率は格段に向上します。
• 判断に迷う場合（「要検討」）は、追加情報を得るためのヒアリング項目と、関係者（営業担当やクライアントなど）への依頼文面まで生成してくれること。
  • 「何を確認すべきか？」を考える時間を短縮できるのは、実務上、非常に助かります。
    この一連の流れにより、要望受け付けから影響範囲の特定、初期判断、ネクストアクション（ヒアリング）の明確化までが、かなり高速化されることが期待できます。

具体的な実装方針を検討：詳細設計 ― 方針作成

さて、「対応する」と判断された要望について、より具体的にどう実装するかを検討するフェーズです。
ここでもCursorの支援を活用します。

### 💡 Cursor Prompt : DETAIL_POLICY
# コア情報以外のスクリプトは省略。Markdown 見出し＋箇条書きで出力。

【タスク】
- 変更対象ファイル・関数
  - ファイルパス / 関数名 / 変更概要
- データ設計方針
  - 追加・変更・削除するテーブル/カラムと理由
- 画面設計方針（必要な場合のみ）
- 判断材料不足時はヒアリング依頼文を末尾に追加

ここでは、前のステップで特定された影響箇所を基に、

• どのファイルのどの関数を、どのように変更する必要がありそうか？
• データベーススキーマ（テーブル/カラム）に変更は必要か？必要であれば、どのような変更か？
• UI/UXの観点から、画面要素をどのように変更するのが適切か？
  といった、設計方針のドラフトを作成してもらいます。
  これも、ゼロから考察するのではなく、AIが生成した提案をベースに人間がレビュー・修正を加える方が、圧倒的に効率的です。
  もし、この段階で設計を進める上で判断材料が不足している点があれば、AIがそれを指摘し、必要なヒアリング依頼文を生成してくれます。これも便利な点です。

認識齟齬を防ぎ、精度を高める：レビュー＆ブラッシュアップ

設計方針のドラフトが完成したら、次はチームメンバーや関係者とレビューを行い、内容を精査していく必要があります。
そのためのレビュー用資料の準備も、Cursorに依頼します。

### 💡 Cursor Prompt : REVIEW_PACKET
# コア情報以外のスクリプトは不要。Markdown で簡潔に。

以下を最新版ドラフトに追加し、Markdown で提示してください。

- 処理フロー (mermaid)
- 開発工数見積（タスク別時間 & 合計人日）
- 未確定事項（要確認ラベル付き）

ここで生成を依頼するのは、

• 処理フロー図（mermaid形式）：実装イメージの共有と認識合わせに有効です。
• 開発工数見積もり：タスクを細分化し、それぞれの見積もり時間と合計人日を算出します（見積もり精度はAIの限界もあるため、最終的にはエンジニアの経験に基づいた調整が不可欠ですが、初期見積もりとしては有用です）。
• 未確定事項リスト：「要確認」といったラベル付きでリスト化されるため、レビュー時に議論すべき点が明確になります。
  これらの情報を、先に作成した設計方針ドラフトに追加してもらうことで、レビューに必要な情報が整理された形で得られます。これにより、認識齟齬の防止や議論の効率化が期待できます。

最終的なドキュメントを生成：ドキュメントアウトプット

そして最後に、ここまでのプロセスで生成・精査してきた情報を、最終的なドキュメントとして集約する作業です。
これも、もちろんCursorで効率化します。

### 💡 Cursor Prompt : FINAL_DOC
# 冗長なコード断片は省き、Markdown で統合。長すぎる場合は .md ファイルで出力。

- プロジェクトルール抜粋
- 要件ジャッジ結果
- 変更対象ファイル・関数リスト
- データ設計方針
- 画面設計方針
- 処理フロー (mermaid)
- 開発工数見積
- 未確定事項 & TODO

このプロンプトにより、最初に設定したプロジェクトルールから、要件判断、設計方針、処理フロー、工数見積もり、未確定事項・TODOリストまでが一貫性を持ってまとめられたドキュメントが生成されます。
ドキュメント作成の手間が大幅に削減されるのは、大きなメリットです。

試してみた結果と考察

実際にこのフローをいくつかの要望に対して適用してみたところ、要件定義プロセスの効率が明らかに向上したことを実感しています。

• 時間短縮: 特に、影響範囲の調査やドキュメントの初期ドラフト作成にかかる時間が大幅に削減されました。
• 精度向上: コードベースの静的解析により、人間では見落としがちな影響箇所を検出できるケースがありました。（この機能は強力です）
• 属人化の軽減: ある程度標準化されたプロセスで進められるため、担当者によるアウトプット品質のばらつきを抑制しやすくなったと感じます。
• コミュニケーションコスト削減: 議論のベースとなる情報が整理されているため、関係者とのコミュニケーションがよりスムーズに進むようになりました。
  もちろん、AIが生成する内容はあくまで「ドラフト」や「提案」であり、必ず人間のエンジニアがその内容を精査し、最終的な判断を行う必要があります。これは言うまでもありません。
  しかし、煩雑な作業や定型的なタスクをAIに委譲することで、人間はより本質的な課題の特定、解決策の考案、技術的な意思決定といった、高度な領域に集中できるようになる。これは非常に大きな価値だと考えています。

これからのエンジニアとAIの協業

AIツールの進化に伴い、「エンジニアの仕事はAIに奪われるのでは？」といった議論も聞かれます。
しかし私は、むしろ逆の可能性を感じています。
定型業務をAIに任せることで、エンジニアは、

• より複雑で高度な問題解決
• 新しい技術の評価・導入・活用推進
• ビジネス要件の深い理解に基づく能動的な提案
• チーム全体の生産性や開発者体験（DX）の向上
  といった、より付加価値の高い活動へとシフトしていくのではないでしょうか。
  これは、私が提唱している**「つよつよエンジニア」（技術力に加え、ビジネスへの貢献意欲と周囲への良い影響力を兼ね備えたエンジニア）の姿とも重なります。
  ビジネス『も』できる（『が』できる、ではなく『も』できる、という点が重要です）エンジニアにとって、AIは脅威ではなく、自身の能力を拡張するための強力なツールセット**となり得るはずです。
  今回のCursor活用例は、単なる作業効率化だけでなく、
• どのようなプロンプト（指示）を与えれば、AIは期待通りのパフォーマンスを発揮するか？
• AIの生成結果をどのように解釈し、どう実務に適用するか？
• AIと人間がどのように役割分担し、協業すれば、チームとしてのアウトプットを最大化できるか？
  といった、AIとの協業のあり方を考える上で、非常に示唆に富む経験となりました。
  エンジニアリングマネージャーとしても、こうした視点を持って技術活用の可能性を探求し続けることの重要性を再認識しています。
  今回は、Cursorを用いて要件定義プロセスを効率化する試みについてご紹介しました。
  まだ改善の余地はありますが、AIをうまく活用することで、日々の業務をよりスマートに、より創造的に進められる可能性を強く感じています。
  もし、皆さんの現場で「こんな風にAIを活用している」といった事例があれば、ぜひ情報交換させていただけると幸いです。
  ぜひ、皆さんもご自身の業務プロセスにAIを取り入れる可能性を探ってみてください。きっと面白い発見があるはずです。