要件定義書のフォーマット 表紙・改訂履歴・ID体系・表のレイアウトと、Word・Excel・ツールの選び方

「要件定義書を作るにあたり、どのような体裁で作ればよいのか決まった様式がわからない」「WordとExcelのどちらで作るべきか迷っている」「担当者ごとに書式がばらばらで、レビューも更新もしにくい」という悩みは、システム開発を発注する企業や、社内で要件定義を担当する方からよく聞かれます。要件定義書には法律や規格で定められた様式はなく、だからこそ自社で「型」を決めておくことが品質と効率を左右します。

この記事では、要件定義書のフォーマットとして、文書全体の様式（表紙・改訂履歴・章番号・版管理）、要件を記述する際のID体系と記述様式、表・図・一覧のレイアウト、Word・Excel・Markdown・ツールの選び方、社内標準フォーマットの作り方までを整理しました。まずは、この記事の要点を表で確認してください。

確認したいポイント	結論	詳細
要件定義書に決まったフォーマットはある？	統一様式はなく、自社で型を決めるのが基本	法律や規格の定めはない。公的機関の様式を参考に、表紙・改訂履歴・章番号・ID体系を社内標準として定める
文書全体はどう整える？	表紙・改訂履歴・承認欄・版管理を固定する	版数と承認者を明示し、変更箇所と理由を履歴に残す。承認版はPDFで固定し、ファイル名規則で最新版を判別する
要件はどんな様式で書く？	IDを固定し、同じ項目で記述する	接頭辞付きIDを付け、入力・処理・出力・例外・優先度・根拠・状態を統一。非機能は水準と測定方法をセットで表にする
WordとExcelはどう使い分ける？	説明はWord系、一覧はExcel系、承認版はPDF	本文と一覧を要件IDで相互参照。Excel方眼紙は避け、統一された構造は生成AI活用の前提にもなる

この記事でわかること

• 要件定義書のフォーマットとテンプレートの違いと、様式を決める効果
• 表紙・改訂履歴・承認欄・章番号・版管理など、文書全体の様式の決め方
• 要件IDの体系と、1つの要件を記述する際の様式
• 機能一覧・画面一覧・データ項目定義・業務フロー図など、表と図のレイアウト
• Word・Excel・Markdown・ツールの使い分けと、社内標準フォーマットの作り方

要件定義書のフォーマットを決める前に押さえておきたいこと

要件定義書のフォーマットとは、文書の体裁・様式・書式のことです。何を書くかを示すテンプレートとは役割が異なり、「どのような形で書き、どう整えるか」を定めるものです。ここでは、フォーマットとテンプレートの違い、決まった様式がないという前提、公的機関の様式、フォーマットを決める効果を整理します。

フォーマットとテンプレートの違い

テンプレートは、章立てや記入欄など「何を書くか」の型です。一方、フォーマットは、表紙の項目、改訂履歴の書き方、章番号やIDの付け方、表の列構成、ファイル形式など「どう書き、どう整えるか」の型です。同じテンプレートを使っても、フォーマットが統一されていなければ、読みにくく、更新や追跡がしにくい文書になります。

要件定義書に「何を書くか」の型（10章構成の記入欄と記入ガイド）は、要件定義書のテンプレートの記事で紹介しています。本記事は、その内容をどのような様式で整えるかを扱います。

決まった様式はない

要件定義書には、法律や公的な規格で定められた統一様式はありません。開発会社や業界によって慣習は異なり、WordやExcel、PowerPoint、Markdown、文書管理ツールなど、形式もさまざまです。

様式が自由であることは、自社に合った形にできる反面、担当者ごと・プロジェクトごとに体裁がばらつく原因にもなります。自社の標準フォーマットを一度決めておくことが、要件定義書の品質を安定させる基本です。

公的機関が公開している様式

デジタル庁のデジタル社会推進標準ガイドラインには、政府情報システムの整備に関する標準ガイドラインと実践ガイドブックが含まれており、要件定義書のテンプレートや、業務要件・機能要件・非機能要件の整理の仕方が体系的に示されています。政府調達向けの様式ですが、章立てや表の構成、記載の粒度は民間のシステム開発でも参考になります。

（出典：デジタル庁「デジタル社会推進標準ガイドライン」 ）

公的機関の様式は網羅性が高い一方で分量が多いため、そのまま使うより、自社のフォーマットを設計する際の項目の参考にする使い方が実践的です。

フォーマットを決める効果

• 読みやすさ：読み手がどこに何が書いてあるかを予測でき、レビューが速くなる
• 追跡性：要件IDや章番号が統一されていれば、設計書・テスト仕様書・議事録との対応付けが容易になる
• 更新のしやすさ：改訂履歴と版管理の様式があれば、変更の経緯と最新版が明確になる
• 分担のしやすさ：複数人で作成しても体裁が揃い、統合の手間が減る
• 社内資産化：プロジェクトをまたいで同じ様式を使うことで、過去の要件定義書が再利用しやすくなる

文書全体の様式の決め方

ここでは、要件定義書を1つの文書として整えるための様式を解説します。表紙から版管理まで、文書の外枠にあたる部分です。これらは一度決めれば、プロジェクトをまたいで使い回せます。

表紙に記載する項目

• 文書名（例：○○システム 要件定義書）
• プロジェクト名、対象システム名
• 版数（例：第1.2版）と、その版の作成日
• 作成者（部門・氏名）、承認者
• 文書の区分（社外秘など）と、配布先の範囲
• 関連文書の一覧（要求定義書、RFP、提案書など）と、それぞれの版数

改訂履歴と承認欄

改訂履歴は、表紙の次のページに置き、版数・日付・変更箇所（章・要件ID）・変更内容・変更理由・変更者・承認者を1行ずつ記録します。承認欄は、発注側の責任者と開発側の責任者の承認日と氏名を記載し、承認された版がどれかを明確にします。

変更理由と変更箇所を必ず残すことが、後から「なぜこの要件になったのか」を追跡するための基本です。版数は、承認された版を整数（第1版、第2版）、作業中の版を小数（第1.1版、第1.2版）とするなど、ルールを決めておきます。

目次・章番号・ページ番号

目次は自動生成し、章番号は「1.」「1.1」「1.1.1」の3階層までにとどめると読みやすくなります。ページ番号はフッターに、文書名と版数はヘッダーに入れておくと、印刷時や部分的な共有時にも出所がわかります。

版管理とファイル名の規則

• ファイル名の例：要件定義書_○○システム_v1.2_20260904.docx（文書名＿対象＿版数＿日付）
• 作業中の版と承認済みの版を、フォルダまたはファイル名で区別する
• 承認済みの版はPDFに変換して固定し、編集可能なファイルと併せて保管する
• ツールで管理する場合は、承認時点のスナップショットを残す

「最新版がどれか」「承認された版がどれか」を誰でも判別できる状態を保つことが、版管理の目的です。

章構成のフォーマット

章立てそのものはテンプレートの領域ですが、各章をどのような様式で書くかはフォーマットの領域です。ここでは、章の冒頭と本文の書き方の統一、章ごとに使う記述形式の使い分けを解説します。

各章の冒頭に目的と対象読者を置く

章の冒頭に「この章では○○を定める」「主な読み手は○○」という1〜2文を置くと、読み手が章の位置づけを理解しやすくなります。特に、業務部門・情報システム部門・経営層・開発会社と読み手が多様な要件定義書では、章ごとに誰が読むべきかを示すことがレビューの効率を上げます。

章ごとの記述形式を決める

• 文章で書く章：背景・目的・方針・前提条件・制約（説明が必要な内容）
• 表で書く章：機能要件・非機能要件・データ要件・画面一覧・帳票一覧（項目と値を整理する内容）
• 図で書く章：業務フロー・システム構成・画面遷移（関係や流れを示す内容）
• 箇条書きで書く章：対象範囲・対象外・リスク・確認事項（列挙する内容）

記述形式を章ごとに固定すると、書き手も読み手も迷いません。「説明は文章、定義は表、関係は図」を基本ルールにしましょう。

【無料資料のご案内】 要件定義から開発・運用までを一貫して支援するサービスの内容や、要件定義書の作成・レビューの進め方をまとめた資料を無料でご用意しています。まずは概要を確認したい方は、以下から資料をご請求ください。 ▶ 資料請求はこちら（https://nextscale.co.jp/service-document/）

要件の記述フォーマット

要件定義書の中核は、個々の要件の記述です。要件IDの体系と、1つの要件を書く際の様式を統一すると、設計・テスト・変更管理のすべてが楽になります。ここでは、ID体系と記述様式を解説します。

要件IDの体系

• 接頭辞で種類を区別する：業務要件 B-、機能要件 F-、非機能要件 N-、データ要件 D-、運用・移行要件 O-、制約 C-
• 連番は3桁（001〜999）とし、欠番を許容する（削除した要件のIDは再利用しない）
• 階層が必要な場合は枝番を使う：F-010-01、F-010-02（親要件と子要件の関係を示す）
• IDは一度付けたら変更しない（設計書・テスト仕様書・議事録から参照されるため）

IDは要件の「住所」です。プロジェクトの途中で体系を変えると、他の文書との対応が崩れるため、最初に決めて守ることが重要です。

1つの機能要件を記述する様式

機能要件は、次の項目を固定した表または定型の段落で記述します。

• 要件ID／要件名（動詞で終わる短い名称。例：受注を登録する）
• 概要（誰が、何のために、何をするか。1〜2文）
• 入力（利用者や他システムからシステムに渡される情報）
• 処理（システムが行うこと。条件分岐や判断基準を含む）
• 出力（画面表示・帳票・通知・他システムへの連携）
• 例外・エラー時の動作
• 制約・前提（業務ルール、法規制、他要件との依存）
• 優先度（必須／重要／あれば望ましい）と、その根拠（対応する課題番号・目的）
• 状態（検討中／確定／保留／対象外）と、確定日
• 備考（判断の経緯、確認事項、関連する画面ID・データID）

この様式で書くと、1つの要件からテストケースを作れる粒度になります。すべての要件を同じ項目で書くことで、抜けている項目（例外処理が書かれていない、根拠がない）が一目でわかります。

非機能要件を記述する様式

非機能要件は、「大項目」「小項目」「要求水準（数値・条件）」「測定方法」「根拠・備考」の5列の表で記述します。大項目は可用性・性能・拡張性・運用保守性・移行性・セキュリティ・システム環境・ユーザビリティなどに統一し、要件IDは N-から始めます。

要求水準と測定方法を必ずセットで書く列構成にすることで、「速い」「安全」といった曖昧な記述が入り込む余地をなくせます。

業務要件を記述する様式

業務要件は、「業務名」「現状（As-Is）」「課題（課題番号）」「導入後（To-Be）」「達成する状態（数値目標）」「測定方法」の列で表にします。機能要件の根拠として課題番号を参照させることで、要件と目的の対応が文書上で追跡できます。

用語と表記の統一

• 用語集を文書の冒頭に置き、本文では用語集の表記のみを使う
• 「〜すること」「〜できること」「〜とする」など、要件の文末表現を1つに統一する
• 「必須」「任意」「推奨」など、義務の程度を示す語の意味を定義する
• 数字は半角、単位は統一（秒・ms、件・レコードなど）、日付は西暦で表記

表・図・一覧のレイアウト

要件定義書は表と図の割合が高い文書です。表の列構成や図の書式が統一されていると、読み手の理解が速くなり、Excelなどでの管理もしやすくなります。ここでは、主要な表と図のレイアウトを解説します。

機能一覧表の列構成

• 要件ID／機能名／分類（登録・照会・更新・削除・出力・連携・バッチ）／概要／利用者／優先度／対応課題番号／関連画面ID／状態／備考

列は10列前後に抑え、詳細は要件ごとの記述に委ねます。一覧は「全体を見渡すため」、記述は「1つを理解するため」と役割を分けると、両方が読みやすくなります。

画面一覧・帳票一覧の列構成

• 画面一覧：画面ID（SCR-）／画面名／目的／利用者／主な操作／遷移元・遷移先／関連要件ID
• 帳票一覧：帳票ID（RPT-）／帳票名／目的／出力形式（PDF・Excel・CSV）／出力タイミング／出力条件／関連要件ID

データ項目定義の列構成

• データID（D-）／データ名／項目名／型／桁数／必須／初期値／説明（業務上の意味）／出所（どのシステム・業務で発生するか）／保持期間

要件定義の段階では物理設計ほど詳細である必要はありませんが、業務上の意味と出所を必ず書くことで、設計段階での確認が減ります。

業務フロー図の書式

• レーン（横または縦の区分）に担当者・部門・システムを配置し、誰が何をするかを明示する
• 開始と終了の条件を図の冒頭と末尾に書く
• 分岐は条件を明記し、例外の流れは通常の流れと線種で区別する（白黒印刷でも判別できるようにする）
• 各処理に番号を付け、本文の説明や課題番号と対応付ける
• As-IsとTo-Beを同じ書式で描き、並べて比較できるようにする

図表の番号付けと参照

図には「図2-1」、表には「表5-3」のように章番号を含めた通し番号を付け、本文から「表5-3を参照」と参照します。図表の直下に出典や前提（数値の根拠、作成日）を記載しておくと、レビュー時の質問が減ります。

印刷と画面表示の両方を考慮する

A4縦で印刷しても読める文字サイズ（本文10〜11ポイント）と余白を確保し、横長の表はA4横のページに配置するか、列を分割します。画面で読む場合も、1画面に収まらない表はスクロールが必要になるため、表を大きくしすぎないことが基本です。

【無料相談のご案内】 「自社の要件定義書のフォーマットが適切か確認してほしい」「AIを含むシステムの要件をどう整理すべきか」といった具体的なご相談は、無料の相談予約からお気軽にお問い合わせください。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

Word・Excel・Markdown・ツールの選び方

要件定義書の形式は、内容と読み手、運用のしかたによって向き不向きがあります。ここでは、主な形式の特徴と使い分け、組み合わせの実務的な形を解説します。

形式ごとの特徴

• Word：文章と図の説明に向く。見出し階層・目次・改訂履歴・コメント機能が使いやすく、正式な提出文書に適する。表形式の大量データの管理には不向き
• Excel：機能一覧・非機能一覧・データ項目定義など表形式の管理に向く。並べ替え・絞り込み・IDによる参照が容易。長文の説明や文書全体の構成の把握には不向き
• PowerPoint：経営層向けの概要説明や、業務フロー・構成図の図解に向く。要件の詳細な記述や管理には不向き
• Markdown：開発チームとの共有やバージョン管理システムとの連携に向く。差分の追跡が容易。表の表現力と、非技術者の編集しやすさに制約がある
• 文書管理・ナレッジツール：複数人の同時編集、コメント、履歴の管理に向く。承認済みの版の固定には別途の運用が必要

実務的な組み合わせ

最も一般的なのは、本文（背景・目的・方針・範囲・前提）をWordで作成し、一覧（機能・非機能・画面・帳票・データ）をExcelで作成して、要件IDで相互参照する組み合わせです。承認時には両方をPDF化して固定します。

開発チームが社内にいる場合や、頻繁に更新する場合は、Markdownやナレッジツールで本文を管理し、一覧は表計算ツールで管理する形も増えています。「説明はWord系、一覧はExcel系、承認版はPDF」を基本に、自社の体制に合わせて選びましょう。

Excel方眼紙の注意点

Excelのセルを細かく正方形にして文書を作る「Excel方眼紙」は、レイアウトの自由度が高い一方で、文章の編集・検索・再利用がしにくく、他の形式への変換も困難です。表形式の管理にはExcelを使い、文章はWord系の形式で書くという役割分担を守ることをおすすめします。

生成AIとの相性

生成AIに要件定義書の下書きや点検を任せる場合、構造化された形式（見出しの階層が明確なWord、列構成が統一されたExcel、Markdown）のほうが、AIが内容を正確に読み取り、出力を文書に取り込みやすくなります。フォーマットの統一は、生成AI活用の前提条件にもなります。

社内標準フォーマットの作り方

フォーマットは、プロジェクトごとに決めるのではなく、社内の標準として整備しておくと、要件定義の品質と効率が継続的に向上します。ここでは、標準フォーマットを作る手順と、運用の考え方を解説します。

規模別に3種類を用意する

• 簡易版：小規模な改修やツール導入向け。表紙・改訂履歴・目的と範囲・要件一覧（機能と非機能を1表）・検収条件の5部構成、数ページ程度
• 標準版：業務システムの新規開発向け。本記事で示した様式をすべて含む。本文Word＋一覧Excelの構成
• 拡張版：基幹システムの刷新や複数システムの連携向け。標準版に、章ごとの分冊、要件間の依存関係表、ステークホルダー別のレビュー記録を追加

すべての案件に同じ重さのフォーマットを適用しないことが、標準化を定着させるポイントです。

記入ガイドとサンプルを添付する

フォーマットには、各項目に「何を書くか」「どの程度具体的に書くか」の記入ガイドと、記入済みのサンプルを添付します。ガイドとサンプルがあれば、初めて担当する人でも一定の水準で書けるようになります。

記入済みのサンプルの例は、要件定義書のサンプル・記入例の記事で紹介しています。

AI開発向けの追加様式

AIを組み込んだシステムでは、標準の様式に「AI機能の定義」「精度目標と評価方法」「学習・参照データの要件」「PoC計画」「運用時の精度管理」の各項目を追加します。AI機能の要件は、入力・処理・出力に加えて「参照するデータ」「出力の確認方法」「誤った場合の対応」の列を持つ表で記述すると、従来の機能要件との違いが明確になります。

AI開発の要件定義や進め方については、AI受託開発の費用相場と開発会社の選び方の記事でも解説しています。

運用ルールを決め、改善を続ける

• フォーマットの管理者を決め、変更は管理者が承認する
• プロジェクト終了時に振り返りを行い、「あれば手戻りを防げた項目」「不要だった項目」をフォーマットに反映する
• 開発会社が独自の様式を持つ場合は、要件IDと章構成の対応表を作り、自社の様式との整合を保つ
• フォーマットの版数も管理し、どのプロジェクトがどの版で作られたかを記録する

フォーマットは配布して終わりではなく、使いながら育てる社内資産です。

フォーマットで失敗しないためのポイント

フォーマットを整えることは重要ですが、体裁が目的化すると本末転倒です。ここでは、フォーマットに関してよく起こる失敗と対策を整理します。

体裁は整っているが中身が薄い

表紙も改訂履歴も表も揃っているのに、要件の記述が曖昧で検証できない、という文書は少なくありません。フォーマットは中身の品質を保証しません。記述様式の各項目（入力・処理・出力・例外・根拠）が実際に埋まっているかを、レビューで確認しましょう。

形式に縛られて必要な情報が書けない

表の列に収まらないからと、重要な例外や判断の経緯を省略してしまうケースです。列に収まらない情報は備考や別紙に書き、フォーマットのために情報を削らないことを原則にします。

更新されず、実態と乖離する

承認後の変更が文書に反映されず、改訂履歴も止まっている状態です。変更管理の手続きに「文書の更新と改訂履歴の記録」を組み込み、最新版が常にどれかを判別できる状態を保ちます。

開発会社の様式と自社の様式が噛み合わない

開発会社が独自の様式で要件定義書を作成し、自社の標準と対応が取れなくなるケースです。契約時に、自社の様式を使うか、開発会社の様式に自社の要件IDと章構成を対応付けるかを決めておきましょう。どちらの様式であっても、要件IDによる追跡ができることが最低条件です。社内に要件定義書を評価できる人がいない場合は、発注側に立って要件定義に伴走してくれる会社に相談するのも一つの方法です。

システム開発やAI活用の進め方については、NextScaleのコラム一覧でも関連記事を公開しています。

【無料相談のご案内】 要件定義書の作成やフォーマットの整備に不安がある方、AIを組み込んだシステム開発を検討している方は、以下から無料の相談予約をご利用ください。自社の課題整理から要件定義、開発・運用までを一貫してご支援します。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

まとめ

要件定義書には決まった様式がないため、自社で「型」を決めておくことが品質と効率を左右します。フォーマットは、何を書くかを示すテンプレートとは異なり、表紙・改訂履歴・承認欄・章番号・版管理といった文書全体の様式、要件IDの体系と1つの要件を記述する様式、表・図・一覧のレイアウトを定めるものです。

要件は、IDを固定し、入力・処理・出力・例外・優先度・根拠・状態を同じ項目で記述し、非機能は要求水準と測定方法をセットで表にすることで、テストケースを作れる粒度になり、設計書やテスト仕様書との追跡も容易になります。形式は「説明はWord系、一覧はExcel系、承認版はPDF」を基本に、体制に合わせて選びます。

社内標準フォーマットは、規模別に簡易版・標準版・拡張版を用意し、記入ガイドとサンプルを添え、AI開発向けの項目を加え、プロジェクトの振り返りで改善を続けます。体裁を目的化せず、中身の品質を保つためにフォーマットを使う、という姿勢で、自社の要件定義の型を育てていってください。