要件定義を頼まれたけれど、どこから始めればいいのかわからない——そう感じている方は少なくありません。「要件定義が必要です」と開発会社から言われたとき、「そもそも要件定義って何をするの？」「自分は何を用意すればいいの？」と戸惑うのは当然のことです。
要件定義は、システム開発の成否を大きく左右する重要なフェーズです。しかし、その重要性を強調するあまり、「難しそう」「専門知識が必要」というイメージが先行しがちです。実際には、発注者として把握しておくべきプロセスの流れは明確で、各ステップで何を準備し何を判断するかがわかれば、開発会社との打ち合わせに自信を持って臨めます。
本記事では、要件定義の目的と全体像から始まり、5つのステップを順番に解説します。各ステップで「発注者として何をすべきか」を具体的にお伝えするので、初めてシステム開発を発注する方でも安心して読み進めていただけます。
なお、要件定義書の実際の書き方・記入例・テンプレートについては、「要件定義書の書き方とテンプレート」で詳しく解説しています。本記事では「どう進めるか（プロセス）」に絞って説明します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
要件定義とは（目的・成果物・期間）
要件定義とは、システム開発を始める前に「何を作るか」を開発会社と合意するためのフェーズです。業務の課題・解決策・必要な機能・性能・予算・スケジュールを整理し、最終的に「要件定義書」という文書にまとめます。
要件定義の目的
要件定義の目的は、一言で言えば「認識のズレをなくすこと」です。
開発会社は、あなたの業務を詳しく知りません。あなたの言葉の裏にある業務の文脈や暗黙知を、正確に汲み取ることはできません。そのギャップを埋めるために行うのが要件定義です。「依頼した内容と違うものが完成した」という最も多いトラブルのほとんどが、要件定義の段階での認識のズレから生じています。
要件定義の成果物
要件定義フェーズが終わると、以下の成果物が揃います。
- 要件定義書: 業務要件・機能要件・非機能要件・制約条件・体制をまとめた文書
- 業務フロー図: 現在の業務の流れと、システム導入後の理想フローを図示したもの
- 画面イメージ・画面一覧: 主要な画面の概要スケッチ（ワイヤーフレーム）
要件定義にかかる期間
要件定義にかかる期間の目安は以下のとおりです。
開発規模 | 要件定義期間の目安 |
|---|---|
小規模（100万円未満） | 1〜2週間 |
中規模（100〜500万円） | 1〜2ヶ月 |
大規模（500万円以上） | 2〜4ヶ月 |
成功しているプロジェクトでは、要件定義に全体工程の30〜40%の時間をかけています。「要件定義が終わったら本当の開発が始まる」というイメージよりも、「要件定義こそが開発の核心」と捉えると期間の重要性が理解しやすくなります。
また、要件定義が上流工程全体の中でどのような位置づけにあるかは、「システム開発の上流工程とは？」で詳しく解説しています。
要件定義の進め方：5つのステップ
要件定義は大きく5つのステップで進みます。ステップごとに「何をするか」と「発注者として何を準備するか」を整理しました。
ステップ1：現状の業務を整理する
最初のステップは、現在の業務フローの棚卸しです。「なぜシステムが必要か」「現在の業務のどこに課題があるか」を整理します。
このステップでやること（開発会社が主導）:
- 現行業務のヒアリング（担当者へのインタビュー）
- 現在の業務フロー・使用している帳票・ツールの確認
- 課題・ボトルネックの洗い出し
発注者として準備すること:
- 現在の業務フローを口頭または簡単な図で説明できるように整理しておく
- 課題を感じている業務担当者（現場の声を持っている人）に同席してもらう
- 既存のシステム・ツール・帳票のサンプルを手元に用意する
ポイント: このステップで最もよくある失敗は、「経営層の認識」と「現場の実態」がズレていることです。現場で実際に作業している方の声を必ず反映させてください。
ステップ2：理想の業務フローを設計する
現状の課題が整理できたら、「システムを入れた後の理想の業務フロー」を設計します。ここで重要なのは、「現在の業務をそのままシステム化する」のではなく、「業務プロセス自体を改善した上でシステム化する」という視点です。
このステップでやること（開発会社が主導）:
- 理想の業務フローの設計
- 自動化できる作業・人間の判断が必要な作業の分類
- 段階的な実装計画の検討（一度にすべての機能を実装するか、段階的に進めるか）
発注者として判断すること:
- 「あったらいい機能」と「なくてはならない機能」の優先順位
- 段階的な実装計画への同意（まず最小限の機能で動かすか、全機能を一度に実装するか）
- 業務プロセスを変えることへの組織内の合意
ポイント: このステップは「業務改革」の意思決定を含みます。開発会社が提案する「理想フロー」に対して、「自社で受け入れられるか」「組織の合意が得られるか」をあなた自身が判断する必要があります。
ステップ3：必要な機能を具体化する
理想の業務フローが決まったら、それを実現するために必要な機能を一つひとつ具体化します。
このステップでやること（開発会社が主導）:
- 機能一覧の作成（業務フローの各ステップで必要な機能を洗い出す）
- 各機能の詳細仕様の確認（「〇〇ができる」を「どのような操作で・どのような結果が得られるか」まで具体化）
- 非機能要件の確認（画面表示速度・同時ユーザー数・セキュリティ要件など）
発注者として確認すること:
- 機能一覧を見て、「これは不要」「これが足りない」という箇所がないかチェックする
- 業務知識が必要な仕様（「承認フローは誰が誰に承認するか」など）を確認・決定する
- 「〇〇ができる」という説明に対して、実際の業務シーンをイメージして確認する
ポイント: 「なんとなくOK」で進めるのが最も危険なタイミングです。「3クリック以内で操作できる」「処理は2秒以内」など、開発会社が具体的な数値で説明している場合は、その数値が自社の業務に適しているかを確認してください。
ステップ4：優先順位と実装計画を決める
すべての機能を一度に実装するのは、予算・期間・リスクの観点から非効率です。このステップでは、機能の優先順位をつけて段階的な実装計画を立てます。
このステップでやること（開発会社が主導）:
- 機能ごとの実装難易度・期間・費用の概算
- 優先順位マトリクス（「業務インパクト」×「実装難易度」）の作成
- フェーズ分けの提案（Phase 1 = 最小限の機能、Phase 2 = 拡張機能など）
発注者として判断すること:
- どのフェーズまでを今回の発注範囲とするか
- 各フェーズのリリースタイミング（「〇月の業務繁忙期は避けたい」など）
- 予算の上限と各フェーズの費用配分
ポイント: このステップで「全機能を一度に」と判断することが、後の予算超過・納期遅延の主因になります。「まず使えるものを早く動かして、改善を重ねる」という方針が、リスクを最小化します。
ステップ5：要件定義書にまとめて合意する
最終ステップは、これまで決めてきた内容を要件定義書にまとめ、双方が合意することです。
このステップでやること（開発会社が主導）:
- 要件定義書の作成（業務要件・機能要件・非機能要件・制約条件・体制をまとめた文書）
- 要件定義書の読み合わせ・確認
- 最終合意・承認
発注者として確認すること:
- 要件定義書の内容が「話し合いで決めたこと」と一致しているか
- 曖昧な表現（「〜など」「適宜」「なるべく」）が残っていないか
- 誤解が生じそうな専門用語について、認識が合っているか確認する
ポイント: 要件定義書はプロジェクトの「契約の根拠」になります。「難しくてよくわからない」という部分はそのままにせず、必ず開発会社に質問して納得してから承認してください。
要件定義書の具体的な書き方・7つの記入項目・テンプレートについては、「要件定義書の書き方とテンプレート」で詳しく解説しています。
発注者が各ステップで果たす役割
要件定義は「開発会社が主導するもの」と思われがちですが、発注者の積極的な関与がなければ成功しません。各ステップにおける発注者の責任範囲を整理します。
発注者が「決める」べきこと
以下は、開発会社が代わりに決めることはできません。発注者自身が判断する必要があります。
ステップ | 発注者が決めること |
|---|---|
ステップ1 | どの業務課題をシステムで解決するか（優先課題の選定） |
ステップ2 | 業務プロセスをどこまで変えるか（業務改革の範囲） |
ステップ3 | どの機能を「必須」とするか（MustとWant の仕分け） |
ステップ4 | 今回の発注範囲と予算・期間の上限 |
ステップ5 | 要件定義書の最終承認 |
発注者が「提供」すべきこと
開発会社が要件定義を正確に進めるために、発注者側から提供が必要な情報があります。
- 業務の詳細情報: 現在の業務フロー・帳票・使用ツールのサンプル
- 現場の声: 現場担当者へのヒアリングへの協力（日程調整・同席）
- 意思決定のスピード: 「後で考えます」を繰り返すと要件定義が長期化します
「丸投げ」が招くリスク
「詳しいことは開発会社に任せます」という姿勢で進めると、以下のリスクが生じます。
- 現場の実態と乖離した仕様になる
- 開発後に「こんな機能は必要なかった」「あの機能が足りない」が発覚する
- 追加費用・納期遅延が発生する
発注者は「業務の専門家」として、開発会社は「技術の専門家」として、互いの専門性を持ち寄ることが要件定義成功の鍵です。
要件定義でよくある失敗と回避策
失敗1：曖昧な表現で進めてしまう
「使いやすいシステムにしてほしい」「できるだけ速く動くように」——このような曖昧な表現は、認識のズレの温床になります。開発完了後に「こんなはずではなかった」となる原因の多くが、曖昧な要件です。
回避策: 「使いやすい」なら「3クリック以内で主要操作が完結すること」、「速い」なら「画面表示は2秒以内」というように、具体的な数値や条件で表現するよう、開発会社に確認を求めてください。
失敗2：現場の声を反映しない
経営層や企画部門だけで要件定義を進め、実際にシステムを使う現場担当者が関与しないと、「便利なはずなのに誰も使わないシステム」が完成します。
回避策: 要件定義の初期段階から、現場のキーパーソンを少なくとも1〜2名、打ち合わせに参加させてください。「現場の声を聞く機会」を意図的に設けることが重要です。
失敗3：変更管理の仕組みがない
要件定義が完了してから「やっぱりこの機能も追加したい」という追加要望は、費用・期間の大幅な変更につながります。
回避策: 要件定義書の承認後は「変更管理プロセス」を設けることを開発会社と合意してください。「変更が発生したら見積もりを再提示する」というルールを最初に決めておくことで、後からの紛争を防げます。
失敗4：期間を短縮しようとする
「要件定義は早く終わらせて、早く開発を始めたい」という気持ちは理解できます。しかし、要件定義を短縮した結果、開発後の修正・追加対応に倍以上のコストがかかるケースが頻繁に発生します。
回避策: 要件定義の期間を開発規模に応じて確保してください。一般的に、開発後に要件を変更する費用は要件定義段階の5〜10倍になります。
要件定義の次のステップ（設計・見積もりへ）
要件定義が完了すると、プロジェクトは次のフェーズに進みます。
見積もり（詳細見積もり）
要件定義完了後、開発会社から詳細な見積もりが提示されます。要件定義前の「概算見積もり」とは異なり、確定した仕様をもとにした正確な費用・期間が示されます。
見積もりのチェックポイントについては、「システム開発における見積もりのチェックポイント」で詳しく解説しています。
基本設計（外部設計）
要件定義の内容をもとに、システムの具体的な画面設計・データ設計・機能設計を行うフェーズです。要件定義書で「何を作るか」が決まっていれば、基本設計はスムーズに進みます。
要件定義から設計・開発への橋渡しのポイント
- 要件定義書を「一度作って終わり」にせず、設計フェーズでも参照しながら進める
- 仕様の認識がズレていないか、設計フェーズの初期にも確認する
- 変更が発生した場合は、必ず要件定義書を更新する
上流工程全体の流れ（要件定義→設計→開発→テスト）については、「システム開発の上流工程とは？」で詳しく解説しています。
まとめ
要件定義の進め方を5つのステップで解説しました。
- ステップ1: 現状の業務を整理する（現状分析・課題の洗い出し）
- ステップ2: 理想の業務フローを設計する（業務改善・自動化計画）
- ステップ3: 必要な機能を具体化する（機能要件・非機能要件の確定）
- ステップ4: 優先順位と実装計画を決める（段階的実装の計画）
- ステップ5: 要件定義書にまとめて合意する（最終承認）
各ステップで発注者として「決めること」「提供すること」「確認すること」を意識することで、開発会社との打ち合わせに主体的に参加できます。
要件定義は難しいものではありません。業務の専門家であるあなたが、技術の専門家である開発会社と協力して進めるプロセスです。各ステップで何を聞かれ、何を決めればいいかがわかれば、要件定義は自然に進んでいきます。
次のステップとして、「要件定義書の書き方とテンプレート」もあわせてご覧ください。7つの記入項目と記入例で、要件定義書の作成がより具体的に進められます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
