公式スキル · プロダクト

受け入れ条件つきのユーザーストーリー

v1.0.1・2026年11月4日更新

機能をユーザーストーリーに分け、Given/When/Then の受け入れ条件、エッジケース、対象外のメモ、ストーリーごとの INVEST のチェックをつける。

チームのPodに追加

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

PRD や機能が合意され、チケットとしてバックログに入れたい
チケットはあるのに、どうなれば完了かだれも言えない

AI に渡すもの

機能の説明か PRD のセクション
関わるユーザーの役割
わかっているルールと制限（任意）

できあがるもの

ユーザーストーリーの一式。それぞれに Given/When/Then のシナリオ、エッジケース、対象外のメモ、INVEST の行、未決の質問をつける。

手順

役割とその目的を挙げる 役割ごとに、この機能で何を成し遂げたいかを書く。1ストーリーに役割は1つ。「ユーザーと管理者」のストーリーは2つのストーリーにする。
各ストーリーを「〈役割〉として、〈成果〉のために、〈機能〉がほしい」の形で書く Dan North は、この型（As a / I want / so that）が、書く人に価値を言わせるものだと説明している。「〜のために」には、機能の言い直しではなく、ユーザーが気にかける成果を書く。正直な「〜のために」が「そう決まったから」なら、範囲から外す候補として印をつける。
ユーザーに見える単位で分ける 業務の流れの段階、業務ルールの違い、データの種類、または正常系を先に例外をあとに、で分ける。技術的な層（「バックエンドのストーリー」「フロントエンドのストーリー」）では分けない。どのストーリーも、ユーザーが試せるものを届ける。
受け入れ条件を Given/When/Then で書く Given は前提の状態。When は1つの操作。Then は目に見える結果。条件を足すときは And でつなぐ。1ストーリーにシナリオを2〜5個（このスキルの既定値）：正常系、少なくとも1つの失敗系、ルールの境界。
エッジケースを挙げる 各ストーリーを次で確かめる：データが空、とても長い入力、重複、権限がない、接続が切れる、同じ操作を2回、既存のデータはどうなるか。各エッジケースは、シナリオにするか、対象外に入れる。
対象外のメモを書く このストーリーであえてやらないことを書き、レビューする人が期待しないようにする。
INVEST で確かめる Bill Wake の INVEST：Independent（独立している）、Negotiable（交渉できる）、Valuable（価値がある）、Estimable（見積もれる）、Small（小さい）、Testable（テストできる）。文字ごとに合格か不合格かをつける。Small が不合格ならさらに分ける。Testable が不合格なら、受け入れ条件があいまいすぎる。Independent が不合格なら、依存関係を書く。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む