開発会社から提示された要件定義書を前に、「この内容で承認してよいのか」「見積もりに含まれない作業はないか」と迷う発注者は少なくありません。機能名が並んでいても、対象外の範囲、例外業務、運用時の対応、受入時の確認方法が曖昧なら、後から認識をそろえる必要が出やすくなります。
この記事では、要件定義書に書く項目、具体化の方法、レビューの進め方を、発注者の確認作業に絞って解説します。開発範囲・見積比較・受入条件を承認または差戻しできる状態を目指し、架空案件の記入例と要件IDを使った照合例を紹介します。
要件定義書では、対象範囲・利用条件・受入条件をそろえ、要件と見積・受入・変更の関係を追える状態にします。
01Section要件定義書は、何を合意するための文書か
要件定義書は、機能の依頼一覧ではありません。今回の対象範囲、業務ルール、品質・運用条件、受入条件を関係者で確認する文書です。
要件定義書でそろえる3つの判断
発注者は、対象範囲・利用条件・受入条件の3点をそろえます。
- 何を対象にするか：スコープ、つまり今回取り組む範囲と、対象外にする業務・機能・連携を区切る
- どの条件で使える必要があるか：通常業務だけでなく、例外、権限、利用条件、運用上の制約を明らかにする
- 何をもって確認完了とするか：重要な要件ごとに、受入条件、確認方法、確認担当を定める
企画書は背景・目的、設計書は実装の構造、見積書は作業範囲・前提、契約書・個別契約は取引条件を扱います。
文書の名称や分け方は案件によって異なりますが、要件定義書、見積書、受入条件の間で対象範囲や前提が矛盾していないことが重要です。デジタル庁のデジタル社会推進標準ガイドラインは、業務要件・機能要件・非機能要件などを整理し、具体性や整合性を確認する考え方の参考になります。政府情報システム向けの資料を含むため、民間案件では自社の規程や契約条件に合わせて活用します。
工程全体の進め方は関連記事で確認する
ここでは成果物の中身とレビューに焦点を当てます。要件定義そのものをどのような順番で進めるかは、要件定義の進め方で確認してください。
02Section要件定義書の記載項目は8つのブロックで整理する
記載項目は、目的・範囲、システム・運用、受入・未決事項のまとまりで確認すると、検討漏れを見つけやすくなります。
固定のフォーマットをそのまま使うのではなく、案件で判断が必要な論点を残すことが大切です。新規のWebサービスでは業務・データ・運用を厚く確認し、限定的な改修では変更対象、影響範囲、対象外、受入条件を重点的に確認します。
| 記載ブロック | 何を決めるか | 発注者の確認事項 | 詳細化しやすい条件 |
|---|---|---|---|
| 背景・目的 | 解決したい業務課題と達成したい状態 | 手段だけでなく、目的と対象利用者が示されているか | 部門横断、制度変更、投資判断がある |
| 対象／対象外 | 対象組織、業務、機能、データ、連携の範囲 | 今回行うことと行わないことを説明できるか | 段階導入、既存システム改修、複数部門利用 |
| 業務要件 | 誰がどの業務をどのルールで行うか | 通常時・例外時・残る手作業を確認できるか | 多段階承認、締切、代理対応がある |
| 機能・非機能要件 | システムの機能と、品質・運用の条件 | 利用者、条件、結果、例外、確認方法があるか | 権限別操作、利用集中、機密情報を扱う |
| データ・連携・移行 | データの責任、外部とのやり取り、移行対象 | 連携失敗時や移行後の確認方法を決められるか | 外部連携、旧データ移行、マスタ統合がある |
| 運用 | 問い合わせ、権限変更、障害連絡、保守分担 | 運用開始後に誰が何をするか分かるか | 利用部門が多い、運用担当が分かれる |
| 受入条件 | 要件をどの方法で確認し、誰が判定するか | 重要要件に確認条件と記録方法があるか | 業務継続性、社内規程、重要機能がある |
| 未決事項 | 未確定の論点をいつ誰が決めるか | 影響する要件、決定者、期限、暫定前提があるか | 連携先回答待ち、予算・方針の判断待ちがある |
対象ではない項目を削除する場合も、空欄のままにせず「対象外」「該当なし」「未決」のいずれかを残します。特に未決事項は、放置するのではなく、影響する要件ID、決定者、期限、暫定的な前提を記録しておくと、見積もりや受入条件への影響を追いやすくなります。
03Section要件を確認可能な表現にする書き方
レビューで確認すべきなのは、文章の表現の美しさではなく、見積もり・設計・受入確認に使える条件がそろっているかです。業務要件、機能要件、非機能要件を分けて記載すると、誰が決めるべき論点かも整理しやすくなります。
業務要件は「誰が、どのルールで行うか」を書く
業務要件は、利用者がどの業務をどのルールで行うかを示します。たとえば「承認できる」だけでは不足です。申請者、承認者、対象となる申請、承認の順序、差戻し時の扱い、締切後の例外対応まで確認します。
業務担当者には、通常の流れだけでなく、「誰が不在の場合にどうするか」「誤った申請をどう取り消すか」「手作業が残るか」といった例外を確認します。例外を今すぐ決められない場合は、未決事項として決定者と期限を置きます。
機能要件は条件・結果・例外まで確認する
機能要件は、システムに何をさせるかを表します。要件ごとに要件ID、目的、対象利用者、開始条件、期待結果、例外、優先度、受入条件または確認方法を置くと、曖昧さを見つけやすくなります。
たとえば「申請を登録できる」という要件は、次のように具体化します。「申請者権限を持つ利用者が必須項目を入力して登録した場合、受付番号を表示し、申請内容を保存する。必須項目が不足する場合は登録せず、入力が必要な項目を表示する」。このように通常と例外の結果を分けると、受入時に確認する内容を決めやすくなります。
非機能要件は品質と運用の条件を決める
非機能要件は、システムがどの品質・運用条件で利用できる必要があるかを示します。「高速に」「安全に」といった表現だけでは、確認方法や受入判断が決まりません。
非機能要件では、対象条件、許容条件または決定待ち条件、確認方法、判断者をそろえます。可用性は「必要なときにシステムを利用できる状態に関する条件」です。停止を避けたい時間帯、障害時の連絡先、復旧を判断する人を定め、手順を確認する方法を記載します。
IPAの非機能要求グレードは、性能・拡張性、可用性、運用・保守性、移行性、セキュリティなどの観点を洗い出す参考になります。アーカイブ掲載資料のため、案件ごとの具体値をそのまま決める根拠ではなく、検討漏れを防ぐための確認先として扱うのが適切です。
04Section記入済みミニサンプルで全体像をつかむ
以下は、社内の備品購入申請を扱う「社内申請・承認Webサービス」を題材にした記入例です。背景から受入条件、未決事項までをつなげて書くことで、機能だけでは見えにくい業務・運用上の前提を確認できます。
サンプルをそのまま流用しない
以下は実在の企業、サービス、運用条件に基づかない架空例です。利用者数、承認経路、扱う情報、連携先、社内規程、契約条件は案件ごとに異なります。文言を転用する前に、対象／対象外と未決事項を必ず見直してください。
| 項目 | 記載例 | 発注者の照合・レビュー観点 |
|---|---|---|
| 背景・目的 | メールと表計算ソフトで行う備品購入申請をWeb化し、申請状況の確認と承認履歴の検索を可能にする。 | 「Web化」ではなく、解決する業務課題と達成したい状態が書かれているか。 |
| 対象 | 申請者による申請登録、一次承認者による承認・差戻し、申請状況の確認、承認履歴の検索。 | 対象組織、利用者、申請種別を区切れているか。 |
| 対象外 | 会計システムへの自動登録、支払処理、紙申請の過去分データ化。 | 見積書などでも同じ対象外が示されているか。 |
| 業務ルール | 申請者は所属組織の承認者へ申請する。差戻し時は理由入力を必須とする。締切後の申請は管理者が個別確認する。 | 代理承認、組織異動、取消、重複申請の扱いを確認する。 |
| F-01 申請登録 | 権限を付与された申請者は必須項目を入力して申請を登録できる。登録後は受付番号を表示する。 | 必須項目、取消可否、通知、保存先を確認する。 |
| F-02 承認・差戻し | 承認者は担当組織の未処理申請を承認または差戻しできる。差戻し理由は申請者が確認できる。 | 承認対象の判定、履歴、権限なし時の扱いを確認する。 |
| NF-01 性能・拡張性 | 平日9時から10時の利用集中を想定し、対象操作と利用条件を定めて応答状況を確認する。許容条件の決定者は業務責任者と情報システム部門とし、合意条件でテストする。 | 想定利用条件、許容条件、測定対象、確認記録があるか。 |
| NF-02 可用性 | 月次締切日に申請業務を行う。停止を避けたい時間帯、障害時の連絡先、復旧判断者を定め、障害連絡・復旧手順の確認記録を残す。 | 停止不可時間、復旧の優先度、連絡体制を決められるか。 |
| NF-03 セキュリティ／権限制御 | 申請者、承認者、管理者で閲覧・登録・承認・出力の権限を分け、承認・差戻しの履歴を確認可能にする。権限区分、閲覧範囲、履歴の扱いは対象条件として整理し、保存期間などは社内規程に照らして決定待ち事項として管理する。情報システム部門と該当する管理責任者が判断し、権限別テスト、権限設定表、操作履歴、AT-05で確認する。 | 決定待ちの条件に決定者・期限があり、AT-05で権限外の承認操作を防げることを確認できるか。 |
| NF-04 運用・保守性 | 問い合わせ窓口、一次対応者、障害連絡先、権限変更の申請方法を対象条件として定める。保守分担、対応条件、教育・引継ぎの要否は、運用責任者と関係部門が決定待ち事項として整理する。運用手順、担当表、引継ぎ記録を確認し、運用責任者が判断する。 | 運用開始後の担当、決定待ち事項、確認記録がそろい、保守分担を説明できるか。 |
| 連携・移行 | 初回導入では外部システム連携を対象外とする。利用者・組織情報の登録方法は未決事項として管理する。 | 手作業登録の担当、頻度、誤登録時の対応を確認する。 |
| 受入条件 | F-01、F-02、NF-03は通常・例外ケースをテストし、画面記録または操作履歴を残す。NF-02は障害連絡・復旧手順をレビューする。 | 受入判断者、再確認が必要になる条件、記録方法を確認する。 |
| 未決事項 | 組織情報の更新責任者、利用者アカウントの登録方法、月次締切の例外承認者。 | 影響要件ID、決定者、期限、暫定前提を付ける。 |
この例では、NF-01を性能・拡張性、NF-02を可用性、NF-03をセキュリティ／権限制御、NF-04を運用・保守性として固定しています。特に権限外の承認操作を防ぐ条件はNF-03に紐付け、後述する受入条件AT-05、見積項目、変更履歴でも同じIDを使います。
05Section作成は共同で進め、発注者は判断を保持する
要件定義書は、発注者だけ、または開発会社だけで完結させるものではありません。発注者・利用部門は業務上の目的や受け入れられる条件を決め、開発会社は技術的な実現方法、制約、確認方法を構造化して提案します。
IPAのユーザのための要件定義ガイド 第2版は、利用者・発注者側が要件定義に主体的に関与する考え方の参考になります。アーカイブ掲載資料であるため、公開ページの掲載状況や資料情報は確認したうえで参照してください。
責任分界とは、発注者、開発会社、連携先などの「誰が対応するかの境目」です。技術的な選択を開発会社へ相談しても、事業・業務として何を優先し、何を受け入れるかの判断者は発注者側で明確にします。
発注者が保持する判断と、開発会社に確認する技術的整理
目的・対象／対象外・優先順位
発注者側で、達成したい状態と今回取り組む範囲を決めます。開発会社には、要件間の依存関係、代替案、実現上の制約を確認します。
業務ルールと例外
利用部門が、承認、差戻し、締切、代理対応などの業務上の受容可否を決めます。開発会社には、システム化した場合の例外処理や運用負荷を相談します。
非機能要件の条件
発注者側が、停止を避けたい時間帯、扱う情報、許容できる手作業などを示します。開発会社には、実現方法、確認方法、運用上の制約を整理してもらいます。
連携・移行の責任分界
発注者側で、連携先の責任者、移行対象データ、業務上の優先順位を明らかにします。開発会社には、接続条件、失敗時の扱い、技術的な影響範囲を確認します。
受入条件と未決事項
発注者側で、受入判断者と未決事項の決定者・期限を置きます。開発会社には、テスト条件、必要な証跡、未決事項が見積・設計へ与える影響を確認します。
目的、対象／対象外、優先順位、業務ルール、受入条件、未決事項の決定者が定まらない場合は、文書作成を急ぐより先に社内調整を優先します。役割分担や承認者の置き方は、組織規程、扱う情報、連携の有無、契約条件に応じて調整してください。
06Section発注者レビューは5つの確認会で進める
レビューを確認会ごとに分けると、範囲・業務・技術運用・見積・受入の判断を順に進めやすくなります。
レビューは、技術用語の正誤を確認する場ではなく、発注者が目的・範囲・業務・運用・受入条件を判断する場です。確認する順番を分けると、業務担当者に技術判断を求めたり、決裁者が細かな操作だけを確認したりする負担を減らせます。
要件定義書を承認・差戻しするための5つの確認会
- Step01
1. 開始確認
主な参加者：プロジェクト責任者、利用部門、開発会社。確認対象：文書名、版数、変更履歴、用語、前提、未決事項。発注者側の準備物：目的、対象範囲、用語一覧、未決事項一覧。決める事項：レビュー対象版、論点、決定期限。承認者：プロジェクト責任者。
- Step02
2. 業務確認
主な参加者：利用部門、業務責任者、開発会社。確認対象：通常・例外業務、業務ルール、対象外、優先順位。発注者側の準備物：現行・将来の業務、例外ケース、業務ルール。決める事項：対象業務、対象外、優先順位、例外の扱い。承認者：業務責任者。
- Step03
3. 技術・運用確認
主な参加者：情報システム部門、該当担当、開発会社。確認対象：権限、データ、連携、移行、利用環境、運用・保守分担。発注者側の準備物：連携一覧、データ一覧、利用環境、運用案。決める事項：責任分界、移行、運用分担、確認方法。承認者：該当責任者。
- Step04
4. 見積前照合
主な参加者：プロジェクト責任者、購買・決裁関係者、開発会社。確認対象：要件ID、見積対象、対象外、見積前提、未決事項、受入条件。発注者側の準備物：要件IDの管理表、見積照合用の記録、未決事項一覧。決める事項：見積対象、除外、仮定、変更時の扱い。承認者：発注判断者。
- Step05
5. 最終承認
主な参加者：発注者責任者、業務責任者、必要な関係部門。確認対象：受入条件、確認記録の計画、残課題、修正履歴、着手条件。発注者側の準備物：受入条件、承認・修正履歴、最終版。決める事項：承認範囲、残課題、開発着手条件。承認者：組織が定める承認者。
承認前に確認する5項目
- ✓
文書の版数、変更履歴、承認状況を確認できる。
- ✓
スコープと対象外の範囲を、関係者が同じ言葉で説明できる。
- ✓
未決事項ごとに、影響要件、決定者、期限、暫定前提がある。
- ✓
重要要件に、通常・例外ケースを含む受入条件がある。
- ✓
見積対象と対象外が、要件定義書の記載と一致している。
差戻しを行う際は、「分かりにくい」とだけ伝えるのではなく、該当する要件ID、足りない条件、決定者、回答期限を残します。修正後は、反映先の版数と承認状況を確認します。
07Section要件IDで見積・受入・変更を照合する
同じ要件IDで見積・受入・記録・変更を照合すると、確認漏れや影響範囲を追いやすくなります。契約上の扱いは関連資料と取引条件を別途確認します。
要件IDは、要件を追跡するための識別番号です。要件IDを見積項目、受入条件、テスト実施記録、承認状況、変更履歴につなげると、未見積・未テスト・未承認の要件を見つけやすくなります。
証跡とは、テストを実施したことや承認したことを確認できる記録です。画面記録、操作記録、履歴記録、権限設定の確認記録、ログなどを、要件の性質に合わせて残します。
| 要件ID・優先度 | 見積項目／対象外 | 発注者側前提・未決事項 | 受入条件ID／テスト条件・期待結果 | 判定・証跡／確認担当 | 承認・変更状況 |
|---|---|---|---|---|---|
| F-01／必須 | 申請登録画面、入力チェック。会計登録は対象外。 | 必須項目と利用者一覧を発注者側で確定する。利用者登録方法は未決。 | AT-01：申請者権限の利用者が必須項目を入力し登録する。受付番号を表示し、必須項目を保存する。AT-02：必須項目を未入力で登録する。登録せず、入力が必要な項目を表示する。 | AT-01：受付番号が表示され、定めた必須項目が保存される。AT-02：未入力のまま申請データが登録されない。証跡：操作記録、画面記録、登録データ確認。確認担当：利用部門。 | 業務責任者が承認。通知文などの変更時は、対象要件IDと反映版数を記録する。 |
| F-02／必須 | 承認・差戻し画面、履歴記録。 | 承認者一覧を提供する。代理承認の要否は未決。 | AT-03：承認者が担当組織の申請を差戻し、理由を入力する。申請者が理由を確認でき、履歴を残す。AT-04：承認者が担当組織の未処理申請を承認する。結果、日時、操作者を確認できる。 | 担当組織の申請だけを処理でき、理由・日時・操作者を履歴で確認できる。証跡：画面記録、履歴記録、承認対象一覧。確認担当：利用部門。 | 業務責任者が承認。代理承認を追加する場合は、見積・受入条件・履歴の影響を再照合する。 |
| NF-02／必須 | 障害連絡・復旧手順の整備支援。 | 停止を避けたい時間帯、連絡先、復旧判断者を承認する。復旧優先度は確認待ち。 | 受入条件は個別設定。月次締切日の運用を想定し、障害連絡・復旧手順をレビューする。 | 合意した連絡先、判断者、手順が確認できる。証跡：手順レビュー記録、承認記録。確認担当：利用部門、運用責任者。 | 業務責任者と運用責任者が承認。停止条件の変更時は、関連する前提と手順を更新する。 |
| NF-03／必須 | 権限設定、履歴記録、ログ確認。認証基盤の刷新は対象外。 | 権限区分と履歴の扱いを承認する。保存期間などは社内規程に照らして確認する。 | AT-05：承認権限を持たない利用者が承認操作を試みる。承認を実行できず、権限外の承認結果が記録されない。 | 権限設定どおりに操作が制御され、権限外の承認結果が残らない。証跡：操作記録、権限設定確認、ログ。確認担当：情報システム部門。 | 情報システム部門が承認。権限や履歴の変更時は、AT-05と関連する見積・証跡を再照合する。 |
F-01には通常登録のAT-01と必須項目未入力のAT-02、F-02には差戻しのAT-03と承認のAT-04、NF-03には権限外操作のAT-05を対応付けています。NF-02は可用性、NF-03はセキュリティ／権限制御として、混同せずに管理します。
概算見積では、仮定、未決事項、対象外を残したまま比較することがあります。発注判断前には、次の順に再照合します。
- 要件IDごとに、対象・対象外・優先度・未決事項を確認する。
- 必須要件が見積対象に含まれ、除外事項と矛盾していないかを確認する。
- 発注者側の前提が未確定なら、決定者、期限、見積もりへの影響確認の方法を決める。
- 重要要件に通常・例外ケースを含む受入条件、確認担当、証跡があるかを確認する。
- 変更時は、対象要件ID、影響範囲、費用・納期・運用への影響、承認者、反映版数を同時に確認する。
変更範囲、進捗、連携先の状況、契約条件によっては、変更が費用や納期に影響する場合があります。変更要望だけを記録するのではなく、関連する要件、見積前提、受入条件、承認記録を同時に見直すことが重要です。
要件IDの照合と契約上の位置付けは分けて確認する
要件IDによる表は、未見積・未テスト・未承認を見つけやすくする実務上の補助です。それ自体が契約上の効力や検収の結果を決めるものではありません。要件定義書、見積書、受入条件表、変更履歴を契約上どのように参照するか、検収手続きや責任範囲をどう扱うかは、個別契約・取引条件を購買、契約、法務担当と確認してください。情報システム取引・モデル契約に関する公的資料は、経済産業省の情報システム取引・契約に関する資料で確認できます。
web-mobile-app-development-quotation
この記事カードはサンプル表示です。CMS連携後は記事タイトル、概要、サムネイルなどを記事データから取得します。
関連記事
08Section要件定義書を承認できる状態にするための最終確認
発注前の承認は、「すべての詳細が決まっているか」だけで判断するものではありません。少なくとも、目的と対象／対象外、重要要件の受入条件、未決事項の管理方法がそろい、誰が何を決めるかが明確になっているかを確認します。
未決事項がある場合でも、影響する要件ID、暫定前提、決定者、期限が記載され、見積もり・受入・変更への影響を確認できるなら、判断を進められることがあります。一方で、対象範囲、優先順位、重要な業務ルール、受入可否の判断者が未確定な状態では、差戻しまたは社内調整を優先するほうが安全です。
要件定義書に関するよくある質問
要件定義書は発注者と開発会社のどちらが作るものですか？+
発注者・利用部門と開発会社が共同で整理する形が一般的です。発注者側は目的、対象／対象外、優先順位、業務ルール、受入条件、未決事項の決定者を明確にします。開発会社には、技術的な実現方法、制約、連携・移行の整理、確認方法の設計を相談します。
要件定義書に未決事項が残っていても進められますか？+
未決事項が残ること自体はあります。ただし、何が未決か、どの要件や見積前提に影響するか、誰がいつ決めるか、決まるまでの暫定前提は記録します。対象範囲や重要な受入条件に関わる未決事項は、発注判断前に扱いを再確認します。
要件IDを付けると契約上の効力も強くなりますか？+
要件IDは、見積、受入条件、テスト記録、承認、変更履歴を照合しやすくする識別子です。契約上の位置付けや検収手続きへの影響は、要件定義書や関連資料を個別契約でどう参照しているかによって異なります。購買、契約、法務担当と確認してください。
web-mobile-app-development-inhouse-vs-agency
この記事カードはサンプル表示です。CMS連携後は記事タイトル、概要、サムネイルなどを記事データから取得します。
関連記事
要件整理から開発会社の比較まで相談したい場合
対象範囲、未決事項、受入条件の整理に不安がある場合は、Webアプリ・SaaS開発の支援会社を比較できます。依頼前に決まっていることと未決事項を分けて共有すると、相談時の論点を整理しやすくなります。
Webアプリ・SaaS開発4593社掲載
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
