要件定義書テンプレート＆サンプル記入例｜業務システムの書き方・費用相場・失敗回避【2026年版】

この記事の結論を先に述べる。 業務システム開発が「思っていたものと違う」「追加費用で予算が倍になった」で終わる最大の原因は、開発会社の技術力でも価格でもなく、発注者側の要件定義が曖昧なまま契約に進んだことにある。IPA（情報処理推進機構）は「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年、498ページ）で、要件定義を「システム開発の成否を左右する上流工程」と位置づけ、業務部門のユーザが主体的に関与すべきだと繰り返し説いている。つまり要件定義書は、外注先に書いてもらう書類ではなく、発注者が「何を作りたいか」の責任を負うオーナー文書だ。

とはいえ、多くの中小企業には情シス部門がなく、「完成形のサンプルを見たことがないので、どこまで書けばいいのかわからない」という担当者がほとんどだろう。そこで本記事では、(1) すぐ使える要件定義書テンプレート（全11セクション）、(2) 受発注管理システムを題材にした1本通しの完成形サンプル記入例、(3) 各セクションの書き方、(4) 見積もりとの突き合わせ方、(5) 発注者が陥る失敗パターンと着手前チェックリスト——を、非ITの経営者・実務決裁者の目線でまとめた。サンプルと同じ構成の受発注システム移行 要件定義テンプレート（Excel/PDF・無料）も用意しているので、読みながら手を動かしたい方はそちらも使ってほしい。

---

この記事を読むべき人

• 社内にIT判断力のある人がおらず、業務部門の担当者が初めて要件定義に取り組む中小企業の経営者・実務責任者
• Excelと紙の業務をシステム化したいが、「どこまで自分で書けば開発会社に相談できるのか」がわからない人
• 複数の開発会社から見積もりを取ったが、金額がバラバラで比較できず、どれが妥当か判断できない人
• 過去にPoC止まりや開発頓挫を経験し、「今度こそ失敗したくない」と考えている人
• 「要件定義はベンダーに任せればいい」と思っているが、それで本当に大丈夫か不安な人

いずれかに当てはまるなら、テンプレートを埋める前に、まず本記事の「失敗パターン」と「着手前チェックリスト」から読んでほしい。書き方の技術よりも、書く前の整理不足でつまずく人が圧倒的に多いからだ。

---

目次

1. 要件定義書とは何か——目的と、発注者が負う責任
2. 要件定義書テンプレート——全体構成（全11セクション）
3. 要件定義書サンプル（受発注管理システムの完成例）
4. 各セクションの書き方——記入のコツ
5. 要件定義書と見積もりの突き合わせ方——第三者検証の観点
6. 失敗する要件定義の6つの特徴
7. 自作すべき範囲と、開発会社に任せてよい範囲の線引き
8. 着手前チェックリストとGXOに相談すべきタイミング
9. FAQ（よくある質問）

---

要件定義書とは何か——目的と、発注者が負う責任

要件定義書は「何を作るか」の合意書

要件定義書は、「何を作るか」を発注者と開発会社の間で合意するための文書だ。口頭の打ち合わせだけでは「言った・言わない」が起き、完成したシステムが「思っていたものと違う」という事態を招く。文書化することで得られる効果は次の4点に集約できる。

• 認識の齟齬を防ぐ：発注者と開発会社が同じ「完成イメージ」を共有できる
• 見積もりの精度が上がる：開発会社が正確な工数を積算でき、予算超過リスクが減る
• スコープを管理できる：「ここまでが今回の範囲」を明確にし、際限のない機能追加を防ぐ
• 検収の基準になる：納品物が要件を満たしているかを客観的に判定できる

要件定義書の位置づけ

システム開発全体の中で、要件定義書は次の位置にある。ここで手を抜くと、下流の設計・開発・テストすべてがブレる。

誰が書くのか——「発注者がオーナー」という原則

作成の主体は発注者側だ。ただし単独で書き切る必要はなく、開発会社のヒアリングを受けながら共同で作るのが一般的である。IPAの前掲ガイドも、ITベンダやシステム部門任せにせず、業務部門のユーザが主体的に関与するスタイルへの変革を促している。「発注者が要件のオーナーである」という原則は公的ガイドラインと一致している、とここでは押さえておけばよい。この一点を誤解して「要件定義もひっくるめて業者に丸投げ」にした瞬間、追加費用と手戻りの引き金を自ら引くことになる（この線引きは本記事後半で詳述する）。

なお、IPAの資料は現在アーカイブ扱いだが、PDFは引き続きダウンロード可能で、要件定義の観点整理として参照価値は失われていない。二次的な解説記事ではなく、まず一次資料に当たれるのがこのガイドの強みだ。

---

要件定義書テンプレート——全体構成（全11セクション）

以下が業務システムの要件定義書の推奨構成だ。プロジェクト規模に応じてセクションを取捨選択してよいが、1〜5は必須と考えてほしい。競合の解説記事の多くは10章前後の項目名を並べて終わるが、重要なのは「どのセクションが見積もりを左右するか」を知ることだ。見積もりが膨らむのは、ほぼ例外なく機能要件（4）と非機能要件（5）、そして前提・制約（11）である。

ExcelとWord、どちらで作るべきか

「要件定義 テンプレート excel」で検索する人が多いように、実務ではExcelが主流だ。理由は明快で、機能要件一覧・非機能要件一覧・業務フロー表がいずれも「行を足していく表形式」だからである。IDでの管理、優先度でのフィルタ、開発会社との差分レビューのしやすさを考えると、少なくとも一覧系はExcel（またはスプレッドシート）が合理的だ。

一方、プロジェクト概要や背景・目的のような「文章で語るセクション」はWordや社内Wikiのほうが書きやすい。中小規模なら「概要はシート1枚目に文章で、要件一覧は2枚目以降に表で」という1ブック完結のExcel構成で十分に機能する。体裁はどうでもよく、後述する「含まないもの」「優先度」「数値」の3点が入っているかがはるかに重要だ。

---

要件定義書サンプル（受発注管理システムの完成例）

ここからは断片的な記入例ではなく、1本の要件定義書として通して読めるサンプルを示す。題材は「Excelと紙で回している受発注管理をシステム化する」という、中堅・中小企業で最も相談の多いケースだ。概要 → As-Is → To-Be → 機能要件 → 非機能要件 → 前提・制約という流れで、そのまま自社の内容に置き換えられる粒度で書いている。

サンプル1. プロジェクト概要

プロジェクト名: 受発注管理システム構築プロジェクト

背景:

当社の受発注管理は現在、Excelと紙の注文書で運用している。月間の受注件数が約500件に増加し、(1)入力ミスによる誤出荷が月平均8件発生、(2)月末の集計作業に3営業日を要する、(3)在庫状況のリアルタイム把握ができない——という課題が深刻化している。

目的:

受発注管理のデジタル化により、入力ミスを月1件以下に削減、月末集計を当日中に完了、在庫のリアルタイム可視化を実現する。

スコープ（対象範囲）:

このサンプルのポイントは、背景に「月8件」「3営業日」という実測値が入っていることと、「対象に含まないもの」が明記されていることだ。この2点があるだけで、開発会社の見積精度と提案の質は大きく変わる。

サンプル2. 現状の業務フロー（As-Is）

完璧なフローチャートである必要はない。この表のように「作業・担当・ツール・時間・課題」の5列が埋まっていれば、開発会社は現状を正確に理解できる。

サンプル3. あるべき業務フロー（To-Be）

As-Isの行番号とTo-Beの行番号を対応させて書くと、「どの作業がどう変わるのか」が一目でわかり、現場担当者のレビューも受けやすい。

サンプル4. 機能要件一覧

IDを振ること、優先度を「必須／希望」で分けることが実務上の肝だ。IDがあれば見積書・設計書・テスト仕様書がすべてこの番号で追跡でき、優先度があれば予算超過時に「F-009とF-011をPhase 2に回す」という調整が感情論にならずに済む。

サンプル5. 非機能要件一覧

数値で書けない非機能要件は要件として機能しない。「速く」「安全に」ではなく「3秒以内」「TLS 1.2以上」と書くから、検収時に満たした・満たさないを判定できる。非機能要件をゼロから発想するのは難しいので、IPAが公開する非機能要求グレードなど上流工程強化の関連資料を観点リストとして使い、抜け漏れをつぶすのが定石だ。

サンプル6. 前提条件・制約事項

前提・制約は「開発会社への公平な情報開示」だ。予算上限や社内体制の弱さを隠して提案を募ると、契約後にそのギャップが追加費用や遅延として跳ね返ってくる。特に法規制の項目は、多くの中小業務システムで見落とされる。電子帳簿保存法（電子取引データの保存義務）やインボイス制度に対応した帳票・データ保存が要件から抜けていると、稼働後に「改修して」となり、そこで初めて追加費用が発生する。制度要件は自社の顧問税理士にも確認し、要件定義の段階で明文化しておくべきだ。

このサンプルをそのまま使いたい方へ

上記サンプル1〜6と同じ構成のExcelテンプレートを、受発注システム移行 要件定義テンプレート（無料ダウンロード）として公開している。受発注以外の業務システム（勤怠、販売管理、生産管理、顧客管理など）でも、表の中身を差し替えるだけで流用できる構成なので、まずダウンロードして自社の言葉に置き換えることから始めてほしい。

---

各セクションの書き方——記入のコツ

完成形サンプルを見たうえで、各セクションを「自社の内容で」書くときのコツを整理する。書く順番は、テンプレートの並び順（概要→As-Is→To-Be→機能→非機能）どおりに進めるのが最も手戻りが少ない。As-Isを飛ばして機能要件から書き始めると、「なぜその機能が要るのか」を後から遡って説明できなくなるからだ。

プロジェクト概要の書き方。 概要は1〜2ページに収める。書くべきは「背景（いま何に困っているか）」「目的（数値目標）」「スコープ（含む・含まない）」の3点だ。背景には必ず実測値を入れる。「ミスが多い」ではなく「誤出荷が月平均8件」と書く。実測値が手元にないなら、1〜2週間だけ現場に記録を取ってもらってから書き始めても遅くない。その数字が、後の投資判断と効果測定の基準線になる。

As-Is/To-Beの書き方。 As-Isは「悪口大会」にならないよう、事実（作業・担当・時間）と課題を分けて書く。現場ヒアリングでは「例外処理」を必ず拾うこと。月500件のうち480件が通る正常ルートより、残り20件の「電話で来る特急注文」「手書きFAXの判読」のような例外こそが、システム化の難所であり見積が膨らむ源泉だ。To-Beは理想論ではなく、「システムが自動でやること」と「人が引き続きやること」の境界線を明示する。

機能要件の書き方。 1機能1行で、「誰が・何を・どうする」が読み取れる粒度まで分解する。「受発注管理機能一式」のような書き方は、開発会社ごとに解釈が変わり、見積の比較可能性を壊す。逆に、画面項目レベルまで細かく書き込む必要はない——それは基本設計の仕事だ。要件定義の段階では「機能の存在と目的」が合意できていればよい。

非機能要件の書き方。 すべての項目を厳しく設定する必要はない。要求水準を上げるほど費用は上がるので、「業務が止まったら何が起きるか」から逆算して、本当に必要な水準を選ぶ。稼働率を99.5%から99.9%へ上げるだけで冗長構成のコストが跳ね上がることは珍しくない。過剰品質は、機能不足と同じくらい予算を壊す。

セクション6〜11の書き方のポイント

---

要件定義書と見積もりの突き合わせ方——第三者検証の観点

ここが、テンプレートを配って終わる競合記事が踏み込めていない部分だ。要件定義書は「書いて満足」する書類ではなく、見積もりを横並びで比較し、追加費用の芽を事前につぶすための道具である。要件定義書と見積書はセットで初めて精度が決まる。片方だけで走らないことが、予算を守る最大のコツだ。

相見積を「同じ土俵」に乗せる

要件定義書がないまま複数社に見積を依頼すると、各社が勝手に前提を置くため、金額を比較しても意味がない。A社は在庫連携込み、B社は別途、C社はそもそも聞いていない——という状態で「B社が一番安い」と決めると、契約後に地獄を見る。同じ要件定義書を全社に渡し、機能ID（F-001…）単位で見積を出してもらうことで、初めて横並び比較が成立する。

見積書のどこを疑うか

とりわけ「〇〇一式」という表記と、データ移行費用の過少計上は、後から追加費用に化けやすい二大ポイントだ。移行は「古いExcelをそのまま新システムに入れられる」と誤解されがちだが、実際にはデータの名寄せ・クレンジング・テストで工数が膨らむ。見積段階で「移行対象データの件数・形式・想定エラー率」を要件定義書に書いておくと、各社の見積の甘さ・厳しさが浮かび上がる。

見積の妥当性を自分では判断しきれない場合、すでに開発会社から見積を受け取っている段階でも、第三者にレビューを依頼できる。GXOではシステム開発・AI開発の見積レビュー相談（セカンドオピニオン）で、スコープ・隠れコスト・リスク要因を30分で確認する窓口を用意している。

AIツールで要件定義書を書いてよいか（2026年の論点）

ChatGPTなどの生成AIに「要件定義書を作って」と投げれば、それらしい雛形は出てくる。だが業務の実測値（月8件の誤出荷、月末3日の集計）も、自社固有の例外処理も、AIは知らない。AIが得意なのは、こちらが埋めた事実を整った文章に清書することであり、要件そのものを発明することではない。AIに丸投げした要件定義書は、一般論の項目が並ぶだけで、見積もりの精度を上げる情報が入っていない。使うなら「観点の抜け漏れチェック」「文章の清書」に限定し、事実の中身は必ず自社で埋めること。ここを取り違えると、見た目は立派で中身が空の要件定義書が量産される。

---

失敗する要件定義の6つの特徴

特徴1：「何を」は書いてあるが「なぜ」がない

機能の一覧は揃っているが、各機能が必要な理由（ビジネス上の課題）が書かれていない。開発会社は「なぜ」がわからないと、最適な実装方法を提案できない。

• NG:「在庫アラート機能を実装する」
• OK:「在庫が発注点を下回った場合にアラートを出す。現状、欠品に気づくのが出荷直前であり、月3件の納期遅延が発生している」

特徴2：スコープが曖昧

「対象に含むもの」だけで「対象に含まないもの」が明記されていない。進行中に「これも入ると思っていた」「いや、スコープ外です」の議論が頻発し、信頼関係が壊れ、追加費用の火種になる。

特徴3：非機能要件がゼロ

機能要件は書かれているが、性能・セキュリティ・可用性の記載がない。結果、開発会社は「最低限のスペック」で実装し、本番で「遅い」「落ちる」「セキュリティが甘い」が発覚する。逆に非機能を盛りすぎて予算を壊すのも失敗だ。要る水準を要る分だけ、が原則。

特徴4：理想ばかりで優先順位がない

「あれもこれも」を盛り込んだ結果、全機能が「必須」になっている。予算・スケジュールの制約がある以上、優先順位づけは不可避だ。「必須」「希望」「将来検討」の3段階で分類する。

特徴5：現場の声が反映されていない

経営層やIT担当だけで要件定義を行い、実際に使う現場担当の意見が入っていない。結果、「現場の実態に合わないシステム」が出来上がり、使われなくなる。

特徴6：法規制・データ移行を「後で考える」にしている

電子帳簿保存法・インボイス制度・個人情報保護といった制度要件と、既存データの移行を「稼働前に何とかなる」と後回しにする。この2つは、後で発覚するほど手戻りコストが跳ね上がる領域だ。要件定義の時点で制約として書き切っておくこと。

関連記事: 要件定義書ができた後の開発会社選定で迷っている方は「システム開発会社の選び方実務ガイド｜比較チェックリスト付き」も参考にしてほしい。

---

自作すべき範囲と、開発会社に任せてよい範囲の線引き

「要件定義は発注者がオーナー」と言っても、非ITの中小企業がすべてを一人で書き切るのは現実的ではない。ここで多くの記事が沈黙するが、実務で必要なのは責任の線引きだ。次の表を、発注前の自己点検に使ってほしい。

原則はシンプルだ。「What（何を・なぜ）は発注者、How（どう作るか）は開発会社」。ここを逆にして、Whatを業者に決めさせると、「業者が作りたいもの・売りたいもの」が要件になってしまう。逆に、Howまで素人が細かく指定すると、開発会社の技術的な最適化を縛り、かえって高くつく。この線引きが自分たちだけでは引けない、あるいはWhatを言語化する自信がない——という段階こそ、外部の伴走を検討すべきタイミングだ。

GXOでは、この「発注前の要件整理」を支援する窓口としてシステム開発の要件整理・費用相談を用意している。要件定義書を書く前の、課題と論点の整理から入るサービスなので、白紙の状態で相談してもらって構わない。DX全体の進め方や既存システムの刷新まで視野に入るなら、DXシステム開発の進め方・要件定義の相談も合わせて見てほしい。要件定義にAI活用の可否を織り込みたい場合は、AI開発の見積もりとAI導入可否アセスメントで「そもそも使えるか」を30分で見極めるところから始められる。

---

着手前チェックリストとGXOに相談すべきタイミング

テンプレートとサンプルが手元にあっても、いきなり書き始めると途中で必ず手が止まる。経験上、止まる原因は文書力ではなく「書く前の整理不足」だ。着手前に以下を確認してほしい。

着手前チェックリスト

• 現在の業務で使っているExcel・紙帳票・SaaS・手作業の依存関係を棚卸ししたか
• 課題を「売上機会の損失」「工数」「ミス・リスク」のどれかに分解し、実測値を取ったか
• 正常ルートだけでなく、例外処理・承認・差し戻しの流れを現場に確認したか
• 予算の上限と、保守・運用・教育まで含めた総コスト（TCO）の枠を経営と握ったか
• 発注側の意思決定者（最終判断する人）と実務担当者を決めたか
• 「今回やらないこと」を経営レベルで合意したか
• 電子帳簿保存法・インボイス・個人情報など、自社に関わる制度要件を洗い出したか
• 稼働開始希望日から逆算して、要件定義に使える期間を確保したか

要件定義書が「ある場合」と「ない場合」の差

GXOに相談すべきタイミング

以下のいずれかに当てはまる場合は、書き始める前に外部の力を借りたほうが、結果的に速く安くつく。

• 業務が複数部門にまたがり、As-Isを誰も全体把握していない
• 既存システムからのデータ移行が絡み、移行可否の技術判断が必要
• 要件定義に割ける社内工数が実質ゼロ（担当者が完全兼任）
• 過去に一度、システム開発で失敗・頓挫した経験がある
• すでに見積を受け取っているが、金額の妥当性を自社で判断できない

前の2つ・後ろの2つは局面が違う。前者は「要件を書く前の整理」の相談、後者は「見積の第三者レビュー」の相談だ。GXOはどちらの段階からでも入れる。要件定義書と見積書はセットで精度が決まるので、片方だけで走らないことが重要だ。

---

FAQ（よくある質問）

Q1. 要件定義書のサンプルはダウンロードできますか？

A. できる。本記事のサンプル（受発注管理システムの完成例）と同じ構成のExcel/PDFテンプレートを、受発注システム移行 要件定義テンプレートとして無料公開している。プロジェクト概要・As-Is/To-Be・機能要件一覧・非機能要件一覧・前提条件で構成されており、受発注以外の業務システムにも項目を差し替えて流用できる。

Q2. 要件定義書は発注者が書くものですか？

A. 原則として発注者が主体となって作成する。ただし開発会社と共同で作るのが一般的だ。「What（何を・なぜ）は発注者、How（どう作るか）は開発会社」という線引きを守るのがコツで、Whatまで業者任せにすると「業者が売りたいもの」が要件になってしまう。

Q3. 要件定義書の作成にどのくらいの期間・費用がかかりますか？

A. プロジェクト規模で異なるが、一般的な経験則としての目安（公的統計ではない）は以下の通り。実際の相場は開発会社や地域で幅があるため、目安として捉えてほしい。

Q4. 要件定義書はExcelで作ってもよいですか？

A. 問題ない。むしろ機能要件一覧や非機能要件一覧のような表形式は、ID管理・フィルタ・差分レビューのしやすさからExcelが主流だ。文章中心の概要も含めて1ブックにまとめれば、開発会社への共有も1ファイルで済む。体裁より「含まないもの」「優先度」「数値」が書かれているかのほうがはるかに重要だ。

Q5. 要件定義書のテンプレートをそのまま使ってよいですか？

A. 本記事のテンプレートをベースに、自社のプロジェクトに合わせてカスタマイズして使ってほしい。規模が小さければ、セクション1〜5だけでも十分だ。

Q6. 要件定義を開発会社に依頼する場合の費用は？

A. 経験則としての一般的な目安だが、システム開発総額の10〜20%が要件定義フェーズの費用とされることが多い。総額500万円のプロジェクトなら要件定義は50万〜100万円が目安だ。この費用を惜しんで要件定義を省略すると、開発フェーズでの手戻りコストが数倍になるリスクがある。

Q7. 要件が途中で変わった場合はどうすればいいですか？

A. プロジェクト開始後に要件が変わること自体は珍しくない。重要なのは変更を管理するプロセスを持つことだ。「変更管理表」で、(1)変更内容、(2)影響範囲、(3)費用・スケジュールへの影響、(4)承認者——を記録し、発注者と開発会社の双方が合意した上で反映する。変更管理の取り決めがない契約は、追加費用の言い値を招く。

Q8. ChatGPTなどの生成AIで要件定義書を書いてもいいですか？

A. 事実（実測値・例外処理・自社固有の制約）は必ず自社で埋める前提なら、文章の清書や観点の抜け漏れチェックに使うのは有効だ。ただしAIは自社の業務実態を知らないため、丸投げすると一般論の項目が並ぶだけで、見積もりの精度を上げる情報が入らない。中身の事実はAIに発明させないこと。

---

まとめ——要件定義は「最初の投資」であり「最大の保険」

要件定義に時間と費用をかけることは、プロジェクト全体のリスクを劇的に下げる。IPAのガイドが指摘するとおり、システム開発の失敗の多くは要件定義の段階に起因する。逆に言えば、要件定義を丁寧に行うだけで失敗確率を大きく下げられる。本記事のテンプレートと完成形サンプル、そして受発注システム移行 要件定義テンプレートを使って、まず自社の要件を紙に落とすところから始めてほしい。

そして、「自分たちだけでは要件をまとめきれない」「受け取った見積が妥当か判断できない」と感じたら、遠慮なく専門家の力を借りてほしい。要件定義書を書く前の整理から、見積の第三者レビューまで、GXOは発注前のどの段階からでも伴走する。まずは現状を聞かせてほしい。

---

参考情報

• ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ（IPA・2019年）
• システム構築の上流工程強化（要件定義・システム再構築・非機能要求グレード）関連情報（IPA）
• 制度・価格・仕様に関する記述は2026年7月16日時点の公開情報に基づく。費用・期間の数値は一般的な経験則の目安であり公的統計ではない。IPAの上記資料は現在アーカイブ扱いだが、要件定義の観点整理として引き続き参照価値がある。 [//]: # (commercial-pillar-extension-20260717)

GXO独自分析：要件定義書を「見積比較できる証拠」にする

要件定義書の完成条件はページ数ではない。業務要件、機能、非機能、データ、移行、運用、対象外が見積行・受入テスト・責任者へつながることだ。GXO式評価表では、要件IDごとに次の5点を確認する。

80点未満、対象外なし、業務責任者不在、データ移行件数不明なら開発見積を止める。要件定義費用200万円、開発1,000万円の例では、要件未確定の20%を予備費に置くだけで200万円増える。これはGXO計算例であり相場ではない。要件の曖昧さを先に減らす方が、安い会社探しより費用を制御しやすい。

ピラー・内部リンク

1. 予算の入口はシステム開発の費用相場
2. 同じ要件で3社の相見積もりを比較
3. 会社の種類はITベンダーの選び方
4. 契約前に納品物・検収条件
5. 判断が割れたらシステム開発セカンドオピニオン

根拠と検証方法

版番号: GXO-REQ-20260717-v1.0。確認日: 2026年7月17日。IPA要件定義ガイド、IPA開発ドキュメント、経済産業省モデル契約、デジタル庁標準ガイドラインを突合した。検証可能性の証拠は要件ID、業務責任者、見積行、受入結果、変更履歴。要件・法令・連携・データ・体制変更を更新条件にする。公式資料の事実とGXOの見解である採点・費用例を分離し、追加費用ゼロを保証しない。自社でテンプレートを埋められない会社はベンダー選定にも向かないため、発注準備診断への相談が向く。