目次
- はじめに
- 改善前の開発フロー
- AIで直列から並列へ転換する
- 実際に生成されたレポートを見てみる
- 店舗満足度アンケート 要件定義書
はじめに
こんにちは。食べログカンパニー 開発本部 ユーザープロダクト開発部の大橋です。
私たちのチームでは、AIを活用して要件定義の土台を即時に生成し、要求変更の手戻りコストをゼロに近づける開発プロセスを構築しました。
要件定義は開発の上流工程でありながら、属人性が高く時間もかかる領域です。「AIで自動化すればいい」と思って取り組み始めたものの、最初はうまくいきませんでした。本記事では、その失敗から方針転換を経て現在のプロセスに至るまでの試行錯誤を共有します。
あらかじめお伝えすると、このプロセスの肝は「直列だった工程を並列に変えたこと」、その鍵は「AIに何を・どの順序で出力させるか」という設計でした。安定した品質のレポートを生むこの設計の考え方こそ、本記事で最もお伝えしたい部分です。
改善前の開発フロー
事業環境や外部要因によって要求は常に変化します。価値ベースで意思決定する以上、要求の変化に要件定義も追従できることが望ましい状態です。
しかし改善前の開発フローは、その柔軟性を実現できる構造ではありませんでした。
直列処理のボトルネック
改善前のフローは以下の直列処理でした。
図のとおり、エンジニアが技術調査から実現可能性判断までを直列に処理し、企画への確認で見直しが発生するたびに全工程をやり直す構造です。
エンジニアはUser Storyを受け取ると、既存のコードを調査して影響箇所や既存の要件を洗い出し、そこからユースケースを導出して要件を定義していました。しかし、長年運用されてきたコードベースは膨大で、影響範囲を完全に網羅することが難しい状況でした。
例えば「店舗会員に案内モーダルを表示する」案件では、エンジニアが既存のモーダル表示基盤を調査して「実装可能」と要件をまとめるところまで進みました。しかしその後の企画とのすり合わせMTGで、エンジニアと企画の双方から「他のモーダルと重なるときはどうする？」「特定状態の店舗は除外したい」といった観点が浮かび、表示制御ロジックの調査からやり直す——といった手戻りが繰り返されていました。
根本原因は、要件が具体像として現れて初めて新たな観点が見えてくるという認知の自然な流れにあります。
抽象的なUser Storyの段階では誰も気づけなかった「他のモーダルと干渉しないか」「特定状態の店舗は除外したい」といった観点は、エンジニアの調査結果という具体像を起点に、企画とエンジニアの双方から自然と湧いてきます。
長年運用されてきた既存システムの干渉ポイントや運用上の例外まで、抽象段階ですべて想像できる人間はいません。要件定義は本来、対話と具体化を繰り返して精度を上げていく工程です。これは企画やエンジニアの準備不足ではなく当たり前のことです。
問題は、直列処理ではそのたびに調査からやり直すしかなく、ループが長期化していた点にありました。
数字で見るコスト
このループが繰り返された結果、開発フロー全体にどれだけのコストがかかっていたかを整理します。
| 課題 | 影響 |
|---|---|
| エンジニアの直列処理に時間がかかる | その間に要求が変わり手戻りが発生 |
| 手戻りのたびに調査→精査→定義→判断をやり直し | すり合わせMTGが1案件あたり4回以上に膨張 |
| 手戻りコストが大きいため企画側がUser Storyの粒度・確度を上げてから渡す運用に | 企画側の準備コストも増大 |
そもそも1サイクルには「要求のすり合わせ」「技術調査結果の共有」「要件の最終確認」の3回のMTGが必要でした。要求が変わるたびにこの3回を調査からやり直すため、MTGは4回以上に膨張していきます。
結果としてウォーターフォール的な運用になり、初回の要件定義には約2週間、要求変更まで重なると約1ヶ月ほどかかっていました。
AIで直列から並列へ転換する
直列処理のボトルネックは「エンジニアとPdM（プロダクトマネージャー）が交互に動く」構造にあります。手戻りが多いほど往復回数が増え、全体時間が線形に伸びていきます。
これを解消するには、エンジニアと企画が同じ成果物を起点に同時並行で動ける形にする必要がありました。
1つのレポートを軸に、エンジニアは要件定義書として、企画は実現可能性の判断材料として、それぞれが並列で作業を始められれば、直列の往復そのものがなくなり、認識の齟齬も早期に解消できます。
そのためには、AIが即時かつ安定した品質でレポートを生成できる必要がありました。
最初のアプローチ ── 直列のまま高速化しようとした（失敗）
最初に試みたのは、直列の構造はそのままに、エンジニアの作業をAIで代替して速くすることでした。AIに要件定義そのものを出力させれば、調査から要件定義までの工程を高速化でき、直列のループも速く回せると考えたのです。
しかし結果は、データ構造・業務ルール・ユースケースが混在した大量のリストが返ってくるだけで、精査コストが手作業と変わりませんでした。
「AIが出した要件定義」は一見それらしく見えるものの、以下の問題がありました。
- データ設計と業務ルールとユースケースが混在し、どれが何なのか分類できない
- 既存システムとの整合性が取れていない項目が紛れ込む
- 「正しいのか判断できない」出力を検証するコスト ≒ ゼロから書くコスト
ループ1周の中身は速くなっても、精査コストの壁が越えられず、結局ループの本数は減らせなかったのです。
そして、より根本的な問題が見えてきました。
仮に精査コストが下がったとしても、エンジニアがこの混在リストから要件を精査し、その上で実現可能性やリスクを整理してからでないと、企画には渡せません。
つまり「エンジニアが要件を精査・判断してから企画に渡す」という直列の構造自体は、AIで内部を高速化しても残り続けるのです。
直列を本当に解消するには、AIの出力の形そのものを変える必要がありました。
方針転換 ── 並列化に切り替える（成功）
そこで「直列のまま速くする」発想を捨て、直列の構造そのものを変えることに切り替えました。
鍵は「AIに何を出力させるか」の再設計です。AIに要件定義の答えを出させるのではなく、エンジニアと企画が同時に使える構造化された論点を出力させます。そのレポートを起点に、両者が並列で作業を始められる形を目指しました。
この成果物を、私たちはフィージビリティレポート（実現可能性の評価レポート）と呼んでいます。ユースケース・業務ルール・データ設計を構造化して1本のレポートにまとめたもので、これが本記事でいう「要件定義の土台」 です。
レポートは以下の3部構成で、それぞれ異なる読者に向けて書かれています。
| Part | 何が書かれているか | 誰が読むか |
|---|---|---|
| Part 1: 評価サマリ | この機能は実現可能か？リスクは？ | 企画・PdM |
| Part 2: ユースケース・業務ルール | 具体的に何が起きるか？ | エンジニア |
| Part 3: データ設計 | どんなデータが必要か？ | エンジニア |
企画はPart 1だけ読めば意思決定に必要な情報が揃い、エンジニアはPart 2・3を要件定義書として使います。同じ成果物を両者が異なる文脈で使うことが、並列に動ける基盤になっています。
例えばPart 1には、以下のような評価サマリが生成されます（実例の抜粋）。
| 項目 | 評価 |
|---|---|
| 全体実現性 | ◎（既存モーダルフレームワークの拡張で実現可能） |
| 技術リスク | 低 |
| セキュリティリスク | 低 |
企画担当者はこの表だけで「実現可能か」「どこにリスクがあるか」を把握できます。レポート全体の構造と実例は後段「実際に生成されたレポートを見てみる」で詳しく紹介します。
改善後の開発フロー（並列化）
図のとおり、AIがレポートを即時生成することで、エンジニアと企画が同じ構造化された論点を起点に並列で作業できるようになりました。企画PRにfeasibilityラベルを付与するだけで自動起動し、User Storyを書き直せばレポートも数分で更新されます。エンジニアはそのレポートを軸に論点と要件をMTG前に整理しておき、MTGはそれを決める場として1回で完結します。
この仕組みはGitHub ActionsとDevin APIで構成されています。ラベル付与をトリガーにDevinセッションが生成され、User Storyが更新されて再びラベルが付与されると再評価モードで動きます。
フィージビリティレポートを生成するAIワークフロー
フィージビリティレポートを生成するために、AIは以下のワークフローで評価を進めます。
| フェーズ | ステップ | 概要 |
|---|---|---|
| 準備 | Step 0: ナレッジ参照 | ドメイン知識・観点パターン・過去レポートを読み込み、コンテキストを構築 |
| 分析 | Step 1〜4 | User Story分析 → ユースケース洗い出し＋データ特定 → 業務ルール策定 → コードベース調査 |
| 評価・出力 | Step 5〜6 | フィージビリティ評価 → レポート生成 |
| 品質保証 | Step 7: セルフレビュー | 4チェック × 最大3反復で品質を自動改善 |
Step 2（ユースケース洗い出し）とStep 4（コードベース調査）は相互にフィードバックしながら進みます。コード調査で発見された新たなユースケースはStep 2に追加され、業務ルールも更新されます。
この反復構造が、AIが暗黙的要件を検出できる仕組みの源泉です。
実際に生成されたレポートを見てみる
ここからは実際に運用で生成されたレポートを紹介します。対象は「店舗会員に月1回、満足度アンケートを回答してもらいたい」という案件のフィージビリティ評価レポートです。
以下は実際に運用で生成されたレポートです。一部のセクションは中略していますが、レポート全体の流れを通して見ることで、「AIがどこまで構造化された成果物を出すのか」を体感していただければと思います。
店舗満足度アンケート 要件定義書
本レポートはAIによる初期評価です。最終判断はエンジニアレビューが必要です。
Part 1: 評価サマリ
システムの目的
店舗管理画面に満足度アンケートをモーダル形式で提示し、店舗会員のロイヤルティを定量計測する。回答データは統一テーブルに蓄積し、スコア算出・店舗属性別クロス集計・信頼区間付帯により、データドリブンな意思決定を支援する。
評価サマリ
項目 評価 判定根拠 全体実現性 ◎ 既存モーダルフレームワークの拡張で実現可能。データ格納は既存DB基盤を踏襲。新規技術要素なし 既存実装流用度 60% モーダル制御フレームワーク、セッション認証、集計基盤を流用可能 新規開発規模 M 新規モデル1〜2件、モーダルUI、集計ビュー。変更ファイル数20〜30件見込み 技術リスク 低 全コンポーネントに既存パターンが存在。新規技術導入なし セキュリティリスク 低 既存の認証基盤とデータ取扱ポリシーで対応可能 業務ルール USに明示: 21件 / AIが追加洗い出し: 9件 — 主要な判断ポイント
- 集計基盤のアクセス権限を開発着手前に確認する必要がある
- 複数店舗オーナーの紐付けルールを確定する必要がある
- モーダル表示期間を決める必要あり
User Storyへの改善提案
追加すべき業務ルール（User Storyに未記載 → AIが洗い出し）
- 回答送信中の通信エラー時、回答データを消失させない → 送信失敗時のリトライまたはローカル保持方針が必要
Part 2: ユースケースと業務ルール
ユースケース一覧
★ は AIが追加で洗い出したユースケース。User Storyに明示されていなかったケース。
モーダル表示制御
- UC-06 [正常系]: 当月未表示・未回答の店舗会員がログインし、特定期間内かつ他モーダル非表示の場合にアンケートモーダルが表示される
- UC-07 [正常系]: 当月既にモーダル離脱済みの店舗会員が同月内に再ログインし、モーダルが再表示されない
- UC-08 [正常系]: 当月既に回答済みの店舗会員が同月内に再ログインし、モーダルが再表示されない
- UC-10 [正常系]: 月をまたいで翌月1日以降にログインした店舗会員に対し、モーダル表示判定がリセットされ再びモーダルが提示される
- UC-11 [正常系]: 表示対象の店舗会員がログイン時に他のモーダルが既に表示されている場合、アンケートモーダルが表示されない
回答収集
- UC-14 [正常系]: 店舗会員が満足度スコアで任意のスコアを選択する
- UC-17 [正常系]: 店舗会員が自由記述未入力のまま回答を送信し、送信が成功する
- UC-18 [正常系]: 店舗会員がスコアを選択し回答を送信し、クロージング画面が表示される
[... 集計・分析 計10件省略 ...]
AIが追加で洗い出したユースケース ★
- UC-34 [境界値]: 月末最終日23:59にモーダルが表示され、翌月0:00を跨いで回答送信された場合、対象月の判定が正しく行われる ★
- UC-36 [異常系]: 店舗会員が自由記述に500文字を超える入力を試みた場合、入力が制限される ★
- UC-37 [異常系]: 回答送信時にネットワークエラーが発生し、送信が失敗した場合に店舗会員が再送信を試みる ★
- UC-38 [並行操作]: 同一店舗会員が複数端末から同時にモーダルを表示し、一方で回答送信後にもう一方でも送信を試みる ★
[... 他2件省略 ...]
業務ルール
BR ルール名 カテゴリ ★ BR-001 月内1回表示制約 モーダル表示制御 BR-002 当月内非再表示（離脱） モーダル表示制御 BR-003 当月内非再表示（回答済み） モーダル表示制御 BR-004 翌月判定リセット モーダル表示制御 BR-005 他モーダル優先 モーダル表示制御 BR-006 特定期間内のみ表示 モーダル表示制御 BR-007 経路非依存の表示判定 モーダル表示制御 BR-008 満足度スコア範囲 回答収集 BR-009 自由記述の任意性 回答収集 BR-010 自由記述の文字数上限 回答収集 BR-011 スコア区分分類 回答収集 BR-013 1回答1レコード格納 データ格納 BR-014 セッションからの店舗会員ID紐付け データ格納 BR-015 紐付け失敗時のNULL許容 データ格納 BR-016 データロスゼロ データ格納 BR-017 重複回答の最古採用 集計・分析 BR-018 サンプル不足フラグ 集計・分析 BR-023 回答送信失敗時のデータ保全 データ格納 ★ BR-025 複数端末同時回答の結果整合性 データ格納 ★ BR-026 NULL回答レコードの集計除外 集計・分析 ★ BR-028 返信なし注意文言の提示義務 回答収集 ★ モーダル表示制御
BR-001: 月内1回表示制約
- 当月内に回答済みでない かつ モーダル離脱済みでない場合にモーダル表示対象とする
BR-005: 他モーダル優先
- 同一画面で他のモーダルが表示中の場合、アンケートモーダルは表示対象としない
BR-006: 特定期間内のみ表示
- 運用担当者が設定した有効な表示期間内のみモーダルを表示対象とする
[... 他のBR詳細は省略 ...]
BR-025: 複数端末同時回答の結果整合性 ★
- 同一店舗会員が複数端末から同時回答した場合、集計上は最古採用で結果整合性を担保する
非機能要件・制約条件
# 制約 設計への影響 CON-04 既存モーダルフレームワーク: 優先度ベースの表示制御 既存フレームワークに追加する方式が推奨 CON-06 モーダル表示判定は2秒以内に完了すべき 表示判定ロジックを軽量に保つ設計 [... 他の制約条件省略 ...]
Part 3: データ設計
データエンティティ一覧
DE 新規/既存 概要 関連UC アンケート回答 新規 満足度スコア・自由記述・店舗属性を統一スキーマで格納する回答レコード UC-14〜UC-20, UC-25〜UC-29 表示判定状態 新規 当月のモーダル表示/離脱/回答済みの状態を保持し月次リセットする判定情報 UC-06〜UC-12 既存モーダル管理情報 既存 既存モーダルフレームワークが管理するモーダル種別・優先度・非再表示制御 UC-06, UC-11 アンケート回答（新規）
状態バリエーション: 有効（集計対象） / NULL紐付け（集計除外） / 重複（同月の2件目以降、最古採用で集計除外）
主要属性（業務観点）:
- 回答ID（主キー）、満足度スコア（整数）
- 自由記述（任意、500文字上限）
- 店舗会員ID（NULLable）、店舗コード（NULLable）
- 回答日時、対象月（集計月）
- 設問バージョン（設問文言改定時の旧/新区別）
表示判定状態（新規）
状態バリエーション: 未表示 / 表示済み・離脱（当月非再表示） / 回答済み（当月非再表示） / リセット済み（翌月1日以降）
主要属性（業務観点）:
- 店舗会員ID、対象月
- 表示状態（未表示/離脱/回答済み）
- 表示日時、離脱日時、回答日時
既存モーダル管理情報（既存）
状態バリエーション: 表示対象 / 非表示（非再表示期間中） / 非表示（他モーダル優先）
主要属性（業務観点）:
- モーダル種別、表示優先度
- 非再表示ボタンの有無、非再表示期間（日数）
既存データモデル参照
- 既存テーブルへのカラム追加: 不要。本機能は新規テーブルで完結し、既存テーブルへのカラム追加は発生しない
- 新規テーブルの設計方針: 対象月+店舗会員IDでの検索を主用途とするインデックス設計が必要
レポートの全体像を把握したところで、特に重要なポイントを補足します。
注目すべきはPart 1の評価サマリにある「AIが追加洗い出し: 9件」です。User Storyに書かれていなかった業務ルールをAIが自ら検出しています。そのきっかけとなったユースケースと、導出された業務ルールを見てみましょう。
AIが追加で洗い出したユースケースの例：
Part 2のユースケース一覧で★印が付いているものが、User Storyには記載されていなかったがAIが検出したケースです。
- [並行操作]: 同一店舗会員が複数端末から同時にモーダルを表示し、一方で回答送信後にもう一方でも送信を試みる（重複回答の発生） ★
この例では並行操作の異常系が検出されていますが、正常系の追加パターンや境界値が洗い出されることもあります。企画がUser Storyを書く段階では気づきにくい観点を、AIがコードベースの既存パターンやドメイン知識から検出しています。
導出された業務ルールの例：
上記のユースケースから、AIは以下の業務ルールを帰納的に導出しています。
回答の制約（AI追加 ★） - 1店舗会員あたり月1回の回答を想定するが、重複回答はシステム的に拒否しない（BR-025: 集計上は最古採用で結果整合性を担保）
User Storyに明示されていたルールもAIが追加で洗い出したルールも同じフォーマットで記述されるため、レビュー時に「User Storyに書いてあったか/AIが発見したか」が一目で分かります。
Part 3のデータ設計について：
Part 3は、ユースケースの洗い出し過程で特定されたデータエンティティとその状態バリエーションを業務観点で整理したものです。テーブル設計やER図ではなく、「どんなデータが必要で、どんな状態を取りうるか」を明らかにすることで、企画段階でデータの実現可能性を判断できるようにしています。
新規エンティティだけでなく、既存のモーダル管理情報のように運用中のデータとの関係も整理されるため、「既存システムのどこに組み込まれるのか」が企画・エンジニア双方にとって明確になります。各エンティティの主要属性（業務観点）は、次の基本設計フェーズでテーブル設計に引き継がれます。
フィージビリティレポートを安定品質で生成する設計
ここまで紹介した並列化は、フィージビリティレポートが即時かつ安定した品質で生成されることが前提です。その鍵は、何を軸にレポートを構造化するかという設計判断にありました。データを軸に選び、そこからユースケースを分解し、ユースケースの集合から業務ルールを導出する——という一連の設計を以下で説明します。
データは機能より安定している
検討の結果、データ（エンティティと関係性） を軸に選びました。
- データ構造は機能要件より変わりにくく、安定した評価軸になる
- 10年以上運用されているDBの暗黙ルールや歴史的経緯を引き出すには、データスキーマ起点が最も効果的
- 既存コードの流用可能性判断にはデータモデルの理解が不可欠
データ状態でユースケースを分解する
データを軸にするとは、ユースケースの洗い出し方そのものを変えることです。
ユースケースを「誰が何をする」ではなく「データエンティティのどの状態のとき何が起きるか」で分解します。例えば「モーダルを表示する」なら、未表示・離脱済み・回答済み・月跨ぎという状態バリエーションごとに別のユースケースを立てます。この分解から、以下の2つが導かれます。
| 概念 | 導かれ方 |
|---|---|
| データエンティティ（DE） | ユースケースを洗い出す過程で「このユースケースに必要なデータは何か」を問うことで特定される |
| 業務ルール（Business Rule） | ユースケースの集合から、具体的なケースの積み重ねを通じて共通ルールを導き出す |
この「データ状態から考える」設計思想が、初期の「データ設計と業務ルールとユースケースが混在する」失敗を解消した根拠です。
なぜこの粒度なのか ── 具体的なシナリオなしに正確なルールは定義できない
ユースケースをこの粒度で記述する理由は、業務ルールの抽象化精度を担保するためです。
例えば「モーダルを表示する」という抽象的な記述しかなければ、そこから導ける業務ルールは「月1回表示する」程度にとどまります。
しかし先ほど紹介したユースケースのようにデータエンティティの状態バリエーション（未表示/離脱済み/回答済み/月跨ぎ）で分解することで、初めて「どの状態のとき表示し、どの状態のとき表示しないか」という正確なルールの条件を定められます。
実際に先ほどの4つのユースケース（未表示→表示 / 離脱済み→非表示 / 回答済み→非表示 / 月跨ぎ→リセット）から、上記の「有効な表示期間内 かつ 当月内に回答済みでない かつ 離脱済みでない場合に表示する」という業務ルールが帰納的に導出されています。
つまり、業務ルールはユースケースの集合から帰納的に導出するものです。この「具体→抽象（ユースケースの集合から業務ルールを帰納する）」の設計はAIとの相性も良く、一方で抽象的な要求からいきなりルールを生成させようとすると、正しいかどうか確認できない出力になります。
初期の失敗で「混在した大量リスト」が出た原因はまさにここにあります。
業務ルールの書き方 ── 実装の詳細は書かない
ここまでは業務ルールをどう導出するかを述べてきました。導出したルールをどう書くかにも、同じく「混在を避ける」原則が効きます。
帰納的に導出した業務ルールは、純粋な業務上の制約・条件として記載します。実装は要件を満たすための手段であり、業務ルールに実装詳細を混入させると手段と目的が混在し、実装の変化が要件の揺れとして現れます。UI操作の詳細やユースケース的な記述（「ユーザーは○○して△△する」）も同様に除外します。
先ほど「実際に生成されたレポートを見てみる」で示した業務ルール（「有効な表示期間内 かつ 当月内に回答済みでない かつ 離脱済みでない場合に表示する」など）も、表示する／しないという業務上の条件だけを宣言的に記述し、それをどう実装するかには触れていません。
ユースケースが「具体的に何が起きるか」のシナリオであるのに対し、業務ルールは「どのような制約・条件が存在するか」を宣言的に記述するもの——という役割の違いを、記述フォーマットのレベルで徹底しています。
この設計思想は案件に依存しない
データの状態を軸にユースケースを分解し、その集合から業務ルールを帰納します。この設計は、今回のモーダル表示に限った話ではありません。安定したデータモデルを持つ機能であれば、ドメインを問わず同じ順序が使えます。
要点は「具体から抽象へ」という順序そのものにあります。これはAIに任せる場合だけでなく、人間が要件を整理するときにも成り立つ原則です。
要求変更が即時要件に反映されるサイクル——具体例
目指したのは手戻りを「なくす」ことではなく、安く・速く回せるようにすることです。新たな観点が後から湧くのは自然で、止められないからです。
このプロセスの真価は、レポートの要件がUser Storyの拡張を促し、そこからさらに新しい業務ルールが生まれるという双方向のサイクルにあります。
先ほど紹介した満足度アンケートのレポートで実際に起きたサイクルを見てみましょう。
サイクルの流れ
- AIがユースケースの集合から業務ルールを導出 — 先ほどのユースケースから、AIが「有効な表示期間内 かつ 当月内に回答済みでない かつ 離脱済みでない場合に表示する」という業務ルールを定義
- 人間がレポートを見てUser Storyを拡張 — この業務ルールを見たエンジニアが「表示制御にさらに条件が必要なのでは？」という問いを立て、企画に確認。「他のモーダルと重なるときは？」「緊急停止できるか？」といった観点が浮かび上がる
- User Storyの追加を受けてAIが再評価 — User Storyが更新されると自動で再評価が走り、レポートに新たな業務ルールが追加される
以下の業務ルールが追加されました。
- 同一画面で他のモーダルが表示中の場合、アンケートモーダルは表示対象としない（BR-005）
- 運用担当者が設定した有効な表示期間内のみモーダルを表示対象とする（BR-006）
業務ルールの進化
| タイミング | 業務ルール |
|---|---|
| 最初のAI導出 | 当月内に未回答 かつ 未離脱なら表示（BR-001） |
| 人間の問い→User Story拡張後 | 当月内に未回答 かつ 未離脱 かつ 有効な表示期間内（BR-006） かつ 他モーダル非表示（BR-005）の場合に表示 |
このように、要求（User Story）→ 要件（レポート）→ 人間の問い → User Storyの拡張 → レポート自動更新というサイクルが回り続けています。企画担当者がUser Storyを更新すると、AIが自動で再評価を実行し、整合性が取れた状態のレポートに更新されます。
このサイクルを、調査のやり直しを挟まず、レポート再生成とMTG1回で（半日以内に）回せることが、従来の直列プロセスとの決定的な違いです。
効果と今後の展望
このサイクルを案件ごとに即時に回せるようになったことで、開発フローにどのような変化が生まれたかを整理します。
Before / After
以下はいずれも体感ベースの概算です。案件規模によって幅があります。
| 指標 | Before | After |
|---|---|---|
| 初回要件定義（変更なし） | 約2週間 | 2〜3日 |
| 初回要件定義（要求変更込み） | 約1ヶ月 | 約1週間 |
| たたき台の生成（技術調査・ユースケース/データ洗い出し） | エンジニアが手動で実施。数日かかり、網羅性も低くなりがち | AIが約5分で生成。網羅性も高い |
| エンジニアの要件確認 | 調査・洗い出しと一体で、準備に時間 | 生成物の確認に専念（約1〜2時間） |
| すり合わせMTG | 3回（手戻りで4回以上に膨張） | 1回（30分） |
| 要求変更1件あたり | 調査からやり直し（数日〜1週間） | 再生成5分＋確認1〜2時間＋MTG30分（半日以内） |
| 企画側のUser Story準備コスト | 高（確度を上げてから渡す必要あり） | 低（ドラフト段階で渡せる） |
最も重要な変化は初回生成の高速化ではなく、要求変更1件あたりの再定義時間です。以前は変更のたびに調査からやり直し、数日〜1週間かかっていました。今はUser Storyを更新すればAIが約5分でレポートを再生成し、エンジニアの要件確認と30分のMTGを挟んでも半日かからず再決定できます。
時間が短縮されただけではありません。変わったのは、エンジニアの仕事の中身です。以前は、要件を決めるためのデータやユースケースを自分で調査・洗い出す準備に時間がかかりました。しかも手動の調査は網羅性が低くなりがちです。今はその準備をAIが担うため、エンジニアは生成物の要件確認（約1〜2時間）に専念できます。
網羅性が上がったうえで、人間の時間が「判断すべき論点」に集中する——これがAfterの本質的な変化です。
今後の展望
本記事で紹介したフィージビリティ評価レポートは、すでにより大きなフローの一ステップとして運用されています。企画検討からリリース後の保守まで、各フェーズで同じ設計思想——「人間が判断すべき場所に人間が集中できる」——を積み重ねる取り組みを続けています。
引き続き、効果の定量計測とチーム全体への展開を進めていきます。
なお、本記事で取り上げた評価フローが位置づけられる企画検討・評価フローの全体像は、同チームの企画メンバーが以下の記事で紹介しています。
おわりに
「AIで自動化できる」という期待から始まり、「混在した大量リスト」という失敗を経て、たどり着いた設計思想はシンプルでした。AIに答えを出させるのではなく、人間が判断すべき論点をAIに構造化させることです。そしてその論点を検証できる形にできたのは、具体的なケースから業務ルールを導く「具体から抽象へ」の順序を徹底したからです。
この方針転換で変わったのは、初回の所要時間だけではありませんでした。要求が変わればレポートが即時更新され、エンジニアが「調査を終えてから確認する」という直列の構えをやめて企画と並列に動ける。
その結果として、要求の変化に追従できる開発フローが生まれました。
レポートの品質改善も、プロセスの最適化も、まだ道半ばです。ただ、AIと人間の役割分担を再設計することで開発フローは変えられる、という手応えは確かに得ています。本記事が同じ課題に向き合っているチームの参考になれば幸いです。
食べログでは新たな仲間を募集しています。興味を持っていただけた方は、ぜひ以下の採用ページをご覧ください。
