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