システム開発の要件定義とは｜発注者が知っておくべき進め方と要件定義書の作り方

システム開発の要件定義とは、ビジネス課題を整理し、システムが満たすべき機能要件と非機能要件を文書化する工程です。本記事は、開発会社への発注に不安を感じる、大手企業の経営企画・DX推進室の責任者の方に向けて、要件定義の進め方を5ステップで解説します。

読了後には、要件定義フェーズで発注者として何を準備し、どこで意思決定すべきかが整理できます。

システム開発における要件定義とは

要件定義の不備はプロジェクト全体のコストを10倍以上に膨張させるリスクがあります。発注者が最初に理解すべき要件定義の位置づけと、見落としやすい非機能要件の考え方を解説します。 

発注者がコスト超過・手戻りを招く前に知っておくべきこと

要件定義の不備は、後工程の追加コストや納期遅延に直結します。たとえば、業務フローの整理が不十分なまま開発に着手したケースでは、テスト段階で機能の作り直しが発生し、当初予算の1.5倍以上にコストが膨張する例も珍しくありません。

要件定義は単なる「仕様書づくり」ではなく、ビジネス課題をシステム要件に落とし込む経営判断の場です。発注者が主体的に関与する姿勢が、プロジェクト成否を決めます。

システム開発の工程比率から見る要件定義の重要性

Boehm & Basili「Software Defect Reduction Top 10 List」（IEEE Computer, 2001）では、要件定義段階で欠陥を除去することは、テスト以降の修正に比べて10〜100倍効率的とされています。

実プロジェクトでは要件定義に全工数の15〜25%程度を割くのが一般的です。ここで投資する時間が、結合テストやリリース後の手戻りコストを大きく抑制します。

ただし、この数値はウォーターフォール型開発を前提とした研究によるものであり、アジャイル開発など反復型の手法では数値の前提が異なる点に留意が必要です。

機能要件と非機能要件の違い

機能要件は「何ができるか」、非機能要件は「どの程度の品質で動くか」を定義します。機能要件は業務観点で発注者が議論しやすい一方、非機能要件は専門用語が多く発注者側で後回しになりがちです。

非機能要件の検討には、IPAが公開する「非機能要求グレード2018」が有用です。可用性・性能・拡張性・運用・保守性・移行性・セキュリティ・システム環境の6大項目を網羅的に整理できます。

具体例としては、応答時間3秒以内、稼働率99.9%以上、同時接続ユーザー1,000人以上、といった数値で合意するのが基本です。これらを後回しにすると、リリース後に「速度が遅い」「業務時間中に止まる」といった問題が顕在化します。

システム開発の要件定義の進め方

要件定義の所要期間は、発注者側の準備度によって2〜3倍変わります。キックオフ前に揃えるべき資料と、ビジネス要件から成果物承認までの5ステップを順を追って解説します。

要件定義に入る前に発注者が準備すべきもの

要件定義のキックオフ前に、以下を発注者側で揃えておくと議論が加速します。

• プロジェクトの目的・KPI
• 現行業務フロー（As-Is）の概要
• 予算・スケジュールの上限
• 意思決定者とステークホルダーの一覧
• 既存システムの構成情報（連携が想定される場合）

ステップ1：ビジネス要件の明確化（企画）

経営課題・事業目標を起点に、プロジェクトの目的・KPI・スコープの草案を策定する段階です。アウトプットはプロジェクト目的・KPI・スコープの草案となります。

発注者の確認ポイント｜ビジネス課題はどのように要件に落とし込まれているか

経営層が共有する課題が、システム要件として一貫した形で言語化されているかを確認します。曖昧な「業務効率化」ではなく、「受注処理の所要時間を50%削減」のように測定可能な目標まで具体化することが必要です。

ステップ2：業務要件の定義

ステップ1で合意したスコープ草案をもとに、業務フロー図とユースケース一覧を作成します。As-Is（現行）とTo-Be（将来像）の両方を文書化し、改善ポイントを可視化します。

発注者の確認ポイント｜想定される最大のリスクとその対策は何か

業務要件のレビューでは、「何を実現するか」だけでなく「失敗したときの最大損失」まで議論します。データ移行失敗、現場の運用切替不可、想定ボリューム超過など、リスクごとに対策と判断基準を明文化します。

ステップ3：機能要件の定義

業務フロー図とユースケース一覧をもとに、画面遷移図・機能一覧・データモデル（ER図）を作成する段階です。発注者は業務観点でのレビューが主担当となります。

発注者の確認ポイント｜要件変更が発生した場合の管理プロセスはどうなっているか

要件定義段階で、変更管理ルールを契約書または別紙で合意しておくのが鉄則です。変更内容・影響範囲・追加工数・追加費用・変更後納期を「変更管理票」に整理し、発注者の決裁印で承認するプロセスを定型化します。

ステップ4：非機能要件の定義

機能要件一覧とシステム利用規模の想定値をもとに、非機能要件定義書を作成します。性能・セキュリティ・可用性・保守性などの観点を網羅し、IPA「非機能要求グレード2018」のチェックリストを参照すると抜け漏れを防げます。

発注者の確認ポイント｜非機能要件の定義にどのような基準を採用しているか

非機能要件は「業界標準を採用」と曖昧にせず、IPA非機能要求グレードのモデルシステム（社会的影響が小〜大）のどれを採用するかまで合意します。基準が明確であれば、後工程でのテスト計画・受入基準も自動的に決まります。

ステップ5：成果物の承認と合意形成

ここまでの成果物（要件定義書・業務フロー図・画面遷移図・ER図・非機能要件定義書）を一括レビューし、発注者・受注者の双方で正式承認します。承認後の変更は、変更管理プロセスを経由する形に切り替わります。

発注者の確認ポイント｜成果物として何をどの粒度で納品してもらえるか

「要件定義書」と一言で言っても、提供される文書の粒度はベンダーで大きく異なります。画面項目の網羅性、ER図の正規化レベル、非機能要件の定量化粒度を、契約書または別紙で具体的に定めておくと検収段階のトラブルを避けられます。

要件定義における生成AI活用の現状と注意点 

生成AIは要件定義の生産性を高めるツールとして活用が広がっています。

ただし、現時点では「万能な自動化ツール」ではなく、人間の判断と併用することが前提です。各ステップでの活用例と限界を整理します。

■ 活用が有効な場面

• ステップ1（ビジネス要件）：競合他社の事業モデルや

  業界トレンドの初期リサーチ、KPI候補の洗い出し

• ステップ2（業務要件）：現行業務フローのたたき台作成、

  用語集・略語リストの初期整理

• ステップ3（機能要件）：画面項目の網羅性チェック、

  類似システムの機能一覧との比較表作成

• ステップ4（非機能要件）：IPA非機能要求グレードの

  チェック項目を自社向けにカスタマイズする際の下書き

■ 生成AIでは補えない領域

• 現場担当者の暗黙知（例外処理、属人的な判断ルール、

  部門間の非公式な調整プロセス）

• 自社固有の業務制約やコンプライアンス要件の最終判断

• ステークホルダー間の利害調整と合意形成

生成AIの出力をそのまま要件定義書に転記するのではなく、「たたき台の作成→現場ヒアリングで検証→修正」のサイクルで活用するのが実務上の原則です。

システム開発の要件定義書の項目と構成サンプル｜実務で使えるテンプレート

要件定義書の粒度はベンダーによって大きく異なり、「何が含まれていて当然か」の認識ズレが検収トラブルの原因になります。標準的な構成項目と、自社プロジェクトに合わせた活用法を解説します。 

要件定義書の主要な構成項目

実務で使われる要件定義書は、以下の項目で構成されるのが一般的です。

項目	記載内容
プロジェクト概要	目的・KPI・スコープ・前提条件
業務要件	業務フロー(As-Is/To-Be)・ユースケース
機能要件	画面一覧・機能一覧・画面遷移図
データ要件	ER図・データ項目定義・移行データ範囲
非機能要件	性能・可用性・運用保守・セキュリティ
外部連携	連携先システム・APIインターフェース
体制・役割分担	発注者・開発会社の責任範囲
スケジュール・予算	工程ごとの期間・コスト・納品物

なお、業種やシステムの特性によって必要な項目は異なります。上記はあくまで標準的な構成であり、たとえば既存システムとの連携が多い場合は「外部連携」の粒度を細かくする、複数部門が関与する場合は「体制・役割分担」を独立したセクションとして厚くするなど、自社プロジェクトの実態に合わせて調整してください。

要件定義書サンプルの活用ポイント

Web上には要件定義書のサンプルやテンプレートが多数公開されています。ただし、業種・システム特性によって必要項目が異なるため、テンプレートをそのままコピーするのではなく、自社プロジェクトの特性に合わせた修整が必要です。

特に非機能要件は、IPA「非機能要求グレード2018」の活用シートをベースに、自社の業務クリティカリティに応じてレベルを段階づけする運用が推奨されます。

要件定義書の簡易テンプレート

発注者が初期検討で使える簡易テンプレートとして、以下の構成を推奨します。

• 1. 背景と目的（経営課題・KPI）
  なぜこのプロジェクトが必要か、何を達成するために実施するかを記載
• 2. システムスコープ（対象業務・対象部門）
  今回のシステムで対応する業務範囲と対象部門を明記
• 3. 業務フロー概要(As-Is)とTo-Be像
  現行の業務フロー（As-Is）と、システム導入後に実現したい理想の状態（To-Be）を図や箇条書きで整理
• 4. 機能一覧（画面・帳票・処理）
  システムが提供する機能を画面・帳票・バッチ処理などに分類して一覧化 
• 5. データ要件（主要エンティティとその関係）
  システムが扱うデータの種類（顧客、受注、在庫など）と、それらの関係性を整理
• 6. 非機能要件（応答時間・稼働率・セキュリティ要件）
  「どの程度の品質で動くか」を数値で定義
• 7. 外部システム連携要件
  既存の基幹システムやSaaSツールとの連携が必要な場合、連携先・連携方式・データ授受のタイミングを明記
• 8. 概算予算・スケジュール・体制
  プロジェクト全体の予算上限、想定スケジュール（工程ごとの期間）、発注者側と開発会社側それぞれの担当者と責任範囲を記載

要件定義でよくある失敗パターンと防止策

要件定義の失敗は、テスト段階や保守フェーズになって初めて顕在化するケースが大半です。現場で繰り返し発生する4つのパターンを、原因となるステップの特定と合わせて解説します。 

要件の曖昧な合意による「言った・言わない」問題

要件定義書に書かれていない口頭合意が、後工程でトラブル化するパターンです。

防止策は、議事録による合意の文書化と、48時間以内の相手側確認ルールの運用です。契約書には契約不適合責任の範囲と期間も明記してください。

発注者の業務フロー整理不足によるヒアリング長期化

現行業務フローの整理が不十分なまま要件定義に着手し、ヒアリングが何度も繰り返されるパターンです。要件定義の前半工程が当初想定の2〜3倍に膨らむケースもあります。

防止策は、要件定義キックオフの前に発注者側でAs-Isフローを文書化しておくことです。網羅的に書き上げる必要はなく、たたき台レベルで構いません。現場ヒアリングはこのたたき台への赤入れ形式で進めると、議論の論点が明確になりスピードが出ます。

非機能要件の後回しによるリリース後の性能問題

機能要件にばかり時間を使い、非機能要件は「適切な水準で」と曖昧なまま開発に進むパターンです。リリース後に「業務時間中に画面が固まる」「データ件数の増加でレスポンスが悪化する」といった問題が顕在化し、追加チューニングのコストが発生します。

防止策は、IPA非機能要求グレードのモデルシステム選定を要件定義段階で完了させ、応答時間・稼働率・想定ユーザー数を数値で合意することです。テスト計画の段階で再確認するのではなく、要件定義段階で測定可能な数値まで落とし込んでおきます。

ステークホルダー合意を取らず現場で使われないシステム

経営層と情報システム部門だけで要件を固め、現場の声を取り入れずに開発した結果、リリース後に使われないシステムが生まれるパターンです。

防止策は、企画段階から現場のキーマンを要件定義チームに組み込み、画面モックアップで早期フィードバックを得ることです。受入テストにも現場ユーザーを巻き込みます。

要件定義に関するよくある質問（FAQ）

発注者の方からよくいただく以下3つの質問にお答えします。

• 要件定義はどこまで発注者側が作るのですか？
• 要件定義にどのくらいの期間がかかりますか？
• 小規模なシステム開発でも要件定義は必要ですか？

要件定義はどこまで発注者側が作るのですか？

発注者がゼロから要件定義書を書く必要はありませんが、ビジネス課題・KPI・現行業務フロー（As-Is）・予算とスケジュールの上限は、発注者側で言語化しておく必要があります。これらを欠いたまま開発会社に丸投げすると、ベンダー側の解釈で要件が固まり、後工程で「想定と違う」と気づくリスクが高まります。

要件定義にどのくらいの期間がかかりますか？

プロジェクト規模により変動しますが、中規模の業務システムで1〜2か月、大規模な基幹系刷新で3〜6か月程度が一般的な目安です。

「短いほうが良い」と考えがちですが、要件定義に投資した時間は後工程の手戻り削減で何倍にもなって返ってきます。Boehm & Basili（IEEE Computer, 2001）の知見どおり、上流で時間をかけるほうが結果的に総コストを抑えられます。

小規模なシステム開発でも要件定義は必要ですか？

小規模であっても、要件定義は必要です。形式的な「要件定義書」を分厚く作る必要はありませんが、目的・スコープ・KPI・想定利用者・最低限の機能と非機能要件は、A4で2〜3ページ程度にまとめて発注者・受注者で合意するのが推奨されます。

まとめ：要件定義はビジネスを成功に導くための設計図

システム開発の要件定義は、ビジネス課題をシステム要件に落とし込む経営判断の場です。発注者として最も重要なのは、現行業務フロー（As-Is）の整理、KPIの数値化、非機能要件の早期確定の3点です。これらを発注者主導で進めることで、後工程の手戻りコストは大きく抑制できます。要件定義書は、開発会社との合意文書であると同時に、社内の意思決定の根拠資料でもあるため、経営層・業務部門・情報システム部門の3者が同じ文書を見て議論できる粒度で作成することが理想です。

Incubation Baseは、新規事業開発・システム開発・DX支援の3軸で、シニアコンサルタントが要件定義から実装まで伴走型で支援しています。要件定義の壁打ち、業務部門と開発会社の橋渡し、IPA非機能要求グレードを活用した非機能要件の整理など、発注者側の体制が整わない段階からの支援も可能です。まずは無料の個別相談からお気軽にお問い合わせください。

お問い合わせはこちら