要件定義書のサンプル【2026年版】公開されている実物6つの入手先と、PDF・Excelの探し分け、自社への当てはめ方

「要件定義書のサンプルを探しているのに、出てくるのは空欄のテンプレートばかりだ」——これから要件定義書を作る方から、こうした相談をよく受けます。検索して、メールアドレスを登録して、ダウンロードして、開いてみると項目名が並んでいるだけ。知りたいのは「性能要件」という見出しではなく、そこに何行、どんな文で書くのかです。埋まった状態の実物を1本見せてほしい。その希望に、検索結果はほとんど答えてくれないのが実情です。

結論から言うと、埋まった実物は公開されています。探す場所が違うだけです。国や自治体が調達のときに公開した要件定義書、そしてIPA(情報処理推進機構)がドキュメント単位で公開しているサンプルとフォーム。この2系統を押さえれば、PDFで通し読みしたい人も、Excelで編集したい人も目的の物にたどり着けます。テンプレート配布サイトを何件も回る必要はありません。

ただし、見つけた実物をそのまま使うことはおすすめしません。公共調達の要件定義書は、情報公開と会計監査に耐えることを前提に書かれています。民間の中規模案件でその分量をまねると、誰も読まない文書ができあがります。サンプルは写経の手本ではなく、自社の文書を採点するための物差しとして使うものです。書きすぎも書かなすぎも、どちらも失敗のもとです。

本記事では、公開されている要件定義書の実物にたどり着き、それを自社の文書に変えるまでを扱います。テンプレートと実物の違い、入手先6つの一覧、IPAで手に入るものの実態、実物を開いたときに見る5つの着眼点、規模別に削る判断と外部委託で足す5項目、そのまま使うと失敗する3つの理由と記入前チェックリスト、そして当社の位置づけとよくある質問の順です。章立ての解説と各章の記載例は「要件定義書 書き方」の記事に、工程としての位置づけは「要件定義とは」の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。テンプレートの空欄が半分埋まらないまま相談に来られる方は、珍しくありません。そして埋まっていない欄には共通点があります。そこは文章が書けない欄ではなく、社内でまだ決まっていない事柄の欄なのです。サンプルを探す前に、この切り分けを済ませたほうが早い。その話も記事の後半でします。

探しているのはどちらか——空欄の「テンプレート」と、実際に使われた「実物」は別物

要件定義書の「サンプル」という言葉は、2つのまったく違うものを指しています。1つは空欄のテンプレート。章立てと項目名だけが用意された、これから埋めるための枠です。もう1つは実物。実際の案件で使われ、中身が埋まった状態の要件定義書です。探し始める前にどちらが欲しいのかを決めておかないと、検索に時間を溶かします。

検索して出てくるものの大半はテンプレート。実物はほとんど混ざっていない

2026年9月時点で「要件定義書 サンプル」の検索上位10件を確認したところ、自社テンプレートを配布している記事が6件、章立てや書き方を解説している記事が2件、公開されている実物を紹介している記事が2件でした。つまり8割は枠だけを渡してくる記事です。しかも配布型の多くはメールアドレスの登録やツールの申し込みを求めます。

配布そのものが悪いわけではありません。ただ、「サンプル」と書かれたリンクを開くと空欄が出てくる状態が続くと、読者は「実物は世の中に出ていないのだろう」と思い込んでしまいます。実際には出ています。後述するとおり、国や自治体が調達のときに公開した要件定義書が、PDFで丸ごと読める形でいくつも残っています。

空欄のテンプレートから読み取れないもの——粒度、厚みの偏り、数値の入れ方

テンプレートで分かるのは項目名だけです。実務で迷うのは項目名ではなく、その先の3点です。

このうち特に効くのが1つ目です。同じ「非機能要件」という見出しでも、小規模な社内システムなら1ページ、数百人が使う基幹システムなら数十ページになります。自分の案件がどちらに近いのかは、実物を1本通しで見ないと感覚がつかめません。書きすぎも書かなすぎも、どちらも失敗のもとです。

本記事の担当範囲——章立ての解説は別記事に譲る

なお、要件定義書の章立て(目次)の型や、各章に何をどう書くかという記載例については、本記事では扱いません。そちらは「要件定義書 書き方」の記事で、9章の並びと曖昧な一文を判定できる一文に直す対比まで解説しています。要件定義という工程そのものの位置づけ(開発全体のどこに入り、誰が関わり、何が成果物として残るか)は「要件定義とは」の記事、手順としての進め方は「要件定義の進め方」の記事が担当です。

本記事が引き受けるのは、その手前と後ろです。手前は「実物をどこで手に入れるか」、後ろは「手に入れた実物をどう読み、自社の文書にどう落とすか」。この2つに絞ります。では、実物がどこにあるかから見ていきます。

公開されている要件定義書の実物はどこにあるか——入手先6つと、それぞれ何が参考になるか

民間企業の要件定義書は、まず公開されません。社内の業務プロセスと課題がそのまま書かれた文書だからです。一方で、国や自治体の情報システム調達では、要件定義書が入札公告の添付資料として公開されます。入札に参加する事業者が同じ条件で見積もるために必要だからです。実物はここに偏在しています。

入手先6つの一覧——資料名・形式・公開年・参考になる点

出典: 国土交通省「建設キャリアアップシステム 要件定義書」(https://www.mlit.go.jp/common/001156807.pdf)、調達ポータル(https://www.p-portal.go.jp/)、札幌市 一般競争入札等情報(https://www.city.sapporo.jp/kikaku/it-keiyaku/1_ippan_kyousou.html)、IPA各ページ。いずれも2026年9月15日確認。

このうち1番は、要件定義書というものを初めて通しで読む人に最も向いています。表紙をめくると目次が4ページ続き、本体は「1 業務要件の定義」「2 機能要件の定義」「3 非機能要件の定義」の3章だけで構成されています。章がたった3つで398ページに達するという事実そのものが、公共調達の文書の性格を物語っています。

官公庁・自治体の調達資料が実物の宝庫である理由と、探し方

公共調達で要件定義書が公開されるのは、会計法令上の公平性の要請があるためです。特定の事業者だけが要件を知っている状態では競争入札が成立しません。結果として、本来は社外に出ない粒度の文書が誰でも読める場所に置かれます。

探すときは、次の順で当たるのが早いです。

1. 調達ポータル(デジタル庁運営)で「システム 要件定義」「設計・開発業務」などの語で調達案件を検索する。国の機関と地方公共団体の案件が集約されている唯一の入口
2. 自治体の情報システム主管課のページを直接見る。多くの自治体が「入札・契約等情報」のページを持ち、調達仕様書と要件定義書を並べてPDFで置いている
3. 省庁の調達情報ページを見る。文部科学省・総務省などは調達情報の一覧を独自に持っている

案件名で探すより、「調達仕様書」という語と併せて探すほうが当たります。要件定義書は単独ではなく、調達仕様書の別紙として添付されることが多いためです。逆に言うと、要件定義書だけを見ても背景や開発スケジュールが書かれていないことがあり、その部分は調達仕様書側にあります。

リンクは消える——案件終了でページごと削除される。消えない入口を押さえる

ここが要注意です。自治体・省庁の調達ページは、案件が終了すると削除されます。技術者向けメディアで紹介されていた札幌市「文書管理システム再構築に係る設計・開発業務」の案件ページを2026年9月15日に確認したところ、404 Not Found でした。紹介記事の投稿は2024年ですから、2年で消えたことになります。

つまり、この分野で「便利なリンク集」は長持ちしません。押さえるべきは個別のPDFのURLではなく、消えない入口のほうです。具体的には、調達ポータル、各自治体の入札情報の一覧ページ、そしてIPAのアーカイブ。この3つは案件単位ではないため残ります。見つけた実物は、その場でPDFを手元に保存しておくことをおすすめします。

IPAの公開資料で手に入るもの——完成品1本ではなく、ドキュメント単位のサンプルと観点リスト

「要件定義書 サンプル ipa」という検索が一定数あります。公的機関の資料なら信用できる、という発想でしょう。ここで先に結論を書いておきます。IPA(情報処理推進機構)は、完成した要件定義書を1本まるごと公開しているわけではありません。出しているのは、ドキュメント単位のサンプルとフォーム、非機能要件の観点リスト、そして発注側向けのガイドの3種類です。この事実を知らないまま探すと、いつまでも見つからない物を探すことになります。

Excelで編集したい場合——「超上流から攻めるIT化の事例集：要件定義」のドキュメント別サンプル

Excelのフォームが欲しいという需要には、この事例集が最もよく応えます。IPAがユーザ企業・ベンダ企業から集めた実際の成果物を、ドキュメントの種類ごとに整理して公開しているものです(https://www.ipa.go.jp/archive/digital/tools/ep/ep2.html / 2026年9月15日確認)。収録されているのは、おおむね次の区分です。

同じ種類のドキュメントについて複数の企業が提供したサンプルが並んでいる点が、この資料の価値です。たとえば業務フロー図なら、詳細に描いたものと標準的な粒度のものが見比べられます。「どの粒度が正しいのか」ではなく「粒度には幅がある」ことが体感できるため、自社の案件でどこに合わせるかを決めやすくなります。

ただし、ここにあるのは要件定義書そのものではなく、要件定義書に添付・引用される個別成果物です。文書全体の構成を知りたいなら、前章で挙げた公共調達の要件定義書を併読してください。

非機能要件を埋めたい場合——非機能要求グレード2018を観点リストとして使う

非機能要件は、実物のサンプルを見ても自社に当てはめにくい領域です。案件ごとに求める水準が違うからです。ここで使えるのが、IPA「非機能要求グレード2018」です(2018年4月公開。利用ガイド[活用編]は2019年3月に第2版へ改訂 / https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html)。

構成は、項目一覧・グレード表・樹形図・活用シート・利用ガイドです。非機能要求項目が6つの大項目(可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー)の下に階層化されており、さらに社会的影響度に応じた3つのモデルシステムごとに推奨レベルが示されています。

使い方としては、埋めるための雛形というより、点検のためのリストとして扱うのが実務的です。6つの大項目を上から順に見ていき、自社の案件で必要なものだけ数値を入れ、不要なものには「対象外」と書き残す。空欄のまま残さないことが要点です。空欄は「まだ決めていない」のか「決めた結果、要らない」のかが後から区別できません。

なお、6大項目それぞれに何をどう書くかという記載の作法は、「要件定義書 書き方」の記事で扱っています。

PDFで通し読みしたい場合——ユーザのための要件定義ガイド 第2版

解説を通しで読みたいなら、IPA「ユーザのための要件定義ガイド 第2版」(2019年9月12日公開)です。副題が「要件定義を成功に導く128の勘どころ」で、構成は全7章。背景、要件定義の問題認識、要件定義の全体像、ビジネス要求定義における問題と勘どころ、システム化要求定義における問題と勘どころ、要件定義マネジメント、そして第7章が主要ドキュメント作成の勘どころです。2019年12月20日以降はパスワードなしのPDFが提供されています。

発注側(ユーザ企業の情報システム部門)向けに書かれていますが、第7章はドキュメントの作り方に踏み込んでいるため、受注側が水準を合わせる用途にも使えます。サンプルそのものではないものの、「なぜこの書き方が必要か」を稟議で説明する根拠としては、匿名のテンプレート配布サイトより格段に使いやすい資料です。

3つの資料の使い分けをまとめると、フォームが欲しいなら事例集、非機能要件の点検なら非機能要求グレード、考え方の根拠が欲しいなら要件定義ガイド、となります。

実物を開いたら、どこを見るか——5つの着眼点

数百ページのPDFを手に入れても、最初から順に読む必要はありません。実物から持ち帰るべきものは内容ではなく、記載の水準です。水準は決まった場所に現れます。ここでは見る順に5つの着眼点を挙げます。

着眼点1〜2: 目次の3分割(業務要件・機能要件・非機能要件)と、章の厚みの偏り

公共調達の要件定義書を何本か開くと、大章の並びがほぼ共通していることに気づきます。国土交通省の建設キャリアアップシステム要件定義書も、大章は「1 業務要件の定義」「2 機能要件の定義」「3 非機能要件の定義」の3つだけです。この3分割は、政府の情報システム調達で標準的に用いられている整理です。

自社の文書でも、まずこの3つが立っているかを確認してください。業務要件が薄い文書は、「何のために作るのか」が共有されないまま機能の話に入っている状態です。非機能要件の章がない文書は、性能やセキュリティの水準を暗黙の了解に委ねている状態です。どちらも後で揉めます。

次にページ番号を見ます。建設キャリアアップシステムの例では、業務要件が1〜37ページ、機能要件が38〜347ページ、非機能要件が348〜398ページでした。機能要件が全体の約8割を占めています。一方で非機能要件は、小項目の数こそ多いものの(ユーザビリティ、システム方式、規模、性能、信頼性、拡張性、上位互換性、中立性、継続性、情報セキュリティ、稼働環境、テスト、データ取込み、引継ぎ、教育、運用、保守など)、1項目あたりは数行から1ページ程度です。

ここから持ち帰れるのは、労力の配分です。非機能要件は「項目を漏らさないこと」が勝負であり、1項目を長く書くことではありません。逆に機能要件は、一覧表と個別の記述を積み上げる作業量そのものが必要になります。

着眼点3〜4: 一文に数値と条件が入っているか、別紙をどこで切っているか

次に、非機能要件の章を数ページ拾い読みします。性能に関する記述を探し、応答時間がどう書かれているかを見てください。実物では「レスポンスタイム」「ターンアラウンドタイム」「サーバ処理時間」のように測定対象が分けられ、それぞれに数値と測定条件が添えられています。「快適に動作すること」とは書かれていません。

この一文の形が、そのまま自社の文書の目標になります。何を測るか、どういう条件下で測るか、いくつなら合格か。この3点セットが入っていれば、受け入れテストで合否が判定できます。入っていなければ、判定は読み手の解釈になります。

もう1つ見るのが、別紙の切り方です。実物では「別紙◯参照」という参照が随所に現れます。何が本文に残り、何が別紙に出ているかを観察すると、境界の引き方が分かります。おおむね、判断や方針は本文に、一覧と明細は別紙に、という切り方です。機能一覧・画面一覧・データ項目定義・テーブル定義のように行数が多く更新頻度も高いものは、別紙にしておくと本文の版管理が軽くなります。

自社の文書でも、本文をA4で30ページ以内に収め、明細は別紙に逃がす構成にすると、業務側の責任者が読み切れる文書になります。要件定義書の合格条件は、設計者が判断に迷わないことと、業務側の責任者が読み切れることの両立です。どちらかに寄ると必ず壊れます。

着眼点5: 改訂履歴——いつ何が変わったかが、その文書の運用の実態を示す

最後に改訂履歴です。表紙の裏か1章に、版数・日付・変更内容・変更理由の表があります。ここが1行(初版のみ)で終わっている文書は、作成後に更新されていない可能性があります。逆に複数版にわたって「◯◯の追加に伴い△△を修正」と記録されている文書は、開発中も参照され続けた文書です。

参考にするなら後者を選んでください。改訂されている文書は、実際に使われて指摘を受け、直された履歴を持っています。そして自社の文書を作るときは、最初から改訂履歴の表を用意しておくことです。変更管理の運用そのもの(誰が起票し、誰が承認し、版番号をどう振るか)については「要件定義書 書き方」の記事で扱っています。

5つの着眼点を通じて見ているのは、結局のところ「この文書は判断に使えるか」という一点です。分量は結果でしかありません。

公開サンプルを自社の文書に落とす——そのまま使うと失敗する3つの理由と、削る・足すの判断

実物が手に入ったあと、多くの人がやりたくなるのが「章立てをそのままコピーして埋める」ことです。これは効率が良さそうに見えて、だいたい途中で止まります。止まる理由には共通の構造があります。

そのまま使うと失敗する3つの理由——前提が違う、網羅性が過剰、決めるべき判断が済んでいない

理由1: 前提が違う。 公共調達の要件定義書は、不特定多数の事業者が同じ条件で見積もれるように書かれています。さらに、会計検査や情報公開請求に耐えることも前提です。だから、社内では自明なことまで明文化されます。民間の案件で発注先が1〜3社に絞られているなら、ここまでの網羅は不要です。

理由2: 網羅性が過剰。 398ページの文書を目標にすると、作成に数か月かかります。その間に事業側の前提が変わります。そして完成した文書は、業務側の責任者が読み切れません。読まれない文書は承認されているように見えて合意されていない状態を生み、これが後で追加費用の交渉に化けます。分量をまねると読まれない文書になる、というのが実情です。

理由3: 決めるべき判断が済んでいない。 これが最大の理由です。テンプレートの空欄が半分埋まらないまま相談に来られる方は珍しくありませんが、埋まっていない欄には共通点があります。そこは文章力が足りない欄ではなく、社内でまだ決まっていない事柄の欄なのです。「優先度」が埋まらないのは優先順位を決める会議をしていないから、「対象外」が埋まらないのは何をやらないかを誰も宣言していないから。サンプルを何本集めても、この欄は埋まりません。

規模別に削る——3つの規模で、残す章と落とす章

では、自社の案件ではどこまで書けばよいか。規模別の目安を整理します。ページ数は本文(別紙を除く)の目安です。

削ってよいのは「記述の詳しさ」であって、「観点」ではありません。特に非機能要件は、小規模案件でも6つの観点を一度は全部見てください。見たうえで「対象外」と書くのと、見ずに書かないのとでは、後で問題が起きたときの立場がまったく違います。

優先度の付け方は、必須・推奨・見送りの3段階で足ります。細かい手法を導入するより、「今回のリリースに要るか、要らないか」を全機能について1回言い切るほうが効きます。この優先順位付けの進め方そのものは「要件定義の進め方」の記事で扱っています。

外部委託・オフショアで足す5項目——用語定義、受入基準、連絡と決裁、変更の扱い、成果物の引き渡し

社内で完結する開発と違い、外部に委託する場合は公開サンプルにない項目を足す必要があります。海外のチームが入るなら、なおさらです。当社が発注前の相談で必ず確認しているのは次の5つです。

3番は軽視されがちですが、時差のある体制では効き方が大きく変わります。ベトナムと日本の時差は2時間で、質問への回答が1日遅れると開発は半日以上止まります。「質問は24時間以内に一次回答」と要件定義書の体制の章に書いておくだけで、滞留はかなり減ります。

なお、要件定義書を受けて作る設計以降の文書(基本設計書・テスト仕様書)をオフショアに渡すときの粒度については、「オフショア開発の仕様書の書き方」の記事で扱っています。

削った理由を残す——「対象外」と「未定(いつ決めるか)」を空欄にしない

削る判断をしたら、削ったことを書き残してください。書き方は2種類です。

• 対象外: 検討したうえで、今回はやらないと決めたもの。「◯◯機能は今回の対象外とする(理由: 現行の運用で代替可能なため)」
• 未定: まだ決まっていないもの。「◯◯の保存期間は未定。2026年10月末までに情報システム部が決定する」

重要なのは、未定を空欄にしないことです。空欄は、読む人によって「決まっていない」とも「必要ない」とも解釈されます。未定であることと、いつ誰が決めるかを書けば、それ自体が有効な合意になります。

介護記録SaaS「CareViewer」のように要件が動き続ける案件でも、この書き方で進められます。当社の体制では日本語のブリッジSE1名とフルスタックエンジニア2名を置き、決定事項を毎回文書に落として週次で優先順位を判断しています。全部決めてから始める必要はありません。決まっていないことを、決まっていないと書いて先に進めばよいのです。

記入前チェックリスト10項目——埋める前に社内で決めておくこと

最後に、サンプルを開いて埋め始める前に社内で確認しておく10項目を挙げます。ここが埋まっていれば、文書を書く作業は驚くほど速く進みます。

10項目のうち3つ以上が「決まっていない」なら、サンプルを探すより先に社内の会議を1本入れるほうが早いです。要件定義書が書けないのではなく、決めていないだけ、という状態は本当によくあります。

当社の位置づけ——要件定義書がない状態から発注するとき、どこまで巻き取れるか

ここまで読んで「サンプルを探すより先に、決めることが多すぎる」と感じた方もいると思います。実際そのとおりで、要件定義書がない状態で相談に来られる方は多数派です。当社がその場合に何を引き受け、何を引き受けないのかを書いておきます。

日本人PMが文書化を担う体制と、発注側に残る判断

当社はベトナム・ホーチミンを拠点に、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするラボ型の開発体制を提供しています。体制はパターンA(日本人PMまたはブリッジSE+エンジニア)とパターンB(エンジニアのみ)の2つで、要件定義書がない状態から入るならパターンAを推奨しています。

パターンAで当社が担うのは、打ち合わせの内容を文書に起こす作業と、決めるべき論点を先回りして提示する作業です。前章の10項目のうち、7番(移行)、9番(質問の窓口と回答期限)、10番(変更の手順)は当社側から型を提案できます。一方で、1番(解決したい課題)、3番(やらないこと)、8番(最終承認者)は発注側にしか決められません。ここを代行することはできず、代行しようとすると後で必ず揉めます。

実例として、介護記録SaaS「CareViewer」では日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら進めています。コストは従来の半分以下になり、お客様からは「想像以上にエンジニアのレベルが高い」という評価をいただきました。金融系のマッチングサービスでは、日本人PM1名+フルスタックエンジニア2名で構想段階から伴走しています。

体制は1名から組め、最短2週間で開始できます。増員は約1週間、縮小や交代は1か月単位です。最小構成は日本人PMをフロントに置いて2〜3人月で月額約80万円からが目安です。エンジニアの公開単価は実務3年目安で1,500USD(1USD=150円換算目安で約22.5万円)、5年で2,000USD、10年目安とブリッジSEで3,000USD。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向く案件・向かない案件

正直に書きます。当社が向くのは、作りたいものの輪郭は決まっているが文書になっていない案件、継続的に開発を続ける案件、そして社内に意思決定できる担当者が1名いる案件です。週1回30分の判断ができる方がいれば、要件定義書がない状態から始めても回ります。

向かないのは、社内で何を作るかがまだ割れている案件です。この場合は先に社内の合意形成が必要で、外部の開発会社を入れても時間と費用が増えるだけになります。また、仕様を完全に固めてから一括で発注し、途中で一切変更しない進め方をご希望なら、請負契約を扱う国内のシステム開発会社のほうが合います。当社のラボ型は、変更が前提の案件に向いた形態です。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準運用としており、AI活用開発体制も整えています。

要件定義書のサンプルに関するよくある質問

最後に、公開サンプルを探す過程でよく受ける質問を5つまとめます。引き写しの可否、ファイル形式の選び方、分量の目安、IPAの資料の実態、そして埋めたあとに何が残るか。いずれも記事本文に入れると流れを止めるため、ここにまとめて置きます。

Q1. 公開されている要件定義書を、自社の文書に引き写してよいですか?

章立てや観点の並びを参考にするのは問題ありませんが、本文をそのまま複製するのは避けてください。官公庁の公開資料には各サイトの利用ルールがあり、出典の明示や改変時の表示が求められる場合があります。IPAの資料についても、たとえば非機能要求グレードの利用ガイド[活用編]はクリエイティブ・コモンズ 表示-継承 2.1 日本ライセンスで提供される一方、図表とイラストは同ライセンスの対象外で抽出使用が禁止されています。参考にする資料ごとに、公開元の利用条件を確認してから使ってください。

Q2. ExcelとWordのどちらで作るべきですか?

本文はWord(またはGoogleドキュメント)、明細はExcelという分け方が扱いやすいです。背景・目的・方針のように文章で書く部分はWord、機能一覧・画面一覧・データ項目定義・非機能要件の点検表のように行が増える部分はExcelに置き、本文からは「別紙1参照」と参照します。すべてをExcelの1ブックに詰めると、文章部分がセル内で読みにくくなります。

Q3. 要件定義書は何ページくらいが目安ですか?

案件規模によりますが、ページ数の目安を示した一次資料は見当たりません。公開されている公共調達の要件定義書は数百ページに達することがありますが、これは不特定多数の入札参加者に同じ情報を与えるための分量で、民間案件の目標にはなりません。判断基準は分量ではなく、業務側の責任者が通しで読み切れるかどうかです。

Q4. IPAに「完成した要件定義書のサンプル」はありますか?

1本の完成文書としては公開されていません。IPAが公開しているのは、ドキュメント単位のサンプルとフォーム(超上流から攻めるIT化の事例集：要件定義)、非機能要件の観点リスト(非機能要求グレード2018)、発注側向けのガイド(ユーザのための要件定義ガイド 第2版)の3種類です。完成した文書を通しで読みたい場合は、国や自治体が調達時に公開した要件定義書を探してください。

Q5. サンプルを全部埋めれば、そのまま発注できますか?

埋まった文書があっても、発注前に確認すべきことは残ります。見積もりの前提が要件定義書のどの版に紐づくか、変更が出たときの追加費用の扱いをどうするか、受入基準を誰がいつ判定するか。この3点は文書の外で合意する事項です。追加費用の線引きについては「仕様変更の追加費用」の記事を参照してください。埋めることと決めることは別作業、という認識が出発点。

まとめ: サンプルは写す手本ではなく、自社の文書を採点する物差し

要件定義書の実物は公開されています。国や自治体が調達のときに添付した要件定義書と、IPAがドキュメント単位で公開しているサンプル・観点リスト・ガイド。この2系統を押さえれば、PDFで通し読みしたい人も、Excelで編集したい人も目的の物に届きます。テンプレート配布サイトを何件も回る必要はありません。ただし調達ページは案件終了で消えるため、個別のリンクではなく調達ポータルやIPAのアーカイブという消えない入口を覚えておいてください。

手に入れた実物は、目次の3分割、章の厚みの偏り、一文に入った数値と条件、別紙の切り方、改訂履歴の5点だけ見れば足ります。そのうえで自社の規模に合わせて記述を削り、外部に委託するなら用語定義・受入基準・連絡と決裁・変更の扱い・成果物の引き渡しの5項目を足す。削ったところには「対象外」と理由を、決まっていないところには「未定、いつ誰が決めるか」を書き残す。空欄のまま残さないことが、後から効いてきます。

そして、埋まらない欄があったときは文書の問題を疑う前に、社内で決まっているかどうかを確かめてください。記入前チェックリストの10項目のうち3つ以上が未決なら、サンプルを探すより会議を1本入れるほうが速い。要件定義書は決めたことを書く場所であって、決めるための場所ではありません。文書の章立てと各章の書き方を知りたい方は要件定義書の書き方を、工程としての位置づけから確認したい方は要件定義とはを続けてお読みください。

現在の体制と要件をお聞かせいただければ、想定される体制と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。