当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
初めて要件定義書を任されて、白紙のファイルを前に手が止まっている方も多いのではないでしょうか。
結論から言うと、要件定義書の書き方は「目的から順に書き、一文ごとに確かめられる言葉で書く」の二つを守れば大きく外しません。
この記事では、作る手順と章ごとの記入例、そしてそのまま要件として通る文への直し方を紹介します。
要件定義書の書き方、まず押さえたい基本
要件定義書は「なぜ作るか」から「何を作るか」「どのくらいの品質か」の順に書きます。
そして一文ごとに、誰が読んでも同じ意味になり、あとでテストできる書き方にします。
要件定義（RD：Requirements Definition）は、システムで何を実現するかを関係者で決める工程です。
要件定義書は、その決めたことを書き残す文書なんです。
『書き方の型さえ分かれば書けるのに』と思っている方もいるかもしれませんね。
実は、型を知るだけでは足りなくて、もう一つ「文の書き方」が大事になります。
書く前に知っておきたい三つの考え方
| 考え方 | 中身 | よくある崩れ方 |
|---|---|---|
| 目的から書く | 背景・目的を最初に書き、すべての要件をそこにつなげる | 機能の一覧から書き始め、なぜ必要か説明できない |
| 範囲を決める | 今回やることと、やらないことを書く | 「やらないこと」を書かず、後から範囲が広がる |
| 確かめられる文で書く | テストで合否が分かる言葉にする | 「使いやすく」「早く」など人によって受け取り方が違う |
この三つは、要件定義の書き方全般に共通する考え方です。
要件定義書そのものが何かを先に知りたい方は、要件定義書とはを読んでから戻ってきてください。
要件定義書の作り方を、手順で見ていきましょう
いきなり本文を書き始めるより、材料を集めて目次を決めてから書くほうが早く仕上がります。
要件定義書の作り方は、だいたい次の流れです。
- 社内の過去の要件定義書や様式を集める
- 背景・目的と対象範囲を短く書き、関係者に確かめる
- 今の業務（As-Is）と目指す業務（To-Be）を書き出す
- 業務要件、機能要件、非機能要件の順に書く
- 決まっていないことを未決事項の一覧に移す
- 読み手ごとにレビューを受けて直す
- 承認欄で合意を取る
最初の一歩は「過去の文書を探す」こと
会社によって様式はかなり違います。
だからこそ、まずは社内の過去の要件定義書を見せてもらうのがいちばんの近道なんです。
様式が無い場合は、要件定義書の例・テンプレートの章立てを土台にしてみてください。
目的と範囲は、短く書いて先に合意する
背景・目的と対象範囲は、ほかの章を書く前に関係者へ見せておきます。
ここがずれたまま書き進めると、あとで全部の章を直すことになりかねません。
例えばこんなやり取りが、早い段階でできると理想的です。
「今回は申請と承認だけを対象にして、給与計算との連携は次の段階にしたいと考えています」
「それで大丈夫です。ただ、連携できるようにデータの形だけは今のうちに決めておきたいですね」
書くときに使う道具は、読み手に合わせて選ぶ
要件定義書を作る道具に、決まりはありません。
文章が中心の章は文書作成ソフト、機能一覧や課題の一覧は表計算ソフト、業務フロー図は作図ツール、と分けている現場が多いです。
| 書くもの | 向いている道具 | 理由 |
|---|---|---|
| 背景・目的、方針 | 文書作成ソフト | 文章で流れを説明しやすい |
| 機能一覧、非機能要件の一覧 | 表計算ソフト | 番号を振って並べ替えやすい |
| 業務フロー図 | 作図ツール | 部署ごとのレーンと流れを描きやすい |
| 未決事項、課題の一覧 | 表計算ソフトやタスク管理ツール | 担当者と期限を管理しやすい |
ファイルが分かれる時は、要件定義書の目次から各ファイルへたどれるようにしておくと、読む人が迷いません。
書く順番と、レビューの順番
業務要件から先に書くのは、機能が業務から生まれるからです。
レビューは、利用部門には業務要件、開発チームには機能要件と非機能要件、というように読み手ごとに見てほしい章を伝えると進めやすくなります。
進め方全体の流れは、要件定義の進め方・手順で詳しく説明しています。
章ごとの書き方と記入例
各章には「何を書くか」と「どこまで書けば十分か」があります。
迷ったら、その章を読む人が次の行動を取れるかで判断してみてください。
ここでは、架空の「社内の勤怠管理システムを入れ替える場合」を題材に、章ごとの記入例を並べます。
あくまで例なので、自分の案件の言葉に置き換えて使ってください。
| 章 | 書くこと | 記入例（架空） |
|---|---|---|
| 背景・目的 | なぜ今このシステムが必要か | 紙の出勤簿の集計に手間がかかり、締め日が遅れがちなため、打刻と集計を自動化する |
| 現状の課題（As-Is） | 今の業務の困りごと | 各部署の担当者が出勤簿を表計算ソフトに手で転記している |
| 目指す姿（To-Be） | 導入後の業務 | 打刻データがそのまま集計され、担当者は確認と承認だけを行う |
| 対象範囲 | やること、やらないこと | 打刻、修正申請、承認、月次集計を対象とし、給与計算は対象外とする |
| 業務要件 | 誰が、いつ、何を、どの基準で | 社員は出勤時と退勤時に打刻し、上長は翌営業日までに修正申請を承認する |
| 機能要件 | 画面、帳票、データ、処理、連携 | 修正申請画面を設け、申請、承認、差し戻しの状態を持つ |
| 非機能要件 | 性能、可用性、セキュリティなど | 始業時刻の前後に打刻が集中しても、打刻を受け付けられること |
| 移行要件 | 旧データの扱い | 過去の出勤簿データのうち、保存が必要な期間の分を取り込む |
| 運用・保守要件 | 稼働後の体制 | 打刻漏れの問い合わせは人事部が一次対応する |
| 未決事項 | 決まっていないこと | 休日出勤の扱いは、人事部が次回の会議までに決める |
背景・目的は、ITに詳しくない人にも伝わる言葉で
背景・目的の章は、経営層や決裁者もよく読む章です。
専門用語を並べるより、「今どんな手間があり、それがどう変わるか」を書いたほうが伝わりますよ。
業務要件は「誰が・いつ・何を・どの基準で」
業務要件は、システムの話をする前に、業務をどう変えるかを書く章です。
主語のない文は、誰の作業か分からなくなるので要注意です。
業務要件の章だけを詳しく知りたい方は、業務要件定義書の書き方もあわせてどうぞ。
機能要件は一覧にして番号を振る
機能要件は、文章で長く書くより、表計算ソフトなどで一覧にして番号を振るのがおすすめです。
番号があると、レビューの指摘や変更の記録で「どの要件の話か」がすぐ分かります。
非機能要件は「非機能要求グレード」を手がかりに
『非機能要件って、何から書けばいいの？』と迷う方はとても多いんです。
IPA（独立行政法人情報処理推進機構）の「非機能要求グレード」では、非機能要件を6つの大項目に分けています。
大項目は可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーで、それぞれのレベルを0〜5の段階で選びます。
全部を埋めなくても大丈夫です。
自分たちの案件に関係しそうな項目を選んで、発注側と開発側で話し合うきっかけにしてみてください。
数値の目標を決めるときは、根拠を一緒に書いておきましょう。
「なぜその水準なのか」が残っていると、あとで見直すときに判断しやすくなります。
未決事項は、隠さずに一覧にする
決まっていないことを書くのは、少し勇気がいりますよね。
ただ、未決事項を書かずに承認すると、あとで「決まっていたはず」とすれ違う原因になります。
「何が」「誰が」「いつまでに」決めるのかを一覧にしておけば、それ自体が立派な要件定義書の一部です。
用語集と承認欄も、手を抜かない
用語集は、つい後回しにしがちな章ですよね。
でも、社内で当たり前に使っている言葉ほど、開発チームには通じないことがあるんです。
例えば「締め」という言葉が、月末の集計を指すのか、承認の締め切りを指すのか、部署によって違うこともあります。
承認欄には、発注側と開発側の責任者の名前と日付を書き、どの版で合意したかを残しておきましょう。
その一文、要件として通りますか？NG文とOK文の書き換え表
要件定義書のつまずきは、章立てより「一文の書き方」で起きることが多いんです。
誰が読んでも同じ意味になり、テストで確かめられる文かどうかで見直してみてください。
要求工学の国際規格 ISO/IEC/IEEE 29148 では、良い要件の性質として、あいまいでない、検証できる、一つのことだけを言う、追跡できる、などが挙げられています。
この考え方をもとに、よく見かけるNG文を直してみました。
| NG文 | どこが困るか | OK文の例 |
|---|---|---|
| 画面は使いやすくする | 「使いやすい」の基準が人によって違う | 入力が必須の項目には、項目名の横に必須の印を表示する |
| 検索はすばやく結果を出す | どのくらいなら合格か分からない | 一覧の検索は、非機能要件の章で決めた応答時間の目標を満たす |
| 必要に応じて管理者に通知する | 「必要に応じて」の条件が無い | 修正申請が翌営業日までに承認されない場合、申請者の上長にメールで知らせる |
| 現行システムと同じ機能を持つ | 現行の機能が書き出されていない | 現行システムの機能一覧のうち、継続と決めた機能を持つ（機能一覧の番号で示す） |
| 申請の登録、承認、取消、集計ができる | 一文に複数の要件が入っている | 申請の登録、承認、取消、集計を、それぞれ別の要件として番号を振る |
| データはきちんと保管する | 何を、どれだけの期間、どこにか分からない | 打刻データは、社内規程で定めた保存期間のあいだ保管する |
| なるべく早く対応する | 誰の、何の対応か不明 | 打刻漏れの問い合わせには、人事部が受付当日中に一次回答する |
| 将来の拡張に備える | 何を備えるのか分からない | 給与計算との連携に使えるよう、集計データを出力する機能を持つ |
書き換えのコツは三つの問いかけ
NG文を見つけたら、次の問いを自分に投げかけてみてください。
- その文を読んだ人によって、受け取り方が変わらないか
- テストの担当者が「合格」「不合格」を判断できるか
- 一つの文に、二つ以上の要件が入っていないか
- 主語（誰が、何が）がはっきりしているか
- どの目的や要求から来た要件か、たどれるか
『全部の文をこんなに細かく書くのは大変そう』と感じたかもしれません。
最初から完璧にしなくても大丈夫です。
レビューで「この文はどうやって確かめますか」と聞かれたら、その場で直していけばいいんです。
数字がまだ決められない時の書き方
『目標の数字なんて、まだ誰も決められない』という場面もありますよね。
そんな時は、無理に数字を埋めずに「何を、誰が、いつまでに決めるか」を書いておきます。
「一覧画面の応答時間の目標は、現行システムの実測を見たうえで、情報システム部門と開発チームが次回のレビューまでに決める」という書き方なら、未決のまま放置されることを防げます。
小さな開発やシステム要件定義書の書き方はどう変わる？
小さな開発では章を減らしてかまいません。
ただし「目的」「範囲」「機能」「未決事項」の四つは残しておくと安心です。
VBAなど社内ツールでも要件定義書はいる？
表計算ソフトのVBAで作る集計ツールのような小さな開発でも、簡単な要件定義書はあったほうがいいです。
作った人が異動したあと、何のために何をするツールなのかが分からなくなるのを防げるからです。
| 項目 | 書く内容の例（架空） |
|---|---|
| 目的 | 部署ごとの経費精算データを月末に一つの表にまとめる手間を減らす |
| 範囲 | 経費精算データの集計だけを行い、承認の操作は対象外 |
| 入力 | 各部署が提出する決まった様式のファイル |
| 出力 | 部署別、科目別の集計表 |
| 機能 | 指定したフォルダのファイルを読み込み、集計表を作る |
| 例外 | 様式が違うファイルはエラーとして一覧に出す |
| 未決事項 | 様式を変える場合の連絡ルール |
これだけでも、作る側と使う側の認識をそろえるには十分役立ちます。
システム要件定義書の書き方で増えること
規模の大きなシステム開発では、業務側の要件定義書とは別に、システム要件定義書を作ることがあります。
システム要件定義書の書き方は、基本は同じです。
違うのは、業務の言葉を、システム全体の機能、性能、他システムとの連携、運用の言葉に置き換えて書く点です。
システム要件定義書で増えやすい項目を、業務側の要件定義書と並べてみました。
| 項目 | 業務側の要件定義書 | システム要件定義書 |
|---|---|---|
| 書く目線 | 業務と利用者 | システム全体 |
| 機能 | 業務で必要なこと | 機能の一覧と、機能どうしのつながり |
| 連携 | どの業務とつながるか | どのシステムと、どんなデータをやり取りするか |
| 品質 | 業務で困らない水準 | 非機能要件として、項目ごとの目標と確かめ方 |
| 運用 | 業務の担当と手順 | 監視、バックアップ、障害時の対応の体制 |
書き上げたら、最後にもう一度見直す
本文を書き終えたら、レビューに出す前に自分で一度見直しておきましょう。
- 背景・目的と、各要件のつながりを説明できるか
- 対象範囲に「やらないこと」を書いたか
- 機能要件に番号が振ってあるか
- 非機能要件に、確かめ方が書いてあるか
- 未決事項に、担当者と期限が書いてあるか
この見直しだけでも、レビューでの指摘はぐっと減りますよ。
業務要件を書かずに、いきなりシステム要件から書き始めてしまうケースです。
なぜその機能が必要なのかたどれなくなり、レビューで判断がつかなくなります。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
よくある相談に答えます
要件定義書の書き方について、よく寄せられる相談を要約してお答えします。
機能要件と非機能要件は書けたものの、その前に置く背景・課題・目的・方針・概要の章で手が止まっている、という相談です。
この章は、経営層や利用部門が「なぜやるのか」を理解するためのものです。
背景には今の困りごとを、目的には導入後にどうなりたいかを、方針には「今回は範囲をここまでにする」といった進め方の考えを書きます。
それぞれ数行で十分なので、まずは箇条書きで書き出してみてください。
プログラミングの前に要件定義が大事だと聞いたけれど、自分で書こうとすると何を書けばいいか分からない、という相談です。
結論から言うと、最初は「誰が使うか」「何ができればいいか」「何はやらないか」の三つを書くところから始めてみましょう。
そのうえで、画面ごとに「入力」「処理」「出力」を書き出していくと、自然と機能要件の形になっていきます。
社内で使う小さな業務アプリを作るよう頼まれたが、目的があいまいなまま依頼されて困っている、という相談です。
小さなアプリでも、目的と範囲だけは書いて依頼者に確かめるのがおすすめです。
「この目的なら、この機能が必要で、これは今回やらない」と書いたものを見せると、依頼者の考えもはっきりしてきます。
先ほどの社内ツール向けの表が、そのまま使えますよ。
よくある質問
要件定義書の書き方で、いちばん大事なことは何ですか？
目的から順に書くことと、一文ごとに確かめられる言葉で書くことです。この二つが守れていれば、様式が多少違っても伝わる要件定義書になります。
要件定義書の作り方は、誰に教わればいいですか？
まずは社内の過去の要件定義書を読み、書いた人に意図を聞いてみるのがおすすめです。公的な資料では、IPAが2019年に公開した発注側向けの要件定義の手引きも参考になります。
システム要件定義書の書き方は、要件定義書とどう違いますか？
基本の考え方は同じです。業務の言葉で書いた要件を、システム全体の機能・性能・連携・運用の言葉に置き換えて書く点が違います。
VBAで作る小さなツールにも要件定義書は必要ですか？
何ページもの文書は要りませんが、目的、範囲、入力と出力、機能、例外、未決事項くらいは書いておくと安心です。作った人が異動したあとも、何のためのツールかを引き継げます。
要件定義書は、どのくらい細かく書けばいいですか？
開発チームが設計に進めて、テスト担当が合否を判断できる細かさが目安です。迷う部分は未決事項に移して、誰がいつ決めるかを書いておきましょう。
まとめ
- 要件定義書は、目的から順に、確かめられる文で書く
- 作り方は、材料集め、目的と範囲の合意、業務要件、機能と非機能、未決事項、レビュー、承認の流れ
- 章ごとに「読む人が次の行動を取れるか」で書く量を決める
- NG文は、受け取り方のぶれ、検証できるか、一文一要件、主語の四点で直す
- VBAなどの小さな開発でも、目的・範囲・機能・未決事項は残しておく
書き終えた要件定義書の形を確かめたい方は、要件定義の具体例で通しの例を見てみてください。
コメント