要件定義とは？基本設計／詳細設計との違いと進め方を解説

2025.09.17

システム開発における開発工程の一部である要件定義について具体的にどのようなことをしているのか。よく比較されがちな基本設計や詳細設計と何が違うのか。

その辺りも含めて本記事では解説していきたいと思います。

1.要件定義とは？

システム開発の一連の流れの中で一番上に位置する（最初にやること）要件定義。ここで手を抜くとシステム開発はだいたいは失敗します。そんな要件定義について1章では概要を説明します。

1-1.要件定義は、クライアントの要望をまとめること

要件定義は、クライアントが作りたいシステムがどんなものかヒアリングして、要件定義書という形でドキュメント化する工程になります。

※要件定義書については、2章以降で詳しく解説いたします。

要件定義で、クライアントが欲しいシステム要件をまとめることになるので、ここで曖昧な状態で進めると、最後出来上がった時に「思っていたモノと違う」というトラブルになりかねません。そのような時は再度システム開発をすることになり、多額の不要な費用が発生しかねません。このようなトラブルを回避するためにも要件定義はかなり重要なフェーズです。

1-2.要件定義は、上流工程に位置する

要件定義は上流工程の中でも上流に位置するフェーズになります。上流の中の上流、システム開発における王様的な存在です。
※水の流れのように開発が進んでいくので、「上流」と呼んでいます。逆にテスト工程は「下流」と呼びます。

要件定義ではこんなことを決めてまとめていきます…

全体のスケジュール（何をいつまでに終わらせるか）
全体で掛けることができる予算
開発手法
リリースする方法
リリース後の運用方法　など…

システム開発は要件定義で決めた内容に沿って大枠は進んでいくので決裁権のある人たちも含めて話し合いを重ねていきます。クライアント側×開発側でプロジェクトマネージャー, プロジェクトリーダーを交えて決めていきます。

各工程を以下のように略して呼ぶこともあるので、ここで覚えておくと良いでしょう。

工程	略称	英語
要件定義	RD	Requirement Definition
基本設計	BD	Basic Design
詳細設計	DD	Detail Design
単体テスト	UT	Unit Test
結合テスト	IT	Integration Test
システムテスト	ST	System Test
運用テスト	OT	Operation Test

1-3.基本設計や詳細設計との違い

良く比較されるのが、基本設計と詳細設計の違いです。簡単に表にまとめると以下の通りです。

名称	工程		対象	内容
要件定義	最上流	WHY （なぜ作るのか）	クライアント向け	システム導入する背景・課題、システム全般の概要
基本設計	要件定義の次	WHAT （何を作るのか）	クライアント向け	システムの各機能、画面イメージ等具体化したもの
詳細設計	基本設計の次	HOW （どうやって作るのか）	開発者向け	基本設計を開発者向けにアレンジしたもの

要件定義は最上流に位置するもので、クライアントから課題やどんなシステムを開発したいのか隅々まで確認することになります。その情報をもとに基本設計以降の工程に入るので、要件定義の時点で齟齬があれば完成品が思ったものと違うものができてしまいます。

2.要件定義書の進め方

2章からは実際に要件定義書を作成するために必要な情報を紹介していきます。まずは要件定義書をどうやって作り進めていけば良いか紹介します。

2-1.現状の課題分析

クライアントからどんな課題を持って、今回システム開発をすることになったのか確認します。ここでは、クライアントから良くいただく課題を紹介します。

＜よくある課題＞

手作業が多く、非効率である
ヒューマンエラーが多いので防ぎたい
情報を一元化したい
既存システムが古いので刷新したい
既存システムでは不足している機能が多すぎる

2-2.システムの開発目的

課題が見えてきたら次にその課題を解決するためにどんなシステムがあったら解決できるか精査していきます。クライアントが気づいていない課題が潜んでいる可能性もあるので、隠れた課題を見つけ出すことも重要です。いわゆるコンサルティング的なことをしていきます。

2-3.システムで実現可能性を精査

続いて、そのシステム開発がどこまで実現可能性があるか精査します。機能が多ければ多いほど費用も増え、時間も掛かるので必須機能、希望機能を洗い出す必要があります。優先順位を決めて、リリース後に希望機能は付け足していく等…進め方は様々あります。クライアントに今回の予算と納期を確認して良い塩梅を探っていきます。

2-4.機能要件を整理

必須機能、希望機能までまとまったら、クライアントの要求を「業務要件」「機能要件」「非機能要件」の3つに分けて整理していきます。

業務要件：目的を達成するために必要な機能や条件をまとめたもの

機能要件：業務要件の中でシステム化することで何が実現できるのかまとめたもの

非機能要件：業務要件の中でシステム化以外で必要な要件をまとめたもの

2-5.予算・体制・スケジュールを設定

最後にここまで整理してきた内容に対して、「いくら掛けて」、「どのような体制」で、「いつまで」に、を決めます。無理な予算、無理な体制、無理なスケジュールでは失敗に繋がりかねません。現実的な計画を立てるようにしましょう。

決まった内容をドキュメントとして残す必要があります。それが要件定義書と呼ばれる代物です。要件定義書の書き方については、3章でまとめています。何か決められたフォーマットがあるわけではないので、自分がまとめやすいにまとめていきましょう。

3.要件定義書に記載すべき項目

3章では要件定義書の中身について踏み込んで紹介していきます。要件定義書は書く人によって内容等が変わりますが、3章で記載している内容は最低限入れるように心がけましょう。

3-1.プロジェクトの概要

まずは与件の整理から入ります。今回のプロジェクトでシステム化することにより、何を実現することができるのか、開発の目的と背景を記載します。関係者の共通認識がずれないようにシステム全体の概略図や、今回のプロジェクトで使われる用語・略語等の定義をまとめたりもします。

＜入れる内容（例）＞

システム化の目的／背景
システム化しないといけない課題
システム全体の概略図
プロジェクトのオリジナル用語／略語の定義

3-2.システム導入後の姿

続いて、現在の業務が今回のシステムが導入されることでどのような姿になるか理想郷を入れます。システムがある場合／ない場合で、何がどう便利になるのかまとめます。まとめるにあたり、今課題になっているものを一覧化すると分かりやすいです。

＜入れる内容（例）＞

業務要件一覧／フロー図
業務の規模
業務の時間や時期
業務の場所
業務の範囲（どの範囲をシステム化するか）
システム化する前と後の変化

3-3.機能要件を整理

ここでは、システムで具体的にどのような機能が必要になるか画面のイメージを含めて整理していくことになります。ここで、抜け漏れがあると本当はこの機能必要だったのに、、という事態が起きるので時間を掛けて練っていく必要があります。

＜入れる内容（例）＞

システムに必要な機能一覧
各機能の役割や画面イメージ
システムに蓄積されたデータの取り扱い／処理方法
API連携（外部システムとの連携）

3-4.見えない部分の機能を整理

3-3では表側を整理しましたが、続いて裏側（ユーザーから見えない部分）を整理することになります。裏側だからといって手を抜いてはいけません。ユーザーがストレスなくシステムを使うためには裏側が重要になってきます。

＜入れる内容（例）＞

想定されるユーザー規模数（同時接続数）
処理速度や閾値等の必要最低限の性能
バックアップの性能
将来的な拡張性
セキュリティレベル
リリース前のテストの種類と方法
リリース後の保守・運用体制／内容（いつまで継続していくか）

4.要件定義で失敗を避けるためのポイント

ここまで要件定義の流れと記載すべき内容をまとめてきました。4章では要件定義において、失敗を避けるために何を注意したら良いか紹介していきます。

4-1.クライアントの要望を隅々まで確認する

クライアントが作りたいシステムを納品しないと意味がありません。クライアントが気づいていないところ（決めないといけないところ）もあるかもしれません、ヒアリング側が積極的に引き出しを開けに行くようにしましょう。

4-2.専門用語少なめで、コミュニケーションを取る

クライアントが非IT系の会社の場合もあります。その際は、IT業界用語を連発してしまうと齟齬が生じる可能性が高いです。IT知識がない人でも伝わるような一般的な言葉でコミュニケーションを取るようにしましょう。

4-3.WBSを活用してスケジュール管理

WBSを活用してスケジュールとタスク管理、そのタスクは誰がやるのかを管理するようにしましょう。曖昧なママ進めると、なあなあになりがちなので、ある程度のマイルストーンは置いてそこに向けて進めるようにしましょう。

「要件定義とは」まとめ

システム開発における要件定義に解説してきました。要件定義はプロジェクトの立ち上げ時期であり、システム開発の工程における最も重要なフェーズです。要件定義を曖昧なママ進めてしまうと開発が終わってから、この機能必要だった、いろんなバグが出てきた、、そんな事態に陥りかねません。最悪な場合、その会社の世間からの信頼が爆落ちする可能性もあります。