LASSIC Media らしくメディア
要件定義書のテンプレート｜記載する項目と書き方の例を表で解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 要件定義書は業務要件・機能要件・非機能要件・実現案の4つで組み立てると、項目の抜けを見つけやすくなります。
- ひな形は項目ごとに書く中身と記入の例、よくある抜けを並べ、自社の値に置き換えて使います。
- 業務をどう変えるかは社内で決め、書き出しや非機能要件の素案は外部に頼むことができます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
初めて要件定義書を書くことになり、テンプレートを探してみたものの、項目の名前が並んでいるだけで、それぞれに何を書けばよいか分からない。開発会社に渡す前にどこまで書けばよいかも分からない——。システムの発注を任された担当者は、こうした場面で手が止まりがちです。
要件定義書に書く項目は、デジタル庁の標準ガイドラインにまとまっています。本記事では、そのガイドラインとIPAの資料をもとに、要件定義書のテンプレートを「項目・書く中身・記入の例・よくある抜け」の表で示します。あわせて、ひな形を埋める順番と、外部に頼める範囲も整理します。
要件定義書とは
要件定義書は、これから作るシステムに何を求めるかをまとめた書類です。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」は、要件定義書に業務要件、機能要件、非機能要件、情報システムの実現案の4つを書くとしています。*1 政府のシステムに向けた決まりですが、項目がそろっているので、民間の会社が要件定義書のテンプレートを作るときの目次としても使えます。
- 業務要件：システムを使って行う業務の中身（誰が・いつ・どれだけ）
- 機能要件：システムが備える機能（画面・帳票・データ・ほかのシステムとの連携）
- 非機能要件：機能のほかに求める条件（速さ・止まりにくさ・運用・保守など）
- 実現案：クラウドやパッケージを使うかなど、どう作るかの案
同じガイドラインは、要件定義が不十分なときには「計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まる」と述べています。*1 要件定義書のテンプレートを使う目的は、書くべき項目の抜けを先に見つけることにあります。
業務要件のひな形
業務要件は、ガイドラインの第4章が挙げる8つの事項で書きます。*1 下の表は、その8項目のひな形です。記入の例の数値などは〇で伏せているので、自社の値に置き換えて使ってください。
| 項目 | 書く中身 | 記入の例 | よくある抜け |
|---|---|---|---|
| 業務実施手順 | 業務の体制と手順、業務フロー図、入出力する情報と取扱量 | 受注から出荷までの流れを、〇〇部と〇〇部の担当ごとに図にする | 差し戻しや取消など、例外の処理が図に無い |
| 規模 | サービスとシステムの利用者数、時間・日・月あたりの処理件数 | 利用者〇名、受注〇件／日 | 繁忙期の件数を書いていない |
| 時期・時間 | 業務を行う時期と期間、繁忙期、業務を行う時間帯 | 月末の〇日間が繁忙、平日〇時〜〇時に利用 | 夜間や休日に使う人がいるか |
| 場所等 | 業務を行う場所、設備、必要な物品の種類と量 | 本社と〇か所の拠点、ハンディ端末〇台 | 在宅や外出先から使うかどうか |
| 管理すべき指標 | 業務の運営で追う指標と、その集め方・頻度 | 受注から出荷までの日数を月1回集計 | 指標を誰が見て何に使うか |
| 情報システム化の範囲 | システムで行う業務と、システムを使わずに行う業務 | 受注以降を対象とし、見積は対象外 | 対象外の業務を書いていない |
| 業務の継続の方針等 | 障害や災害のときに続ける業務と、その考え方 | 停止中は〇〇の受付を紙で続ける | 止まったときの代わりの手順 |
| 情報セキュリティ | 扱う情報の重要度に応じた対策の考え方 | 顧客の個人情報を扱い、閲覧は〇〇部に限る | 委託先が触れるデータの扱い |
いまの業務がある場合、ガイドラインは、新しい業務要件といまの業務との差が分かるようにしておくことを求めています。*1 表の各行に「いま」と「変更後」の2つの欄を設けておくと、何が変わるのかを関係者が一目で確かめられます。
機能要件と非機能要件のひな形
機能要件は、機能・画面・帳票・データ・外部インタフェース（ほかのシステムとの連携）の5つの事項で書きます。ガイドラインは帳票について、業務のデジタル化を前提に最小限にすることが望ましいとしています。*1 いまの帳票をそのまま書き写す前に、紙のままでなければならないかを確かめておきます。
| 項目 | 書く中身 | 記入の例 | よくある抜け |
|---|---|---|---|
| 機能 | 処理の中身、入力と出力の情報と方法 | 受注を登録すると在庫を引き当てる | 誰がその機能を使うか |
| 画面 | 画面の概要、表示のイメージ、画面の移り方 | 受注一覧から受注詳細、出荷指示へ進む〇画面 | 権限によって見え方が変わる画面 |
| 帳票 | 入出力する帳票の概要と、表示のイメージ | 納品書を1日〇枚印刷する | 紙をやめられる帳票が残っている |
| データ | データのまとまりと定義、データの使い道 | 顧客・商品・受注の3つのまとまり | 古いデータを何年残すか |
| 外部インタフェース | 連携する相手のシステム、やり取りするデータ、タイミング | 会計システムへ受注データを毎日1回送る | 相手側の担当者との確認 |
非機能要件は、ガイドラインではaからrまでの18の事項に分かれています。*1 下の表では、初めて書く人が抜かしやすい8項目を選びました。性能と信頼性について、ガイドラインは業務要件に照らして過度にならないよう求め、運用と保守、保守と機能の改修をそれぞれ分けて書くことも求めています。*1
| 項目 | 書く中身 | 記入の例 | よくある抜け |
|---|---|---|---|
| 規模 | 機器の数、データ量、処理件数、利用者数 | データ量〇GB、〇年後の見込みも書く | 将来の見込み |
| 性能 | 画面の応答時間、まとめて処理する時間 | 一覧画面は〇秒以内に表示 | 業務に対して過剰な値 |
| 信頼性 | 稼働率など | 平日の業務時間の稼働率〇％ | 業務に対して過剰な値 |
| 継続性 | 障害・災害時の機能、どこまで戻すか、いつまでに戻すか | 〇時間以内に再開、データは前日分まで戻す | 業務の継続の方針との食い違い |
| テスト | テストの種類、目的、実施者、合否の基準 | 受け入れテストは〇〇部が実施 | 合否の基準 |
| 移行 | 移行の時期、方式、対象 | 旧システムの受注データ〇年分を移す | 移さないデータの扱い |
| 運用 | 運用時間、監視、障害からの復旧 | 平日〇時〜〇時に監視 | 保守と混ぜて書いている |
| 保守 | 製品やプログラムの保守と、問い合わせの体制 | 不具合の問い合わせ窓口を1つにする | 機能の改修と混ぜて書いている |
残りの項目の抜けを防ぐには、IPA（情報処理推進機構）の「非機能要求グレード」が役に立ちます。非機能要求の項目を網羅的に並べ、それぞれの求める水準を段階で示したもので、*2 可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大きな項目に分かれています。*3 重要な項目から順に水準を決めていく使い方が案内されています。*2
ひな形を埋める順番
業務から機能、機能から非機能へと進めると、書いた内容どうしの食い違いが起きにくくなります。次の4つの段階で進めます。
- ステップ1：業務要件を「いま」と「変更後」に分けて書く
- ステップ2：変更後の業務に要る機能・画面・データ・連携を書き出す
- ステップ3：非機能要件を、止まると困る業務から順に決める
- ステップ4：決まっていない項目を明記して、関係する部門と確かめる
ステップ4で見る点として、ガイドラインは「必要性、網羅性、具体性、定量性、整合性、中立性及び役割分担の明確性」を挙げています。*1 書いた時点で決まっていない要件は、プロジェクトを進めるうえでの危険の種になり得るので、その旨を要件定義書に書くことも求めています。空欄のまま次の工程へ渡すのではなく、「未定・〇月までに決める」と書いておくのが確実です。
また、機能要件や非機能要件は、情報システム部門だけで決めるものではないとされています。業務を担う部門の人にも表を見てもらい、記入の例を自社の値に置き換えてもらいます。
外部に頼める範囲
要件定義書のテンプレートを埋める作業には、社内でしか決められないことと、外部の手を借りられることがあります。業務をどう変えるかの判断は社内に残し、書き出しや下書き、技術面の確認を外部に頼む分け方にすると進めやすくなります。
| 項目 | 社内で決めること | 外部に頼めること |
|---|---|---|
| 業務要件 | 業務をどう変えるか、どこまでをシステムにするか | 聞き取りの記録、業務フロー図の清書 |
| 機能要件 | 機能の優先度 | 画面・データ・連携の一覧の下書き |
| 非機能要件 | 止まると困る業務、許せる停止の長さ | 非機能要求グレードを使った素案、実現できるかの確認 |
| 実現案 | どの案で進めるかの最終判断 | クラウドやパッケージを使う案など、複数の案の比較 |
ガイドラインは、実現案を複数検討するとしています。*1 外部に頼む場合も、比べた案を残してもらうと判断しやすくなります。外部に依頼する前に、次の点を確かめておきます。
- どこまで頼むか：このひな形のどの項目まで、下書きと清書のどちらを頼むか
- 成果物の形：要件定義書の目次と表の形を、最初に双方で決めておくか
- 未定の項目：決まっていない要件を誰がいつまでに決めるか
- 確かめ方：途中で見直す回数と、そこに参加する部門
- 引き継ぎ：要件定義書を開発会社へ渡すときに、誰が説明するか
ガイドラインは、要件定義書が次の工程以降でも使われ続けることに注意するよう求めています。*1 費用の考え方や依頼先の選び方は要件定義を外注する費用と進め方で、要求定義との違いは要件定義と要求定義の違いで扱っています。
まとめ：要件定義書のテンプレートで確かめておきたい3つの点
要件定義書のテンプレートを使って書き始めるうえで、確かめておきたい点は3つに整理できます。第一に、業務要件・機能要件・非機能要件・実現案の4つがそろっているかを目次で確かめること。第二に、業務から機能、機能から非機能の順に埋め、決まっていない項目は空欄にせず「未定」と書くこと。第三に、業務をどう変えるかは社内で決め、書き出しや技術面の確認を外部に頼む分け方を最初に決めることです。この3点を踏まえておけば、「テンプレートは埋めたのに、開発の途中で抜けが見つかった」という事態を避けやすくなります。要件定義書の書き方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
要件定義書のテンプレートはExcelとWordのどちらで作ればよいですか
どちらでも作れます。項目ごとに値を並べる部分は表計算ソフト、背景や目的の説明は文書作成ソフトと使い分けても構いません。大切なのは形式よりも、項目がそろっていることです。
小さなシステムでも全部の項目を書く必要がありますか
ガイドラインも、作るシステムの特徴を踏まえて記載の軽重を検討するとしています。*1 当てはまらない項目は消さずに「対象外」と理由を一言書いておくと、検討したうえで外したことが後から分かります。
要件定義書と調達仕様書はどう違いますか
要件定義書はシステムに求める要件をまとめた書類で、調達仕様書は発注の条件をまとめた書類です。ガイドラインでは、調達仕様書に要件定義書を添付し、要件定義書を満たすべき旨を記載する形になっています。*1
要件定義書づくりのご相談
要件定義書の項目の洗い出しから、非機能要件の素案づくり、開発会社への引き継ぎまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン（DS-100）」2026年6月12日 デジタル社会推進会議幹事会決定（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：第3編第4章5「業務要件の定義」、第5章「要件定義」（要件定義書の記載内容、機能要件・非機能要件の各事項、未確定な要件の扱い、実現案の複数検討）、第6章「調達」の記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「システム構築の上流工程強化（非機能要求グレード）紹介ページ」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）。出典：非機能要求グレードの説明と利用手順の記述を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018 改訂情報 ～初版との差異～」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf）。出典：非機能要求の大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）の記述を参照（2026年10月確認）
