要件の抜けを減らすユーザーストーリー作成プロンプト｜受け入れ条件まで整える実務テンプレート
このプロンプトは、企画メモや利用者の要望から、開発チームが検討できるユーザーストーリーを作るためのものです。プロダクトオーナー、ディレクター、業務担当者など、要件整理の最初の一歩を効率化したい人に向いています。
結論から言えば、AIにはストーリー本文だけでなく、根拠、受け入れ条件、不明点を分けて出力させるのが重要です。これにより、もっともらしい要件の創作を抑え、人が確認すべき箇所を見つけやすくなります。
この記事で分かることは次のとおりです。
- コピペして使えるユーザーストーリー作成プロンプト
- 入力時に変更する項目と、固定しておきたい条件
- 曖昧な依頼が失敗しやすい理由と改善例
- Given／When／Then形式の受け入れ条件を作る方法
- AIの出力をバックログへ移す前の確認項目
このプロンプトで作るもの
完成形は「誰が、何のために、何を必要としているか」が分かり、受け入れ条件まで確認できる下書きです。
ユーザーストーリーでは、一般に次のような短い形式が使われます。
{利用者}として、{達成したいこと}をしたい。なぜなら、{得たい価値}だから。
短い形式には、チーム内の会話を始めやすい利点があります。一方、入力情報が足りないままAIに作らせると、実際には確認していない利用者像や業務ルールまで補われることがあります。
そこで、この記事のテンプレートでは、1件のストーリーを次の要素に分けます。
- ストーリー本文
- 背景と利用者の目的
- 受け入れ条件
- 対象外
- 根拠となった入力情報
- 不明点と確認質問
Agile Allianceの解説でも、ユーザーストーリーは要求を簡潔に表す実務上の手法として整理されています。ただし、短い一文だけで開発可能な要件が完成するわけではありません。AIには、話し合いに必要な材料を整理させる役割を持たせるのが現実的です。
コピペ用プロンプトテンプレート
次のテンプレートでは、与えた情報とAIの推測を混ぜないように指示しています。{}内を書き換え、不要な項目は「情報なし」と入力してください。
あなたは、プロダクト開発の要件整理を支援するアシスタントです。
以下の情報をもとに、開発チームがレビューできるユーザーストーリーの下書きを作成してください。
# 目的
{今回の機能や改善で解決したい問題}
# 対象となる利用者
{役割、利用状況、習熟度など}
# 利用者が達成したいこと
{利用者が行いたい操作や完了したい仕事}
# 現在の困りごと
{現状の手順、負担、エラー、待ち時間など}
# 業務ルール・制約
{権限、期限、対象データ、禁止事項、法令・社内ルールなど}
# 対象範囲
{今回含める機能や処理}
# 対象外
{今回扱わない機能や将来対応に回す事項}
# 参考情報
{ヒアリングメモ、問い合わせ内容、既存仕様など}
# 作成ルール
- 入力情報だけを根拠にする
- 情報がない内容を事実として補わない
- 推測が必要な箇所は「要確認」と明記する
- 1件のストーリーに複数の独立した目的を詰め込まない
- UI部品名ではなく、利用者が達成したい結果を中心に書く
- 実装方法や技術選定は、入力に明記されている場合を除いて含めない
- 受け入れ条件は、利用者または外部システムから確認できる結果にする
- 受け入れ条件には正常系だけでなく、該当する場合は権限不足、入力不備、データなしのケースも含める
# 出力形式
## ストーリーID
仮IDを1つ付ける
## ユーザーストーリー
「{利用者}として、{達成したいこと}をしたい。なぜなら、{得たい価値}だから。」の形式で1文にする
## 背景
利用者の状況と解決したい問題を3文以内で説明する
## 受け入れ条件
各条件を次の形式で書く
- Given: 前提条件
- When: 利用者の操作または外部イベント
- Then: 観察できる結果
## 対象外
今回のストーリーに含めない内容を箇条書きにする
## 入力情報との対応
ストーリーと各受け入れ条件が、どの入力情報に基づくかを示す
## 不明点・確認質問
確定できない点を、回答しやすい具体的な質問として列挙する
## 分割候補
ストーリーが大きい場合だけ、価値を保ったまま分割する案を示す
ここがポイント: 「足りない情報は自然に補って」と指示せず、不明点を質問として返すようにします。AIの文章完成度より、レビュー可能性を優先する設計です。
入力時に変える項目
出力品質を左右するのは、機能名よりも利用者の状況と達成したい結果です。 最低限、利用者、目的、制約の3点を具体化してください。
毎回変更する項目
{今回の機能や改善で解決したい問題}- 「検索機能を作る」ではなく、「問い合わせ担当者が過去の回答を探すのに時間がかかる」のように問題を書く
{対象となる利用者}- 「ユーザー」だけでなく、「初めて申請する社員」「複数店舗を管理する責任者」など、役割や状況を示す
{利用者が達成したいこと}- 画面やボタンではなく、利用者が完了したい仕事を書く
{業務ルール・制約}- 閲覧権限、締切、入力上限、承認の要否など、結果を変える条件を入れる
{対象範囲}と{対象外}- 今回作るものと作らないものの境界を明確にする
固定しておきたい条件
次の指示は、案件が変わっても残すのがおすすめです。
- 入力情報にない事実を補わない
- 推測を「要確認」として分離する
- ストーリーに独立した目的を詰め込まない
- 実装方法ではなく利用者の結果を書く
- 根拠となる入力情報を示す
- 不明点を具体的な質問へ変換する
AIが不足情報を滑らかに補完すると、文章は読みやすくても、どこまでがヒアリング済みの事実か分からなくなります。「入力情報との対応」は、その混同を見つけるための欄です。
出力形式は「本文・条件・不明点」を分ける
ユーザーストーリー本文と受け入れ条件は役割が異なるため、別の欄に出力させます。
ストーリー本文は利用者と価値を短く共有するものです。受け入れ条件は、そのストーリーが満たされたかを判断する材料になります。
受け入れ条件には、Given／When／Then形式を使えます。CucumberのGherkinリファレンスでは、それぞれを初期状態、イベントや操作、期待される結果として整理しています。
たとえば、次のように記述します。
- Given: 問い合わせ担当者が社内ナレッジを閲覧できる
- When: キーワードを入力して検索する
- Then: 閲覧権限のある記事だけが関連度順に表示される
Thenには「検索処理が実行される」のような内部動作ではなく、担当者が画面上で確認できる結果を書きます。テスト自動化を行わないチームでも、前提、操作、結果を分けることで認識差を見つけやすくなります。
NG例と改善例
失敗しやすいのは、AIに「よいユーザーストーリー」を丸ごと考えさせる指示です。 評価基準も根拠もないため、AIが不足部分を埋めやすくなります。
NG例
管理画面に検索機能を追加します。
よいユーザーストーリーと受け入れ条件を作ってください。
この指示では、少なくとも次の点が分かりません。
- 誰が検索するのか
- 何を検索するのか
- 検索によってどの仕事を早くしたいのか
- 閲覧権限をどう扱うのか
- 0件時や入力不備をどう表示するのか
AIがこれらを埋めると、未確認の仕様が確定事項のように見える危険があります。
改善例
対象利用者は、顧客からの問い合わせに回答するサポート担当者です。
担当者は現在、社内ナレッジをカテゴリから順に開いて過去の回答を探しています。
目的は、問い合わせ文に含まれる語句から関連する記事を見つけ、回答準備を短縮することです。
制約:
- 担当者が閲覧権限を持つ記事だけを表示する
- 検索対象は記事タイトルと本文
- 並び順と検索語の扱いは未決定
- 記事の新規作成と編集は今回の対象外
この情報だけを使い、ユーザーストーリー、Given／When／Then形式の受け入れ条件、対象外、不明点を出してください。
未決定事項は推測せず、確認質問にしてください。
改善点は、単に文章量を増やしたことではありません。利用者、現在の行動、目標、制約、未決定事項を分けたことで、AIが判断してよい範囲を狭めています。
出力を安定させる3つのコツ
形式、制約、確認手順を明文化すると、案件が変わってもレビューしやすい出力になります。
1. 1件に1つの利用者価値を置く
「検索して、記事を編集し、承認依頼を送る」のようなストーリーは、複数の目的を含んでいます。AIには、独立して確認できる価値ごとに分割候補を出させます。
ただし、作業工程だけを細かく切り分けると、単独では価値を確認できない項目が増えます。分割後も、誰にどんな結果が届くかを残してください。
2. 正常系以外を入力段階で指定する
受け入れ条件が正常系だけにならないよう、案件に関係する例外を入力します。
- 権限がない場合
- 必須情報が欠けている場合
- 対象データが0件の場合
- 同じ操作が重複した場合
- 外部サービスが応答しない場合
すべてを機械的に追加する必要はありません。「該当するケースだけ」と指示すれば、不要な条件の水増しを抑えられます。
3. 最後に自己点検させる
最初の出力に続けて、次の追加プロンプトを送ります。
作成した内容を次の観点で点検してください。
- 利用者の役割が具体的か
- ストーリーに独立した目的が複数入っていないか
- 利用者が得る価値を説明できているか
- 受け入れ条件が観察可能な結果になっているか
- 入力にない仕様を事実として追加していないか
- 対象外と不明点が分離されているか
問題がある箇所だけを示し、修正版を出してください。
新しい事実は追加しないでください。
この点検は人のレビューを代替するものではありません。AIが作った下書きの内部矛盾や、指定形式からの逸脱を先に洗い出すために使います。
活用例：問い合わせ検索の要件を整理する
短いヒアリングメモでも、確定事項と質問を分離すれば次の打ち合わせに使える下書きになります。
入力例は次のとおりです。
目的: 問い合わせへの回答準備を短縮する
対象利用者: 社内ナレッジを利用するサポート担当者
達成したいこと: 問い合わせ文の語句から過去の回答を見つける
現在の困りごと: カテゴリを順番に開いて探している
制約: 閲覧権限のある記事だけを表示する
対象範囲: 記事タイトルと本文の検索
対象外: 記事の作成・編集、顧客向け画面
参考情報: 並び順、部分一致の扱い、0件時の表示は未決定
期待する出力の要点は次のようになります。
## ユーザーストーリー
サポート担当者として、問い合わせ文の語句から閲覧可能な過去の記事を検索したい。なぜなら、回答に使える情報を見つけやすくしたいから。
## 受け入れ条件
- Given: サポート担当者が社内ナレッジを閲覧できる
- When: 検索語を入力して検索する
- Then: タイトルまたは本文が検索条件に該当する記事が表示される
- Given: 閲覧権限の異なる記事が存在する
- When: サポート担当者が検索する
- Then: その担当者に閲覧権限がある記事だけが表示される
## 不明点・確認質問
- 検索結果は何を基準に並べますか
- 部分一致、完全一致のどちらを必要としますか
- 該当記事がない場合、どの案内を表示しますか
ここでは、未決定の並び順や0件時の表示を、受け入れ条件へ勝手に追加していません。質問として残すことで、プロダクトオーナーや利用部門が判断できます。
AIの出力をそのまま確定要件にしない
AIが作るのは会話を始める下書きであり、優先順位や実装可否を決める主体ではありません。
Scrum Guideでは、プロダクトバックログをプロダクト改善に必要なものの順序付きリストとし、プロダクトオーナーが明確なバックログ項目の作成・伝達や順序付けに責任を持つとしています。また、バックログ項目はリファインメントによって、より小さく具体的な項目へ継続的に整えられます。
そのため、AIの出力後には関係者が次を確認します。
- 実在する利用者の問題を表しているか
- その価値はプロダクトゴールに結び付くか
- 業務ルールや権限の理解に誤りがないか
- 受け入れ条件をチーム全員が同じ意味で読めるか
- 1回の開発単位として大きすぎないか
- 対象外や未決定事項が合意されているか
見落とされやすいのは、文章の整い方と要件の確かさは別だという点です。読みやすいストーリーでも、利用者への確認や技術的な検討が済んでいるとは限りません。
実行前チェックリスト
プロンプトを送る前後に、次の項目を確認してください。
- [ ] 利用者を「ユーザー」だけで済ませず、役割や利用状況を書いた
- [ ] 実装したい機能ではなく、解決したい問題を書いた
- [ ] 対象範囲と対象外を分けた
- [ ] 権限や業務ルールを入力した
- [ ] 未決定事項を明記した
- [ ] 入力にない内容を補わないよう指示した
- [ ] 受け入れ条件を観察可能な結果で書かせた
- [ ] 根拠と不明点を別々に出力させた
- [ ] 利用者、開発担当者、プロダクト責任者がレビューした
最初から完璧なストーリーを一括生成する必要はありません。まず不明点を出し、関係者から回答を得て、同じテンプレートへ追記する。この往復を短く回すことが、AIを要件整理に使う際の実践的な進め方です。
次の分岐点は、AIが挙げた確認質問に誰が答えるかです。回答者と期限が決まらなければ、整った下書きも未確定のまま止まります。バックログへ移す前に、各質問の担当者を割り当ててください。