# 要件定義書テンプレート > Beekle が実際の発注プロジェクトで使っている要件定義書テンプレートです。 > 空欄（〈　〉や「（記入例）」の箇所）を自社の内容に書き換えれば、そのまま開発会社との合意形成に使えます。 > 最初に書くべきは 1〜4 章の半分ほど。5 章以降は開発パートナーと一緒に詰めれば十分間に合います。 > > 書き方の解説はこちら: https://beekle.jp/column/requirements-definition-template - プロジェクト名: 〈プロジェクト名を記入〉 - 作成者 / 作成日: 〈氏名〉 / 〈YYYY-MM-DD〉 - バージョン: 0.1（ドラフト） --- ## 1. プロジェクト概要 ### 1.1 目的（なぜやるか） 〈このシステムで解決したい業務課題と、なぜ今やるのかを2〜3行で記入〉 （記入例）現場が紙とExcelで在庫を管理しており、月末の棚卸しに毎回3日かかっている。これをなくし、リアルタイムで在庫を把握できるようにする。 ### 1.2 成功の定義（何が達成されたら成功か） 〈「何がどうなったら成功」と言えるかを、できるだけ検証可能な形で記入〉 （記入例）棚卸し作業をゼロにする。欠品による販売機会損失を現状より減らす。 ### 1.3 スコープ（やること・やらないこと） - やること - 〈今回のリリースで作るものを箇条書き〉 - やらないこと（今回は作らない） - 〈あえて作らないもの。ここを明示すると後の「やっぱり欲しい」を防げる〉 --- ## 2. 関係者 ### 2.1 ステークホルダー一覧 | 役割 | 氏名・部署 | 関わり方 | | --- | --- | --- | | 〈発注責任者〉 | 〈記入〉 | 〈記入〉 | | 〈現場の利用者〉 | 〈記入〉 | 〈記入〉 | | 〈情報システム部門〉 | 〈記入〉 | 〈記入〉 | ### 2.2 意思決定者と権限 〈仕様・予算・リリース可否を誰が最終決定するかを記入。曖昧だと開発が止まる〉 --- ## 3. 要求の洗い出しと優先順位づけ まず「やりたいこと」を1行ずつ、粗く全件書き出します。この段階では詳細化しません。 書き出した要求を3軸で評価し、「作る／後回し／作らない」を決めます（FM法）。 「作る」と決めた要求だけを、次章でユーザーストーリーと受け入れシナリオに詳細化します。 ### 3.1 要求一覧（1行で粗く） | ID | 要求（やりたいこと） | 由来（誰の要望か） | | --- | --- | --- | | REQ-01 | 〈記入例）商品をお気に入り登録できるようにしたい〉 | 〈営業部〉 | | REQ-02 | 〈記入〉 | 〈記入〉 | | REQ-03 | 〈記入〉 | 〈記入〉 | ### 3.2 優先順位の判定（FM法） | ID | ビジネス価値（★1〜3） | 現場で使えるか（★1〜3） | 技術コスト（低/中/高） | 判定 | | --- | --- | --- | --- | --- | | REQ-01 | ★★★ | ★★☆ | 低 | 作る | | REQ-02 | 〈記入〉 | 〈記入〉 | 〈記入〉 | 後回し | | REQ-03 | 〈記入〉 | 〈記入〉 | 〈記入〉 | 作らない | > どれか1軸でも「★1」または「技術コスト:高」があれば、いったん「作らない」に倒すのが原則です。 > 使われない機能・無謀な機能を最初に外すことで、開発費と期間を守れます。 --- ## 4. ユーザーストーリーと受け入れシナリオ 3章で「作る」と決めた要求だけを、ここで詳細化します。 ユーザーストーリーで「誰が・何を・なぜ」を、受け入れシナリオで「どうなったら完成か」を書きます。 シナリオはそのまま受入テストの項目＝納品デモの台本になります。 ### 4.1 ペルソナ 〈想定ユーザーを3〜5人に絞って定義。役割・ITリテラシー・使う場面など〉 ### 4.2 ユーザーストーリー 基本構文: ``` As a 〈ユーザー（誰が）〉 I want to 〈やりたいこと〉 So that 〈得られる価値（なぜ嬉しいか）〉 ``` （記入例・REQ-01 から詳細化） ``` US-01 As a 一般ユーザー I want to 気になる商品をお気に入り登録したい So that 後でまとめて比較・購入判断ができる ``` ``` US-02 As a 店舗運営者 I want to お気に入り登録された商品の傾向を確認したい So that 在庫補充や仕入れ判断の精度を上げられる ``` ### 4.3 受け入れシナリオ（Gherkin形式） 各ストーリーに1〜3本、「前提（Given）／もし（When）／ならば（Then）」でシナリオを書きます。 このシナリオを開発会社と共有しておくと、「完成した」の基準がずれません。 （記入例・US-01 の受け入れシナリオ） ``` シナリオ: 商品をお気に入り登録する 前提 一般ユーザーがログインしている もし 商品「A」のお気に入りボタンを押す ならば 商品「A」がお気に入り一覧に追加される かつ ボタンの表示が「登録済み」に変わる ``` ``` シナリオ: ログインしていないとお気に入り登録できない 前提 ユーザーがログインしていない もし 商品「A」のお気に入りボタンを押す ならば ログイン画面が表示される かつ ログイン後に元の商品ページへ戻る ``` 正常系だけでなく、「うまくいかないケース」のシナリオを必ず1本は書きます。 ここが抜けると、トラブル時の挙動が開発会社まかせになります。 ``` シナリオ: ログインに5回連続で失敗するとロックされる 前提 ユーザーが4回連続でログインに失敗している もし 5回目のログインに失敗する ならば 当該アカウントは15分間ロックされる かつ 「しばらく時間をおいて再度お試しください」と表示される ``` ### 4.4 ストーリーとシナリオの一覧 | ストーリーID | 元の要求 | シナリオ数 | 備考 | | --- | --- | --- | --- | | US-01 | REQ-01 | 2 | 〈記入〉 | | US-02 | REQ-01 | 〈記入〉 | 〈記入〉 | --- ## 5. 非機能要件 ### 5.1 性能・可用性 〈想定同時利用者数、レスポンス目標、稼働率、メンテナンス時間帯など〉 ### 5.2 セキュリティ 〈認証方式、権限管理、データの暗号化、ログ・監査、外部にデータを出せるか など〉 ### 5.3 運用・保守 〈バックアップ、障害時の連絡体制、問い合わせ窓口、更新頻度など〉 --- ## 6. データ要件 ### 6.1 データモデル概要 〈扱う主なデータ（顧客・注文・在庫 …）と、その関係を記入〉 ### 6.2 既存データの移行方針 〈現行システム／Excelからの移行有無、量、クレンジングの要否〉 --- ## 7. 制約事項 ### 7.1 技術制約 〈使用が決まっている技術、連携先システム、対応ブラウザ・端末など〉 ### 7.2 法務・コンプライアンス 〈個人情報の取り扱い、業界規制、社内規程など〉 --- ## 8. リリース計画 ### 8.1 フェーズ分割 〈まず何を出し、次に何を足すか。小さく出して広げる前提で記入〉 ### 8.2 マイルストーン | フェーズ | 内容 | 目安時期 | | --- | --- | --- | | フェーズ1 | 〈最小構成で出す範囲〉 | 〈記入〉 | | フェーズ2 | 〈次に足す範囲〉 | 〈記入〉 | --- ## 付録: ストーリーからシナリオへの書き分け例 ユーザーストーリーで「なぜ」を、受け入れシナリオで「どうなったら完成か」を書きます。 **ユーザーストーリー** ``` As a 一般ユーザー I want to パスワードを忘れた時に、メールから再設定したい So that 問い合わせなしで自分でログインを回復できる ``` **受け入れシナリオ** ``` シナリオ: パスワード再設定メールを受け取る 前提 ユーザーが登録済みのメールアドレスを持っている もし 「パスワードを忘れた」からそのメールアドレスを送信する ならば 1時間有効な再設定リンクがメールで届く シナリオ: 未登録のメールアドレスでも結果が同じに見える 前提 入力されたメールアドレスが未登録である もし メールアドレスを送信する ならば 登録済みの場合と同じ完了メッセージが表示される （「該当メールアドレスは登録されていません」とは表示しない） シナリオ: 期限切れリンクは使えない 前提 再設定リンクの発行から1時間以上経過している もし そのリンクを開く ならば 「リンクの有効期限が切れています」と表示され、再発行を案内される ``` 2つ目のシナリオが、アカウントの存在確認攻撃を防ぐ実装意図を伝えています。 機能リストだけを書いていると抜け落ちる情報です。 シナリオは開発中の自動テストにそのまま変換でき、納品時のデモ項目としても使えます。 --- 要件定義の進め方・書き方の詳しい解説: - 要件定義書テンプレートの解説: https://beekle.jp/column/requirements-definition-template - ユーザーストーリーの書き方: https://beekle.jp/column/user-story-template-examples - Gherkin（受け入れシナリオ）入門: https://beekle.jp/column/gherkin-bdd-introduction （本テンプレートは Beekle 株式会社が無償で提供しています。改変・社内利用は自由です。）