ユーザーストーリーの書き方｜INVEST原則と「As a / I want / So that」フォーマット完全解説

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

ユーザーストーリーが機能しない根本原因は、「システムが何をするか」を書いてしまうことです。 ユーザーストーリーは「ユーザーが何を達成したいか」を書くものであり、この視点のズレが「書いたけど誰も見なくなった」「テストの基準が曖昧」という状態を生みます。本記事では、AtlassianやAgile Allianceの定義をもとに、「As a / I want / So that」フォーマットの書き方とINVEST原則によるチェック方法を実例付きで整理します。

ユーザーストーリーとは

ユーザーストーリーとは、ユーザーの視点から見た「誰が・何を・なぜ必要か」を1〜2文で表した要件記述の単位です。Agile Allianceでは「ソフトウェアの機能を、それを使いたいユーザーの視点から短く記述したもの」と定義されています。

ユーザーストーリーの役割は3つです。

役割	内容
会話のきっかけ	チームとPO・ユーザーの対話を促す出発点。詳細はすべてストーリーに書かない
価値の可視化	「なぜ作るか（So that）」を明記することでビジネス価値を常に意識する
テストの基準	受け入れ条件（Acceptance Criteria）とセットで「完成の判断基準」になる

---

「As a / I want / So that」フォーマット

ユーザーストーリーの標準フォーマットは次のとおりです。

As a [ユーザーの種類],
I want [達成したいこと],
so that [なぜ達成したいか・得られる価値].

日本語では「〜として、〜したい。なぜなら〜だから。」と読み替えられます。

各パーツの書き方

① As a ——「ユーザーの種類」

ロールや属性でユーザーを定義します。「ユーザー」や「管理者」のような漠然とした表現より、具体的なペルソナや役割で書くと要件の解釈のブレが減ります。

NG（曖昧）	OK（具体的）
As a user	As a 購買担当者
As a manager	As a 在庫管理を担当している倉庫スタッフ
As an admin	As a システム管理権限を持つ担当者

② I want ——「達成したいこと（機能・行動）」

ユーザーが行いたいこと（動作） を書きます。「システムが〜する」という主語にしてしまうのが最もよくある誤りです。

NG（システム主語）	OK（ユーザー行動）
I want the system to send emails	I want to receive a shipment confirmation email
I want the database to be updated	I want to update my delivery address before shipping
I want the API to return data	I want to see my order history on one screen

③ So that ——「得られる価値・目的」

「なぜその機能が必要か」を書きます。このパーツを省略するストーリーが多いですが、ここが優先順位判断の根拠になるため必ず書きます。

実例（ECサイトの在庫管理機能）

As a 在庫管理担当者,
I want to 商品の在庫数をリアルタイムで確認したい,
so that 欠品が起きる前に補充発注を出し、機会損失を防ぐことができる.

---

INVEST原則｜6つのチェックリスト

INVESTは、2003年にBill Wakeが提唱したユーザーストーリーの品質チェック原則です。xp123.comで公開されたこの原則は、6つの頭文字で構成されます。

文字	英語	日本語	意味
I	Independent	独立している	他のストーリーへの依存がない
N	Negotiable	交渉可能	スプリント開始前は変更・調整できる
V	Valuable	価値がある	ユーザーまたはビジネスに明確な価値をもたらす
E	Estimable	見積もり可能	チームが見積もりできる粒度・情報量がある
S	Small	小さい	1スプリント内で完了できるサイズ
T	Testable	テスト可能	完了を判断できる受け入れ条件を書ける

I — Independent（独立している）

ストーリーが別のストーリーに依存していると、スプリントの計画が崩れます。「ストーリーBが完了しないとAに着手できない」という状況は、バックログの並べ替えの自由度を奪います。

依存を解消する方法：

• 依存している部分を抽象化してAとBを独立させる
• AとBを合体させて1つのストーリーにする
• 依存関係を受け入れ条件で管理する（小さな依存なら許容）

N — Negotiable（交渉可能）

ストーリーは固定された仕様書ではありません。スプリントで実装が始まる前であれば、実装方針・スコープ・UIを柔軟に変更できます。「交渉可能」は「いつでも破棄できる」ではなく、「詳細はチームとPOの対話で決まる」という意味です。

V — Valuable（価値がある）

ストーリーはエンドユーザーまたはビジネスに価値をもたらすものでなければなりません。技術的なタスク（「データベースをリファクタリングする」「テストカバレッジを80%にする」）は技術的負債の解消として価値がありますが、それを「ユーザーストーリー」として書いてはいけません。

カテゴリ	バックログへの入れ方
ユーザー価値（機能）	ユーザーストーリーとして書く
技術的負債・インフラ	テクニカルタスクとして書く（as a developer〜でも可）
調査・スパイク	スパイクとして書き、タイムボックスを設ける

E — Estimable（見積もり可能）

チームがストーリーポイントなどで見積もりできなければ、スプリントプランニングで選択できません。見積もりができない主な原因は2つです。

• ドメイン知識の不足：チームがその領域を知らない → スパイク（調査）を先に行う
• ストーリーが大きすぎる：サイズが見通せない → 小さく分割する

S — Small（小さい）

ストーリーは1スプリント内で完了できるサイズが理想です。大きいストーリーは「エピック」と呼び、スプリントに投入する前に小さなストーリーに分割します。

分割のヒント：

分割の切り口	例
ワークフロー（手順）で分割	「注文完了」→①カート追加 ②決済 ③確認メール
データ種別で分割	「商品検索」→①キーワード検索 ②カテゴリ絞り込み
ハッピーパス vs エラーケース	正常系を先に、例外処理を後のストーリーに
操作権限で分割	閲覧のみ → 編集可能 → 管理者の順

T — Testable（テスト可能）

「テスト可能」とは、受け入れ条件（Acceptance Criteria）を書ける状態であることを指します。テストできないストーリーは「完成したかどうか」を誰も判断できず、品質の曖昧さが残ります。

---

受け入れ条件（Acceptance Criteria）の書き方

受け入れ条件は「このストーリーが完了したと判断するための基準」です。Gherkin形式（Given/When/Then）または箇条書き形式で書きます。

Gherkin形式（Given/When/Then）

Given（前提条件）: 在庫管理担当者がダッシュボードにログインしている
When（操作）: 「商品一覧」ページで商品名を選択する
Then（期待結果）: 現在の在庫数・入荷予定数・出荷済み数がリアルタイムで表示される

パーツ	役割	書き方のコツ
Given	テスト開始時の前提状態	ログイン状態・権限・データの有無など
When	ユーザーが行う操作	クリック・入力・送信など1つのアクション
Then	操作後の期待する結果	画面表示・メール送信・DB更新など検証可能な状態

箇条書き形式

シンプルなストーリーには箇条書きが適しています。

【受け入れ条件】
□ 在庫数が10個以下になると、一覧画面で「残りわずか」バッジが表示される
□ 在庫数が0になると「在庫切れ」と表示され、発注ボタンが非活性になる
□ 在庫数の更新は1分以内に画面に反映される
□ 管理者権限のない担当者は在庫数を編集できない

---

エピック・ストーリー・タスクの違い

単位	説明	粒度の目安	バックログへの入れ方
エピック	複数スプリントにまたがる大きな機能の塊	数か月〜数スプリント分	バックログに入れ、分割してからスプリントへ
ストーリー	1スプリントで完了できる価値の単位	数時間〜数日（1〜2週間以内）	INVESTを満たした状態でスプリントへ投入
タスク	ストーリーを完了させるための技術的作業	数時間以内	スプリントバックログ内で開発者が分解

---

ユーザーストーリーのメリット・デメリット

---

よくある失敗5選

❌ 失敗①：システム主語で書く（「システムが〜する」）

「システムが注文データを送信する」はユーザーストーリーではなくシステム仕様です。ユーザーストーリーはユーザーが主語でなければなりません。書く前に「このストーリーの主語はエンドユーザーか？」を確認してください。

❌ 失敗②：So that を省略する

「As a 担当者, I want 在庫を確認する」だけでは、なぜ確認するのかが分かりません。「So that 欠品前に補充発注を出し、機会損失を防ぐ」まで書いて初めてビジネス価値が見えます。So that がないストーリーは優先順位を下げる根拠にも、上げる根拠にもなりません。

❌ 失敗③：エピックをそのままスプリントに投入する

「ECサイトの注文管理機能をすべて作る」はエピックです。このままスプリントに入れると2〜3スプリントが終わっても完了しません。INVESTの「S（Small）」チェックで「1スプリントで完了するか？」を確認し、分割してからスプリントに投入します。

❌ 失敗④：受け入れ条件を書かない

受け入れ条件がないストーリーは「テスト可能（T）」の原則に反します。開発者は「何をもって完成とするか」が分からず、POは「自分のイメージと違う」と言い始めます。ストーリーをバックログに追加するとき、受け入れ条件を同時に書くことをルールにしてください。

❌ 失敗⑤：技術タスクをユーザーストーリー形式で無理に書く

「As a developer, I want to refactor the database schema」は技術タスクです。無理にユーザーストーリー形式で書くより「テクニカルタスク」や「スパイク」として別扱いし、なぜその技術的作業が必要か（ユーザー価値との接続）をコメントや補足として添える方がチームに伝わります。

---

よくある質問（FAQ）

Q. 「As a developer, I want〜」は書いていい？

書けますが、「ユーザーストーリー」ではなく「テクニカルストーリー」として扱いましょう。バックログ上で区別するためにラベルを付けるか、エピックとは別のカテゴリで管理する運用が多いです。重要なのは「このタスクがどのユーザー価値に紐づくか」を明示することです。

Q. 1つのストーリーに受け入れ条件は何個まで？

一般的な目安は5〜10個以内です。それ以上になる場合、ストーリーが大きすぎる（Sに違反）可能性があります。受け入れ条件の数はストーリーサイズの指標として使えます。

Q. Given/When/Then と箇条書きはどちらがいい？

複雑な操作フローや条件分岐がある場合はGherkin形式（Given/When/Then）、シンプルな表示・権限・非機能要件は箇条書きが向いています。チームで統一することが重要で、どちらが正しいというわけではありません。

Q. INVESTの全項目を毎回チェックしないといけない？

スプリントに投入する前（リファインメント時）に確認するのが理想です。特に「S（Small）」と「T（Testable）」は必ずチェックします。残りは状況に応じて重点的に確認する項目を変えても構いません。

Q. ユーザーストーリーはユーザーが書く必要があるか？

必ずしもそうではありません。プロダクトオーナーやスクラムマスターが書くケースが多いです。重要なのは「書く人」ではなく「ユーザー視点で書かれているか」です。書いた後にユーザーや実際の担当者にレビューしてもらうことで精度が上がります。

---

まとめ｜ストーリーの質は「視点」と「受け入れ条件」で決まる

ユーザーストーリーのポイントを整理すると次のとおりです。

チェック項目	OKの状態	NGの状態
主語	ユーザー・担当者が主語	「システムが〜」「データベースが〜」
So that	なぜ必要かが書いてある	省略されている
INVEST	6項目を満たしている	依存・大きすぎ・テスト不可
受け入れ条件	Given/When/Then または箇条書きで書かれている	記載なし・「動けばOK」

ユーザーストーリーは「要件の箱」ではなく「チームとの対話のきっかけ」です。完璧に書こうとするより、チームが「これ、どういう意味？」「この受け入れ条件で合ってる？」と対話できる水準で書き、リファインメントで詳細を決める運用が現場に合っています。

次のステップとして、以下の関連記事も参照してください。

• スクラムの3つの作成物 完全解説（プロダクトバックログ・スプリントバックログとの関係）
• スクラムの5つのイベント完全解説（リファインメント・プランニングでストーリーを使う場面）
• スクラムガイド2020完全解説｜3つの役割・5つのイベント・3つの作成物（スクラムの全体像）