要件定義の進め方｜発注者がやるべきことと成果物
システム開発の成否は、要件定義でほぼ決まるといわれます。要件定義で決めたことが設計・開発・テストのすべての土台になるため、ここでの漏れや曖昧さは、後の工程で手戻りや追加費用として表面化します。
一方で、「要件定義は開発会社がやってくれるもの」と考えている発注者も少なくありません。この記事では、要件定義の進め方を6つのステップで解説し、発注者がやるべきことと、成果物である要件定義書の内容を紹介します。
- 要件定義とは、システムで「何を実現するか」を発注者と開発会社で合意し、文書にする工程
- 進め方は「目的の確認 → 現状業務の把握 → 課題と要求の整理 → 要件の定義 → 優先順位づけ → 合意」の6ステップ
- 発注者の役割は、業務の説明・要望の優先順位づけ・最終判断。開発会社任せにはできない
- 期間は中規模の業務システムで1〜2か月、費用は開発全体の10〜15％程度が目安
目次
要件定義とは
要件定義とは、システムに求める機能や性能、条件を明確にし、発注者と開発会社の間で合意する工程です。「こんなシステムがほしい」という要望（要求）を、開発できる具体的な形（要件）に落とし込みます。
| 用語 | 意味 | 例 |
|---|---|---|
| 要求 | 発注者の「こうしたい」という要望 | 在庫をリアルタイムで把握したい |
| 要件 | システムで実現する具体的な内容 | 入出庫登録時に在庫数を自動更新し、一覧画面で商品別・倉庫別に表示する |
要件は大きく機能要件（システムが何をするか）と非機能要件（性能・セキュリティ・可用性など、どのように動くか）に分かれます。
要件定義の進め方（6ステップ）
要件定義の6ステップ
- 目的とゴールの確認システム化の目的、成功の基準、対象範囲を合意する
- 現状業務の把握今の業務の流れ、使っている帳票・Excel、関係者を洗い出す
- 課題と要求の整理困っていること、実現したいことを集めて整理する
- 要件の定義新しい業務の流れ、機能、画面、帳票、データ、非機能要件を決める
- 優先順位づけ必須・重要・任意に分け、今回の範囲を決める
- 要件定義書の作成と合意文書にまとめ、関係者が確認・承認する
STEP1 目的とゴールの確認
最初に、「なぜシステムを作るのか」「何ができたら成功か」を確認します。目的が共有されていないと、要望が際限なく広がり、範囲が決まりません。できれば「月40時間の作業削減」のように数値でゴールを置きましょう。
STEP2 現状業務の把握
開発会社が業務担当者にヒアリングし、現在の業務の流れ（As-Is）を整理します。発注者は、実際に使っているExcelや帳票、業務マニュアルを提供し、例外的なケースも含めて説明します。
STEP3 課題と要求の整理
現状の業務から課題を洗い出し、「こうしたい」という要求を集めます。部門によって要求が異なる場合は、この段階で調整が必要です。
STEP4 要件の定義
システム化後の業務の流れ（To-Be）を描き、必要な機能、画面、帳票、データ、外部連携、非機能要件を具体的に決めます。画面のイメージ（ワイヤーフレームやプロトタイプ）を作ると、認識のズレを防げます。
STEP5 優先順位づけ
すべての要望を最初から実現しようとすると、予算と期間が膨らみます。必須・重要・任意の3段階に分け、今回の開発範囲を決めましょう。
STEP6 要件定義書の作成と合意
決めた内容を要件定義書にまとめ、発注者の関係者と開発会社が確認して合意します。この文書が、以降の設計・開発・テストの基準になります。
発注者と開発会社の役割分担
発注者がやること
- 目的・ゴールの決定
- 業務の説明と資料の提供
- 現場担当者のヒアリング参加
- 要望の優先順位づけ
- 要件定義書の確認・承認
開発会社がやること
- ヒアリングと業務の整理
- 実現方法と代替案の提案
- 要件の文書化
- 画面イメージの作成
- 費用・スケジュールへの影響の説明
要件定義の主役は発注者です。開発会社は専門家として整理と提案を行いますが、「何を作るか」を最終的に決めるのは発注者です。
要件定義の成果物
- 要件定義書：目的、範囲、機能要件、非機能要件、前提条件をまとめた文書
- 業務フロー図：システム化後の業務の流れ
- 機能一覧：実現する機能と優先度
- 画面一覧・画面イメージ：画面の種類とレイアウトのイメージ
- 帳票一覧：出力する帳票の種類と項目
- データ定義（概要）：扱うデータの種類と主な項目
要件定義書に書く項目の詳細は、テンプレートつきの記事で解説しています。
期間と費用の目安
| システムの規模 | 期間の目安 | 費用の目安 |
|---|---|---|
| 小規模（単一業務） | 2〜4週間 | 開発全体の10〜15％程度 |
| 中規模（複数機能） | 1〜2か月 | 開発全体の10〜15％程度 |
| 大規模（基幹業務） | 2〜6か月 | 開発全体の10〜20％程度 |
要件定義は、準委任契約で独立したフェーズとして発注し、その成果物をもとに開発の見積もりを確定させる進め方が安全です。
要件定義で失敗しないためのポイント
- 決裁者に早い段階から関わってもらう：後からの方針変更を防ぐ
- 現場の担当者を必ず参加させる：例外的な業務の漏れを防ぐ
- 「やらないこと」も決める：範囲の曖昧さをなくす
- 画面イメージで確認する：文章だけでは認識がずれやすい
- 決まらないことは期限を決めて保留にする：議論が長引いてスケジュールが遅れるのを防ぐ
よくある質問
- 要件定義は誰がやるものですか？
- 発注者と開発会社が共同で行います。開発会社がヒアリングと整理・文書化を担い、発注者が業務の説明と要望の優先順位づけ、最終判断を担います。
- 要件定義だけを依頼することはできますか？
- できます。要件定義を独立したフェーズとして依頼し、成果物をもとに開発の見積もりを取る進め方は、費用のブレを抑えられるためおすすめです。
- 要件定義が長引くのはなぜですか？
- 目的が共有されていない、決裁者が不在で決まらない、部門間の要望が調整できていない、といった原因がよくあります。目的の確認と、決定のルールを最初に決めておくことが大切です。
- 要件定義の後に要件を変更できますか？
- 変更は可能ですが、工程が進むほど影響範囲が大きくなり、費用と期間が増えます。変更の手続きと費用の扱いを事前に取り決めておきましょう。
まとめ
要件定義は、目的の確認、現状業務の把握、課題と要求の整理、要件の定義、優先順位づけ、合意の6ステップで進めます。発注者は業務の説明と優先順位の判断を担う主役であり、開発会社任せにはできません。
要件定義にしっかり時間をかけることが、結果的に費用と期間を抑え、使われるシステムをつくる近道です。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
