システム開発の要件を整理するとき、

「ユーザーストーリーはどう書けばよいのか」

「『ユーザーとして○○したい』だけで十分なのか」

「業務システムではどのくらい細かく分ければよいのか」

と迷うことがあります。

ユーザーストーリーとは、システムの機能を利用者の立場から表現した短い要求です。

一般的には、

＜誰が＞として、＜何をしたい＞。なぜなら＜目的・価値＞だから。

という形で書きます。

例えば顧客管理システムなら、

営業担当者として、担当顧客を検索したい。なぜなら問い合わせを受けたときに、過去の対応状況をすぐ確認したいから。

と表現できます。

単に、

顧客検索機能を実装する

と書くよりも、

誰が、何のために使う機能なのか

が伝わります。

ただし、ユーザーストーリーを書くだけでは実装条件として不十分な場合があります。

業務システムでは、

• 誰が使うか
• 何を実現したいか
• なぜ必要なのか
• どの状態になれば完了なのか

まで整理することが重要です。

この記事では、業務システム開発を想定して、ユーザーストーリーの基本的な書き方、具体例、適切な粒度、受入条件への落とし込み方まで解説します。

ユーザーストーリーとは

ユーザーストーリーとは、システムに必要な機能を利用者が実現したい価値の単位で表現する方法です。

例えば在庫管理システムで、

「在庫検索機能」

という機能が必要だとします。

機能名だけでは、

• 誰が利用するのか
• なぜ検索するのか
• 何を確認したいのか

が分かりません。

これをユーザーストーリーにすると、

倉庫担当者として、商品コードから在庫を検索したい。なぜなら出庫依頼を受けたときに、すぐ在庫の有無を確認したいから。

となります。

「在庫検索」というシステム側の表現から、

利用者が業務上やりたいこと

へ視点が変わるのがポイントです。

ユーザーストーリーの基本的な書き方

代表的なのは次の形式です。

＜ユーザー＞として、＜やりたいこと＞をしたい。なぜなら＜目的・価値＞だから。

3つに分解すると、

誰が

• 営業担当者
• 営業管理者
• 経理担当者
• 倉庫担当者
• システム管理者
• 顧客

何をしたいか

• 顧客を検索したい
• 案件を登録したい
• 在庫を確認したい
• 申請を承認したい
• ユーザーを追加したい

なぜ必要か

• 問い合わせへすぐ回答したい
• 案件状況を共有したい
• 欠品を防ぎたい
• 不正な申請を防ぎたい
• 新入社員がシステムを利用できるようにしたい

という構成です。

良いユーザーストーリーの具体例

例えば営業支援システムなら、

営業担当者として、顧客名から顧客情報を検索したい。なぜなら問い合わせ時に過去の対応履歴をすぐ確認したいから。

となります。

在庫管理システムなら、

倉庫担当者として、商品の現在庫を確認したい。なぜなら出庫可能な数量を判断したいから。

承認システムなら、

部門管理者として、自部署の申請一覧を確認したい。なぜなら未承認の申請を漏れなく処理したいから。

ユーザー管理なら、

システム管理者として、退職したユーザーを無効化したい。なぜなら退職者がシステムへアクセスできないようにしたいから。

このように、機能ではなく業務上の目的まで含めると理解しやすくなります。

悪いユーザーストーリーの例

悪い例1｜機能名だけ

顧客検索機能を作る。

これはユーザーストーリーというより、機能一覧です。

誰が何のために検索するのか分かりません。

改善例

営業担当者として、顧客名・電話番号から顧客を検索したい。なぜなら問い合わせ時に対象顧客をすぐ特定したいから。

悪い例2｜ユーザーが曖昧

ユーザーとして、顧客を管理したい。

「ユーザー」が誰なのか分かりません。

営業担当と管理者では必要な操作が違う可能性があります。

改善例

営業担当者として、自分が担当する顧客情報を更新したい。なぜなら最新の連絡先・対応状況をチームへ共有したいから。

悪い例3｜大きすぎる

管理者として、在庫管理したい。

これでは範囲が広すぎます。

実際には、

• 在庫を検索する
• 在庫数を確認する
• 入庫する
• 出庫する
• 在庫を調整する
• 履歴を見る

などに分かれます。

ユーザーストーリーと機能要件の違い

混同されやすいポイントです。

ユーザーストーリー

利用者の視点で、

何を実現したいか・なぜ必要か

を書きます。

例えば、

営業担当者として、担当顧客を検索したい。問い合わせへ迅速に対応するため。

です。

機能要件

システム側で、

何ができる必要があるか

を具体化します。

例えば、

顧客名・電話番号・メールアドレスを条件に顧客を検索できること。

です。

つまり、

ユーザーストーリー → 利用者の要求

機能要件 → システムとして実装する条件

と考えると整理しやすいでしょう。

業務要件からユーザーストーリーへ落とす

ユーザーストーリーだけを思いつきで作るのではなく、業務要件から落とす方法がおすすめです。

例えば、

業務課題

営業担当者ごとにExcelで顧客情報を管理しており、他担当者の対応内容を確認できない。

↓

業務要件

営業部内で顧客情報・対応履歴を共有できるようにする。

↓

ユーザーストーリー

営業担当者として、顧客の過去の対応履歴を確認したい。なぜなら担当変更後でも、それまでのやり取りを把握して対応したいから。

↓

機能要件

• 顧客ごとに対応履歴を登録できる
• 対応履歴を時系列で表示できる
• 対応日時・担当者・内容を表示する

という流れです。

課題 → 業務要件 → ユーザーストーリー → 機能要件

とつなげると、なぜその機能が必要なのか追跡しやすくなります。

業務システム向けユーザーストーリーの具体例

顧客管理

営業担当者として、担当顧客を一覧表示したい。なぜなら今日対応すべき顧客を確認したいから。

営業担当者として、顧客の対応履歴を登録したい。なぜなら次回対応時や担当変更時に過去のやり取りを確認できるようにしたいから。

営業管理者として、全担当者の案件状況を確認したい。なぜなら遅延している案件を早期に把握したいから。

在庫管理

倉庫担当者として、商品コードから在庫を検索したい。なぜなら出庫前に在庫数を確認したいから。

倉庫担当者として、入庫数量を登録したい。なぜならシステム上の在庫数を実在庫に反映したいから。

管理者として、在庫調整履歴を確認したい。なぜなら在庫差異が発生した原因を追跡したいから。

予約管理

利用者として、空いている日時を確認したい。なぜなら予約可能な時間を選びたいから。

利用者として、自分の予約をキャンセルしたい。なぜなら参加できなくなった場合に予約枠を解放したいから。

運営担当者として、日時ごとの予約者一覧を確認したい。なぜなら当日の参加者を把握したいから。

申請・承認

申請者として、経費申請を登録したい。なぜなら上司へ承認を依頼したいから。

上司として、自分に届いている申請を一覧確認したい。なぜなら承認漏れを防ぎたいから。

上司として、内容に問題のある申請を差し戻したい。なぜなら申請者へ修正を依頼したいから。

ユーザーストーリーには受入条件も付ける

ユーザーストーリーだけでは、

どの状態になれば完成なのか

が曖昧です。

そこで受入条件を追加します。

例えば、

ユーザーストーリー

営業担当者として、顧客を検索したい。なぜなら問い合わせ時に対象顧客をすぐ確認したいから。

受入条件

• 顧客名で検索できる
• 電話番号で検索できる
• メールアドレスで検索できる
• 部分一致検索ができる
• 検索結果に顧客名・担当者・電話番号を表示する
• 該当データがない場合は「該当する顧客がありません」と表示する

ここまで整理すると、開発者・テスターも完成条件を理解しやすくなります。

Given／When／Thenで受入条件を書く方法

受入条件をさらに具体化する方法として、

Given／When／Then

があります。

例えば、

顧客検索

Given

顧客「株式会社ABC」が登録されている

When

営業担当者が検索欄へ「ABC」と入力して検索する

Then

検索結果に「株式会社ABC」が表示される

となります。

日本語にすると、

前提

株式会社ABCが登録されている

操作

顧客名「ABC」で検索する

結果

株式会社ABCが検索結果に表示される

でも構いません。

業務担当者が理解できる表現を優先します。

ユーザーストーリーの適切な粒度とは

ユーザーストーリーで難しいのが粒度です。

大きすぎる例は、

営業担当者として、顧客管理したい。

です。

逆に細かすぎると、

営業担当者として、顧客一覧の検索ボタンをクリックしたい。

のようになり、業務価値が分からなくなります。

目安は、一つの業務上の目的・価値を実現する単位です。

例えば、

「顧客管理」

では大きすぎます。

そこで、

• 顧客を検索する
• 顧客詳細を確認する
• 顧客を登録する
• 顧客を編集する
• 対応履歴を登録する

に分割します。

ただし、

「入力欄へ文字を入力する」

「登録ボタンを押す」

まで分ける必要は通常ありません。

大きなユーザーストーリーを分割する方法

大きすぎるストーリーは、いくつかの観点で分割できます。

1．操作で分ける

例えば、

管理者として、ユーザーを管理したい。

を、

• ユーザーを一覧表示したい
• ユーザーを登録したい
• ユーザーを編集したい
• ユーザーを無効化したい

に分けます。

2．利用者で分ける

例えば顧客情報について、

営業担当者

自分の担当顧客を確認したい。

営業管理者

全担当者の顧客を確認したい。

と分けます。

3．業務フローで分ける

予約なら、

予約枠を探す
↓
予約する
↓
予約を確認する
↓
変更する
↓
キャンセルする

に分けます。

4．ルール・難易度で分ける

最初は、

顧客名で検索できる

だけを実装し、後から、

複数条件による詳細検索

を追加する方法もあります。

「CRUDで分ければよい」とは限らない

業務システムでは、

• Create
• Read
• Update
• Delete

で機械的に分割しがちです。

例えば、

顧客を登録する
顧客を表示する
顧客を更新する
顧客を削除する

という分割です。

これでも整理できますが、業務価値が見えにくくなる場合があります。

例えば「削除」ではなく、

システム管理者として、退職者のアカウントを無効化したい。退職後のアクセスを防ぐため。

の方が、実際に必要なのが物理削除ではなく「無効化」であることが分かります。

ユーザーストーリーでは、DB操作ではなく業務の目的から考えるのがポイントです。

ユーザーストーリーの優先順位を付ける

すべてを同時に開発する必要はありません。

例えば、

Must

• ログイン
• 顧客検索
• 顧客登録
• 案件管理

Should

• CSV出力
• ダッシュボード

Could

• メール通知

Later

• AIによる営業分析

などに分けます。

ユーザーストーリー単位で優先順位を決めれば、

初回リリースでどこまで作るか

を整理しやすくなります。

ユーザーストーリーにIDを付ける

実務ではIDを付けると管理しやすくなります。

例えば、

ID	ユーザーストーリー	優先度
US-001	営業担当者として顧客を検索したい	Must
US-002	営業担当者として顧客を登録したい	Must
US-003	営業担当者として対応履歴を記録したい	Must
US-004	管理者として案件状況を確認したい	Should

さらに、

• 業務要件ID
• 機能要件ID
• 画面ID

と紐付けることもできます。

例えば、

BR-001
顧客情報を営業部内で共有する

↓

US-003
営業担当者として対応履歴を確認したい

↓

FR-010
顧客ごとに対応履歴を表示できる

↓

SCR-004
顧客詳細画面

という関係です。

【コピペ用】ユーザーストーリーテンプレート

基本形は次のとおりです。

■ ユーザーストーリーID

US-


■ 利用者

○○として


■ やりたいこと

○○したい


■ 目的

なぜなら○○だから


■ ユーザーストーリー

○○として、○○したい。
なぜなら○○だから。


■ 受入条件

・
・
・


■ 優先度

Must / Should / Could / Later


■ 関連業務要件

BR-


■ 関連機能要件

FR-


■ 関連画面

SCR-


■ 備考

【一覧管理用】ユーザーストーリー表

ExcelやGoogle Sheetsなら、次の形式でも管理できます。

ID	利用者	やりたいこと	目的	優先度	状態
US-001	営業担当	顧客検索	問い合わせ対応	Must	確定
US-002	営業担当	顧客登録	顧客情報共有	Must	確定
US-003	管理者	案件一覧確認	遅延把握	Should	検討中

詳細な受入条件は別シートやチケットへ記載しても構いません。

ユーザーストーリーを作る7ステップ

実務では次の流れがおすすめです。

STEP1｜利用者を整理する

まずシステムを使う役割を洗い出します。

例えば、

• 一般社員
• 営業担当
• 管理者
• 経理
• システム管理者

です。

STEP2｜業務フローを整理する

例えば受注管理なら、

問い合わせ
↓
見積
↓
受注
↓
出荷
↓
請求

という流れを整理します。

STEP3｜各工程で利用者がやりたいことを出す

例えば「受注」なら、

営業担当者として、受注内容を登録したい。

などです。

STEP4｜「なぜ？」を付ける

なぜ必要かを確認します。

なぜ登録したい？

↓

出荷・請求担当へ正確な受注情報を共有したいから。

となります。

STEP5｜ストーリーを適切な粒度へ分割する

一つのストーリーが大きすぎる場合は分けます。

STEP6｜受入条件を書く

どこまでできれば完了なのか決めます。

STEP7｜優先順位を付ける

初回リリースで必要か、後回しにできるか判断します。

ユーザーストーリーをレビューするときのチェックリスト

□ 誰が使うか明確か

□ 何をしたいか明確か

□ なぜ必要か説明できるか

□ 一つの業務価値に絞られているか

□ 大きすぎないか

□ 細かすぎないか

□ 受入条件があるか

□ 完了したか判断できるか

□ 業務要件と紐付いているか

□ 必要な画面・機能と紐付いているか

□ 優先順位が決まっているか

ユーザーストーリーでよくある失敗

失敗1｜「ユーザーとして」で全部書く

利用者ごとの違いが見えません。

「営業担当者」「営業管理者」など具体的な役割を書きます。

失敗2｜機能名を書いただけになる

「CSV出力したい」ではなく、なぜ必要なのかまで確認します。

失敗3｜粒度が大きすぎる

「販売管理したい」では開発タスクへ落とせません。

業務価値単位へ分割します。

失敗4｜細かすぎる

「ボタンをクリックしたい」まで細分化すると、本来の目的が見えなくなります。

失敗5｜受入条件を書かない

開発者と発注者で「完成」の認識がずれる原因になります。

失敗6｜画面からユーザーストーリーを作る

「顧客一覧画面があるから検索ストーリーを作る」という順番だけでは、本来の業務課題から離れる可能性があります。

基本は、

業務 → ユーザーストーリー → 機能・画面

です。

失敗7｜一度作ったら変更しない

プロトタイプや現場レビューによって、ユーザーストーリーが追加・分割されることがあります。

必要に応じて更新します。

ユーザーストーリーとプロトタイプを組み合わせる

ユーザーストーリーは文章なので、画面イメージと組み合わせるとさらに理解しやすくなります。

例えば、

ユーザーストーリー

営業担当者として、顧客の過去の対応履歴を確認したい。なぜなら担当変更後もスムーズに対応したいから。

↓

プロトタイプ

顧客詳細画面に、

• 対応日時
• 担当者
• 対応方法
• 対応内容

を時系列で表示します。

↓

現場レビュー

電話・メールを絞り込みたい

という要望が出ます。

↓

ユーザーストーリー・受入条件を更新

という流れです。

文章と画面の両方で確認すると、認識ズレを減らしやすくなります。

業務システムでは「現場が理解できる言葉」で書く

ユーザーストーリーの目的は、開発者だけが理解することではありません。

例えば、

Warehouse OperatorとしてStock EntityのAvailable QuantityをReferenceしたい

と書く必要はありません。

現場で、

倉庫担当者として、出庫できる在庫数を確認したい。

と理解できるなら、その方が適切です。

特に要件定義では、

• 発注者
• 現場担当
• PM
• エンジニア
• テスター

が同じ内容を理解できる表現を使うことが重要です。

ユーザーストーリーは仕様書の代わりになる？

完全な代替にはなりません。

ユーザーストーリーでは、利用者の要求・価値を整理できます。

しかしシステム開発には、

• 非機能要件
• データ設計
• 権限
• API
• バッチ
• セキュリティ
• バックアップ
• 外部連携

などもあります。

例えば、

営業担当者として顧客を検索したい

だけでは、

• 何秒以内に表示するか
• 10万件でも検索できるか
• 他部署の顧客を見られるか

までは決まりません。

そのため、

ユーザーストーリー＋受入条件＋機能要件＋非機能要件

などを組み合わせます。

ユーザーストーリーを使うべきケース

特に向いているのは、

• アジャイル開発
• 業務システム
• 新規Webサービス
• 現場ユーザーが多いシステム
• 要件を段階的に具体化する開発

などです。

利用者視点で機能の価値を整理しやすいためです。

一方、画面のない単純なバッチ処理などでは、詳細な処理要件の方が分かりやすいケースもあります。

すべてを無理にユーザーストーリー化する必要はありません。

ユーザーストーリーに関するよくある質問

ユーザーストーリーは一文だけでよいですか？

基本形は一文ですが、実装へ進む場合は受入条件・優先度・関連要件なども整理する方が実務では使いやすくなります。

一つのユーザーストーリーに何機能まで入れてよいですか？

明確な件数ルールはありません。

一つの業務価値として説明でき、開発・レビュー可能な大きさかどうかで判断します。

ユーザーストーリーとユースケースは何が違いますか？

ユーザーストーリーは「誰が、何をしたい、なぜ」を短く表現します。

ユースケースは、利用者とシステムのやり取りをより具体的なシナリオとして整理する方法です。

複雑な業務では、ユーザーストーリーから詳細なユースケースへ展開する方法もあります。

ユーザーストーリーは誰が書きますか？

プロジェクトによります。

PM・プロダクトオーナー・要件定義担当などが中心となり、業務担当者・開発者と確認しながら作る方法があります。

重要なのは、一人で考えるのではなく実際の利用者・業務担当者の要求を反映することです。

ウォーターフォールでも使えますか？

使えます。

アジャイルで利用されることが多い手法ですが、ウォーターフォールでも業務要求を利用者視点で整理する補助資料として利用できます。

hiro-dev-labの要件定義・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく業務整理・要件定義から対応しています。

例えば、

• 現状業務のヒアリング
• As-Is・To-Be業務フロー整理
• 業務要件整理
• ユーザーストーリー整理
• 機能要件・受入条件整理
• 画面一覧作成
• プロトタイプ整理
• データ・権限設計
• Java・Python・TypeScriptによるWebシステム開発

などを検討できます。

例えば、

「現場から要望は出ているが、そのまま機能一覧にしてよいか分からない」

という場合でも、

業務課題 → 業務要件 → ユーザーストーリー → 機能要件 → 画面・プロトタイプ

という順番で整理できます。

良いユーザーストーリーは「機能」ではなく「業務価値」が伝わる

ユーザーストーリーを書くときに重要なのは、テンプレートへ文章を当てはめることではありません。

例えば、

営業担当者としてCSV出力したい。

だけではなく、

なぜCSVが必要なのか？

まで考えます。

そこで、

会計システムへ月次データを登録するため

と分かれば、CSV以外の連携方法がより適切かもしれません。

つまりユーザーストーリーは、要求された機能の裏側にある業務目的を確認するための手段でもあります。

基本は、

＜誰が＞として、＜何をしたい＞。なぜなら＜価値・目的＞だから。

で書き、

さらに、

• 受入条件
• 優先順位
• 業務要件
• 機能要件
• 画面

へつなげます。

業務システムでは特に、

「何を作るか」だけでなく「なぜ必要なのか」が現場・発注者・開発者に伝わる粒度

を意識すると、要件整理や優先順位付けがしやすくなります。

「現場の要望を開発要件へ整理したい」

「ユーザーストーリーの粒度が分からない」

「業務要件から画面・機能へ落とし込みたい」

「要件定義から設計・開発まで相談したい」

といった段階からでも、実際の業務をもとに要求を整理できます。

要件定義・業務システム開発について相談する