ガイド
ChatGPT でユーザーストーリーを書く方法
ChatGPT や Claude は、役に立つストーリーの要素を頼めば、機能をチームが作って確かめられるユーザーストーリーにできます。1 つのストーリーに 1 つの役割で、「〜として、〜したい。なぜなら〜」と書き、「なぜなら」に利用者が大事にする成果を入れる。バックエンドとフロントエンドではなく、利用者が単独で試せる単位で切る。受け入れ条件は Given/When/Then で、うまくいく道、少なくとも 1 つの失敗の道、ルールの境目。境界の場面(データが空、重複、権限なし、同じ操作を 2 回)、わざと範囲外にすること、そしてストーリーごとの INVEST の確認。そのあとチームはほかの下書きと同じようにレビューし、Small か Testable で落ちたものから見ます。
要点
- 1 つのストーリーに 1 つの役割、本当の「なぜなら」。
- 利用者が試せる単位で切る。
- Given/When/Then、失敗の道つき。
- 境界の場面、範囲外、INVEST。
そのまま使える頼み方
ユーザーストーリーの頼み方
「この機能をユーザーストーリーにしてください。
1 つのストーリーに 1 つの役割:[役割]として、[操作]したい。なぜなら[利用者が大事にする成果]。本当の「なぜなら」が「そう決めたから」になるものには印をつける。
技術の層では分けず、利用者が試せる単位で分ける。
ストーリーごとに、Given / When / Then の受け入れ条件を 2〜5 つ:うまくいく道、少なくとも 1 つの失敗の道、ルールの境目。
データが空、とても長い入力、重複、権限なし、接続が切れる、同じ操作を 2 回、既存のデータ、を確かめる。それぞれ受け入れ条件にするか範囲外に。
最後に INVEST の確認を、文字ごとに合否で。
機能とルール:[貼りつけ]」
例
架空の例です。請求書のアプリで、顧客が請求書を表計算のファイルに書き出せるようにします。ストーリーの 1 つ:
ストーリーから
ストーリー:経理の担当者として、1 か月分の請求書を CSV で書き出したい。なぜなら、打ち直さずに会計ソフトで照合できるから。
Given 3 月の日付の請求書が 40 枚ある、When 3 月を書き出す、Then 40 行で、番号、日付、顧客、税抜、税、合計の列を持つ CSV が 1 つできる。
Given 3 月の請求書がない、When 3 月を書き出す、Then「この月の請求書はありません」と表示され、ファイルはできない。
Given 請求の権限がない閲覧者である、When 書き出しを開く、Then ボタンは押せず、だれが書き出せるかが表示される。
境界の場面:カンマを含む顧客名(CSV では引用符で囲む)。2 回書き出す(ファイルが 2 つ、エラーなし)。
範囲外:入金の書き出し。定期の書き出し。
INVEST:すべて合格。入金は別のストーリーなので Small も合格。
プロダクトマネージャーは、会計ソフトが求める列の順番(AI には知りようがない)を足してから、計画に回しました。
計画の前に
- どの「なぜなら」も、利用者が欲しいと言いそうなことか確かめる。
- 自分しか知らないことを足す:形式、上限、製品のルール。
- Small で落ちたものは分け、Testable で落ちたものは条件を鋭くする。
- 顧客のデータは貼らず、データの形を説明する。
- 頼み方を保存し、次の機能で使う。
次の一歩:作る前にレビュー
ストーリーは、もとの仕様書の抜けを引き継ぎます。仕様書全体の確かめ方は作る前に仕様書を AI でレビューする方法で。メモから始めるならメモから ChatGPT で PRD を書く方法で。
このテーマに使えるスキル
- プロダクト受け入れ条件つきのユーザーストーリー機能をユーザーストーリーに分け、Given/When/Then の受け入れ条件、エッジケース、対象外のメモ、ストーリーごとの INVEST のチェックをつける。
- プロダクト散らかったメモから PRD を作るメモ、Slack のスレッド、商談メモから PRD を作る。根拠つきの課題、目標と目標外、指標、Must・Should・Could の要件をそろえ、足りない情報を挙げる。
- プロダクト作りはじめる前の仕様書レビュー作りはじめる前に PRD や仕様書をレビューする。あいまいさ、空・読み込み中・エラー・権限なしの抜け、指標、段階リリース、はじめて使う人としての流れ。
- プロダクトRICE で機能の優先順位づけバックログを RICE か ICE で採点し、項目ごとの計算と感度を示して、工数に合わせた線引きと依存関係を提案する。
よくある質問
ChatGPT でユーザーストーリーは書ける?
作れるストーリーにするための要素を頼めば書けます。1 つのストーリーに 1 つの役割、本当の成果を言う「なぜなら」、利用者が単独で試せる切り方、少なくとも 1 つの失敗の道を含む Given/When/Then の受け入れ条件、境界の場面、範囲外のこと、INVEST の確認。そのうえで、ほかの下書きと同じようにチームでレビューします。
受け入れ条件の形式は?
Given(前提の状態)、When(1 つの操作)、Then(目に見える結果)。条件を足すときは And でつなぎます。1 つのストーリーに 2〜5 つ。うまくいく道、少なくとも 1 つの失敗の道、ルールの境目です。
大きなストーリーはどう分ける?
技術の層ではなく、利用者が試せる単位で分けます。作業の手順、ルールの違い、データの種類、まずうまくいく道であとから例外、など。「バックエンドのストーリー」と「フロントエンドのストーリー」はストーリーではなく作業です。
AI スキル
AI に、機能を受け入れ条件つきのユーザーストーリーにさせる
このスキルを AI Skill Pod に入れれば、チーム全員が自分の Claude、Cursor、ChatGPT(Pro・Business・Enterprise)で使えます。招待リンク 1 つで共有でき、無料で始められます。「受け入れ条件つきのユーザーストーリー」スキルで、各自の AI が、機能をユーザーストーリーにします。1 つのストーリーに 1 つの役割、本当の「なぜなら」、利用者が試せる切り方、Given/When/Then の受け入れ条件、境界の場面、範囲外のメモ、ストーリーごとの INVEST の確認。
14日間無料・カード不要
出典
- Dan North:Introducing BDD — As a / I want / so that、Given / When / Then (閲覧 2026-11-04)
- Martin Fowler:Given When Then (閲覧 2026-11-04)
- Bill Wake:INVEST in good stories — Independent、Negotiable、Valuable、Estimable、Small、Testable (閲覧 2026-11-04)