要件定義は、システム開発プロジェクトの成否を決める最も重要な工程だ。IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2025」によると、プロジェクト失敗の原因として「要件定義の不備」が最も多く、全体の約35%を占めている。

しかし、「要件定義書を書いたことがない」「どんな構成にすればいいのかわからない」という企業担当者は非常に多い。特に中小企業では、情シス部門がなく、業務部門の担当者が初めて要件定義に取り組むケースも珍しくない。

本記事では、業務システムの要件定義書テンプレートを公開し、各セクションの書き方を記入例付きで解説する。加えて、失敗する要件定義の特徴と、それを回避するためのポイントも紹介する。

目次

  1. 要件定義書とは何か——目的と位置づけ
  2. 要件定義書テンプレート——全体構成
  3. 各セクションの書き方と記入例
  4. 失敗する要件定義の5つの特徴
  5. FAQ（よくある質問）

要件定義書とは何か——目的と位置づけ

要件定義書の目的

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

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

要件定義書の位置づけ

システム開発プロジェクト全体の中で、要件定義書は以下の位置にある。

フェーズ主な作業成果物
企画ビジネス要件の整理、予算確保企画書、予算申請書
要件定義 ← 本記事の対象業務要件・機能要件の定義要件定義書
基本設計画面設計、DB設計、API設計基本設計書
詳細設計プログラム仕様の設計詳細設計書
開発・テストコーディング、テスト実施ソースコード、テスト結果
リリース・運用本番環境への展開、保守運用マニュアル

誰が書くのか

要件定義書の作成主体は「発注者側」だ。ただし、発注者が単独で書く必要はない。開発会社にヒアリングを受けながら共同で作成するケースが一般的であり、GXOでもこの「共同作成」のアプローチを推奨している。

要件定義書テンプレート——全体構成

以下が、業務システムの要件定義書の推奨構成だ。プロジェクトの規模に応じてセクションの取捨選択をしてよいが、1〜5は必須と考えてほしい。

#セクション必須度概要
1プロジェクト概要★★★プロジェクトの目的、背景、スコープ
2現状の業務フロー（As-Is）★★★現在の業務プロセスの可視化
3あるべき業務フロー（To-Be）★★★システム導入後の業務プロセス
4機能要件★★★システムが提供すべき機能の一覧
5非機能要件★★★性能、セキュリティ、可用性等
6画面・帳票要件★★☆画面レイアウト、出力帳票の仕様
7データ要件★★☆データの種類、量、移行要件
8外部連携要件★★☆他システムとの連携仕様
9運用・保守要件★★☆運用体制、バックアップ、保守契約
10プロジェクト体制・スケジュール★☆☆体制図、マイルストーン、納期
11前提条件・制約事項★☆☆技術的・組織的な制約

各セクションの書き方と記入例

セクション1：プロジェクト概要

このセクションは、プロジェクトの「全体像」を1〜2ページで伝えるためのものだ。

記載項目と記入例

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

背景:

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

目的:

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

スコープ（対象範囲）:

対象に含むもの対象に含まないもの
受注管理機能会計システムとの自動連携（Phase 2で検討）
発注管理機能モバイルアプリ対応（Phase 2で検討）
在庫管理機能ECサイトとの連携
売上集計・レポート機能CRM機能
重要ポイント: 「対象に含まないもの」を明記することが極めて重要だ。これがないと、プロジェクト進行中に「これも入ると思っていた」という認識齟齬が発生する。

セクション2：現状の業務フロー（As-Is）

現在の業務プロセスを可視化する。完璧なフローチャートでなくても、以下のような表形式で十分だ。

記入例：受注業務のAs-Is

#作業内容担当使用ツール所要時間課題
1FAX/メールで注文書を受信営業事務FAX機、Outlook—見落としリスクあり
2注文内容をExcelに転記営業事務Excel15分/件手入力でミスが発生（月8件）
3在庫を倉庫に電話確認営業事務電話5分/件担当者不在時に確認不可
4受注確認書をFAXで返信営業事務FAX機5分/件送信失敗に気づかない場合あり
5出荷指示書を印刷・倉庫に渡す営業事務Excel、プリンタ3分/件印刷忘れ・紛失リスク
6月末にExcelを集計して売上レポート作成経理Excel3日集計ミス、属人化

セクション3：あるべき業務フロー（To-Be）

システム導入後にどう変わるかを記述する。

記入例：受注業務のTo-Be

#作業内容担当使用ツール所要時間改善効果
1注文データをシステムに登録（Web入力 or CSV取込）営業事務新システム3分/件手入力箇所を最小化
2在庫の自動引当・確認システム自動新システム即時電話確認不要
3受注確認メールを自動送信システム自動新システム即時FAX不要、送信漏れ防止
4出荷指示を倉庫端末に自動送信システム自動新システム即時印刷不要、紛失リスク解消
5売上レポートをリアルタイムで閲覧経理・経営層新システム即時月末集計作業3日→0日

セクション4：機能要件

システムが「何をできるか」を一覧化する。優先度を付けることで、予算やスケジュールの制約がある場合に「最低限これは実装する」「余裕があれば実装する」の判断がしやすくなる。

記入例

ID機能名概要優先度
F-001受注登録Web画面から受注情報を登録する。CSV一括取込にも対応必須
F-002受注一覧・検索受注データの一覧表示、日付・顧客名・ステータスで検索必須
F-003在庫自動引当受注登録時に在庫を自動引当し、不足の場合はアラート表示必須
F-004受注確認メール自動送信受注登録後、顧客に確認メールを自動送信必須
F-005出荷指示自動生成受注確定後、出荷指示データを自動生成必須
F-006売上レポート日次・月次・年次の売上レポートを自動生成必須
F-007発注管理仕入先への発注登録・管理必須
F-008在庫管理入出庫管理、在庫数の自動計算、棚卸支援必須
F-009ダッシュボード売上・在庫・受注状況の概要を一画面で表示希望
F-010権限管理ユーザーごとに閲覧・編集権限を設定必須
F-011CSVエクスポート各種データをCSV形式でエクスポート希望
F-012監査ログ操作履歴の記録・閲覧希望

セクション5：非機能要件

システムの「品質特性」を定義する。機能要件ばかりに注目して非機能要件を疎かにすると、「機能は揃っているが遅い・落ちる・危ない」システムが出来上がる。

記入例

カテゴリ要件項目要件値
性能画面表示のレスポンスタイム3秒以内（通常時）
性能同時接続ユーザー数50名以上
性能データ保持期間過去7年分
可用性稼働時間平日8:00〜22:00（月間稼働率99.5%以上）
可用性バックアップ日次自動バックアップ、30日間保持
可用性障害復旧時間（RTO）4時間以内
セキュリティ認証方式ID/パスワード＋二段階認証
セキュリティ通信暗号化HTTPS（TLS 1.2以上）
セキュリティアクセスログ全操作を記録、90日間保持
互換性対応ブラウザChrome、Edge、Safari（最新版）
互換性対応デバイスPC（Windows/Mac）、タブレット
拡張性ユーザー数の増加100名まで追加費用なしで拡張可能

セクション6〜11のポイント（簡潔に）

セクション記載のポイント
画面・帳票要件主要画面のワイヤーフレーム（手書きでも可）、出力帳票の種類とフォーマット
データ要件既存データの移行対象・量・形式、マスターデータの管理方法
外部連携要件連携先のシステム名、連携方式（API、CSV、DB直接）、連携頻度
運用・保守要件運用時間帯、障害発生時の連絡フロー、保守契約の範囲
プロジェクト体制発注者側の体制（意思決定者、担当者）、想定スケジュール
前提条件・制約技術的制約（既存システムとの整合性等）、予算上限、法規制対応

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

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

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

例:

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

特徴2：スコープが曖昧

「対象に含むもの」だけでなく「対象に含まないもの」が明記されていない。プロジェクト進行中に「これも入ると思っていた」「いや、スコープ外です」の議論が頻発し、信頼関係が損なわれる。

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

機能要件は書かれているが、性能・セキュリティ・可用性についての記載がない。結果として、開発会社は「最低限のスペック」で実装し、本番運用で「遅い」「落ちる」「セキュリティが甘い」といった問題が発覚する。

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

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

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

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

関連記事: 開発会社の選び方で迷っている方は「システム開発会社の選び方完全ガイド」も参考にしてほしい。

FAQ（よくある質問）

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

A. 原則として発注者が主体となって作成する。ただし、開発会社と共同で作成するのが一般的だ。GXOでは、ヒアリングを通じて要件を引き出し、要件定義書のドラフトを作成した上で発注者にレビューしてもらうプロセスを採用している。

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

A. プロジェクトの規模によって異なるが、目安は以下の通りだ。

プロジェクト規模要件定義の期間目安費用の目安
小規模（機能数10以下）2〜4週間30万〜80万円
中規模（機能数10〜30）1〜2ヶ月80万〜200万円
大規模（機能数30以上）2〜4ヶ月200万〜500万円

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

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

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

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

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

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

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

要件定義に時間と費用をかけることは、プロジェクト全体のリスクを劇的に低減する。IPA の調査データが示す通り、プロジェクト失敗の35%は要件定義の不備に起因している。逆に言えば、要件定義を丁寧に行うだけで、失敗確率を大幅に下げられるということだ。

本記事のテンプレートを活用して要件の整理を始めてほしい。そして、「自分たちだけでは要件をうまくまとめられない」と感じたら、遠慮なく専門家の力を借りてほしい。

要件定義からGXOが支援します

>

GXO株式会社では、業務システムの要件定義から開発・運用までを一貫して支援しています。

>

- 「何を作ればいいかわからない」段階からの要件整理サポート

  • ヒアリングを通じた課題の可視化と優先順位付け
  • 要件定義書の共同作成（ドラフト作成はGXO側で対応）
  • 要件定義から開発・運用まで一気通貫（認識齟齬のリスクを最小化）

>

「まず自社の課題を整理したい」「要件定義の進め方を相談したい」という方は、お気軽にお問い合わせください。

>

無料相談を申し込む →