はじめに：AI時代にこそ「要件定義」が最重要スキルになる
最近は生成AIの進化により、コードを書くこと自体のハードルは劇的に下がりました。「どう実装するか（How）」の多くをAIが担ってくれるようになった今、ソフトウェア開発において人間の役割は明確にシフトしています。
それは、「何を作るべきか（What）」「なぜ作るのか（Why）」を正確に定義し、チームやAIに迷いなく伝えることです。曖昧な指示からは、人間相手でもAI相手でも、期待したプロダクトは生まれません。
しかし現実には、要件定義や仕様書の作成は現場ごとにやり方がバラバラで、極めて属人的なスキルになりがちです。「もっと体系的に、誰もが迷わず要求を仕様に落とし込める『型』が欲しい」——そうした背景から、GWのお題として、頭の整理も兼ねて作成したのが本記事で紹介する「要求仕様書テンプレート」です。
なぜ要求仕様書が必要なのか
「要件はSlackのスレッドに書いてあります」「仕様はNotionに散らばってます」
——こういった状態でプロジェクトが進むと、何が起きるでしょうか。
- 開発者が作ったものと顧客が期待したものが違う
- テストで「合格」の判断基準がなく、いつまでも終わらない
- 後から「あの話どこに書いてあったっけ」が頻発する
要求仕様書は、こうした問題を未然に防ぐためのチームの共通言語です。
本記事では、筆者が作成した要求仕様書テンプレートを使って、会議の文字起こし・メモから実際の仕様書を作る手順を解説します。
そもそも「要求」と「要件」の違いとは？
テンプレートの解説に入る前に、重要な言葉の定義をしておきます。
開発現場では「要求」と「要件」が混同されがちですが、これらは「誰の視点か」によって明確に異なります。
- 要求（Requirement）＝ 顧客の視点
- 「やりたいこと」「解決したい課題」などの主観的・願望的なもの。
- 例：「手作業の入力ミスをなくしたい」
- 要件（Specification/Condition）＝ システムの視点
- 要求を実現するために、システムが「満たすべき条件・動作」を客観的に定義したもの。
- 例：「入力フォームの必須項目をバリデーションする」
家づくりに例えると、「冬でも暖かい家がいい」が要求であり、「南側に幅2mの窓を設置し、壁に〇〇の断熱材を使う」が要件（仕様）です。
顧客の「要求」を鵜呑みにせず、テスト可能な「要件（仕様）」に翻訳して落とし込むことがポイントで、本記事のテンプレートは、この「翻訳プロセス」を迷わずに行えるように設計しています。
💡 テンプレートのダウンロード
本記事で解説する「要求仕様書テンプレート（Markdown版）」はGitHubにて公開しています。手元で開きながらお読みいただくとより理解が深まります。
スプシで見ると👇のような感じです！
テンプレートの全体構成
GitHubで公開しているテンプレートは11のセクションから成ります。一見多く見えますが、「なぜ作るか」→「何を作るか」→「どう作るか」 の順に論理が積み上がる構造になっています。
ドキュメント管理
↓ いつ・誰が・何バージョンかを管理する
1. プロジェクト概要
↓ なぜ作るか（目的・背景・スコープ・成功指標）
2. ステークホルダー分析
↓ 誰が関わるか・誰が使うか
3. ビジネス要求（BR）
↓ ビジネス上の目標
4. ユーザー要求（UC）
↓ 誰が何をしたいか
5. 機能要求（FR）
↓ システムが何をするか ← ここが最も詳細
6. 非機能要求（NFR）
↓ 性能・可用性・セキュリティ等
7. 制約条件（CON）
8. 外部インターフェース要求（IF）
9. 前提条件・依存関係（ASM）
10. 未解決事項（OI）← 最重要。毎回更新する
11. 用語定義
ここからは、実際にこのテンプレートを埋めていく手順をステップ・バイ・ステップで解説します。
ステップ1：まずドキュメント管理表を埋める
最初に「このドキュメントが何者か」を確定させます。
ここを後回しにすると、気づいたら複数バージョンが存在して混乱することになります。
| ドキュメントID | REQ-XXXX | ← プロジェクト固有のIDを振る
| バージョン | 0.1.0 | ← 草案は 0.x.x
| ステータス | 草案 | ← 草案 / レビュー中 / 承認済
| 作成日 | YYYY-MM-DD |
| 承認者（顧客側）| 〇〇 様 | ← 空でもいいが、誰に承認を取るか明記
💡 バージョン番号のルール（推奨）
-
0.x.0：草案・レビュー前 -
1.0.0：初回顧客合意済み -
1.x.0：合意後の部分改訂 -
2.0.0：スコープ変更を伴う大幅改訂
ステップ2：プロジェクト概要でスコープを確定する（最重要）
2-1. 目的は「ビジネスゴール」で書く
❌ 悪い例（機能ベース）
データをCSVで取り込んでDBに保存するシステムを作る
⭕️ 良い例（ゴールベース）
受注入力の手作業ミスを撲滅し、担当者が本来業務に集中できる状態にする
「何を作るか」ではなく「何を実現するか」で書きます。
開発が進む中で機能が変わっても、目的は変わりません。目的が変わったときこそが、仕様書を全面改訂するタイミングです。
2-2. スコープの IN/OUT を明確にする
「そこまでやるんですか？」という会話が発生したら、スコープが曖昧な証拠です。
スコープは「〜すること」の形で動詞を明確にします。
**IN**
- A社・B社の受注データを CSV 形式で取り込むこと ← 対象範囲を限定
- 取り込み結果を一覧画面で確認できること
**OUT**
- C社フォーマットへの対応（フェーズ2以降） ← 理由も書く
- 過去データの一括移行 ← やらない理由が"後で"でも今は書く
OUT を書くことで「これはやらない」という合意が取れます。後から「あれはスコープ外だった」と堂々と言えるようになります。
2-3. 成功指標は必ず数値で書く
| 指標 | ❌ 悪い例 | ⭕️ 良い例 |
|---|---|---|
| 品質 | エラーが少ないこと | 取り込みエラー率 0.1% 以下 |
| 速度 | 高速に処理すること | 1,000件を 3分以内に処理 |
| 期限 | 来月デモを実施する | YYYY-MM-DD にデモを実施し顧客承認を得る |
成功指標は「それが達成できたか判定できる」形で書きます。測定方法（どうやって測るか）もセットで書いておくと、のちのテスト計画が圧倒的に楽になります。
ステップ3：ビジネス要求と機能要求を分けて書く
ここは多くの人が混同するポイントです。テンプレートでは明確にレイヤーを分けています。
| 種別 | 問いかけ | 書く内容 | ID |
|---|---|---|---|
| ビジネス要求（BR） | なぜ作るか | 達成したいビジネスの状態 | BR-01 |
| ユースケース（UC） | 誰が何をしたいか | ユーザーの行動シナリオ | UC-01 |
| 機能要求（FR） | システムが何をするか | システムの動作仕様 | FR-01 |
階層の例
BR-01: 受注ミスを月XX件以下にする
↓ そのために
UC-01: 業務担当者が受注データを登録する
↓ そのためにシステムは
FR-01: 入力フォームの必須項目を検証する
FR-02: 重複受注を自動検知する
FR-03: 登録完了後に確認メールを送信する
BR は「〜する」「〜になる」、FR は「〜のとき、システムは〜する」で書くと自然に分かれます。
ステップ4：機能要求を「テスト可能な粒度」に分解する
機能要求の書き方でプロジェクトの品質が決まります。鉄則は以下の3つです。
鉄則1：記述形式を統一する
[条件/トリガー] のとき、[主語] は [動作] する。
例
ユーザーが「送信」ボタンをクリックしたとき、システムは入力フォームの全項目を検証し、エラーがない場合はデータを保存して完了画面に遷移する。
「〜できる」と「〜する」を使い分けましょう。
-
できる→ ユーザーの能力（UI で操作できる） -
する→ システムの動作（検証する、保存する）
鉄則2：受け入れ基準はチェックボックスで書く
受け入れ基準は「テストケース」の原型です。YesかNoで答えられる形で書きます。
❌ 悪い例
- ファイルサイズに制限があること
⭕️ 良い例
- 10MB 以下のファイルをアップロードできる
- 10MB を超えるファイルを選択した場合、「ファイルサイズが制限を超えています（上限10MB）」と表示される
境界値（10MB ちょうどは？10.1MBは？）まで明記すると、テスト担当者が迷いません。
鉄則3：「してはいけないこと」も明示する
暗黙の前提は仕様書に書かない限り伝わりません。特に AI を使うシステムや外部データを扱うシステムでは「何をしてはいけないか」の明示が重要です。
| FR-05-05 | 未入力フィールドをシステムが推測して自動補完しない |
「やること」だけでなく「やらないこと」を書くことで、過剰な実装を防げます。
ステップ5：非機能要求は「数値なしは仕様ではない」
非機能要求でよくある失敗は、フワッとした形容詞を使ってしまうことです。
| 項目 | ❌ 悪い例 | ⭕️ 良い例 |
|---|---|---|
| 性能 | 高速に動作すること | 通常操作は 3秒以内（同時接続100ユーザー時） |
| 可用性 | なるべく落ちないこと | 稼働率 99.9% 以上（月次・計画メンテ除く） |
| セキュリティ | 安全であること | TLS 1.2 以上・セキュリティレビュー承認後にデプロイ |
「測定条件」と「測定方法」をセットで書くのが重要です。「3秒以内」でも「何ユーザーで3秒なのか」が書いてないと、テスト結果の合否が判定できません。
ステップ6：未解決事項（Open Issues）を重要視する
未解決事項（OI）のテーブルはプロジェクトの「借金リスト」です。
| OI-01 | 外部連携先 API の仕様書の提供依頼中 | 顧客技術担当 | YYYY-MM-DD | 未解決 |
運用のポイント
- 毎回の打ち合わせで先頭に表示する → 解決しないと要求が確定しない
- 解決したら「解決済」に変更し、関連する要求（FR）を更新する → IssueのIDは変えない
- 「担当者」と「期限」を必ず入れる → 担当者がいないIssueは永遠に解決されない
実践：会議メモから仕様書を作る手順
会議の文字起こし・議事メモは情報の原石です。そのまま仕様書にはなりませんが、正しく読み解けばほとんどの情報が揃っています。
ここでは、ある受注管理システムの要件定義会議を例に、メモから仕様書への変換手順を示します。
Step A：登場人物と関心事を拾う
会議の冒頭から「誰が」「何を気にしているか」を拾います。
- PM → スケジュール・顧客への期待値管理
- 開発リード → 実装コスト・技術的な実現性
- 顧客担当 → 業務上の使い勝手・既存システムとの整合性
これがそのまま「ステークホルダー分析（セクション2）」になります。
Step B：「問題」「議論」「決定事項」を分ける
会議の発言は混在しています。仕様書に書くのは決定事項と未解決事項です。
| 発言の種類 | 発言例 | 仕様書での扱い |
|---|---|---|
| 問題提起 | 「入力と保存を同時にやろうとしているから精度が悪い」 | 背景・課題に記載 |
| 決定事項 | 「バリデーションを先に完了させてから保存処理に入る」 | FR の詳細仕様に記載 |
| 決定事項 | 「本番デプロイ前にセキュリティレビューを必ず通す」 | 非機能要求・制約条件に記載 |
| 未解決 | 「外部システムの API 仕様はいつもらえるか」 | Open Issues に記載 |
Step C：「なぜ」を必ず書く
制約条件や前提条件は、理由がないと後で誰かが「これなんで？」となります。
❌ 理由なし（悪い）
CON-T01: 既存の認証基盤（〇〇システム）を流用すること
⭕️ 理由あり（良い）
CON-T01: 既存の認証基盤（〇〇システム）を流用すること
理由: 新規認証基盤の構築はコスト・期間の両面で本プロジェクトのスコープ外のため
Step D：用語定義は迷ったらすぐ書く
会議中に「これ何のこと？」「顧客と開発側で意味が違うかも」と感じた言葉は、すべて用語集（セクション11）に入れます。
- 業界用語と一般用語が混在：「受注」と「注文」を別の概念として使っている
- 略称の指す範囲が不明確：「旧システム」が複数のシステムを指している
- 動詞の主語が曖昧：「確認する」が目視確認なのか、システム検証なのか
チームで言葉の意味が揃うだけで、打ち合わせの質が劇的に上がります。
よくある間違いと対処法
間違い1：機能要求に「〜できること」だけ書く
「できること」は能力の宣言であって、動作の仕様ではありません。テスト担当者は「何を入力したら何が起きるか」を知りたいのです。
# ❌ 悪い
- ユーザーがログインできること
# ⭕️ 良い
ユーザーが ID とパスワードを入力して「ログイン」ボタンをクリックしたとき、
システムは認証を行い、正常な場合はダッシュボード画面に遷移する。
異常な場合は「ログイン情報が正しくありません」と表示し、入力フォームをクリアする。
間違い2：Open Issues を放置する
OI は「今すぐ決めなくていい」のではなく「担当者と期限を決めた上で後で決める」ものです。毎回の打ち合わせで OI テーブルを開き、「これ、その後どうなりました？」を確認する習慣をつけましょう。
間違い3：承認者欄を空のままにする
承認者が空でも仕様書は書けますが、それは誰も「合意した」と言えない文書になります。草案段階でも「この人に最終的に承認してもらう」という名前を書いておくべきです。
まとめ：仕様書を書く意味
要求仕様書を書く本当の目的は、「ドキュメントを完成させること」ではありません。
仕様書を書くプロセスを通じて、チームが「何を作るか」について合意することです。
書いている途中で「これどうする？」が出てきたら、それは未解決事項（OI）に入れればいいだけです。全部決まってから書き始めるのではなく、書きながら決めていくのが正しい使い方です。
最終的に仕様書の価値は「美しさ」より「合意の証跡があること」にあります。
顧客との打ち合わせが終わったら、その日のうちに仕様書を更新する——それだけで、プロジェクトの認識齟齬は大幅に減るはずです。