「要件定義書は作ったのに、開発が進むと『思っていたものと違う』と言われる」——プロダクト開発の現場でよく聞く悩みです。原因の多くは、機能の仕様は書けていても「誰が」「なぜそれを必要としているか」が抜け落ちていることにあります。この課題を解決する手段として広まったのが「ユーザーストーリー」という要件表現です。この記事では、ユーザーストーリーの書き方の基本と、AIプロダクト開発ならではの受け入れ条件（Acceptance Criteria）設計の考え方を整理します。
プロダクト開発におけるユーザーストーリーとは？機能要件との違い
ユーザーストーリーとは、「誰が」「何をしたいか」「なぜそれが必要か」を短い一文で表現した要件の記述形式です。従来の機能要件書が「システムは〇〇の機能を実装すること」と実装内容から書き始めるのに対し、ユーザーストーリーは利用者の価値や目的を先に書き、実装方法はチームで後から議論するという順序を取ります。この違いにより、開発者が「なぜこの機能が必要なのか」を理解した上で実装判断できるようになり、仕様の解釈違いによる手戻りを減らせます。アジャイル開発の普及とともに広まった手法ですが、AIプロダクトのように仕様が開発途中で変わりやすい領域では特に有効です。
Format
ユーザーストーリー 書き方の基本：フォーマットとINVEST原則
基本のテンプレートは「As a（誰として）／I want（何をしたい）／So that（なぜそれが必要か）」の3行です。例えば「As a 現場担当者 として／I want 発注書をアップロードするだけで見積金額の妥当性チェックをしたい／So that 取引先ごとに単価の相場を調べる手間をなくしたい」のように書きます。この粒度を保つための指針がINVEST原則です。Independent（他のストーリーに依存しすぎない）、Negotiable（実装方法は交渉可能）、Valuable（利用者価値がある）、Estimable（工数を見積もれる）、Small（1〜数日で完了できる小ささ）、Testable（達成したかどうか検証できる）の6要素を満たすほど、スプリントに落とし込みやすいストーリーになります。
要件定義の途中段階でも構いません。ユーザーストーリーの書き方から一緒に整理します。
無料で相談するMisconceptions
よくある誤解・失敗パターン3選
誤解1：主語や目的語が曖昧でも通じる。実際には「ユーザーが便利に使えるようにしたい」のような曖昧な主語・目的語では、開発者ごとに解釈が分かれ、実装後に「思っていたものと違う」という食い違いが起きます。「誰が」を役割まで具体化することが必須です。
誤解2：ストーリーは大きくまとめた方が管理しやすい。実際には「発注から支払いまで一括で自動化したい」のように粒度が大きすぎるストーリーは、1スプリントに収まらず見積りも曖昧になります。INVEST原則のSmallに沿って分割する必要があります。
誤解3：受け入れ条件は『〇〇できる』の一文で十分。実際には「見積金額が妥当かどうか判定できる」だけでは、何をもって完了とするか検証できません。次章で解説する具体的な条件への分解が欠かせません。
Process
受け入れ条件（Acceptance Criteria）の書き方ステップ
独立行政法人情報処理推進機構（IPA）の「ユーザーのための要件定義ガイド」でも、要件定義段階で利用者側の問題を丁寧に把握する活動が、後工程の失敗を減らす上で重要だと解説されています。ユーザーストーリーを書いた後は、以下の手順で受け入れ条件に落とし込みます。
- Given-When-Thenで場面を分解する：「〇〇の状態で（Given）／〇〇を行ったとき（When）／〇〇が起きる（Then）」の形で、正常系・異常系それぞれの動作を書き出します。
- チェックリスト形式で検証項目を列挙する：入力値のバリデーション、表示内容、エラー時の挙動など、テストで確認できる項目に分解します。
- スプリント単位に見積り可能な粒度まで分割する。AI開発のタスク管理は探索的段階型で進めることが多いため、受け入れ条件が細かいほど各段階の完了判定がしやすくなります。
AI-Specific
AIプロダクト開発特有の工夫：非決定的な出力をAcceptance Criteriaに落とし込む
生成AIや機械学習モデルの出力は、同じ入力でも毎回完全に同一結果になるとは限りません。そのため「〇〇と表示される」という完全一致を前提にした受け入れ条件は機能しないことが多く、精度スコアの閾値、許容誤差の範囲、信頼区間、そして人間による最終確認（Human-in-the-loop）を組み合わせた設計が必要になります。当社が開発・運営する製造業向けAI見積・受発注システム「Newji one」でも、AIが提示単価の妥当性を根拠つきで判定する機能を提供していますが、これも「完全一致」の判定ではなく、根拠データと共に妥当性を示す形の出力です。こうした非決定的な出力の扱い方をあらかじめ受け入れ条件に書いておくことで、開発中の「AIの出力が毎回微妙に違う」という指摘に振り回されずに済みます。
| 受け入れ条件の設計アプローチ | 特徴 |
|---|---|
| 従来型（Pass/Fail基準のみ） | 結果が一意に決まる機能向け。AI出力のゆらぎには対応できない |
| 閾値型（精度・許容誤差で判定） | 正解率や誤差範囲を数値で定義。検証はしやすいが閾値設定に経験が要る |
| 人間レビュー併用型（Human-in-the-loop） | AIの提案を人が最終確認する前提で条件を書く。実運用に近いが確認コストが残る |
| オプティソースの要件定義・AC設計支援 | 閾値設計とレビュー運用を組み合わせて条件を設計。ただし業務知識のすり合わせに一定の対話時間は必要 |
日経クロステック（xTECH）が報じた日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2016」によると、500人月以上の大規模システム開発では工期遅れ44.5％、予算超過39.6％、品質不満29.2％と高止まりしています。規模の大小を問わず、要件のすり合わせ不足による手戻りコストは無視できません。AIプロダクトでは出力の非決定性という要素が加わる分、受け入れ条件の設計をより丁寧に行う価値があります。
FAQ
よくある質問
ユーザーストーリーとユースケースの違いは何ですか？
ユースケースはシステムと利用者のやり取りを手順として詳細に書く手法で、機能仕様に近い粒度になりがちです。一方ユーザーストーリーは「誰が・何を・なぜ」を短く書き、実装の詳細は後から議論する前提の軽量な表現です。素早く優先順位をつけて開発したいプロダクト開発では、ユーザーストーリーの方が扱いやすい場面が多くあります。
ユーザーストーリーは誰が書くべきですか？非エンジニアでも書けますか？
基本的には利用者の業務を理解している人（発注者側の担当者やプロダクトオーナー）が書くのが望ましく、エンジニアである必要はありません。「誰が・何を・なぜ」は業務知識があれば書けるため、非エンジニアの方が主体となって作成し、受け入れ条件の技術的な妥当性はエンジニア側と一緒に詰めるという分担がうまくいきやすいです。
受け入れ条件はどこまで細かく書くべきですか？
目安は「第三者が読んでテスト可能かどうか」です。正常系だけでなく異常系（入力エラー、想定外のデータなど）も含めて書くと、開発中の認識齟齬を減らせます。AI機能の場合は、精度の閾値や人間による確認プロセスまで書き込むことをおすすめします。
自社にユーザーストーリーを書ける担当者がいませんが、依頼できますか？
可能です。業務内容についてヒアリングを行いながら、当社側でユーザーストーリーと受け入れ条件の設計を支援する形で進められます。要件定義の途中段階からのご相談も歓迎です。
ユーザーストーリーと受け入れ条件は、要件定義段階の齟齬を防ぎ、開発が進んでからの手戻りを減らすための実務的な手段です。特にAIプロダクトでは、出力の非決定性を前提にした受け入れ条件の設計が品質を左右します。要件定義やユーザーストーリー設計の段階から相談したい場合は、お気軽にお問い合わせください。
