手戻りを防ぐ、AI駆動プロダクト企画開発プロセス

はじめに

食べログカンパニープロダクト本部 PdM（プロダクトマネージャー）の阿部です。

本記事では、PdMとしてAIを活用し、個人の作業効率化だけでなく、チーム全体のプロダクト企画開発プロセスをどう改善したかをお伝えします。

紹介する内容はAIをプロダクト企画開発プロセスを改善するための仕組みとして位置づけた取り組みになります。

想定している読者は以下のような方です。

プロダクト企画開発に関わるPdM、エンジニア、デザイナー、QAの方
個人利用の域を超えてAIをチーム全体のプロセスに取り入れたい方

食べログのプロダクト企画開発プロセスと「手戻り」の課題

前提の共有：チームの開発プロセス

私のチームの開発プロセスは、大きく3つのフェーズで構成されています。

開発プロセス全体のフロー図

※プロジェクトによってどこまでをどのように対応するかが変化します。あくまでもフローを例示するための参考図となります。

企画・要求事項策定フェーズ
- 企画段階（Why）
- 要求事項策定（What）
要件定義・設計フェーズ
- 要件定義策定（How）
- 設計
- 設計完了
開発・QA・リリースフェーズ
- UI・開発作業
- QA（総合・受入れテスト）
- リリース・運用

このプロセスの中で、チームはフロー図で赤色に強調した「2. 要求事項策定」に起因する2つの課題を抱えていました。

「要求事項策定」プロセスで抱えていた、2つの具体的な課題

課題1: 上流の要求事項策定の品質を担保しきれない

要求事項策定が十分に実施しきれず、設計・実装・テストの段階で差し戻しが発生
ユーザーストーリーがEpic単位（提供価値単位）で整理されておらず、スコープ分割や優先順位づけが困難
受け入れ基準（Acceptance Criteria）が明確でない。ボリュームの多いプロジェクトでは手作業で全部定義するのが現実的に困難

課題2: 成果物の届け方が適切でなく、関係者との認識ズレが解消されない

仮に上流で網羅性のある要求事項策定ができたとしても、それを全く同じ形で関係者全員にデリバリーするだけでは機能しない
開発者・QA・法務・CS・営業・経営層など、関わるステークホルダーはそれぞれ求める情報の粒度・形式が異なる

課題の影響

手戻りが頻発し、チーム全体のプロダクト開発速度低下
PdMが本来時間をかけるべき「戦略や体験を考える時間」が減少
事前に見通しを立てるプロセスの強みが、上流の品質と届け方の問題によって活かしきれていない状態

これらの課題に対して、次のセクションでAIの位置づけを定義し、その後に具体的な解決策を示します。

AI-DLCの考え方をプロダクト企画開発に適用する

AI-DLCとは？

チームでは、AWSが提唱するAI-DLC（AI-Driven Development Life Cycle）の考え方を、プロダクト企画開発プロセスに適用しています。

参考: 『AIを使って開発』から『AI主体の開発プロセス』へ — AWS AI-DLC Unicorn Gym ワークショップで見えた、次世代の開発スタイル

以前からAIの業務活用を個人レベルで進めていましたが、「個人が便利になる」だけではチーム全体のプロダクト開発速度は上がらないという課題にぶつかっていました。

AI-DLC Unicorn Gymへの参加は、個人利用からチームプロセスへの転換を模索する中で、その具体的な方法論を学ぶ機会として最適でした。

チームでは、AI-DLCの考え方を以下のように自分たちのプロセスに咀嚼して適用しました。

	従来	AI-DLC適用後
人間の役割	要件を整理し、必要な情報をすべてまとめた上でAIに作業を「依頼」する	AIの提案に対して判断・回答・承認する
AIの役割	依頼された作業を実行する	人間と共に作業計画を立て、アウトプットを出力し、不明点を人間に質問する

これは、以下2つの利点がありました。

人間は「Why」と「体験」に集中できる
- 「なぜやるのか？」「どんな体験を実現したいか？」に集中できる
- 考慮が漏れていそうな部分はAIが疑問点を挙げてくるため、網羅性が上がる
人間の「考えて止まる時間」が減る
- まずAIに提案させてみることで一歩を踏み出すのが早くなる
- 提案が出れば、それに対して「合っている/違う」を判断するだけで前に進める

Human-in-the-Loop：AIは提案し、人間が意思決定する

AI-DLCはAIに主導権を渡しますが、最終的な意思決定は必ず人間が行う。これがHuman-in-the-Loopの原則であり、チームのAI活用の大前提です。

役割	担当	具体的な責務
段取り・構造化・網羅性担保	AI	計画の提案、不明点の質問、ドキュメントのドラフト作成、パターンの洗い出し
WhatとWhyの意思決定	人間（PdM/デザイナー）	顧客の課題発見、戦略の方向性、AIの提案に対する判断・承認
確実な設計・実装・テスト	人間（エンジニア/QA）	AIが構造化した要件をもとに、信頼性の高いプロダクトを構築

AIの出力はあくまで「提案」。意図と合っているか、間違ったことを記載していないかは必ず人間が確認した上でドキュメントを更新します。

この原則を崩さないことが、AI駆動のプロダクト企画開発を安全に進めるための前提条件です。

導入当初：「わかる」と「できる」は全然違った

ここまで読むと整然としたフレームワークに見えるかもしれませんが、実際の導入はスムーズに進みませんでした。

最初のプロジェクトで痛感したのは、AIの提案を「それっぽい」という理由でそのまま通してしまう怖さでした。AIが生成したドキュメントの中に、細かい意図しないような要求が紛れ込んでいました。

また、慣れるまではAIのアウトプット速度に人間が追いつけない場面もありました。AIは数分で数十ページ分のドラフトを出してくる。人間はそれに対して次々と判断を下さなければならない。

「合っている/違う」「この方向で進めてよい/修正すべき」をクイックに何度も繰り返します。

しかし、この過渡期は約半年で収束しました。同じメンバーが半年後には「慣れると今までより楽」と語っています。

判断すべきポイントの見極めが速くなり、AIの提案に対して「ここだけ確認すればよい」という勘所がチーム全体で共有されるようになりました。

フェーズ別：手戻りを構造的に減らすAI活用実践プロセス

① Epic / User Story / Acceptance Criteria の作成（PdM × AI）

チームのプロセスではEpic/User Storyで提供する体験を定義し、要件定義・設計を経てスコープを決定します。

この上流の定義品質がプロセス全体の品質を決定します。

AIを「熟練PdM」として要求事項策定を代行させ、人間はレビューに集中する

AI-DLCの考え方に基づき、AIに「熟練したプロダクトマネージャー」の役割を与え、ユーザーストーリーの計画・作成を一貫して実行させる。

人間は計画のレビュー・質問への回答・修正指示・最終承認に集中します。

プロンプトテンプレートの活用

チームでは以下のようなプロンプトテンプレートをCursorのコマンドとして整備し、プロジェクトごとに繰り返し利用しています。

プロンプトテンプレート（抜粋）：

あなたの役割: あなたは熟練したプロダクトマネージャーです。
以下のタスクセクションに記載されているシステムを開発するための
契約となる、明確に定義されたユーザーストーリーを作成する任務を
担っています。ドキュメントはすべて日本語で生成してください。

作業の計画を立て、inception/user_stories_plan.md ファイルに
ステップを記載してください。各ステップにチェックボックスを
付けてください。いずれかのステップで私の説明が必要な場合は、
[Question] タグを付けて質問を追加し、私が回答を記入するための
空の [Answer] タグを作成してください。
独自の判断や決定は行わないでください。
計画を作成したら、私のレビューと承認を求めてください。

あなたのタスク: [ここにシステムの説明や要件を記載]

AIに「独自の判断をするな」「不明点は質問しろ」と明示的に指示することで、AIが勝手に仕様を決めてしまうリスクを排除しています。

AIが生成する成果物の全体像

このプロンプトを起点に、AIは以下の成果物を段階的に生成します。

inception/
├── user_stories_plan.md      # 計画（質問と回答を含む）
├── epics_definition.md       # エピック定義
├── user_stories.md           # ユーザーストーリー + 受け入れ基準
├── acceptance_criteria.md    # 受け入れ基準（Given-When-Then形式）
└── prioritization_and_mvp.md # 優先順位付けとMVP定義

実際のプロジェクトでの成果物例（抜粋）

1. user_stories_plan.md（計画ファイル）— AIが質問し、人間が答える

以下は外部公開可能な範囲に編集した、実際のプロジェクトの抜粋です。実際にはPJの大きさや事前インプットの内容に応じて質問数は増減します。

## 作業ステップ

### Phase 1: 要件理解とヒアリング
- [x] Step 1.1: 現状システムの詳細把握

[Question] 現在の通知の配信頻度・タイミング・配信数の
実績データはありますか？

[Answer] 店舗ごとにグラデーションがありますが、
大半の店舗は1日X件程度です。
タイミングに関してはユーザーの操作のタイミングに依存します。

[Question] 店舗と連携アカウントの紐付け方法について、
想定している仕組みはありますか？

[Answer] 管理画面上で店舗と連携アカウントを紐付ける形を
想定しています。連携設定は店舗の管理者が行い、
紐付けが完了した状態で通知機能が有効になります。

AIが仕様を理解するために必要な質問を自ら洗い出し、PdMはそれに回答する。従来PdMが1から考えて書き出していた要件の「抜け漏れ」を、AIの質問力で補完しています。

2. epics_definition.md（エピック定義）— 提供価値単位での構造化

### Epic 1: 通知設定管理
概要: ユーザーごとに通知のON/OFF設定を管理する機能
ビジネス価値:
- 役割に応じた柔軟な通知設定
- 通知過多の防止
- 多様な運用スタイルへの対応

### Epic 2: 当日一覧通知
概要: 当日の予約を朝にまとめて通知で配信する機能
ビジネス価値:
- 1日の状況を早期把握
- スタッフ間の情報共有円滑化

### Epic 3: リアルタイム通知
概要: 予約の新規・変更・キャンセルを即座に通知する機能
...

機能の羅列ではなく、ビジネス価値ベースでEpicを構造化。

これにより、スケジュールに対して「どのEpicまで提供するか」の優先度判断がしやすくなります。

3. user_stories.md（ユーザーストーリー + 受け入れ基準）— 開発契約書レベルの精度

#### US-1.1: 通知種別のON/OFF設定

ユーザーストーリー:
スタッフとして、通知をそれぞれON/OFFしたい。
なぜなら、自分の役割に必要な通知だけを受け取りたいため。

優先度: P0（必須）

受け入れ基準:

AC-1.1.1: 通知設定表示
- Given: ユーザーが連携済みである
- When: 管理画面で通知設定を開く
- Then: 通知設定が表示される
- And: 各設定項目にトグルスイッチが表示される

AC-1.1.2: 個別ON/OFF切り替え
- Given: ユーザーが通知設定画面にアクセスしている
- When: トグルスイッチを操作する
- Then: 即座にON/OFF状態が切り替わる
- And: フィードバックが表示される

Given-When-Then形式の受け入れ基準までAIが自動生成。

人間はこれをレビューし、ビジネス判断が必要な箇所（優先度、スコープ判断）を中心に修正します。

Human-in-the-Loopの実践

このプロセスにおける人間の役割は「レビューと意思決定」に集約されます。

フェーズ	AIの役割	人間の役割
計画作成	ステップの洗い出し、不明点の質問	質問への回答、計画の承認
エピック定義	提供価値単位での構造化	ビジネス価値の妥当性レビュー
ユーザーストーリー作成	US文/受け入れ基準のドラフト	仕様の正確性・網羅性レビュー
優先順位付け	情報に基づく優先度案の提示	最終的な優先度の意思決定

重要なのは、AIの出力は「提案」であること。

意図と合っているか、間違ったことを記載していないかは必ず人間が確認した上でドキュメントを更新します。

このプロセスの成果

あるプロジェクトでは、AIが46のユーザーストーリーと約180のAcceptance Criteriaをドラフトとして生成
PdMはレビュー・修正に集中できたため、従来1〜2週間かかっていた要求事項策定を数日で完了
ユーザーストーリーの品質が上がったことで、後工程（設計・実装・テスト）での差し戻しが大幅に減少

チームの声（振り返り会より）

「細かいユースケースなども整理されて、考慮漏れが減ったと思う」 ── デザイナー

「ユーザーストーリーベースでチーム内で議論できるのが良い」 ── エンジニア

「高速に叩き台を作れるので、チームでの議論に時間を割けるようになっていると思います」 ── エンジニア

AIがドラフトを高速に生成することで、チームは「作る作業」ではなく「議論・レビュー」に時間を使えるようになりました。

② 関係者との認識合わせ・考慮漏れ防止

前セクションで作成したドキュメントは、1ファイル1,000行を超えることもあります。網羅性がある一方、マークダウンの文章で作成するため、初見で読み解くのは難しい場合があります。

関わるステークホルダーは多岐にわたり、全員に同じ形で渡すだけでは認識合わせや考慮漏れ防止が機能しません。

最初の失敗：「網羅されたドキュメント」を全員に渡しても効果を発揮しない

当初は、精度の高いドキュメントをそのまま全関係者に共有していました。「情報の質が上がったのだから、伝わるはずだ」と考えていました。

一部開発者は「この粒度の情報がほしかった」と評価してくれた一方、他の関係者からは「あまりに文字の分量が多くて読み解くのがしんどい」という声が返ってきました。

ここで気づいたのは、ドキュメントの網羅性とデリバリーは別の問題だということです。この経験から、相手に応じて情報の形を変える必要があると学び、以下の3つのパターンに整理しました。

パターン1：原文 + AIが生成したdrawio図で渡す

渡すもの:

原文ドキュメント（User Story / Acceptance Criteria）
User Storyを元にAIが自動生成した処理フロー図など（drawio）

該当する関係者:

自チームの開発者・デザイナー
QA
法務・個人情報保護部

仕様の原型を正確に把握し、自分たちの専門領域で判断する必要のある人たちがここに該当します。

各専門領域の観点から仕様をレビューでき、PdMの気づかない観点（セキュリティ・法的リスク等）を発見できます。

AIによる工夫:

ドキュメントはAIが読み取りやすい構造で作られているため、各部門がAIを使って自分たちに必要な範囲の情報を抽出・分析することも可能
開発者の事前調査（既存仕様の影響範囲調査）では、チームが既存の実装が保持されているリポジトリに接続したDevin等のAIエージェントにドキュメントをインプットし、既存コードベースと合わせて調査することで効率化

パターン2：運用に必要な情報だけを加工して渡す

渡すもの:

FAQ、機能説明資料、運用マニュアルなど（AIが原文から加工・生成）

該当する関係者:

CS（カスタマーサポート）
営業
関係部署の運用担当

仕様の全体の細かい部分までは不要だが、ユーザーや店舗からの問い合わせに対応するための情報や、提案活動に必要な機能説明を求める人たちがここに該当します。

ドキュメントをベースに、AIに「CS向けのFAQ」「営業向けの機能説明資料」「運用チーム向けの操作手順」など用途に応じたドキュメントを加工・生成させます。

AIによる工夫:

同じ情報源（ドキュメント）から派生させるため、情報の一貫性が担保される。仕様変更が発生した場合も、原文を更新すればAIで再生成するだけで関連ドキュメントを同期できる
PdMが1からFAQや説明資料を書き起こす工数が不要になり、レビューと微調整に集中できる

パターン3：視覚的な表現を中心に渡す

渡すもの:

簡易Mock、画面プロトタイプ

該当する関係者:

ビジネス側意思決定者
他部門のマネジメント

ユーザー体験の全体像に基づき、迅速かつ大局的な意思決定を求められる方々がここに該当します。

「ユーザーがどのような体験をするのか」の具体的なイメージをもとに方向性を判断することが求められます。

AIによる工夫:

FigmaMake等のAIツールを使い、ユーザーストーリーをベースに実際の画面を用いた簡易的なMockを作成
デザイナーに画面上のプロトタイプを作ってもらうケースもあれば、Mockレベルで済ませるケースもあり、案件の重要度や相手に応じて使い分けている

まとめ：同じ情報源から、3つの届け方に変換する

パターン	渡すもの	該当する関係者	認識合わせ・考慮漏れ防止の効果
1. 原文 + drawio図	原文 + AI生成の処理フロー図	開発・デザイナー・QA・法務	専門領域の観点からの仕様レビュー、テスト観点・セキュリティ・法的リスクの早期発見
2. 加工ドキュメント	FAQ・説明資料・運用マニュアル	CS・営業・運用担当	運用視点からのフィードバック、現場起点の考慮漏れ防止
3. 視覚表現中心	Mock・プロトタイプ	ビジネス側意思決定者	方向性レベルの認識ズレ早期解消、大きな手戻り防止

すべてが同じ情報源から派生しているため、どのパターンでも情報の一貫性と正確性が担保されます。

そして、この変換作業自体もAIが担うため、PdMの工数は大きく増えません。

開発メンバーから見たプロセスの改善効果

ここまではPdM視点でのAI活用を中心に紹介してきました。ここからは、開発メンバーがこれらのドキュメントをどう活用しているかを紹介します。

チーム内の開発メンバー3名にヒアリングを行ったところ、使用しているAIツールはそれぞれ異なるものの、共通する2つのポイントがありました。

ポイント1：「正」となるドキュメントの存在が、各フェーズでのAI活用を支えている

開発メンバーが最も効果的だと感じているのは、開発の各工程において、網羅性のある「正」となるドキュメントが存在していることでした。

開発プロセスのフロー図（簡易版）

上流でAIを使って作成された正確なドキュメント（Epic / User Story / Acceptance Criteria）が、各工程の判断基準・入力情報として機能しています。

「正」のドキュメントが存在することで、各フェーズの作業中・作業完了時にAIへ照らし合わせてチェックすることが容易になる。

たとえば、設計が要求を満たしているか、実装が受け入れ基準に合致しているかを、AIに要求ドキュメントを読み込ませた上で確認させることができます。

ポイント2：設計・テストケース作成でもHuman-in-the-Loopが機能している

もう1つの共通ポイントは、設計書やテストケースの作成においても、AIにドキュメントを読み込ませてドラフトを作成し、Human-in-the-Loopがしやすいことです。

具体的には、元となる要求のドキュメント（Epic / User Story / Acceptance Criteria）をAIへ先に読み込ませ、それをベースにドラフトを生成させます。

人間はそのドラフトをブラッシュアップする。これはPdMが要求事項策定で実践しているHuman-in-the-Loopと同じ構造です。

開発工数への影響

同規模の開発をAI駆動あり・なしで比較した場合、開発工数が推計で約40%削減されているという実感がヒアリングから得られています。

PdMの上流工程だけでなく、開発メンバーの下流工程にもAI駆動プロセスの効果が波及しています。

まとめと今後の展望

成果

厳密な計測の仕組みはまだ整備途上であり、数値比較は今後の課題としています。ここでは、PdM視点と開発メンバー視点のそれぞれで実感している成果を紹介します。

PdM視点：

要求定義フェーズの所要時間が体感ベースで約50%減（作業時間・リードタイムともに半減の感覚）
あるプロジェクトでは、46のUser Storyと約180のAcceptance Criteriaを数日で策定
PdMの役割が「ドキュメントを書く人」から「AIの提案をレビュー・意思決定する人」へ変化し、戦略検討へ集中できるようになった

開発メンバー視点（チーム内へのヒアリング）：

同規模の開発をAI駆動あり・なしで比較した場合、開発工数が推計で約40%削減
上流で作られた網羅的なドキュメントが各工程の判断基準として機能し、手戻り起因の差し戻しが減少
設計・テストケース作成においてもAIドラフト→人間レビューのプロセスが定着し、開発メンバーもHuman-in-the-Loopを実践

まとめ

上流にAIを配置する: 手戻りは「下流で発見して修正する」のではなく、「上流でAIの力を借りて予防する」
適切な役割分担: AIは構造化と網羅性を担保し、人間は意思決定とレビューに集中する（Human-in-the-Loop）
チーム全体で目線を揃える: 自分たちのチームでは、AI活用が個人利用のままでは手戻りの削減に繋がらなかった。チームのプロセスに組み込んではじめて効果が出た

AIで速くなった分、戦略の策定・人間の意思決定・合意形成などに時間をかけられるようになりました。

これこそが本来人間がやるべきことであり、AIとの役割分担の理想形だと考えています。

最後に、食べログでは一緒に働く仲間を募集しています！食べログに興味を持ってくださった方は、以下の採用情報リンクからぜひご応募ください！

プロダクトマネージャー【食べログ】

https://hrmos.co