要件定義とは？目的・流れ・要件定義書の書き方を解説
「開発会社から『まずは要件定義から』と言われたが、具体的に何をする工程なのかわからない」「要件と要求は何が違うのか」「要件定義書には何を書くのか」。要件定義はシステム開発で最も重要な工程といわれますが、言葉の意味や位置づけがあいまいなまま進んでしまうことも少なくありません。
この記事では、要件定義とは何かを、目的、要求との違い、基本設計との境界、全体の流れ、要件定義書の構成という観点から整理して解説します。手順の詳細やテンプレートは別記事にまとめているため、ここでは要件定義の全体像をつかむことに重点を置きます。
- 要件定義とは、システムで何を実現するかを発注者と開発者で合意し、文書にする工程です。
- 目的は、作るものの範囲・品質・費用・期間の共通認識をつくることにあります。
- 「要求」は利用者の望み、「要件」はそれを実現可能な形に整理し合意したものです。
- 成果物の要件定義書には、目的・業務フロー・機能要件・非機能要件・範囲外事項などを記載します。
目次
要件定義とは？
要件定義とは、システム開発の最初の工程で、発注者の業務課題や要望を整理し、システムが備えるべき機能・性能・制約条件を明確にして、発注者と開発者の間で合意した内容を文書化することです。英語ではRequirements Definitionと呼ばれ、開発会社の資料では「RD」と略されることもあります。
家づくりにたとえると、要件定義は「家族構成や暮らし方を聞き取り、部屋数や広さ、予算、完成時期を決める段階」にあたります。間取り図を描く設計や、実際に建てる工事はその後の工程です。最初の段階で認識がずれていると、どれだけ腕のよい職人が建てても住みにくい家になってしまいます。
要件定義の目的
要求と要件の違い
要件定義を理解するうえで押さえておきたいのが、「要求」と「要件」の違いです。似た言葉ですが、システム開発では明確に区別されます。
| 項目 | 要求 | 要件 |
|---|---|---|
| 意味 | 利用者や発注者が「こうしたい」と望むこと | 要求を整理し、システムで実現すると合意した条件 |
| 例 | 「受注入力を早くしたい」 | 「得意先コード入力で住所・単価を自動表示する」 |
| 性質 | あいまい・矛盾を含むことがある | 具体的で、実現可能性と優先度が検討済み |
| 主な担い手 | 発注者・現場 | 発注者と開発者の合意 |
要件定義の工程では、要求を集める「要求定義」を経て、それを要件にまとめていきます。すべての要求が要件になるわけではなく、予算や期間、効果を踏まえて取捨選択されます。
要件定義で決める2種類の要件
要件は大きく「機能要件」と「非機能要件」に分けられます。
機能要件
- システムが「何をするか」
- 例：受注登録、在庫引当、請求書発行
- 画面、帳票、データ、外部連携など
- 利用者が意識しやすく、議論されやすい
非機能要件
- システムが「どの程度の品質で動くか」
- 例：応答速度、稼働時間、バックアップ
- セキュリティ、運用・保守、拡張性など
- 見落とされやすく、稼働後の不満の原因になりやすい
非機能要件は発注者から要望として出てきにくいため、開発会社が項目を提示して確認していくのが一般的です。
要件定義の位置づけと全体の流れ
要件定義は、企画の後、設計の前に行う工程です。基本設計（外部設計）との境界がわかりにくいといわれますが、要件定義が「何を作るか」を決めるのに対し、基本設計は「どう見せるか・どう動かすか」を具体化する工程と整理すると理解しやすくなります。
- 現状把握現在の業務の流れ、使っている資料、課題をヒアリングで把握します。
- 要求の収集部署ごと、立場ごとの要望を集め、課題との関係を整理します。
- 要件の整理・優先度づけ要求を機能要件・非機能要件にまとめ、必須かどうかを判断します。
- 要件定義書の作成決めた内容を文書にし、業務フロー図や画面イメージで補います。
- レビューと合意発注者が内容を確認・承認し、設計工程に進みます。
それぞれの手順の具体的な進め方や、ヒアリングのコツは以下の記事で詳しく解説しています。
要件定義は誰が行うのか
受託開発では、開発会社のPMやSEがヒアリングと文書化を担い、発注者が業務の説明と判断を担うのが一般的です。本来、システムで何を実現したいかを決めるのは発注者の責任であり、開発会社はそれを引き出し形にする専門家という関係です。発注者が判断を開発会社に任せきりにすると、業務に合わない要件になりやすい点に注意しましょう。
要件定義書の書き方と主な構成
要件定義書は、要件定義の成果物となる文書です。決まった様式はありませんが、一般的には次のような項目で構成されます。
| 項目 | 書く内容 |
|---|---|
| 概要・目的 | システム化の背景、目的、期待する効果 |
| 対象範囲 | 対象業務・部署・利用者、対象外とする範囲 |
| 業務フロー | 現状と導入後の業務の流れ |
| 機能要件 | 機能一覧、画面・帳票一覧、データ、外部連携 |
| 非機能要件 | 性能、可用性、セキュリティ、運用・保守、移行 |
| 前提・制約 | 予算、スケジュール、利用環境、法令など |
書くときのポイントは、専門用語より業務の言葉を使うこと、「など」「適宜」といったあいまいな表現を避けること、対象外の事項も明記することの3点です。具体的な記入例は、テンプレート記事を参考にしてください。
要件定義で発注者が準備すること
要件定義を効率よく進めるためには、発注者側の準備が欠かせません。開発会社がヒアリングで一から情報を集めるほど、期間も費用も増えていきます。
- システム化の目的：解決したい課題と期待する効果を、できれば数値を交えて言葉にしておく。
- 現状の業務資料：業務の流れのメモ、使っているExcel、帳票、マニュアルを集めておく。
- 関係者と決裁者：誰に話を聞き、誰が最終的に判断するのかを決めておく。
- 予算と時期：開発・保守を含めた予算の上限感と、稼働させたい時期を共有しておく。
RFP（提案依頼書）を作成している場合は、その内容が要件定義の出発点になります。RFPに書いた目的や範囲と、要件定義で決まった内容に食い違いがないかも確認しましょう。
要件定義は、システム開発の中で発注者の関与が最も大きい工程です。この段階で時間をかけて認識をそろえておくことが、後の設計・開発・テストをスムーズに進め、追加費用や手戻りを防ぐ一番の近道になります。
無料テンプレートシステム開発の無料テンプレート集｜RFP・要件定義書・見積もり比較表・保守契約チェックリスト
よくある質問
- 要件定義と基本設計の違いは何ですか？
- 要件定義は「システムで何を実現するか」を決める工程で、基本設計は要件をもとに画面や帳票、データ構造など「どう実現するか」を具体化する工程です。要件定義で合意した範囲の中で基本設計が行われます。
- 要件定義は発注者と開発会社のどちらが行うものですか？
- 両者の共同作業です。開発会社がヒアリングや文書化を担い、発注者が業務の説明と要件の判断・承認を担うのが一般的です。
- 要件定義を省略して開発に入ることはできますか？
- 極めて小さな改修を除き、おすすめできません。要件があいまいなまま開発すると、手戻りや追加費用、業務に合わないシステムにつながりやすくなります。
- RFPと要件定義書の違いは何ですか？
- RFP（提案依頼書）は開発会社に提案を求めるために発注者が作る文書で、要件定義書は発注後に開発会社と合意した要件をまとめた文書です。RFPの内容が要件定義の出発点になります。
まとめ
要件定義とは、システムで何を実現するかを発注者と開発者で合意し、要件定義書として文書化する工程です。要求と要件の違い、機能要件と非機能要件の2分類、基本設計との境界を押さえておくと、開発会社との打ち合わせで何を判断すべきかが明確になります。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
