■ 1. 改善前の課題
- エンジニアが技術調査から実現可能性判断まで直列に処理していた
- 企画とのすり合わせで見直しが発生するたびに全工程をやり直す必要があった
- 1案件あたりのすり合わせMTGが4回以上に膨張していた
- 初回要件定義に約2週間、要求変更を含めると約1ヶ月を要していた
- 根本原因は「要件が具体像として現れて初めて新たな観点が見えてくる」という認知的自然性にあった
■ 2. 最初のアプローチと失敗
- 「AIに要件定義そのものを出力させれば高速化できる」という仮説を立てた
- データ構造・業務ルール・ユースケースが混在し、分類が困難だった
- 精査コストが手作業と変わらず、エンジニアの精査判断が必須のまま残った
- 直列構造を解消できなかったため、アプローチを転換した
■ 3. 方針転換と解決策
- AIには「要件定義の答え」ではなく「構造化された論点」を出力させる方針に切り替えた
- 直列構造そのものを変えることを目指した
- 成果物として「フィージビリティレポート」を開発した
■ 4. フィージビリティレポートの構成
- Part 1 - 評価サマリ:
- 実現可能性評価とリスク判定を含む
- 対象読者は企画・PdM
- Part 2 - ユースケース・業務ルール:
- 具体的な動作シナリオと業務上の制約条件を記載
- 対象読者はエンジニア
- Part 3 - データ設計:
- 必要なデータエンティティと状態バリエーションを記載
- 対象読者はエンジニア
■ 5. 設計思想
- データを軸にした構造化:
- 「データ構造は機能要件より変わりにくく、安定した評価軸になる」という判断に基づく
- データエンティティの状態バリエーションでユースケースを分解する
- ユースケースの集合から業務ルールを帰納的に導出する
- 実装詳細は記述せず、宣言的な要件記述にとどめる
- 具体から抽象への導出:
- 業務ルールはユースケースの集合から帰納的に導出する
- 抽象的な要求からいきなりルール生成を試みると検証不可能な出力になるため、この順序を徹底する
■ 6. AIワークフロー
- 準備フェーズ:
- Step 0: ドメイン知識・観点パターン・過去レポートの読み込み
- 分析フェーズ:
- Step 1: User Story分析
- Step 2: ユースケース洗い出し
- Step 3: 業務ルール策定
- Step 4: コードベース調査（Step 2と相互フィードバックしながら進行）
- 評価・出力フェーズ:
- Step 5: フィージビリティ評価
- Step 6: レポート生成
- 品質保証フェーズ:
- Step 7: 4チェック×最大3反復での自動改善
- 実装技術:
- GitHub ActionsとDevin APIで構成
- ラベル付与をトリガーにDevinセッションが生成される
- User Story更新時に自動的に再評価が実行される
■ 7. 実装事例: 店舗満足度アンケート
- 案件概要:
- 「店舗会員に月1回、満足度アンケートを回答してもらう」案件で検証
- 評価サマリの結果:
- 全体実現性: ◎（既存モーダルフレームワークの拡張で実現可能）
- 技術リスク: 低
- セキュリティリスク: 低
- User Storyに明示された件数: 21件 / AIが追加洗い出しした件数: 9件
- AIが自動検出したユースケース例:
- 月末最終日23:59にモーダル表示され、翌月0:00を跨いで回答送信された場合の対象月判定
- 回答送信時のネットワークエラー発生時の再送信処理
- 同一店舗会員が複数端末から同時回答する場合の結果整合性
- 導出された業務ルール例:
- BR-001: 月内1回表示制約
- BR-005: 他モーダル優先
- BR-006: 特定期間内のみ表示
- BR-025: 複数端末同時回答の結果整合性（AI追加）
■ 8. 効果測定
- 時間短縮の実績:
- 初回要件定義（変更なし）: 約2週間 → 2〜3日
- 初回要件定義（要求変更込み）: 約1ヶ月 → 約1週間
- たたき台生成: 数日（網羅性低）→ 約5分（網羅性高）
- すり合わせMTG: 3〜4回以上 → 1回（30分）
- 要求変更1件あたり: 数日〜1週間 → 半日以内
- 本質的な変化:
- 最も重要な変化は初回生成の高速化ではなく、要求変更1件あたりの再定義時間の短縮
- エンジニアの仕事が「調査・洗い出し中心」から「判断すべき論点への集中」へシフト
■ 9. 今後の展望
- 現在のフィージビリティ評価レポートは企画検討からリリース後保守までの大きなフローの一ステップとして運用されている
- 同じ設計思想を各フェーズで積み重ねる取り組みが継続中