「要件定義書を用意してください」と開発会社から言われ、検索して無料テンプレートをいくつかダウンロードしたものの、Excel版・Word版・IPAやデジタル庁の公的なものまであって、結局どれを使えばいいのか分からない——そんな状態で手が止まっていませんか。
さらに困るのは、テンプレートを開いた後です。たくさんの空欄が並んでいるけれど、「どこまで具体的に書けばいいのか」「自分が書いた内容で開発会社に本当に伝わるのか」が判断できず、提出ボタンを押す勇気が出ない。社内にIT専任がいない中小企業の発注担当者にとって、これはごく自然な悩みです。要件定義書を最後まで自分で書き上げた経験がなければ、完成のゴールが見えないのは当然だからです。
この記事は、その「テンプレートは手に入れたけれど提出できない」状態を解消するために書きました。要件定義書テンプレートを「選ぶ」「埋める」「提出前に確認する」という3つの手順に分け、それぞれで迷わないための判断基準を、発注者の目線でまとめています。
具体的には、まずテンプレートを大きく3系統に整理して自社に合うものを選ぶ方法、無料で入手できる代表的なテンプレートの使い分け、各欄をどの粒度で埋めれば開発会社に伝わるかの「記入の型」、そして提出前に抜け漏れを確認できる完成度チェックリストを順番に解説します。読み終えるころには、手元のテンプレートを「これなら開発会社と話を始められる」と思える状態まで仕上げられるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
要件定義書テンプレートは「選び方」で迷わないのが先決
無料の要件定義書テンプレートはインターネット上に数多く公開されています。だからこそ、最初につまずくのは「書き方」よりも「どれを使えばいいか」という選択の場面です。種類を眺めているうちに時間だけが過ぎてしまうのは、もったいない足止めです。
選ぶときのコツは、世の中のテンプレートを1つずつ比較しようとしないことです。テンプレートは大きく3つの系統に分けて捉えると、自社に合うものがすぐに見えてきます。
テンプレートは3系統（Excel型／Word型／公的テンプレート）で捉える
要件定義書テンプレートは、形式と狙いの違いから次の3系統に整理できます。
- Excel型（表で一覧管理する）: 機能の一覧や項目をセルで管理しやすく、「どの機能があるか」「優先度はどれか」を表で並べて見せたい案件に向きます。機能の数が多いシステムや、項目を整理しながら埋めたい場合に扱いやすい形式です。
- Word型（文章で背景を伝える）: 業務の背景や目的、困りごとを文章で説明しやすく、「なぜこのシステムが必要か」という文脈を伝えたい案件に向きます。機能数がそれほど多くなく、経緯や狙いを丁寧に共有したい場合に適しています。
- 公的テンプレート（IPA・デジタル庁／網羅性重視）: 国の機関が公開している、抜け漏れを防ぐための網羅的なひな形です。確認すべき観点が体系的に整理されている一方で、大規模・公共システムを想定しているため、項目数が多く中小規模の案件にはやや過剰になりがちです。
この3系統を頭に入れておくと、「自分の案件はどの形式が向いているか」という観点で候補を絞り込めます。
自社の案件に合うのはどれか（規模・目的別の早見表）
どの系統を選ぶかは、案件の規模と「何を一番伝えたいか」で決めると迷いません。下の早見表を出発点にしてください。
自社の案件の特徴 | 向いている系統 | 理由 |
|---|---|---|
機能を一覧で整理したい・項目数が多い | Excel型 | 機能と優先度を表で並べて管理しやすい |
「なぜ必要か」「現状の困りごと」を丁寧に伝えたい | Word型 | 背景や目的を文章で説明しやすい |
小〜中規模の業務システム・Webサービスを初めて外注する | Excel型またはWord型（民間配布） | 項目が絞られていて、発注者が無理なく埋められる |
抜け漏れを徹底的に防ぎたい・規模が大きい | 公的テンプレートを参考にする | 確認すべき観点が体系的に整理されている |
初めての外注で、規模もそれほど大きくないのであれば、まずは民間配布のExcel型またはWord型から始めるのが現実的です。公的テンプレートは、自分のテンプレートに抜けがないかを後から照らし合わせる「チェックの物差し」として使うと、過不足なく活用できます。
無料の要件定義書テンプレートの入手先と選定チェック
系統の見当がついたら、実際に無料で入手できるテンプレートを選びます。ここでは入手先を「民間配布のExcel/Word」と「公的テンプレート」に分け、それぞれがどんな案件・目的に向くかを整理します。
民間配布のExcel/Wordテンプレート（手早く埋めたい中小・小規模案件向け）
IT企業やビジネス情報サイトが、Excel版・Word版の要件定義書テンプレートを無料で配布しています。会員登録なしでダウンロードできるものも多く、項目があらかじめ絞られているため、初めて要件定義書を書く発注者でも手早く埋め始められるのが利点です。
中小企業の小〜中規模案件であれば、この民間配布のテンプレートで十分なことがほとんどです。複数を見比べる場合は、「項目が多すぎて埋めきれない」ものより、「自社で答えられる項目だけで構成されている」ものを選ぶと挫折しにくくなります。
IPA・デジタル庁の公的テンプレート（網羅性・抜け漏れ防止を重視する案件向け）
抜け漏れを防ぎたい場合や、要件定義の「勘どころ」を体系的に学びながら進めたい場合は、公的機関が公開している資料が参考になります。
- IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」: 発注者（ユーザー）主体で要件定義を進めるための考え方を、要件定義を成功に導く128の勘どころとしてまとめた資料です。テンプレートそのものというより、「何をどう決めればよいか」の判断基準が充実しています（IPA ユーザのための要件定義ガイド 第2版）。
- デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（要件定義）」: 政府の業務システム開発で実際に作るべきドキュメントを工程ごとに整理した資料で、別紙として業務要件・機能要件・非機能要件のひな形（機能要件定義書テンプレート例を含む）が用意されています（デジタル・ガバメント推進標準ガイドライン 実践ガイドブック 第3編第5章 要件定義）。
これらは大規模・公共システムを前提としているため、中小企業の小規模案件にそのまま使うと項目が多すぎて手が止まりがちです。「自分のテンプレートに抜けている観点はないか」を確認する参照資料として活用するのがおすすめです。
テンプレートを選ぶときの3つの確認ポイント
候補が複数あって決めきれないときは、次の3点で確認すると最後の1つに絞り込めます。
- 項目の過不足はないか: 自社の案件に必要な欄（目的・機能・予算・納期など）が揃っていて、かつ埋められない専門的すぎる欄が並んでいないか。
- 自社で埋められる粒度か: 各欄が「自分の言葉で答えられる質問」になっているか。専門用語ばかりで何を書けばよいか分からないテンプレートは、後の工程でつまずきます。
- 開発会社と共有しやすい形式か: ExcelやWordなど、相手が開いて追記・コメントしやすい一般的な形式か。特殊なソフトが必要な形式は避けると、提出後のやり取りがスムーズです。
この3点を満たすテンプレートを1つ選べれば、選定の工程は完了です。次は、その空欄をどう埋めるかに進みましょう。
テンプレートを埋めるときの「記入の型」（発注者が押さえる粒度）
テンプレートを選んでも、空欄を前に手が止まるのが最大の難所です。ここでつまずく原因は、「正しい書き方が分からない」というより「どこまで具体的に書けば伝わるのか」という粒度の目安が分からないことにあります。
そこで、主要な欄について「何を・どの粒度で書けば開発会社に伝わるか」の型を示します。難しい文章を書く必要はありません。各欄に「伝わる書き方」と「避けたい書き方」を添えるので、自分の下書きと見比べてみてください。なお、各項目を一から書き起こす詳しい手順は要件定義書の書き方とテンプレートに譲り、ここではテンプレートを埋める実務の勘所に絞ります。
背景・目的欄は「困りごと」と「達成したい状態」をセットで書く
背景・目的の欄は、システムの善し悪しを左右する出発点です。「業務を効率化したい」だけでは、開発会社は何を作ればよいか判断できません。
- 伝わる書き方:「現在は注文情報を手作業でExcelに転記しており、1日あたり2時間かかっている（困りごと）。これを自動化し、転記作業を10分以内にしたい（達成したい状態）」
- 避けたい書き方:「業務を効率化したい」「DXを進めたい」（何が困っていて、どうなれば成功かが分からない）
今の困りごとと、達成したい状態の2つをセットで書くのがコツです。
機能一覧欄は「必須／あれば良い／将来」の優先度を必ず添える
やってほしいことを並べた機能一覧は、優先度がないと「全部を最初から作る」前提で見積もられ、予算や納期が膨らみがちです。
- 伝わる書き方: 各機能に「必須」「あれば良い」「将来的に検討」のラベルを付ける（例:「在庫の自動アラート=必須」「売上のグラフ表示=あれば良い」）
- 避けたい書き方: やりたいことを思いつくまま列挙し、優先度を付けない
優先度を添えるだけで、開発会社は「まず何から作るべきか」を提案しやすくなり、予算内で実現可能な範囲も見えてきます。
非機能要件欄は専門用語より「どのくらい速く・安全に・落ちないか」を言葉で
非機能要件は専門的に見えますが、発注者は技術用語で書く必要はありません。性能・セキュリティ・安定性などについて、「どのくらいを望むか」を日常の言葉で書けば十分です。
- 伝わる書き方:「画面の表示は3秒以内に終わってほしい」「個人情報を扱うので外部から見られない仕組みにしてほしい」「営業時間中（9〜18時）は止まらないでほしい」
- 避けたい書き方:「レスポンスタイムを最適化」「高可用性を確保」（具体的な希望水準が伝わらない）
希望の水準を素朴な言葉で書いておけば、それを技術的にどう実現するかは開発会社が提案してくれます。
未確定の欄は空欄より「未確定」と明記する
すべての欄を完璧に埋める必要はありません。むしろ、決まっていないことを無理に埋めるより、未確定であることを正直に書くほうが後のトラブルを防げます。
- 伝わる書き方:「予算は社内で調整中（未確定）。○月までに確定予定」「対象ユーザー数は現状不明のため、開発会社と相談して決めたい」
- 避けたい書き方: 空欄のまま放置する（開発会社は「考慮不要」なのか「決まっていない」のか判断できない）
空欄は「抜け」と受け取られかねません。「未確定」と一言添えるだけで、開発会社はその欄をすり合わせの議題として扱ってくれます。
提出前に使う要件定義書テンプレート完成度チェックリスト
各欄を埋め終えたら、最後に「これで開発会社に渡してよいか」を確認します。提出ボタンを押せない不安の正体は、抜け漏れがないかを自分で判断できないことです。次のチェックリストで、観点ごとに確認していきましょう。
提出前チェックリスト（観点別の確認項目と合格ラインの目安）
確認観点 | チェック項目 | 合格ラインの目安 |
|---|---|---|
目的・背景 | 今の困りごとと、達成したい状態の両方が書けているか | 第三者が読んで「何のために作るか」が分かる |
機能 | 各機能に「必須／あれば良い／将来」の優先度が付いているか | すべての機能に優先度のラベルがある |
非機能要件 | 性能・セキュリティ・安定性の希望水準が言葉で書けているか | 「どのくらい速く・安全に・落ちないか」が1つ以上書いてある |
予算・納期・制約 | 予算感、希望時期、外せない制約（既存システム連携など）が書けているか | 未確定でも「未確定」と明記されている |
未確定事項 | 決まっていない欄が空欄でなく「未確定」と明示されているか | 空欄が残っていない |
社内合意 | 内容を社内の関係者（利用部門・決裁者）と確認したか | 関係者の認識が揃っている |
この6観点をすべて満たしていれば、テンプレートは「開発会社と話を始められる状態」に達しています。1つでも引っかかる項目があれば、先ほどの記入の型に戻って補えば十分です。なお、これは自分が埋めたテンプレートを渡す前の確認です。逆に、開発会社から届いた要件定義書を署名前に確認する観点については要件定義書の読み方｜署名前チェックリストで扱っていますので、受領する局面ではそちらを参照してください。
全部埋まっていなくてよい——「対話のたたき台」として渡す考え方
ここで大切なのは、要件定義書テンプレートは「完璧な完成物」である必要はないということです。発注者がすべてを正確に決めきるのは現実的ではありませんし、その必要もありません。
テンプレートの役割は、開発会社との対話を始めるためのたたき台です。困りごとと目的、優先度を付けた機能、希望水準、そして未確定事項が整理されていれば、開発会社はそれを起点に質問し、足りない部分を一緒に埋めていけます。「完璧に書けたら提出する」ではなく「話を始められる状態になったら提出する」と考えると、提出のハードルはぐっと下がります。
テンプレート提出後の進め方と、つまずいたときの相談先
テンプレートを提出した後、何が起きるのかが見えていると、安心して提出に踏み切れます。最後に、提出後の一般的な流れと、自社だけで埋め切れないときの相談先を整理します。
提出後はテンプレートを起点に開発会社とすり合わせる
要件定義書を提出すると、多くの場合、開発会社から質問や確認が返ってきます。「この機能の優先度はどちらが高いですか」「この非機能要件はこういう理解で合っていますか」といったやり取りを通じて、要件は少しずつ精緻になっていきます。
つまり、提出はゴールではなくスタートです。テンプレートに書いた内容は、このすり合わせの議題の一覧として機能します。未確定と書いた欄も、この段階で開発会社と相談しながら決めていけるので、提出時点で埋め切れていなくても前に進めます。
自社だけで埋め切れないときの相談の選び方
社内にIT専任がいないと、機能の整理や非機能要件の判断で「自分たちだけでは決めきれない」と感じる場面が出てきます。そのときは、要件整理の段階から相談に乗ってくれる開発会社を選ぶのが現実的な選択肢です。
開発会社を探すときは、いきなり開発の見積もりを求めるのではなく、「要件定義の段階から一緒に整理してもらえるか」を確認するとよいでしょう。発注者の困りごとを聞き出して要件に翻訳する伴走をしてくれる相手であれば、テンプレートの空欄を前に一人で悩む時間を減らせます。テンプレートはあくまで対話のたたき台ですから、埋め切れない部分を持ち込んで相談すること自体が、要件定義の正しい進め方です。
まとめ｜要件定義書テンプレートは「選ぶ・埋める・確認する」の3手順で提出できる
要件定義書テンプレートを前にして手が止まってしまうのは、「どれを選ぶか」「どこまで埋めるか」「これで提出していいか」という3つの判断が同時にのしかかるからです。逆に言えば、この3つを順番に片付ければ、提出までの道のりは見えてきます。
- 選ぶ: テンプレートをExcel型／Word型／公的テンプレートの3系統で捉え、自社の規模と伝えたい内容に合うものを1つ選ぶ。
- 埋める: 困りごとと目的をセットで書き、機能には優先度を添え、非機能要件は希望水準を言葉で表し、未確定の欄は「未確定」と明記する。
- 確認する: 提出前チェックリストの6観点で抜け漏れを確認する。
そして何より、テンプレートは完璧な完成物でなくてかまいません。開発会社との対話のたたき台として「話を始められる状態」になったら、自信を持って提出して大丈夫です。届いた要件定義書を受領者として確認する局面では要件定義書の読み方｜署名前チェックリストも役立ちますので、発注の流れに合わせて使い分けてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 要件定義書テンプレートは未確定の欄が多くても提出してよいですか？
はい、未確定の欄は「未確定」と明記した上で提出して構いません。要件定義書は完璧な完成物ではなく、開発会社との対話のたたき台です。困りごとと目的、優先度付きの機能一覧が揃っていれば、残りは開発会社と一緒に詰めていけます。
- 機能要件と非機能要件の区別がつかない欄はどちらに書けばよいですか？
「何をするシステムか（機能）」は機能要件、「どのくらい速く・安全に・落ちないか（品質水準）」は非機能要件が目安です。判断に迷う場合はどちらかに書いて「開発会社と確認したい」と一言添えれば、相手が適切な欄に整理してくれます。
- 予算がまだ確定していませんが、テンプレートの予算欄に何を書けばよいですか？
「社内調整中（未確定）。○月までに確定予定」のように状況と確定予定時期を書いてください。空欄のままだと開発会社が考慮不要と判断してしまうため、未確定でも現時点の状況を一言書くことで、見積もり段階での確認事項として扱ってもらえます。
- 提出前チェックリストで一部の観点がクリアできない場合、どう判断すればよいですか？
未クリアの項目が「未確定事項の明記」や「社内合意」であれば、その旨をテンプレートに書き添えて提出を進められます。目的・機能・非機能要件の観点が揃っていれば、開発会社から不足点を確認してもらえるので、「話を始められる状態」を基準に判断してください。
- 要件定義書テンプレートを複数の開発会社に送る場合、内容を変える必要はありますか？
基本的な要件は同じものを送って構いません。ただし、提示する予算感や重視する点（コスト・スピード・技術力など）を相手によって変える場合は、該当欄のみ調整すると比較見積もりの精度が上がります。
