要求定義と要件定義の違いとは？発注側がすべき準備を解説

「ベンダーから『まず要求定義書を作ってください』と言われたものの、何から手をつければいいか分からず、画面の前で固まっていませんか。」

システム開発の上流工程で出てくる「要求定義」と「要件定義」は、言葉が似ているうえに責任範囲も曖昧です。社内に開発経験者がいない事業会社の担当者にとっては、「自分はどこまで書けばよいのか」「ベンダーと自分の役割はどう違うのか」が分からず、最初の一歩で手が止まってしまうケースが少なくありません。

しかし、ここで動きが止まるとプロジェクトは前に進みません。実際、独立行政法人情報処理推進機構（IPA）が公表している調査でも、システム開発プロジェクトの遅延・品質問題の多くが上流工程の要件定義の不備に起因することが繰り返し指摘されています（IPA「ユーザのための要件定義ガイド 第2版」）。発注側の準備不足は、後工程でのコスト超過や手戻りに直結します。

本記事では、要求定義と要件定義の違いを「定義の暗記」ではなく「自分の作業範囲を確定させるためのフレーム」として整理します。そのうえで、発注側が要求定義で準備すべきことを5ステップで解説し、要求定義書のテンプレート、ベンダーとの対話で詰まらないためのチェックリストまで一気通貫で扱います。読み終わった頃には、翌日の社内打ち合わせで「やること」と「巻き込む人」を提示できる状態を目指します。

要求定義とは｜発注側が「何を実現したいか」を言語化する工程

このセクションでは、要求定義の定義と目的、そして「主担当は誰か」をまず確定させます。

要求定義の定義と目的

要求定義とは、発注者・ユーザー視点で「このシステムで何を実現したいのか」「なぜそれが必要なのか」を整理し、文書として言語化する工程です。新しい業務システムの構築・既存システムの刷新を行う際、最初に発注側が取り組む作業に位置づけられます。

要求定義の目的は、大きく2つあります。

• 社内の合意形成: 経営層・現場・情シスなど関係者の間で「実現したい状態」のイメージを揃える
• ベンダーへのインプット作成: ベンダーが提案書・概算見積を作成できる粒度の情報をまとめる

つまり、要求定義は「自分たちが何を欲しているかを明確にする」段階です。「どう作るか」はまだ決めません。

要求定義の主担当は発注側である理由

要求定義の主担当は、原則として発注側（ユーザー企業）です。理由はシンプルで、「自社の業務課題と実現したい姿を最も理解しているのは発注側自身」だからです。

ベンダーは技術や開発手法に詳しいですが、貴社の業務フロー・社内政治・既存資産の使われ方までは把握していません。要求定義をベンダーに丸投げすると、ベンダーは聞き取った範囲でしか情報をまとめられず、結果として「実態と合わない要求定義書」ができあがってしまいます。

ただし、発注側にシステム開発の知見が乏しい場合は、要求定義の作成支援をベンダーや外部のITコンサルタントに依頼するケースもあります。その場合も、最終的な意思決定者と内容の責任は発注側に残ります。

要求定義のアウトプット（要求定義書／RFPの位置づけ）

要求定義のアウトプットは、主に以下の2つです。

• 要求定義書: 社内の関係者向けに、要求事項を体系的にまとめたドキュメント
• RFP（提案依頼書）: 複数のベンダーに対して、要求内容と提案を求める条件を伝えるドキュメント

両者は重なる部分が多く、実務上は「要求定義書をベースにRFP化する」流れが一般的です。本記事では「要求定義書」を中心に扱いますが、RFPを作成する場合も同じ準備プロセスがそのまま使えます。

要件定義とは｜要求を「どう実現するか」に翻訳する工程

このセクションでは、要件定義の役割と「なぜ主担当がベンダー側になるのか」を整理します。

要件定義の定義と目的

要件定義とは、要求定義で言語化された「実現したいこと」を、システムで実現するための機能・性能・制約に落とし込む工程です。要求定義が「WHY」と「WHAT（何を実現したいか）」を扱うのに対し、要件定義は「WHAT（システムが備えるべき機能）」と「HOW（どう実装するか）」をより具体的に詰めていきます。

例えば、要求定義で「現場担当者がスマートフォンから日報を入力できるようにしたい」とまとめられていた場合、要件定義では以下のような形で具体化されます。

• 入力項目: 日付、案件ID、作業時間、作業内容（自由記述400文字以内）、写真添付（最大5枚）
• 認証方式: 既存ADと連携したシングルサインオン
• 同時接続数: 平日ピーク時に最大200名

このように、要件定義では「ベンダーが設計・開発に着手できる粒度」まで情報を落とし込みます。

要件定義の主担当はベンダー側である理由

要件定義の主担当は、原則としてベンダー側です。理由は2つあります。

• 技術的な実現可能性の判断が必要: 要求を機能・性能に翻訳する際は、技術選定・既存システムとの整合性・性能設計など、技術知見を前提とした判断が必要になる
• 責任範囲の明確化: 要件定義書はベンダーが「この内容で開発を請け負う」と合意するドキュメントになるため、ベンダー自身が記述・確認することで責任の所在が明確になる

ただし、発注側も要件定義フェーズに無関与でよいわけではありません。ベンダーからのヒアリング対応、要件定義書のレビューと承認、業務的な整合性のチェックは、発注側担当者の重要な役割です。詳細は 要件定義の進め方 で解説しています。

要件定義のアウトプット（要件定義書・機能要件／非機能要件）

要件定義のアウトプットは「要件定義書」です。要件定義書は通常、以下の2種類の要件で構成されます。

• 機能要件: システムが提供する機能（画面、帳票、データ処理、外部連携など）
• 非機能要件: 性能、可用性、セキュリティ、運用保守性など、機能ではない品質特性

機能要件と非機能要件の詳細な分類や、それぞれの記述ポイントは別記事で扱います。本記事の段階では、「要件定義書はベンダーが中心となって作成し、発注側はレビューする側」とだけ理解しておけば十分です。

要求定義と要件定義の違いを5つの軸で整理

このセクションを読むと、要求定義と要件定義の違いを「自分の作業範囲を決めるフレーム」として使えるようになります。

比較表で見る5つの違い（目的／主担当／粒度／成果物／表現）

要求定義と要件定義の違いは、以下の5つの軸で整理できます。

軸	要求定義	要件定義
目的	何を実現したいか（WHY/WHAT）を明確化	どう実現するか（WHAT/HOW）を具体化
主担当	発注側（ユーザー企業）	ベンダー側（発注側はレビュー）
粒度	業務目線・概要レベル	システム仕様レベル
成果物	要求定義書、RFP	要件定義書（機能要件・非機能要件）
使う言葉	業務用語・経営用語	機能名・データ項目・性能数値

SCROLL→

例えば「営業の生産性を上げたい」は要求定義の言葉、「商談一覧画面で顧客名・最終接触日・次回アクション期限を表示できる」は要件定義の言葉です。

一言で覚える「要求はWHY、要件はWHAT・HOW」

5つの軸を覚えるのが大変であれば、まずはこのフレーズだけ記憶してください。

要求はWHY、要件はWHAT・HOW

「なぜ必要か・何を実現したいか」が要求、「具体的に何を作るか・どう実現するか」が要件。この区別ができるようになると、ベンダーと話していて「今の話は要求の確認なのか、要件の合意なのか」を判断できるようになります。打ち合わせの議事録を書くときの整理軸としても役立ちます。

違いを意識しないと起こる3つの失敗

要求定義と要件定義の役割分担が曖昧なまま進めると、発注側はおおむね次の3つのつまずきに陥ります。

1. 要求定義をベンダーに丸投げしてしまう

「ベンダーに任せれば全部きれいにまとめてくれる」と考えてしまうケースです。先述のとおり、ベンダーは社内事情までは知らないため、丸投げすると「業務の実態と合わないシステム」が出来上がります。後工程で要求が次々と追加され、追加見積が膨らむ典型パターンです。

2. 要求定義の段階で要件まで書こうとして固まる

逆に、真面目な担当者ほど「最初から完璧に書かなければ」と考え、画面項目や処理ロジックなど要件レベルの粒度まで自分で書こうとします。結果、用語が分からず手が止まり、ドキュメントが何ヶ月も完成しません。要求定義の段階では、業務目線の粒度で十分です。

3. 要求が後から際限なく増え続ける

優先度を付けずに「あったらいいな」を全部要求として並べてしまうケースです。ベンダーから返ってくる見積は予算を大幅に超え、どこを削るかで社内が紛糾します。要求定義の段階で「これは必須・これは将来」と仕分けておくことが、予算と納期を守るカギになります。

これら3つの失敗を避けるためにも、次の章で紹介する5ステップの準備を意識して進めましょう。

発注側が要求定義で準備すべきこと｜5ステップで進める

このセクションでは、発注側担当者が翌日から動ける具体的なアクションを5ステップで提示します。各ステップに「所要時間目安」「巻き込むべき社内関係者」を併記しているので、社内打ち合わせの計画にそのまま使えます。

ステップ1: プロジェクトの目的とゴールを言語化する

• 所要時間目安: 1〜2週間
• 巻き込む人: 経営層、事業責任者、プロジェクトオーナー

最初にやるべきは「なぜこのシステムを作るのか」を言葉にすることです。具体的には、以下を明らかにします。

• 解決したいビジネス課題（例: 受注処理に1件あたり30分かかっており、繁忙期に処理が追いつかない）
• システム導入で実現したい状態（例: 受注処理を1件あたり10分以内、繁忙期も残業ゼロで回せる）
• 成功とみなす定量指標（例: 月間受注処理時間を50%削減、エラー率を3%未満に）

ここを曖昧にしたまま進めると、後の要求が「課題と関係ない便利機能」で膨らんでいきます。経営層・事業責任者を1〜2回の打ち合わせで巻き込み、目的について合意を取ってください。

ステップ2: 現状業務（As-Is）を棚卸しする

• 所要時間目安: 1〜2週間
• 巻き込む人: 現場担当者、業務マネージャー

次に、現状の業務がどのように回っているかを整理します。「現場で実際にどんな手順で、誰が、どのツールを使って業務をしているか」を可視化する作業です。

棚卸しのコツは以下の3点です。

• ヒアリングは「業務の流れ」「使っているツール」「困っていること」の3点に絞る
• 業務フローは細かい例外まで書こうとせず、まずは主要パスをExcelやMiroで図示する
• 現場で使っているExcelファイル・帳票のサンプルを集めておく（後でベンダーに見せる材料になる）

ここでの目的は完璧な業務マニュアル作りではなく、「現状を把握し、後でTo-Beとのギャップを見つけるための材料を揃える」ことです。

ステップ3: To-Be像と要求事項を洗い出す

• 所要時間目安: 1〜2週間
• 巻き込む人: 現場担当者、業務マネージャー、情シス

ステップ1の目的・ゴールと、ステップ2の現状業務を照らし合わせ、「あるべき姿（To-Be）」と現状のギャップを洗い出します。このギャップを埋めるためにシステムでやりたいことが「要求」です。

要求は最初から整理せず、まずは付箋やスプレッドシートに思いつくまま書き出してください。例えば以下のような粒度で構いません。

• 受注情報を1画面で確認したい
• 月次レポートを自動生成したい
• 在庫数とリアルタイムに連動させたい
• 過去の受注履歴から類似案件を検索できるようにしたい

書き出した要求は、業務領域ごと（受注管理・在庫管理・レポートなど）にグルーピングしておくと、次のステップで優先度を付けやすくなります。なお、各要求を「誰が、どんな状況で、何のために使うか」というユースケース形式で補足しておくと、ベンダーへの伝わりやすさが格段に上がります。

ステップ4: 要求の優先度を決める（MoSCoW法を使う）

• 所要時間目安: 1週間
• 巻き込む人: 経営層、事業責任者、現場マネージャー

洗い出した要求を、初回リリースで実装すべきものとそうでないものに仕分けます。世界的に使われている整理手法が MoSCoW法（モスコー法） です。要求を以下の4つに分類します（MoSCoW分析 - Wikipedia）。

区分	意味	例
Must（必須）	これがないとシステムを導入する意味がない	受注情報の入力・参照、月次レポート出力
Should（重要）	できれば実現したい高価値な要求	在庫数とのリアルタイム連動
Could（あれば良い）	付加価値はあるが必須ではない	類似案件の検索機能
Won't（今回はやらない）	将来検討する要求	多言語対応、AIによる需要予測

SCROLL→

優先度を決める観点としては、QCD（品質・コスト・納期）に加えて以下も意識すると判断がぶれにくくなります。

• 業務インパクト: 業務効率・売上・顧客満足にどれだけ影響するか
• 実現難易度: 既存システムや業務との整合性、必要な工数
• リスク: 実装しないことで生じる業務リスク

優先度を決める打ち合わせは、必ず経営層・事業責任者を巻き込んでください。担当者だけで決めると、後で「これは必須ではないか」と覆されることになります。

ステップ5: 要求定義書にまとめてベンダーに渡す

• 所要時間目安: 1〜2週間
• 巻き込む人: 情シス、プロジェクトオーナー

最後に、ステップ1〜4の成果物を要求定義書としてまとめます。具体的な書き方とテンプレートは次の章で詳しく解説します。

要求定義書ができたら、ベンダーに渡して「この内容で提案書と概算見積をお願いします」と伝えましょう。複数ベンダーに渡す場合はRFP形式に整え、回答期限と評価軸を明記します。ここまで来れば、プロジェクトは「漠然とした構想」から「動き出した案件」に変わります。

要求定義書の書き方｜最低限おさえるべき9項目

このセクションでは、要求定義書を実際に書くときのテンプレート構成を提示します。すべての項目を完璧に埋める必要はありません。「ベンダーが提案書・概算見積を出せる粒度」が合格ラインです。

必須項目（7項目）

最低限、以下の7項目があれば要求定義書として機能します。

項目	記載内容	書く深さの目安
1. 背景	プロジェクトを実施する背景・経緯	200〜400字程度
2. 目的	このシステム導入で実現したいこと	5項目以内に絞る
3. 対象業務範囲	システム化の対象となる業務領域	業務一覧として箇条書き
4. 現状課題	解決したい課題	5〜10項目
5. 要求一覧	システムへの要求	区分（Must/Should/Could）ごとに整理
6. 優先度	各要求の優先度	MoSCoW法で4区分
7. スコープ外	今回のプロジェクトでは扱わない範囲	明示することで認識齟齬を防ぐ

SCROLL→

特に意外と忘れがちなのが「スコープ外」の明記です。「やること」と同じくらい「やらないこと」を書くことで、ベンダーとの認識齟齬を防げます。

あると望ましい項目（3項目）

以下の項目は必須ではありませんが、含めておくとベンダーからの提案精度が一段上がります。

• 成功指標（KPI）: ステップ1で決めた定量指標を記載する。例: 受注処理時間50%削減、エラー率3%未満
• 予算・納期の目安: ベンダーが概算見積のスケールを判断する材料になる。「未定」と書くより「○○万円〜○○万円のレンジで検討中」と書いた方がよい
• 既存システム制約: 連携が必要な既存システム、利用中のクラウドサービス、社内のセキュリティポリシーなど

ベンダーが提案書・概算見積を出せる粒度＝合格ラインの考え方

「どこまで書けばOKか分からない」という不安は、合格ラインを次のように設定すると判断しやすくなります。

要求定義書の合格ライン: ベンダーが提案書・概算見積を作成し、要件定義の見積もできる状態

この基準で考えると、画面の詳細仕様や処理ロジックを書く必要はないことが分かります。逆に、業務範囲が曖昧であったり、優先度が決まっていなかったりすると、ベンダーは見積金額を大きくふらせるしかなく、結果として高めの見積が返ってきます。

完璧を目指して書き続けるよりも、合格ラインに達したらまずベンダーに渡し、不足分はベンダーからの質問やフィードバックで補完していく方が、結果的に早く前に進みます。

書き方のNG例とOK例

要求の文言は、抽象的すぎても具体的すぎても扱いにくくなります。良い粒度は「業務目線で具体的だが、実装方法には踏み込まない」レベルです。

種別	例	コメント
NG（抽象的すぎ）	使いやすくしたい	何が「使いやすい」かが伝わらない
NG（要件レベル）	React で SPA を構築し、Material-UI を使ったレスポンシブ画面を実装したい	実装方法はベンダーの領域
OK	月次帳票出力を3クリック以内・15秒以内で完了したい	業務目線で測定可能な粒度
OK	営業担当者が外出先のスマートフォンから案件状況を確認できるようにしたい	利用者・利用シーン・実現したいことが明確

SCROLL→

OKの例のように「誰が・どんな状況で・何ができるか」のフォーマットを意識すると、自然と良い粒度に収まります。

ベンダーとの対話で詰まらないためのチェックリスト

このセクションでは、要求定義書を渡した後にベンダーから「ここを教えてください」と聞かれて答えに詰まりがちな項目を、4カテゴリに分けて整理します。事前に確認しておくと、打ち合わせの場で「持ち帰り」を連発せずに済みます。

体制・意思決定

ベンダーが最初に確認するのは「誰と話せば物事が決まるか」です。ここが曖昧だと、ベンダーは社内調整に時間を取られ、プロジェクト全体が遅延します。

• 決裁者は誰か: 予算・スコープを最終決定する人
• 窓口担当者は誰か: 日々のやり取りの窓口
• プロジェクトオーナーは誰か: プロジェクト全体の責任を持つ人
• レビュー頻度・場所: 週次・隔週など、定例のリズムと参加メンバー

利用者・利用環境

機能要件・非機能要件を見積もるための前提情報です。これが分からないとベンダーは「想定」で見積を出すしかなく、結果として後で大きな乖離が生じます。

• 想定ユーザー数: 全社で何名が使うか、ピーク時の同時接続数は何名か
• 利用デバイス: PC のみか、スマートフォン・タブレットも対象か
• 対象ブラウザ・OS: 社内標準ブラウザの種類とバージョン
• 利用シーン: オフィス内のみか、外出先・自宅も含むか

データと既存システム

新規システムは既存資産との連携が必須です。データ移行や連携範囲は見積を大きく左右する論点なので、事前に整理しておきましょう。

• データ移行の範囲: 過去データを何年分移行するか、移行対象外のデータはあるか
• 連携対象システム: 既存の会計・販売管理・人事システムなどとの連携要否
• 連携方式の希望: API 連携、ファイル連携、手動転記など
• 既存資産の扱い: 現在使っているExcel・Accessなどを残すのか置き換えるのか

非機能（性能・可用性・セキュリティ・運用保守）

非機能要件は要件定義の段階で詰めるものですが、要求定義の段階でも「最低限ここは守ってほしい」というレベルは伝えられるようにしておきます。

• 性能要件: 主要画面の応答時間目安（例: 3秒以内）
• 可用性要件: 24時間稼働か、計画停止は許容するか
• セキュリティ要件: 社内のセキュリティポリシー、業界規制（個人情報、医療、金融など）
• 運用保守体制: 運用は社内で行うか、ベンダー委託か

すべてを完璧に埋める必要はなく、「分からない項目はベンダーと一緒に決める」というスタンスで構いません。ただし、上記が網羅的に存在することを認識しているだけでも、打ち合わせでの「想定外の質問」が激減します。

要求定義から要件定義への引き渡しで気をつけること

このセクションでは、要求定義書を渡した後の流れと、発注側が要件定義フェーズで担う役割を整理します。「要求定義書を出したら自分の仕事は終わり」と考えてしまうと、要件定義の品質が落ち、結果として完成物が要求と乖離します。

要件定義フェーズで発注側が担う3つの役割

要件定義の主担当はベンダーですが、発注側にも以下の3つの重要な役割があります。

1. ヒアリングへの誠実な対応

ベンダーは要件定義書を作成するために、発注側担当者・現場担当者へのヒアリングを行います。回数は規模にもよりますが、数回〜十数回に及ぶこともあります。「業務が忙しいから」と対応を後回しにすると、ベンダーは推測で要件を埋め、後で大きな手戻りになります。ヒアリングのスケジュールは事前にカレンダーをブロックしておきましょう。

2. 要件定義書のレビューと承認

ベンダーが作成した要件定義書をレビューし、業務的に問題がないかを確認します。レビューの観点は次のセクションで詳しく解説します。要件定義書への合意（承認）は、後続の設計・開発のスコープを確定させる大きな意思決定です。慎重に行ってください。

3. 業務側の意思決定

要件定義の過程では、「Aの業務フローでもBの業務フローでも実装可能だが、どちらにしますか」というような、業務側の判断が必要な論点が次々と出てきます。これらを意思決定するのは発注側の役割です。事業責任者とのコミュニケーションラインを確保しておきましょう。

要件定義書のレビューで確認すべき観点

要件定義書をレビューする際は、技術的な妥当性ではなく「要求が漏れなく要件に翻訳されているか」を中心に確認します。

• 要求定義書に記載した「Must」要求が、すべて要件として記述されているか
• 業務フロー上、明らかに抜けている処理や画面はないか
• 業務用語の解釈にズレがないか（例: 「商談」の定義が業務側とベンダー側で同じか）
• スコープ外と明記した内容がうっかり要件に含まれていないか

技術的な実装方法（言語選定、アーキテクチャなど）の妥当性は、社内に判断できる人がいなければ無理に踏み込む必要はありません。第三者のITコンサルタントにセカンドオピニオンを求めるのも一つの選択肢です。

要求と要件の追跡可能性（トレーサビリティ）の重要性

最後に、要求定義書と要件定義書の間で「どの要求がどの要件に対応するか」を追跡できる状態を保ちましょう。これを 要求トレーサビリティ と呼びます。

トレーサビリティを保つメリットは2つあります。

• 要件定義書で要求の取りこぼしがないかを確認しやすい
• 開発中・テスト中・運用後に「なぜこの機能が必要だったか」を遡れる

具体的な方法としては、要求定義書の各要求にIDを振り（REQ-001、REQ-002…）、要件定義書の各要件にも対応する要求IDを記載する形が一般的です。ベンダーに対してトレーサビリティの維持を要望として伝えておくと、要件定義書の作成段階から考慮してもらえます。

まとめ｜要求定義は発注側の準備力でプロジェクトの成否が決まる

要求定義は、システム開発プロジェクトの中で発注側が最も主体的に動く工程です。技術はベンダーに任せられても、「自社が何を実現したいか」を言語化できるのは発注側だけです。

本記事の要点を3つにまとめます。

• 違いを理解する: 要求はWHY（なぜ・何を実現したいか）、要件はWHAT・HOW（具体的な機能・実装方法）。発注側は要求定義を主担当し、要件定義はベンダーと一緒に作る
• 5ステップで準備する: 目的整理 → 現状業務の棚卸し → To-Beと要求の洗い出し → MoSCoW法で優先度決定 → 要求定義書化、の流れで進めれば、最短2ヶ月程度でベンダーに渡せる状態になる
• チェックリストで詰める: 要求定義書を渡す前に、体制・利用者・データ・非機能の4カテゴリでベンダーから聞かれそうな項目を確認しておくと、打ち合わせで詰まらない

明日からの第一歩としては、まず本記事の「ステップ1: プロジェクトの目的とゴールを言語化する」を社内打ち合わせのアジェンダに入れてください。経営層・事業責任者を巻き込み、「なぜこのシステムを作るのか」「何を成功とみなすか」の合意を取ることが、その後すべての作業の土台になります。

要求定義の質は、プロジェクト全体のQCD（品質・コスト・納期）を大きく左右します。最初の準備に時間をかけることで、後工程の手戻り・追加コスト・納期遅延を大幅に減らせます。本記事を片手に、まずは小さく一歩を踏み出してみてください。