こんにちは、ものづくり部ICTチームの、んだです。 好きな銘柄はキリンラガーで、２児の父です。
生まれと育ちは山形ですが、佐賀県からフルリモートで働いています。
さて、今回は
「CursorとClaude Codeで開発の意思決定を爆速にさせようとしている話」
というテーマでお届けします。
はじめに
ユーザーから日々届く要望。仕様をスピーディーに決めて、ユーザーに素早く価値提供したい。
でも、実際の会議では情報集めや根拠探しに時間がかかって、なかなか本題にたどり着けない――。
そんな悩みを、CursorとClaude Codeでどう変えられるのか。
SENで実践している“やるやら判定”を例に、リアルをお伝えします。
意思決定のための情報収集＆認識合わせで時間が溶ける...
前述の通り、仕様検討の段階では様々な疑問が浮上し、その都度情報を収集するために多くの時間が必要でした。
- 「この機能って、どれくらいのユーザーにどれくらい使われてるっけ？」
- 「他の要望ってどんなのがあるっけ？」
- 「この機能の実装って、結構複雑じゃなかった？」
- 「これを実装すると困るユーザーはいそう？」
こうした疑問に答えるため、従来は手作業での調査や関係者への確認が必要で、会議や意思決定のスピードが大きく損なわれていました。
そこで私たちは、CursorとClaude Codeを活用し、情報収集・分析・レポート生成の自動化を進めることにしました
CursorとClaude Codeを使った意思決定プロセス
具体的に、以下のような情報を自動で収集・整理してます。
.cluade/構成
.cluade/judgement ├── 要求定義書.yaml ├── 2_競合他社機能調査 │ ├── 競合_該当機能概要.yaml │ ├── 競合他社機能調査.md │ └── 競合他社機能調査.yaml ├── 3_機能利用率集計 │ ├── 機能利用率集計.md │ └── 機能利用率集計.yaml ├── 4_顧客要望一覧 │ ├── 顧客要望一覧.md │ └── 顧客要望一覧.yaml ├── 5_UI確認 │ ├── UI確認.md │ └── UI確認.yaml ├── 6_ソースコード調査 │ ├── ソースコード調査.md │ └── ソースコード調査.yaml ├── 7_影響範囲・工数・リスク調査 ├── 8_将来要望予測.yaml ├── 9_最終判定.yaml
会議の前には、こうした各種yamlファイルをもとに、必要な情報を自動で整理・出力する仕組みを整えています。
CursorとClaude Codeの使い分けですが、現在ではほとんどClaude Codeで一発で生成させています。ただ、どんどん生成させてプロンプトを微調整しているので、同時に動かしていることも多々あります。
具体的には、CursorやClaude Codeを活用し、要件定義や競合調査、利用率集計、要望一覧、UI確認、ソースコード調査など、意思決定に必要な材料を事前に自動生成しています。
これにより、会議の場では「情報集め」に時間を取られることなく、「本質的な意思決定」に集中できるようになりました。
具体的な自動アウトプット例
- 競合調査：主要な競合サービスの同等機能の有無や仕様、運用事例を自動で整理。公式情報や公開資料をもとに、事実ベースで比較できるアウトプットを生成。不明点は「未掲載」と明記し、推測や曖昧な情報は排除。
- 機能利用率集計：各機能がどれくらい現場で使われているか、利用率を自動集計。データベースやログから集計し、意思決定の根拠となる数値を可視化。集計方法や根拠カラムも明記し、再現性を担保。
- 他現場の要望集約：他の現場から寄せられた要望を横断的に抽出・グルーピング。似た要望の有無や、関連する具体的な声を自動で整理。代表的な要望例や背景も記載し、現場のリアルな課題感を共有。
- UI・画面構成の確認：対象機能の画面キャプチャや導線、操作手順を自動で整理。誰でも再現できる形で、現状仕様や運用手順を明記。
- ソースコード・技術的影響の可視化：対象機能の実装箇所や関連ロジック、データ構造を自動で調査・記録。影響範囲やリスク、技術的な複雑さも可視化し、判断材料を提供。必要に応じて、根拠となるコード断片や設計コメントも明記。
このように、AIは「競合調査」「利用率集計」「要望集約」「UI確認」「技術調査」など、意思決定に必要な多角的な情報を自動で整理し、会議前に“現場知見とデータ”が揃った状態を作り出します。 これにより、会議では「情報集め」ではなく「本質的な意思決定」に集中できるようになりました。
tips
全ての質を決める要求定義.md
要求定義.mdを一番大事にしています
これはもう、開発現場では何度も語られてきたことですが――いただいた要望を、そのまま機能として実現してしまうと、ユーザーが本当に欲しかったものとはズレてしまうことがよくあります。
「なぜそれが欲しいのか？」「ゴールは何なのか？」――よく言われる“フォードの名言”のように、表面的な要望の奥にある本質や目的を深掘りすることが、何より大切です。
この要求定義の精度が低いと、後続のドキュメントや意思決定もどんどん精度が落ちてしまいます。だからこそ、最初の要求定義だけは必ず人間がレビューし、生成のプロセスに乗せるようにしています。
影響範囲・将来要望予測で“悲観的な議論”をする
意思決定の際には、影響範囲.mdと将来要望予測.mdという2つのファイルも自動生成しています。
影響範囲.mdでは「この機能を実装したことで、どんなユーザーにどんな影響が出るか」「逆に不便になるケースはないか？」といった“悲観的な視点”でリスクや懸念点を洗い出します。
将来要望予測.mdでは「この要望を叶えたら、次にどんな要望が出てきそうか？」を先回りして考えさせています。たとえば「この条件で検索できるようになったら、次はこういう条件でも検索したいという声が出るかもしれない」といった具合です。
こうした“悲観的な議論”や“将来の発散”を事前に可視化しておくことで、会議の場でも議論が深まりやすく、意思決定の質が上がると感じています。
playwright mcpでスクショやUI確認をする
会議の場では「この機能を実現したら、どんな画面になるの？」というUIの確認をよく行います。そのたびに本番環境やステージング環境を誰かが立ち上げて、画面共有しながら確認する――実はこれ、意外と手間も時間もかかる作業です。
そこで、事前にplaywright mcpを使って、必要になりそうなページのスクリーンショットを自動で取得しておくようにしています。これにより、会議中は「この画面です」とすぐに見せられるので、認識合わせがとてもスムーズになりました。
ちょっとした工夫ですが、現場のストレスや無駄な時間を大きく減らすことができています。
うまくいかず工夫した点
ハルシネーション対策
要望整理を始めた当初は、AIが分からないことをそれっぽく埋めてしまう“ハルシネーション”が課題でした。
そこで、「分からない時は分からない」と正直に出力するルールを徹底しています。 - 不明点やカラム未特定時は「不明」と明記し、無理に埋めない - 公式データ以外の根拠なき情報は記載しない
このシンプルなルールで、AIの出力品質と現場の信頼性が大きく向上しました。
文脈の取り違えとduckDBによる改善
AIを活用していると、時々「食事チェック」と「検食簿」のような似た機能を取り違えて調査を進めてしまったり、「登園」の話を「従業員の出退勤」と混同してしまったりと、うまく文脈を読み取れないことがありました。
この課題に対しては、duckDBを活用してユビキタス言語や各機能のURLパス、コントローラー名などを整理し、まずは正しい文脈や機能の位置づけをAIが読み込めるように改善しました。
また、要望リクエストもduckDBに格納しておくことで、類似要望の検索や関連情報の抽出が高速かつ正確にできるようになりました。
こうした工夫によって、AIが現場の文脈をより正確に理解し、調査や意思決定の精度がぐっと上がったと感じています。
どうやって最終決定をしているのか？
意思決定の“最後の一押し”――ここが現場のスピードと納得感を大きく左右します。
SENでは「判断基準.md」と「プロダクトビジョン.md」を“軸”に、最終判定を行っています。
判断基準.mdには「現場の要望の強さ」「利用率」「工数やリスク」「競合比較」など、判断の観点が明文化されており、迷いなく判断できます。
会議ではCursorとClaude Codeで集めた材料を「最終判定.md」にまとめ、全員で読み合わせて議論します。根拠や経緯がすぐ分かるので、情報集めに時間を取られず、本質的な意思決定に集中できます。
この仕組みで、意思決定のスピードと納得感が大きく向上しました。
意思決定後は、duckDBに判定理由を保管
判定会議後のナレッジ蓄積と活用
判定会議が終わった後は、「なぜその判断をしたのか？」という理由や経緯を、duckDBにしっかり格納しています。
こうすることで、過去の意思決定の根拠が属人化せず、誰でもすぐに振り返ったり、次の判断材料として活用できるようになります。結果として、意思決定のスピードや納得感もどんどん高まっていくはずです。
具体的には、会議の内容をgeminiで文字起こしし、CursorやClaude Codeで要約・整理したうえで、duckDBに保存しています。
この仕組みを通じて、現場のナレッジがどんどん蓄積され、より強いチームになっていけると感じています。
現状の課題とこれから
その1：インプット量のジレンマ
今、会議のための情報収集はかなり精度が上がってきていますが、その分インプットしなければいけないドキュメントが増えてしまうというジレンマがあります。精度を上げようとすると、どうしても読むべき情報が多くなってしまうんですよね。
とはいえ、まだ取り組みを始めて2週間ほどの“発散フェーズ”なので、今は仕方ない部分もあると思っています。今後はduckDBなども活用しながら、より少ない情報で的確な判断ができる仕組みを目指していきたいです。
その2：リリースまでの爆速化
要望整理や「やる・やらない」の判断は以前より格段に早くなりました。次の課題は、「やる」と決めたチケットをどうリリースまで持っていくか、です。
ここはデザイナーやCSチームとも連携しながら、デザイン・実装・リリースまでを爆速で回すために、どんなデータ基盤や運用が必要かを現在検討しています。
課題はまだまだありますが、現場で感じたリアルな悩みも含めて、これからもアップデートしていきたいと思います。
おわりに
ここまでお読みいただき、ありがとうございました。
SENでは、AIと現場知見を組み合わせて、意思決定や要望整理の“もどかしさ”を本気で変えようとしています。まだまだ試行錯誤の連続ですが、現場のリアルな課題に向き合いながら、日々アップデートを続けています。
もしこの記事を読んで「千のプロダクト、ちょっと面白そうだな」「こういう現場で働いてみたいな」と思っていただけた方、弊社に興味ある方はカジュアル面談お待ちしておりますー!!
お気軽にどうぞーー！！！
