要件定義書の書き方：発注側が埋めるべき項目とテンプレートの使い方

要件定義書は、開発会社が書くものだと思われがちです。しかし、システムの目的、対象となる業務の範囲、譲れない制約といった中身を知っているのは発注側だけです。開発会社は聞き取りをもとに文書を整えることはできても、事業の判断までは代わりに下せません。発注側が「目的・業務範囲・機能・非機能・制約」の5つを自分たちの言葉で書き出しておくだけで、要件定義書の精度は大きく上がり、見積もりのぶれや開発途中の手戻りが減ります。

一方で、発注側がすべてを技術的な表現で書く必要はありません。画面の細かなレイアウトやデータベースの構造は、開発会社が設計の段階で詰めるものです。発注側に求められるのは、何のために、誰が、どんな業務で、どの水準で使うのかを、判断の根拠とともに伝えることです。

この記事は、初めて要件定義に関わる事業部門の担当者や、開発会社から「要件をまとめてください」と言われて手が止まっている方に向けています。要件定義書に入れる項目、発注側がどこまで書くべきかの線引き、テンプレートの使い方、書き進める手順、よくある抜け漏れまでを順に解説します。

要件定義書とは何か、なぜ発注側が関わるべきか

要件定義書とは、これから作るシステムが満たすべき条件を、関係者が合意できる形で文書にまとめたものです。「何を作るか」の合意書であり、その後の設計・開発・テスト・検収のすべての基準になります。

要件定義書が曖昧なまま開発に進むと、次のような問題が起きます。開発会社は分からない部分を自分たちの解釈で埋めるため、出来上がったものが現場の期待と合わない。テストの段階で「こういう動きのはずだった」という指摘が大量に出る。そして修正のたびに追加費用とスケジュールの延長が発生します。

こうした行き違いの多くは、技術の問題ではなく、発注側が持っている前提が文書に書かれていなかったことから生まれます。業務の例外、社内の決まりごと、取引先との約束といった情報は、発注側が書かない限り開発会社には伝わりません。要件定義書は開発会社のための書類であると同時に、発注側の考えを整理するための道具でもあるのです。

なお、要件定義の後には基本設計、詳細設計と工程が続きます。要件定義書が「何を満たすか」を決めるのに対し、基本設計（外部設計）は画面や帳票など利用者から見える形を決める工程です。この境目を理解しておくと、要件定義書にどこまで書けばよいかの判断がしやすくなります。

要件定義書に入れる5つの項目と発注側の担当範囲

要件定義書の構成は会社やテンプレートによって異なりますが、中身は大きく5つに整理できます。それぞれについて、発注側が書くべきことと、開発会社と一緒に詰めることを分けて示します。

表のとおり、目的と制約はほぼ発注側にしか書けません。業務要件と機能要件は発注側が素案を出し、開発会社が整理する分担がうまくいきやすい形です。非機能要件は専門用語が多く難しく感じますが、発注側は「どんな状況で何人が使うか」「止まったら何が困るか」といった事実を伝えれば、開発会社が数値目標に落とし込めます。

項目ごとの書き方と記入例

ここからは、5つの項目それぞれについて、具体的に何を書けばよいかを見ていきます。記入例はいずれも架空のものです。

目的・背景：成功の基準まで書く

「業務を効率化したい」だけでは目的として弱く、開発の判断基準になりません。現在何が起きていて、システムによって何をどう変えたいのか、そして何をもって成功とするのかを書きます。

記入例としては、「現在、受注情報を営業担当がExcelに入力し、事務担当が基幹システムに再入力している。二重入力による転記ミスと、月末の締め作業の遅れが課題である。受注情報の入力を一度で済ませ、締め作業を月末の前営業日までに終えられる状態を目指す」のような書き方です。成功の基準が具体的であるほど、機能の優先度を判断しやすくなります。

業務要件：例外とその頻度を書く

対象となる業務の流れを、誰が、いつ、何をするかの順に書き出します。文章だけでなく、業務フロー図を添えると伝わりやすくなります。描き方は業務フロー図の書き方で解説しています。

ここで大切なのは、通常の流れだけでなく例外を書くことです。「キャンセルが出たとき」「承認者が不在のとき」「月をまたぐとき」など、現場では当たり前に処理している例外が、システムでは個別の機能になります。例外ごとに、どれくらいの頻度で起きるのかも添えておくと、システムで対応するか手作業で残すかの判断材料になります。

機能要件：優先度と理由を添える

必要な機能を一覧にし、それぞれに優先度を付けます。「必須」「あると望ましい」「将来検討」の3段階程度で十分です。機能ごとに「なぜ必要か」を一言添えておくと、開発会社が代替案を提案しやすくなります。

画面の見た目にこだわりがある場合は、手描きのラフや参考にしたい既存サービスの画面を添えます。画面同士のつながりを整理するなら、画面遷移図を簡単に描いておくのも有効です。

非機能要件：事実と困りごとで書く

非機能要件は、発注側が専門用語で書く必要はありません。次のような事実を書けば、開発会社が具体的な要件に置き換えてくれます。

• 利用者の数と、同時に使う人数の目安
• 利用する時間帯と、止まると困る時間帯
• 止まった場合に何が起きるか（売上が止まる、顧客に迷惑がかかる、社内で代替できる、など）
• 扱う情報の種類（個人情報、決済情報、取引先の機密情報など）
• 社内のセキュリティ規程や、取引先から求められている基準
• データを何年保存する必要があるか

たとえば「営業担当30人が日中に使い、夜間は止まってもかまわない。ただし月末の締め日に止まると請求が遅れる」と書けば、開発会社は締め日に負荷が集中する前提で構成を考え、保守の対応時間帯も提案できます。数字が分からない項目は空欄にせず「不明、目安を相談したい」と書いておくと、確認漏れを防げます。

制約条件：動かせないものを明確にする

予算の上限、公開の期限、使い続ける既存システム、守るべき法令や社内ルールなど、動かせない条件を書きます。期限については、なぜその日なのか（キャンペーン開始、制度変更、契約更新など）の理由も添えると、範囲を調整する際の判断材料になります。

範囲外（スコープ外）を書く

5つの項目に加えて、意外と効果が大きいのが「今回は作らないもの」の明記です。たとえば「請求書の発行は既存の会計ソフトで行うため対象外」「スマートフォン専用アプリは今回作らない」と書いておけば、開発会社が範囲を広く解釈して見積もりが膨らむことも、逆に発注側が当然含まれていると思い込むことも防げます。範囲外の一覧は、後の検収や仕様変更の議論でも判断の拠り所になります。

要件定義書を書き進める手順

白紙から要件定義書を書こうとすると、どこから手を付けてよいか分からなくなります。次の順番で進めると、無理なく形になります。

1. 関係者を洗い出す：システムを使う人、業務の責任者、決裁者、情報システム担当、経理など、影響を受ける人を一覧にします。後から「聞いていない」という人が出ないようにするためです。
2. 目的と成功の基準を決裁者と合意する：最初に目的を固めておかないと、後の機能の議論が発散します。一文で言える目的と、測れる成功の基準を決めます。
3. 現状の業務を書き出す：現場の担当者に話を聞き、業務の流れと例外を書き出します。実際の帳票や画面のスクリーンショットも集めておきます。
4. 課題と変えたい点を整理する：現状の流れのどこに問題があり、どう変えたいのかを書きます。ここで初めて「システムで何をするか」が見えてきます。
5. 機能を一覧にして優先度を付ける：変えたい点を実現するための機能を一覧にし、目的に照らして優先度を付けます。
6. 非機能要件と制約を書く：利用規模、止まってよい時間、扱う情報、予算、期限などを書き出します。
7. 開発会社とすり合わせる：素案をもとに開発会社と打ち合わせ、実現方法や抜けている観点を確認します。ここで機能の分け方や優先度を見直します。
8. 合意して版を管理する：最終版を関係者で確認し、合意した日付と版番号を記録します。以降の変更は変更履歴として残します。

打ち合わせを進める際は、毎回の終わりに「決まったこと」「持ち帰って確認すること」「次回までの担当者」を記録して共有します。要件定義は一度の会議では終わらず、確認と修正を何度も往復する作業です。決定事項が議事録の中に埋もれると、同じ議論を繰り返すことになります。決まった内容はその都度要件定義書に反映し、議事録は根拠として紐づけておくと、後から「なぜこう決めたのか」をたどれます。

テンプレートの上手な使い方

インターネットで探すと、要件定義書のテンプレートは数多く見つかります。テンプレートは項目の抜け漏れを防ぐのに役立ちますが、使い方を誤ると逆効果になります。

全項目を埋めようとしない

テンプレートは大規模なシステムを想定して作られていることが多く、小さなシステムにはそぐわない項目も含まれます。自社の案件に関係のない項目は「対象外」と明記して飛ばしてかまいません。すべてを埋めようとして形式的な文章が並ぶより、重要な項目を具体的に書くほうが価値があります。

項目の意味を理解してから書く

テンプレートの項目名だけを見て書くと、意図とずれた内容になりがちです。分からない項目は開発会社に意味を確認し、自社の状況に置き換えてから書きます。

チェックリストとして使う

テンプレートを「埋める書式」ではなく「確認する観点の一覧」として使う方法もあります。自社の言葉で要件をまとめたあと、テンプレートの項目と照らし合わせて、抜けている観点がないかを確かめるのです。この使い方なら、テンプレートの形式に縛られずに済みます。

粒度の目安は「誰が読んでも同じ動きを想像できるか」

どこまで詳しく書けばよいか迷ったときは、その記述を業務を知らない人が読んで、同じ動きを想像できるかで判断します。「承認フローを作る」では人によって想像する動きが違いますが、「申請額が一定額を超える場合は部長承認を追加し、差し戻された申請は申請者が修正して再提出できる」と書けば、ほぼ同じ動きが浮かびます。逆に、ボタンの色や配置まで書く必要はありません。それは設計の段階で開発会社が提案し、発注側が確認すればよい部分です。

架空の例：社内申請システムの要件定義でつまずいたケース

ここで、仕組みを理解するための架空の例を紹介します。ある会社で、紙で回していた経費申請をWebで行うシステムを作ることになりました。担当者はテンプレートに沿って要件定義書を作り、開発会社に渡しました。

ところが、開発が進んでテストの段階になると、経理部門から次々と指摘が出ました。部門をまたぐ費用の按分、出張の仮払い精算、承認者が長期休暇中の代理承認など、紙の運用では担当者が個別に処理していた例外が、要件定義書にまったく書かれていなかったのです。経理部門は要件定義の打ち合わせに呼ばれていませんでした。

この会社は、追加の要件を整理し直し、優先度の高い例外だけをシステムに組み込み、頻度の低い例外は当面手作業で対応すると決めました。振り返ると、手順の最初にある「関係者の洗い出し」と、業務要件での「例外とその頻度」の記述が不十分だったことが原因でした。テンプレートの項目は埋まっていても、中身の確認が足りなかった例です。

次の段階の開発では、この会社は要件定義の初回に経理・総務・各部門の申請担当者を集め、過去数か月分の紙の申請書を一緒に見ながら例外を洗い出しました。実物の書類を前にすると、「この欄はこういう場合に使う」という暗黙の運用が次々と出てきたといいます。文書の形式を整えることより、現場の実物に触れながら話を聞くことのほうが、抜け漏れを防ぐうえで効果的だったわけです。

よくある抜け漏れと避け方

要件定義書で特に抜けやすい項目を、避け方とあわせて挙げます。

• 管理者側の機能：利用者向けの画面ばかり考え、マスタ登録やデータ修正、利用者管理など管理者が使う機能が抜けます。誰がどのデータを登録・修正するのかを業務の流れに含めて書きましょう。
• 既存データの移行：新しいシステムに古いデータを移すかどうか、どの範囲を移すかが書かれていないことがあります。移行の要否と対象期間を明記します。
• 権限の違い：役職や部署によって見られる情報、できる操作が違う場合、その区別を書きます。権限が後から増えると設計の見直しが必要になります。
• 帳票や出力：画面で見るだけでなく、CSVやPDFでの出力が必要な場合は、形式と用途を書きます。
• 運用の担当者：公開後に誰が問い合わせを受け、誰が設定を変えるのかが決まっていないことがあります。運用体制も要件の一部として書きます。
• 用語の定義：社内で使っている言葉が、開発会社には別の意味で伝わることがあります。「顧客」「案件」「契約」などの用語は定義を添えます。
• 通知とメール：誰に、どのタイミングで、どんな内容の通知を送るかは、業務の流れを書いても抜けやすい部分です。承認依頼、期限切れの警告、完了報告など、人に知らせる場面を一覧にしておきます。
• 集計と分析の観点：システムに貯まったデータを後で何に使うのかが書かれていないと、必要な項目が記録されないまま公開されることがあります。月次で見たい数字や、経営会議で使う資料を例として添えると、記録すべき項目が明確になります。

要件定義書の提出前チェックリスト

要件定義書を開発会社に渡す前、または合意する前に、次の点を確認します。

• 目的と成功の基準が、関係者全員に同じ意味で伝わる言葉で書かれているか
• 関係する部署と担当者がすべて打ち合わせに参加したか
• 通常の業務の流れに加えて、例外とその頻度が書かれているか
• 機能ごとに優先度と、必要な理由が添えられているか
• 管理者側の機能、権限の違い、帳票・出力が含まれているか
• 利用規模、止まってよい時間、扱う情報の種類が書かれているか
• 予算、期限、既存システムとの関係、守るべきルールが明記されているか
• データ移行の要否と範囲が書かれているか
• 社内用語の定義が添えられているか
• 版番号と合意日、変更履歴の記録方法が決まっているか

要件定義書が固まったら、それをもとに見積もりや提案を依頼する段階に進みます。複数社に提案を求める場合は、RFP（提案依頼書）の書き方も参考にしてください。

よくある質問

Q. 要件定義書は発注側と開発会社のどちらが作るものですか？

最終的な文書を整えるのは開発会社であることが多いですが、目的・業務・制約といった中身は発注側が出すものです。発注側が素案を作り、開発会社が整理と補足をする分担にすると、行き違いが少なくなります。

Q. 要件定義にはどれくらいの期間がかかりますか？

システムの規模、関係者の数、発注側の準備度合いによって大きく変わります。事前に目的と業務の流れを整理しておくと、打ち合わせの回数が減り、期間を短くできます。

Q. 要件定義書が固まった後に変更したくなったらどうすればよいですか？

変更は可能ですが、費用やスケジュールに影響することがあります。変更の内容と理由を記録し、開発会社に影響範囲を見積もってもらったうえで、優先度を判断します。変更の手続きは契約前に決めておくと安心です。

Q. 小規模なシステムでも要件定義書は必要ですか？

必要です。ただし、分量は規模に合わせてかまいません。目的、必須機能、利用者、制約が1〜2枚にまとまっているだけでも、行き違いは大きく減ります。

Otsumuに相談できること

業務の流れを把握している担当者がいて、作りたいものの輪郭が見えている場合は、この記事の手順とチェックリストに沿って素案を作り、開発会社とすり合わせるだけで十分に機能する要件定義書になります。小さな社内ツールであれば、目的と必須機能を1枚にまとめるところから始めれば足ります。

一方で、目的は決まっているが何をシステム化すべきかが定まらない、関係部署の意見がまとまらない、新規事業でそもそも業務の流れがまだ存在しない、といった状況では、要件を引き出して整理する役割を外部に任せたほうが早く進むことがあります。特に新規事業では、要件を固めすぎず、検証しながら決めていく進め方のほうが向いている場合もあります。

Otsumuは、自ら事業を手がける立場から、目的から逆算して必要な機能を絞り込む要件整理を得意としています。要件定義から開発、公開後の運用・改善までを一気通貫で支援しており、AIを活用した開発で少人数・短期間での立ち上げが可能です。システム開発の進め方を紹介しているほか、構想段階であれば新規事業開発コンサルティングとして、事業の検証と要件の整理を並行して進めることもできます。

お手元の要件定義書の素案を見ながらの相談も歓迎しています。まずは30分の無料相談で、現在の状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01