当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
初めてシステム開発の打合せに出て『要件定義書をまとめておいて』と言われ、何から手を付ければいいのか固まってしまった方も多いはずです。言葉は聞いたことがあっても、中身がぼんやりしていますよね。
結論から言うと、要件定義書は「何のために、何ができるシステムを、どんな条件で作るか」を発注側と開発側で合意した文書です。中身は「業務要件」「機能要件」「非機能要件」「制約・前提」の4つの箱で考えると、ぐっとわかりやすくなります。
この記事を読めば、要件定義書とは何か、どんな内容を書くのか、どんな順番で作るのかが分かります。
要件定義書とは？ひと言でいうと
要件定義書とは、システムに求めることを文書にして、関係者が「これで作る」と合意した記録です。開発の一番最初にまとめ、その後の設計やテストはこの文書を土台に進みます。
まずは、公的な手引きでの言い方を見てみましょう。
デジタル庁の標準ガイドライン群用語集では、要件定義を「必要な要件を明確に定める行為又はその定めた内容」と説明しています。情報システムの設計・開発や機器の調達などを行う時の言葉として定義されているんです。
IPAのDX SQUARE「要件定義とは？」では、要件定義を「システム開発の工程の1つであり、プロジェクトの初期に実施される工程」と説明しています。つまり、要件定義という作業の成果をまとめた文書が要件定義書です。
「要求」と「要件」はどう違う？
『要求と要件って、同じ意味じゃないの？』と感じる方もいますよね。
IPAのDX SQUAREでは、要求を「ビジネス要求」と「システム化要求」に分けています。それを文書にして関係者と合意したものを要件と呼ぶ、という趣旨の説明です。ただ、要求と要件には標準的な定義が無い、とも書かれています。
| 言葉 | ざっくりした意味 | 例 |
|---|---|---|
| 要求 | 利用者や会社が「こうしたい」と思っていること | 申請の受付をもっと早くしたい |
| 要件 | 要求を文書にして、関係者と合意したこと | 申請画面から受付番号を自動で発行する |
| 要件定義 | 要件を決めていく作業 | 打合せ、業務の聞き取り、合意の取り付け |
| 要件定義書 | 要件定義の結果をまとめた文書 | 業務要件・機能要件・非機能要件などを書いた文書 |
職場によって言い方が違うこともあるので、最初の打合せで「この文書では要求と要件をどう使い分けるか」をそろえておくと安心です。
要件定義書は何のために作る？
要件定義書を作る目的は、大きく3つあります。
- 発注側と開発側で「何を作るか」の認識をそろえる
- 設計・開発・テストの判断の拠り所にする
- 後から「言った・言わない」になった時に立ち返る場所を作る
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義書はバイブルであり，事あらばここへ立ち返るもの」という一文があります。迷った時に戻る場所だと考えると、なぜ丁寧に作るのかが見えてきますよね。
要件定義書の内容は4つの箱で考えるとわかりやすい
要件定義書の内容は「業務要件」「機能要件」「非機能要件」「制約・前提」の4つの箱に入れて考えると、書き漏れが減ります。どの箱が空っぽかを見れば、まだ決まっていないことも分かります。
『要件定義書って、結局どんな内容を書けばいいの？』という疑問に、ここで答えていきますね。
| 箱 | 書くこと | 例 |
|---|---|---|
| 業務要件 | 業務の目的、目標、業務の流れ | 申請から承認までの流れ、どこを楽にしたいか |
| 機能要件 | システムにできてほしいこと | 画面、帳票、データ、外部とのやり取り |
| 非機能要件 | 機能以外で求める水準 | 速さ、止まりにくさ、セキュリティ、運用、移行 |
| 制約・前提 | 動かせない条件と、決まっていないこと | 予算や期限、使う環境、未確定の項目 |
業務要件：何のためのシステムかを書く
デジタル庁の用語集では、業務要件を「業務を行う目的、達成したい目標、目標を達成するためのプロセスやフロー等」と説明しています。
ここが空っぽだと、機能の話ばかりが先に進んでしまいます。例えば「経費精算を楽にしたい」なら、今は誰が、どの紙を、どの順番で回しているかから書き始めるのがコツです。
機能要件：システムにできてほしいこと
機能要件は、用語集では「システム要件のうち機能に関する内容」とされています。
デジタル庁のDS-100（デジタル・ガバメント推進標準ガイドライン）では、機能要件の定義として、機能・画面・帳票・データ・外部インタフェースに関する事項を挙げています。画面一覧や帳票一覧のように、一覧表で並べると漏れに気づきやすいですよ。
非機能要件：速さや止まりにくさなどの水準
非機能要件は「機能要件以外の情報システム要件」で、性能や信頼性、拡張性、運用性、セキュリティなどがあります。
IPAの「非機能要求グレード2018」では、大項目を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つに分けています。何を決めればいいか迷った時の目次として使えます。
くわしくは非機能要件とは？要件定義書に書く項目と決め方で紹介しています。
制約・前提：動かせない条件とまだ決まっていないこと
予算や期限、使える機器やソフト、守るべき社内ルールなど、動かせない条件をここに書きます。
DS-100では、未確定な要件はリスク要因となり得るので、その旨を要件定義書で明らかにすることとしています。決まっていないことを隠さず「未定」と書いておくのも、大事な内容なんです。
DS-100の第3編第5章では、要件定義書の記載内容を「業務要件の定義」「機能要件の定義」「非機能要件の定義」「システム方式の決定」の4つとしています。この記事の4つの箱とは分け方が少し違うので、行政の調達で使う時はDS-100の項目に合わせてください。
要件定義書と仕様書・設計書・RFPの違い
要件定義書は「何を作るか」、設計書は「どう作るか」、RFPは「提案してほしいこと」をまとめた文書です。仕様書はこれらを広く指す言葉として使われることもあります。
開発の現場では、似た名前の文書がたくさん出てきますよね。『どれが何だか分からない』となりやすいので、並べてみます。
| 文書 | 何を書くか | 主に誰が作るか | いつ作るか |
|---|---|---|---|
| 要件定義書 | 何のために、何ができるシステムを作るか | 発注側が中心（開発側が手伝うことも多い） | 開発の初め |
| RFP（提案依頼書） | 提案してほしい内容と条件 | 発注側 | 開発会社を選ぶ時 |
| 調達仕様書 | 調達の条件や作業の範囲 | 発注側 | 契約の前 |
| 基本設計書 | 画面や帳票など、利用者から見える設計 | 開発側 | 要件定義の後 |
| 詳細設計書 | 機能を実現するための内部の設計 | 開発側 | 基本設計の後 |
| テスト仕様書 | 何をどう確かめるか | 開発側・発注側 | 設計と並行して |
デジタル庁の用語集では、RFPを「提案依頼又は提案依頼書のこと。Request For Proposal の略字」としています。DS-100では、調達のたびに調達仕様書を作り、要件定義書をそこに添付する流れになっています。
仕様書という言葉そのものの意味は仕様書とは？意味と目的、設計書・要件定義書との違いで、要件定義書と仕様書の違いは要件定義書と仕様書の違いでくわしく紹介しています。
設計書との境目はどこ？
IPAのDX SQUAREでは、基本設計を「要件定義でまとめた要件を具体化し、業務フローを明確にする工程」と説明しています。
例えばこんな場面で考えてみましょう。
- 申請を受け付けたら受付番号を発行する
- 承認者は申請一覧から内容を確かめられる
- 繁忙期でも画面の表示が待たされにくい
- 受付番号の桁数と採番のルール
- 申請一覧の画面のレイアウトと項目の並び
- どの処理をどの順番で動かすか
「何を」が決まっていないのに「どう」を書き始めると、後で作り直しになりがちです。順番を守るのがいちばんの近道ですよ。
要件定義書を作る流れ
要件定義書は「目的をそろえる」「業務を聞き取る」「要件を書き出す」「関係者で確かめる」「合意して版を固める」の順に作ります。一度で完成させようとせず、何回か読み合わせて仕上げるものです。
IPAの共通フレーム2013では、システム開発の作業を細かく分けていて、その中に「要件定義プロセス」があります。企画のあと、システム開発に入る前に置かれている作業です。
- 目的と範囲をそろえる（何のために、どこまでをシステムにするか）
- 今の業務を聞き取る（誰が、何を、どの順番でしているか）
- 4つの箱に要件を書き出す（業務・機能・非機能・制約と前提）
- 関係者と読み合わせる（足りない所、食い違う所を直す）
- 合意して版を固める（承認した日と版を残す）
誰が作るの？
IPAの原理原則17ヶ条には「要件定義は発注者の責任である」という一文があります。開発会社に手伝ってもらうことはあっても、何を作りたいかを決めるのは発注側なんです。
ただ、実際には開発会社が聞き取りをして文書にまとめる場面も多いですよね。共通フレーム2013のガイダンスでは、企画や要件定義の一部を発注する場合、「請負」か「準委任」かの区別をしておくのがよい、としています。
役割の分け方は要件定義書は誰が作る？発注側と開発側の役割分担でくわしく紹介しています。
聞き取りでは「困っていること」から聞く
聞き取りの場で、いきなり「どんな機能がほしいですか？」と聞くと、答えに詰まる人が多いです。
例えば、こんな聞き方をしてみてください。
「今いちばん時間がかかっている作業は何ですか？」
「その作業がなくなったら、何が楽になりますか？」
困りごとから聞くと、業務要件が自然に集まります。機能の話はその後で十分間に合いますよ。
合意の記録を残す
原理原則17ヶ条には「取り決めは合意と承認によって成り立つ」という一文もあります。
- 承認した日と承認した人
- 文書の版（第1版、第2版のような番号）
- 前の版から変わった所
- まだ決まっていない項目と、決める予定の時期
要件定義書でよくある失敗と防ぎ方
よくある失敗は「機能がどんどん増える」「あいまいな言葉で書く」「決まっていないことを書かない」の3つです。どれも、書く時のちょっとした工夫で防げます。
『ちゃんと書いたつもりなのに、後でもめてしまった』という声は少なくありません。よくある失敗を先に知っておきましょう。
機能がどんどん増える
原理原則17ヶ条には「機能要求は膨張する。コスト，納期が抑制する」という一文があります。
打合せのたびに「これもあったら便利」が足されていくのは、どの現場でも起きることなんです。
「せっかくだから」と機能を足し続けて、予算や期限に収まらなくなってしまうことがあります。機能ごとに「必須」「できれば」「今回は見送り」の印を付けておくと、優先順位で話し合えます。
あいまいな言葉で書く
「使いやすい画面」「すばやく表示する」のような言葉は、人によって受け取り方が違います。
| あいまいな書き方 | 伝わる書き方の例 |
|---|---|
| 使いやすい画面にする | 申請に必要な入力を1画面で終えられるようにする |
| すばやく表示する | 一覧画面は何秒以内に表示する（数値は関係者で決める） |
| 必要に応じて通知する | 承認待ちが出たら承認者にメールで知らせる |
| なるべく止まらないようにする | 利用時間帯と、止まった時に復旧するまでの目安を決める |
書き方のコツは要件定義書の書き方｜項目・目次と、伝わる書き方のコツでくわしく紹介しています。
決まっていないことを書かない
決まっていないことを書かずに進めると、後で「それは聞いていない」となりがちです。
先ほどのとおり、DS-100でも未確定な要件はその旨を要件定義書で明らかにすることとしています。「未定」「次回の打合せで決める」と書いておくだけでも、後のもめごとが減りますよ。
要件定義書は後から変えてもいい？
『一度合意したら、もう変えられないの？』と心配な方もいますよね。実は、変えることはできます。
大事なのは、変える時に版を上げて、何が変わったかを残すことです。変更の伝え方は仕様書の変更管理｜仕様変更の伝え方と版の付け方で紹介しています。
要件定義書のよくある相談
知恵袋でよく読まれているのは「要件定義書はどう書くの？」「何のソフトで書くの？」「要件定義書からテスト仕様書を作るのは普通？」といった相談です。どれも、文書の役割が分かると答えが見えてきます。
ここからは、知恵袋でよく読まれている相談を要約して答えてみますね。
相談1：要件定義書ってどんなふうに書くの？
『プログラムを書く上で要件定義が大事だと聞いたけど、要件定義書ってどう書くの？』という相談です。
まずは、この記事で紹介した4つの箱を見出しにした文書を作ってみてください。業務要件から順番に埋めていくと、何を書けばいいかが見えてきます。
実在の会社の見本をそのまま写すより、自分たちの業務に合わせて項目を足し引きする方がうまくいきます。見本の使い方は要件定義書のサンプル・テンプレートで紹介しています。
相談2：要件定義書や基本設計書は何で書くの？
『要件定義書や基本設計書は、スライド？ Excel？ 何で書くのが普通？』という相談です。
決まったソフトはありません。文章が中心ならWord、一覧表が多いならExcel、打合せで見せるならスライドと、職場ごとに使い分けていることが多いです。
| 書く内容 | 向いている形 |
|---|---|
| 目的や業務の流れなど文章が多い所 | Word などの文書 |
| 機能一覧、画面一覧、項目の一覧 | Excel などの表 |
| 打合せで説明する全体像 | スライド |
| 版の管理をしながら複数人で直す | Markdown などのテキスト |
大事なのは、ソフトより「最新版がどれか分かること」です。ファイル名や表紙に版と日付を入れておきましょう。
相談3：要件定義書からテスト仕様書を作れと言われた
『要件定義書からテスト仕様書とテストデータを作れと言われた。そんなやり方、普通あるの？』という相談です。
要件定義書をもとにテストを考えるのは、おかしなことではありません。
DS-100でも、PJMOが利用者の参加する受入テストを行う流れが書かれています。発注側が「要件どおりにできているか」を確かめるには、要件定義書が拠り所になるんです。
ただ、細かい画面の動きまでは要件定義書に書かれていないことが多いので、設計書もあわせて見られるか、確認してみてください。
相談4：SESでも要件定義の仕事はできる？
『要件定義は発注者と開発者が打合せをするものだと思うけど、SESでも要件定義の仕事はできるの？』という相談です。
契約や配属先によって、要件定義の聞き取りや文書作りを手伝う場面はあります。ただ、どこまで任されるかは現場次第です。
要件定義や設計を書く経験は、上流工程を任される職場で評価されやすいものです。
今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると道が見えてきます。今の職場で少しずつ担当を広げていく道も、もちろんありです。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
仕様書を書く仕事の全体像は仕様書を書く仕事とは？SE・PM・社内SEの仕事内容と違いで紹介しています。
よくある質問
要件定義書とは何ですか？わかりやすく教えてください。
システムで何をしたいか、何ができてほしいか、どんな条件で作るかを文書にして、発注側と開発側が合意した記録です。開発の最初に作り、設計やテストの土台になります。
要件定義書の内容には何を書けばいいですか？
業務要件、機能要件、非機能要件、制約と前提の4つの箱で考えると書きやすくなります。行政の調達では、デジタル庁のDS-100にある項目に合わせて書きます。
要件定義とはどの工程のことですか？
IPAのDX SQUAREでは、システム開発の工程の1つで、プロジェクトの初期に行う工程と説明されています。企画の後、設計に入る前に行います。
要件定義書と基本設計書の違いは何ですか？
要件定義書は「何を作るか」、基本設計書は要件を具体化して「利用者から見てどう動くか」を決める文書です。要件定義書が決まってから基本設計に進みます。
要件定義書は誰が書くのですか？
IPAの原理原則17ヶ条には「要件定義は発注者の責任である」とあります。実際には開発会社が聞き取りや文書作りを手伝うことも多いので、役割を最初に決めておくと安心です。
まとめ
- 要件定義書は、システムに求めることを関係者で合意した文書
- 内容は業務要件・機能要件・非機能要件・制約と前提の4つの箱で考える
- 要件定義書は「何を作るか」、設計書は「どう作るか」を書く
- 目的をそろえる所から始め、読み合わせて合意し、版を固める
- 未確定のことは隠さず「未定」と書いておく
コメント