要件定義書の書き方が分からない発注者向けテンプレ｜項目立てと記入例 2026

先日、ある店舗オーナーさんから相談を受けました。「予約システムを外注したのに、完成したものが欲しかった機能と全然違う」と。話を聞くと、依頼時に渡した資料はA4一枚の箇条書きだけ。要件定義書と呼べる代物ではありませんでした。結論から言うと、要件定義書 書き方 テンプレを事前に押さえておくかどうかで、外注の成否は8割決まります。つまり、発注前の準備が甘いと、開発会社が悪いわけでもないのに「イメージと違う」トラブルが起きるということです。この記事では、非エンジニアの発注者でも迷わず作れる要件定義書のテンプレと、項目ごとの記入例を具体的に解説します。

要件定義書とは何か。発注者が知っておくべき位置づけ

要件定義書とは、システムやWebサイトの開発を発注する際に「何を」「なぜ」「どこまで」作ってほしいかを整理した文書です。混同されやすい言葉に企画書やRFP（提案依頼書）がありますが、役割は異なります。企画書は事業としての狙いを示すもので、RFPは複数の開発会社に提案を募るための比較検討資料です。要件定義書はその一歩先、実際に依頼する開発会社と「これを作る」という合意を取るための実務文書に当たります。

これ、知らない人が本当に多いんです。多くの発注者は「開発会社にお任せすれば、うまく汲み取ってくれるだろう」と考えがちです。しかし開発会社は魔法使いではありません。渡された情報を文字通りに受け取り、そこに書かれていないことは実装しません。つまり、要件定義書に書かれていない機能は「存在しないもの」として扱われるということです。ここを誤解したまま発注すると、納品後に「これも当然入っていると思っていた」というすれ違いが必ず起きます。

要件定義書を作る目的は大きく3つあります。1つ目は開発会社との認識のズレを防ぐこと。2つ目は見積もり金額の根拠を明確にすること。3つ目はトラブルが起きた際の判断基準にすることです。特に3つ目は見落とされがちですが、契約書と並んで「言った言わない」を防ぐ最重要の証拠になります。行政書士として契約トラブルの相談を受ける中で、要件定義書がしっかり作られていた案件は、揉めても解決が早い傾向があります。逆に要件定義書が曖昧だった案件は、責任の所在があいまいになり、長期化しやすいというのが現場の実感です。

要件定義書 書き方 テンプレを探す前に知っておきたい市場の現状

外注市場全体を見ると、システム開発やWeb制作の発注件数はここ数年で着実に増えています。中小企業庁の調査でも、中小企業のIT投資意欲は高まり続けている傾向が示されています。

中小企業においても、デジタル技術を活用した経営課題の解決に向けた取組が広がりつつある。 出典: chusho.meti.go.jp

一方で、発注側の準備不足によるトラブルも比例して増えています。特に多いのが「要件定義書を作らずに発注してしまう」ケースです。予算が限られている個人事業主や中小企業ほど、要件定義に時間をかけず、口頭やチャットのやり取りだけで発注してしまう傾向があります。これは非常にもったいない選択です。要件定義にかける時間は、開発期間全体の10%から20%程度が目安とされますが、この工程を省くと、後工程での手戻り（仕様変更・作り直し）に何倍もの時間とコストがかかることになります。

費用相場の面でも、要件定義書の有無は見積もり金額に直結します。要件が曖昧なまま見積もりを依頼すると、開発会社はリスクを織り込んで高めの金額を提示せざるを得ません。逆に要件定義書がしっかりしていれば、開発会社は無駄なバッファを積む必要がなくなり、結果的に見積もりが適正化されやすくなります。私が見てきた案件では、要件定義書の完成度によって最終的な見積もり金額に2割から3割程度の差が出ることも珍しくありませんでした。

要件定義書に書くべき7つの基本項目

非エンジニアの発注者が要件定義書を作る際、専門的な図解や技術用語をすべて理解する必要はありません。まずは以下の7つの項目を埋めることから始めてください。

1. 目的・背景

なぜこのシステムやサイトが必要なのかを書きます。「売上を伸ばしたい」だけでは弱く、「電話予約の対応にかかる週15時間の工数を削減し、予約の取りこぼしをなくしたい」のように、現状の課題と数値を具体的に書くことが重要です。目的が明確であるほど、開発会社は「本当に必要な機能」を提案しやすくなります。

2. 現状の業務フロー

今、どのような流れで業務が回っているかを書きます。図解できなくても構いません。「電話で予約を受ける、紙の台帳に記入する、スタッフ間でチャットで共有する」のように、時系列で箇条書きにするだけで十分です。開発会社はこのフローを見て、どこを自動化・効率化できるかを判断します。

3. 実現したいこと（機能要件）

システムに「してほしいこと」を機能単位で書きます。「予約をWebで受け付けたい」「予約状況をリアルタイムで確認したい」「予約確定メールを自動送信したい」のように、一文一機能で箇条書きにします。抽象的な表現ではなく、できるだけ具体的な動作で書くことがポイントです。

4. 利用者・利用シーン

誰が、いつ、どのように使うかを書きます。「顧客がスマートフォンから予約する」「店舗スタッフがタブレットで予約状況を確認する」のように、利用者ごとの使い方を分けて書くと、画面設計の精度が上がります。

5. 予算・納期の希望

正直に希望予算と納期を伝えます。「予算を伝えると高く見積もられるのでは」と隠す発注者もいますが、これは逆効果です。予算を伝えないと、開発会社は要望のすべてを盛り込んだ最大構成で見積もりを出さざるを得ず、結果的に予算オーバーになりやすくなります。範囲で構わないので、目安を必ず伝えてください。

6. 対応してほしくない範囲（スコープ外）

「これはやらなくていい」という範囲を明記することも重要です。例えば「決済機能は今回のスコープに含めない」「多言語対応は将来のフェーズで検討する」のように書くことで、見積もりの範囲が明確になり、追加費用の発生を防げます。

7. 参考にしたいサービス・サイト

イメージに近い既存のサービスやサイトのURLを2から3件挙げます。「このサイトの予約フォームのような操作感にしたい」と具体例を示すことで、言葉だけでは伝わりにくいニュアンスを補完できます。

記入例。予約システム導入案件で見る具体的な書き方

実際にどう書けばよいか、架空の店舗オーナーが予約システムを導入するケースで見てみましょう。

目的・背景の記入例としては「現在、電話予約の対応に週15時間かかっている。この工数を3時間以下に削減し、予約の取りこぼしをゼロにしたい」と書きます。現状の業務フローは「電話で予約を受ける、紙の台帳に記入する、当日は台帳を見ながら対応する」という3ステップを書きます。実現したいことは「顧客がWebから24時間予約できる」「予約が入ったらスタッフにメールで通知される」「予約のキャンセル・変更もWebで完結する」という具合に一つずつ列挙します。

このように具体的な数字と動作で書くと、開発会社は迷わず見積もりを出せます。曖昧な依頼と具体的な依頼とでは、見積もり作成にかかる往復の質問の回数が全く違います。開発会社が「わかりやすい」と感じる要件定義書は、決して専門用語が並んだ難しい文書ではなく、5W1H（誰が、いつ、どこで、何を、なぜ、どのように）が明確に書かれた文書です。

要件定義書でよくある失敗は、「わかりやすい画面にしてほしい」「使いやすくしてほしい」といった曖昧な表現です。開発会社は言葉を文字通りに受け取るため、「わかりやすい」の基準が発注者と異なると、完成後に「こんなはずじゃなかった」という事態になります。 出典: syusodo.co.jp

このコツはそのまま7項目すべてに応用できます。「かっこいいデザイン」ではなく「参考サイトのようなシンプルな配色で、写真を大きく見せるレイアウト」。「使いやすいシステム」ではなく「スタッフが1画面で当日の予約一覧を確認できる」。こうした言い換えを意識するだけで、要件定義書の質は大きく変わります。

要件定義書の書き方でよくある3つの失敗

失敗1：曖昧な表現のまま提出してしまう

先ほど触れた通り、「使いやすく」「おしゃれに」「今どき風に」といった主観的な表現は、開発会社によって解釈が分かれます。曖昧な表現を見つけたら、必ず「誰が」「何を」「どのように」の3点セットに分解してください。分解できない要望は、まだ自分の中でも整理できていない証拠です。

失敗2：スコープを決めずに発注してしまう

「とりあえず作りながら決めていきましょう」というスタンスで発注すると、開発の途中で要望が次々と追加され、いわゆるスコープの肥大化が発生します。追加要望のたびに見積もりが膨らみ、当初の予算を大きく超えることになりかねません。スコープ外の項目をあらかじめ明記しておくことで、追加費用が発生する条件を事前に合意できます。

失敗3：完成後の運用・保守を考えずに要件を固めてしまう

システムは納品して終わりではありません。稼働後にデータをどう管理するか、不具合が出たときの対応窓口はどこか、機能追加が必要になったときの費用感はどうかといった、運用フェーズの取り決めを要件定義書に含めない発注者が非常に多いです。私が相談を受けた案件でも、納品後の保守費用について事前の合意がなく、想定外の月額費用を請求されてトラブルになったケースがありました。運用・保守の項目は7つの基本項目に追加して書いておくことを強くおすすめします。

私自身、初めて外注を依頼したときに苦い経験をしました。行政書士事務所のホームページ制作を依頼した際、複数社から見積もりを取ったのですが、金額の安さだけで比較して発注先を決めてしまったのです。結果、要件定義書を作る工程そのものを省略され、口頭の打ち合わせだけで進んだ案件は、完成後に「問い合わせフォームの必須項目が思っていたものと違う」という食い違いが発生しました。安さだけで選ぶのではなく、要件定義をきちんと一緒に詰めてくれる開発会社かどうかを見極めることの大切さを痛感した出来事です。

費用相場と依頼先の選び方。仲介と直接依頼の違い

要件定義書の作成そのものを開発会社に依頼する場合、費用相場は案件の規模によって幅があります。小規模なWebサイト制作であれば数万円から、業務システムのような複雑な案件では数十万円になることもあります。ここで発注者が押さえておきたいのが、依頼先の選び方によってコスト構造が大きく変わるという点です。

制作会社や開発会社の中には、実際の開発作業を自社のフリーランスエンジニアや外部パートナーに再委託している会社が少なくありません。この場合、発注者が支払う金額には、間に入る会社の仲介手数料が上乗せされています。仲介手数料の相場は案件の20%から30%程度に及ぶこともあり、同じ品質の成果物でも、依頼するルートによって最終的な支払額が変わってくるのです。

一方、フリーランスのエンジニアやデザイナーに直接依頼する場合は、この中間マージンが発生しません。手数料0%で直接やり取りできる仕組みを使えば、同じ予算でより手厚い開発時間を確保できる、あるいは同じ品質をより抑えた予算で実現できるという構造上のメリットがあります。もちろん、直接依頼の場合は発注者自身が要件定義の質を高め、進行管理も主体的に行う必要が出てきますが、要件定義書さえしっかり準備できていれば、その負担は大きく軽減されます。

依頼先を選ぶ際にチェックすべきポイントは、過去の制作実績が自社の業種・規模に近いか、要件定義の段階からヒアリングを丁寧に行ってくれるか、見積もりの内訳が明確に提示されるかの3点です。特に見積もりの内訳が「一式〇〇円」としか書かれていない場合は要注意です。要件定義書の作成費用、設計費用、開発費用、テスト費用がそれぞれいくらなのかを分けて提示してくれる相手を選ぶことで、後から「この作業は含まれていなかった」という追加請求のトラブルを防げます。

外注先を探す際は、実際にどのようなスキルを持つ人材がいるかを知っておくことも判断材料になります。ソフトウェア作成者の年収・単価相場では、エンジニアの相場観を把握できるため、見積もり金額が適正かどうかの目安として参考になります。要件定義書自体の作成支援や、開発全体のディレクションを依頼したい場合は、アプリケーション開発のお仕事で、どのような業務範囲を任せられるかの具体例を確認しておくとイメージが掴みやすくなります。

要件定義から開発完了までの進め方（ステップ）

要件定義書を作った後、実際にどのような流れで開発が進むのかを把握しておくと、発注者としての心構えができます。

まず要件定義書をもとに開発会社と1回から2回のすり合わせミーティングを行います。ここで解釈のズレがないかを確認し、必要であれば要件定義書を修正します。次に開発会社から正式な見積もりと概算スケジュールが提示されます。この段階で契約書を締結し、着手金を支払うのが一般的な流れです。

契約後は、要件定義書をもとに開発会社側が詳細設計書や画面設計書を作成します。発注者はこの設計書の内容を確認し、実際の画面イメージと要件定義書の内容が一致しているかをチェックする役割を担います。ここで見落としが多いのが「確認するだけで、修正の意見を出さない」という受け身の姿勢です。設計段階での修正は軽微な手戻りで済みますが、開発が進んでからの修正は工数もコストも跳ね上がります。設計書のレビューには必ず時間を確保し、疑問点はその場で解消してください。

開発が完了すると、テスト段階に入ります。ここで要件定義書に書いた機能がすべて実装されているかを、発注者自身の目で確認する検収作業が行われます。要件定義書が具体的に書かれていればいるほど、この検収作業はスムーズに進みます。逆に要件定義書が曖昧だと、「これは仕様通りか、それとも不具合か」の判断が難しくなり、検収が長引く原因になります。

契約に関わる部分では、フリーランス保護新法の施行以降、発注者には受領日から60日以内に報酬を支払う義務が明確に定められています。要件定義書と成果物の対応関係が明確であれば、検収の合否判断もスムーズになり、結果として支払いの遅延を防ぐことにもつながります。つまり、要件定義書をしっかり作ることは、発注者自身を契約トラブルから守る盾にもなるということです。

要件定義書テンプレの実践的な使い方

ここまで紹介した7つの項目は、そのままExcelやWord、あるいはGoogleドキュメントの見出しとして使えます。実務上は、各項目を見出しにして、その下に箇条書きで内容を埋めていくシンプルな形式で十分です。凝ったフォーマットや図解ソフトを用意する必要はありません。

テンプレートを使う際のコツは、最初から完璧を目指さないことです。まずは分かる範囲で7項目をラフに埋め、それを開発会社に見せて「ここは書き方が分かりにくいので教えてほしい」と相談することをおすすめします。多くの開発会社は、要件定義書の作成段階から丁寧に伴走してくれます。むしろ、要件定義の段階でどれだけ質問を投げかけてくれるかは、その開発会社の力量を見極める良い判断材料にもなります。逆に「とりあえず要件定義書を出してください、それを見て見積もりします」としか言わない相手には注意が必要です。要件定義は発注者と開発会社の共同作業であるべきで、一方通行の作業ではありません。

なお、要件定義書を書く際に自社にIT担当者がいない場合は、外部のITコンサルタントに要件定義の整理だけを依頼するという選択肢もあります。AIコンサル・業務活用支援のお仕事では、業務課題を整理してシステム化の要件に落とし込む支援を行う人材の探し方を確認できます。また、要件定義書と合わせて業務の全体設計や補助金申請を考えている場合は、フリーランスの事業計画書の書き方｜融資・補助金申請で使えるテンプレートも、数値目標の立て方という点で参考になる部分があります。

運営者の一次観察。要件定義書の質が信頼関係を左右する

フリーランス・在宅ワーク市場を長く見てきた立場から言えば、要件定義書をきちんと作れる発注者ほど、開発会社やフリーランスとの関係が長続きする傾向があります。これは単に「良い文書を作れるから」ではありません。要件定義書を丁寧に作るプロセスそのものが、相手に対する敬意の表れとして伝わるからです。曖昧な指示を投げて「あとはうまくやってください」という発注者と、自分の考えを整理して具体的に伝えようとする発注者とでは、受け手側のモチベーションも仕事の質も変わってきます。

もう一つ、運営者として見てきた実感があります。中間マージンが乗らない直接取引は、単に「安く済む」という話にとどまりません。同じ予算であれば発注者はより多くの作業時間や修正回数を依頼でき、受け手であるフリーランス側は同じ作業でも手取りが厚くなります。この双方が得をする構造は、額面の安さだけでなく、発注者と受注者がより深く対話する時間的な余裕を生み出します。要件定義の段階でじっくりすり合わせができる関係性こそが、結果的にトラブルのない発注につながっているというのが、長年この市場を見てきた実感です。

よくある質問

Q. 要件定義書はどのくらいの分量で書けばいいですか？

案件の規模によりますが、小規模なWebサイトであればA4で2〜3枚程度、業務システムであれば5〜10枚程度が目安です。分量よりも、7つの基本項目が具体的に埋まっているかどうかを優先してください。

Q. 要件定義書を作らずに発注するとどんなリスクがありますか？

開発会社との認識のズレが起きやすくなり、完成後に「イメージと違う」というトラブルに発展しやすくなります。見積もりもリスクを見込んで高めになりがちで、結果的にコストと時間の両方を損する可能性があります。

Q. 要件定義書の作成自体を外注してもいいのですか？

問題ありません。ITコンサルタントや上流工程の経験があるフリーランスに、要件定義の整理だけを依頼することも可能です。自社に知見がない場合は、この段階から専門家に伴走してもらう方が結果的にスムーズに進みます。

Q. 途中で要件定義書の内容を変更したい場合はどうすればいいですか？

変更は珍しいことではありませんが、必ず開発会社に速やかに共有し、見積もりや納期への影響を確認してください。変更内容を口頭だけで済ませず、書面やチャットの記録として残しておくことがトラブル防止につながります。

無料で案件を掲載する

入力は3分ほど。掲載料も取引手数料も0円です。@SOHOに登録しているフリーランス・副業ワーカーから、早ければ当日中に最初の応募が届きます。