「要件定義書、何から書き始めれば良いか分からない」を解決する
システム開発を発注する立場になると、最初に直面するのが「要件定義書をどう書けば良いのか」です。
世の中には立派な要件定義書のサンプルが転がっていますが、いざ書こうとすると以下の壁に当たります。
- 章立てが多すぎて、どこから手をつけるか分からない
- 専門用語（機能要件・非機能要件・ユースケース）の使い分けが曖昧
- 書けば書くほど分量が増え、レビューが回らない
このコラムでは、Beekleが実際の発注プロジェクトで使っている要件定義書テンプレート と、その書き方の核となる2つの記法（EARS／ユーザーストーリー）を、サンプル付きで公開します。
要件定義の全体像については 要件定義の完全ガイド を、フェーズごとの進め方は 要件定義の進め方 を参照してください。
要件定義書テンプレートの全体像
Beekleの要件定義書は、以下の構成です。
1. プロジェクト概要
1.1 目的（なぜやるか）
1.2 成功の定義（何が達成されたら成功か）
1.3 スコープ（やること・やらないこと）
2. 関係者
2.1 ステークホルダー一覧
2.2 意思決定者と権限
3. ユーザーストーリー
3.1 ペルソナ
3.2 ストーリー一覧
4. 機能要件（EARS記法）
4.1 機能カテゴリ
4.2 個別機能の振る舞い
5. 非機能要件
5.1 性能・可用性
5.2 セキュリティ
5.3 運用・保守
6. データ要件
6.1 データモデル概要
6.2 既存データの移行方針
7. 制約事項
7.1 技術制約
7.2 法務・コンプライアンス
8. リリース計画
8.1 フェーズ分割
8.2 マイルストーン
膨大に見えますが、最初に書くべきは1〜4までの50% です。残りはベンダーと一緒に詰めれば十分間に合います。
ユーザーストーリーの書き方（実例付き）
機能要件の手前で、必ず書いてほしいのが ユーザーストーリー です。
基本構文
As a <ユーザー（誰が）>
I want to <やりたいこと>
So that <得られる価値（なぜ嬉しいか）>
サンプル：ECサイトの場合
As a 一般ユーザー
I want to 気になる商品をお気に入り登録したい
So that 後でまとめて比較・購入判断ができる
As a 店舗運営者
I want to お気に入り登録された商品の傾向を確認したい
So that 在庫補充や仕入れ判断の精度を上げられる
なぜユーザーストーリーから書くのか
ストーリーは 「誰が・何を・なぜ」を1行で表現する ため、
- 関係者がそれを欲しい理由を共通理解できる
- 仕様変更に強い（画面が変わってもストーリーは変わりにくい）
- 優先順位（MoSCoW：Must/Should/Could/Won't）を付けやすい
機能リストから書き始めると、「なぜそれが必要なのか」が抜け落ちて、後で削る判断ができなくなります。詳しくは ユーザーストーリーテンプレートと実例 を、半自動化したい方は /tools/story-builder をお試しください。
EARS記法の5パターン（実例付き）
機能の 振る舞い を曖昧さなく書くための記法が EARS（Easy Approach to Requirements Syntax） です。5つのパターンを使い分けます。
パターン1：Ubiquitous（常時要件）
「システムは常に〜である」という不変の振る舞い。
The システム shall すべての通信をTLS 1.2以上で暗号化する。
パターン2：Event-driven（イベント駆動）
「〜が起きたら、システムは〜する」
WHEN ユーザーがログインボタンを押した時、
THE システム shall 認証サーバーに認証リクエストを送る。
パターン3：State-driven（状態駆動）
「〜の状態のとき、システムは〜する」
WHILE ユーザーがログイン済みの間、
THE システム shall マイページへのリンクを表示する。
パターン4：Optional Feature（オプション機能）
「〜が有効な場合、システムは〜する」
WHERE 二要素認証が有効な場合、
THE システム shall ログイン後にOTP入力を要求する。
パターン5：Unwanted Behavior（望ましくない事象）
「〜が起きたら、システムは〜することで対処する」
IF 認証に5回連続で失敗した場合、
THEN THE システム shall 当該アカウントを15分間ロックする。
EARS記法の効果
「〜できるようにする」「〜を考慮する」のような 解釈余地のある日本語 が、IF/WHEN/WHILE/WHEREの前置句で 発火条件 が明確になります。これが曖昧さを排除する最大のポイントです。詳細な構文と実プロジェクト例は EARS記法ガイド を参照してください。
ユーザーストーリーとEARSの併用例
ユーザーストーリーで「なぜ」を、EARSで「振る舞い」を、それぞれ書きます。
ユーザーストーリー
As a 一般ユーザー
I want to パスワードを忘れた時に、メールから再設定したい
So that 問い合わせなしで自分でログインを回復できる
EARS（紐づく機能要件）
WHEN ユーザーが「パスワードを忘れた」リンクを押した時、
THE システム shall メールアドレス入力フォームを表示する。
WHEN ユーザーが登録済みのメールアドレスを送信した時、
THE システム shall 1時間有効な再設定リンクを当該メールアドレスに送付する。
IF 入力されたメールアドレスが未登録の場合、
THEN THE システム shall 「該当メールアドレスは登録されていません」とは表示せず、登録の有無に関わらず同じ完了メッセージを表示する。
3つ目の「望ましくない事象」のEARSが、セキュリティ上の アカウント存在確認攻撃 を防ぐ実装意図を明確に伝えています。これが、機能リストだけ書いていると抜ける情報です。
テンプレート無料ダウンロード
実プロジェクトで Beekle が使っている要件定義書テンプレート（Word／Excel／Markdown 形式）を無料配布しています。記入例付きで、空欄を埋めれば即使える状態です。
ダウンロードは お問い合わせフォーム から「要件定義テンプレート希望」とご連絡ください。フォーム送信後、ダウンロードリンクをお送りします。
失敗しない要件定義の進め方
テンプレートと記法を揃えても、進め方を誤ると要件定義は炎上します。Beekleが推奨するのは以下の順序です。
- 目的とスコープ を1ページで書く（細部は書かない）
- ペルソナ を3〜5人に絞って定義する
- ユーザーストーリー を全件書き出す（Must/Should/Could/Won'tに分類）
- Mustストーリーから順に EARS記法で機能要件 を起こす
- 非機能要件・データ要件は 3割ベンダーに任せて 起案してもらう
このフローで進めると、発注側が書く分量は全体の40%程度で、残りはベンダーと共同編集する形になります。「全部発注側が書こう」とすると失敗します。
優先順位の付け方は MoSCoWとFMで要件を絞り込む方法 と スコープ管理FM法、ツール化したい方は /tools/scope-manager をご覧ください。
まとめ：要件定義は「ストーリー＋EARS」で曖昧さを潰す
要件定義書のテンプレートは、検索すれば無数に見つかります。しかし重要なのはテンプレートではなく、書く内容の精度 です。
- ユーザーストーリーで「なぜ」を握る
- EARS記法で「振る舞い」を曖昧さなく書く
- Must/Should/Could/Won't で優先順位を可視化する
この3つだけで、要件定義の質は劇的に変わります。
Beekleの進め方
Beekleでは、要件定義フェーズで 発注側と共同でユーザーストーリーとEARS要件を書き起こすワークショップ を提供しています。テンプレートを渡して終わり、ではなく、書き上がるまで伴走します。
要件定義書のテンプレート全文（Word/Markdown形式）が必要な方は、お問い合わせフォームよりご連絡ください。