要件定義の極意と上流工程の成功ポイント
外さない要件定義の骨子は「目的・境界・非機能」
1. 目的と成果指標を先に固定する
機能一覧から入るとスコープが膨張します。先にビジネス目的とKPIを1枚に固定します。例：新規受注率＋5pt、在庫差異−30％、1注文の処理時間90秒以下、P95応答時間500ms以下。目的→指標→主要シナリオ→必要最小限の機能、の順で落とすと要件が痩せていきます。
2. スコープの境界線を明文化する
「やらないこと」を同じ熱量で書きます。外部システム、支払い手段、返品パターンなど、境界は図解できなくてもテキストで十分です。MoSCoWでMust/Should/Could/Won’tを明記し、Must＝リリース1、Should＝次期で期待、に分けて期待値を整えます。インターフェース一覧（IF名、方向、頻度、遅延許容、責任境界）を作ると後工程が安定します。
3. 非機能・制約を「赤札」扱いにする
非機能は後追いで高く付きます。初回合意の必須セットは以下がおすすめです。
- 可用性SLA：99.9％（平日日中）／メンテ窓口明示
- 性能目標：P95 500ms、ピーク200RPS、同時接続2,000
- バックアップ：RPO 15分、RTO 4時間
- 監査・ログ：重要操作は改ざん耐性、保存7年
- データ保護：個人情報は静止時AES-256、転送時TLS1.2+
数値は仮でも置くと見積りが実態化します。根拠は「現状・将来・ピークイベント（例：セール、請求締め）」の三点から算出します。
上流工程を週次で運ぶ実務フロー
Week1：仮説の骨組みを作る
- ゴールキャンバス（目的・KPI・制約）
- キーパーソンRASCI（意思決定者/責任者/支援/相談/報告）
- 決定ログ開始（ID、論点、選択肢、採択理由、反証、期限）
Week2：業務から要件へ落とす
- ユーザーストーリーマッピング（体験→エピック→ストーリー）
- データ定義（エンティティ、主キー、整合性、ID採番方針）
- 外部IF素案（方式：REST/Batch、頻度、再送・整合戦略）
Week3：受け入れ基準で締める
- 受け入れ条件をGherkinで記述（Given-When-Thenを3例以上）
- 非機能レビュー（性能・可用性・セキュリティ・運用）
- リスクのプレモートム（失敗見取り図→対策とトリガー）
Week4：見積りと変更管理に接続
- 3点見積（楽観/最頻/悲観）×依存度スコアでバッファ設計
- 変更要求（CR）票の運用ルール（影響、コスト、優先度）
- 合意版のスコープ文書とトレーサビリティ（目的↔機能↔テスト）
ここまでの成果物が揃えば、契約やロードマップへの接続が滑らかになります。PoCと本開発を分ける場合も、同じ骨子で要求を薄く管理すると迷いにくいです。
合意形成を強くする会議設計とAIの使い方
60分会議の型（論点が散らからない）
- 5分：目的・KPIの再確認（前回からの変更点のみ）
- 20分：論点A/B/Cの選択肢比較（メリデメ、影響）
- 20分：受け入れ条件の文言確定（曖昧語を除去）
- 10分：決定ログ記入と反証期限の設定
- 5分：次アクションとオーナー割り当て
「1機能＝1目的＝1指標」を崩さないと、後で誰も守れない要件になります。曖昧語（高速、簡単、柔軟）は禁止し、閾値で表現します。
AIは下準備に活かすと効果的です。ChatGPTやClaudeで受け入れ条件のたたき台や抜けやすい例外ケースを洗い出し、Geminiでアクセスログからピーク推定を試算する、といった使い方は時間を節約します。開発側はCopilotでAPIスタブと契約テスト雛形を生成し、上流の合意をすぐに実行可能な形へブリッジします。最終判断は人が行い、AIの提案には根拠ソースをつけてレビューするのが前提です。
身近な企業の失敗と再起：中堅スーパー「みなとマート」の例
地方で20店舗を運営する「みなとマート」（従業員200名）は、店舗受取型のオンライン注文を内製と受託の混成で立ち上げました。初回リリースは1カ月のヒアリングのみで要件凍結。非機能は「なるべく速く」、在庫連携は毎時バッチ、返品は「店頭で対応」の一言で終了。結果、週末ピークで欠品表示が遅れ、現場はクレーム対応で疲弊。返品の棚卸しがPOSに反映されず、在庫差異が膨らみました。
再起では上流工程をやり直しました。ゴールは「欠品率1％以下」「ピッキング時間20％短縮」「P95 500ms」。返品を業務として分解（起点：顧客都合/品質・期限切れ、経路：店頭/配送）し、Gherkinで受け入れ条件を20本作成。外部IFは在庫を店舗ごとにイベント駆動で5分同期へ見直し。非機能はRPO 5分、RTO 1時間、ピーク200RPSを数値で合意しました。
準備ではChatGPTで例外ケースの草案を生成し、ClaudeでFAQと「やらないこと」リストを整理。過去売上CSVをGeminiに要約させ、特売日のピーク係数を推定。開発側はCopilotで契約テストのスタブを自動生成し、要件確定と同時に疎通検証を開始。結果、ローンチ2カ月で在庫差異は40％改善、返品処理の自動化率は90％、現場の工数は25％削減。以降の機能追加もMoSCoWで優先度がぶれず、経営会議への説明もKPI基準で通るようになりました。
要件定義はドキュメント作成ではなく、意思決定の連鎖を透明化する営みです。目的・境界・非機能を先に固定し、週次の型で合意を積み上げ、受け入れ条件まで言語化する。受託開発ソリューション事業では、この上流の質がそのまま納期・品質・関係性の安定に跳ね返ります。現場の言葉をKPIとテストに翻訳できるチームが、下流の不確実性を最小化します。
