「要件定義を確認してください」と言われても、何を確認するのか分からず戸惑う方も多いでしょう。
要件定義は、これから作るシステムについて、目的や必要な機能、満たすべき条件などを関係者で整理し、合意する作業です。
この記事では、要件定義の意味と進め方を注文住宅の例で解説します。要求との違い、機能要件と非機能要件、基本設計や受入テストとのつながりも初心者向けに整理します。
💡 このページでわかること
- 要件定義の意味と目的
- 要求と要件の違い
- 要件定義で決める内容
- 要件定義の進め方と関わる人
- 基本設計や受入テストとのつながり
要件定義とは？
要件定義とは、作りたいシステムについて、なぜ必要なのか、何が必要なのか、どのような条件を満たすべきかを関係者で整理し、合意する作業です。
たとえば、会社から「注文管理の仕事を効率化したい」という相談があったとします。
この言葉だけでは、どの仕事をどのように変えたいのか、誰が使うのか、何件の注文を扱うのかが分かりません。そのまま開発を始めると、完成後に「必要な機能がない」「現場の仕事に合わない」といった問題が起こります。
そこで、現在の仕事や困りごとを確認し、必要な機能、性能、利用者、対象範囲、運用方法などを具体的にします。その結果を関係者が確認し、これから作るシステムの共通認識にするのが要件定義です。
要件定義の目的
要件定義の目的は、依頼する側と作る側が「何を目指し、何を作るのか」を共有することです。
主に次のような認識をそろえます。
- システムを導入する目的
- 解決したい仕事上の問題
- システムを使う人
- 必要な機能と品質
- 今回作る範囲と作らない範囲
- 予算、期限、法律などの制約
- 完成後の運用方法
すべての希望を無条件に入れるのではありません。重要度や費用、期限、実現できるかどうかを考え、今回の開発で対応する内容を決めます。
開発工程のどこで行う？
要件定義は、一般に、設計や実装へ進む前の段階で行います。
順番を単純化すると、次のようになります。
- 目的や課題を整理する
- 要件定義で、必要なことや条件を決める
- 設計で、実現方法を具体化する
- 実装して、動くシステムを作る
- テストで、決めた内容を満たすか確認する
- 利用開始後に運用・保守を行う
ただし、要件定義が必ず一度で終わるとは限りません。開発の進め方によっては、小さな機能ごとに要件を確認したり、試作品を見ながら見直したりします。
要求と要件の違い
要求は「こうしたい」という希望や必要性です。要件は、その要求を実現するために、システムや仕事が満たすべき内容を具体的にしたものです。
| 比較項目 | 要求 | 要件 |
|---|---|---|
| 意味 | 実現したいことや解決したい問題 | 実現のために満たすべき具体的な内容や条件 |
| 表現の例 | 注文確認の手間を減らしたい | 注文を番号・氏名・日付で検索できる |
| 確認のポイント | なぜ必要なのか | 満たしたか判断できるか |
「業務を効率化したい」だけでは、何を作ればよいか判断できません。
そこで、「注文を検索できる」「発送待ちの注文を一覧で確認できる」など、実現したか確かめられる形へ具体化します。
要求と要件の言葉の使い方は、会社や資料によって異なる場合があります。実務では言葉だけで判断せず、その資料で何を指しているか確認しましょう。
具体例｜注文住宅で考えよう
要件定義は、注文住宅を建てる前の打ち合わせに似ています。
依頼する人が「家族が過ごしやすい明るい家にしたい」と希望したとします。これは、実現したい暮らしについての要求です。
しかし、このままでは家を設計できません。家族構成や予算、土地の広さを確認し、次のように具体化します。
- 家族4人で暮らす
- 個室を3部屋用意する
- リビングには南向きの大きな窓を設ける
- 予算は決められた範囲内にする
- 入居希望日までに完成させる
システム開発でも同じように、「仕事を楽にしたい」という希望から、誰が何をできる必要があるか、速さや安全性はどの程度必要か、予算や期限にどのような制約があるかを整理します。
たとえ話とITの要件定義が完全に同じわけではありませんが、曖昧な希望を、関係者が確認できる具体的な条件へ整理する点は共通しています。
要件定義では何を決める？
要件定義では、機能だけでなく、業務の目的、対象範囲、性能、安全性、運用方法なども整理します。
プロジェクトによって内容は異なりますが、初心者の方は次の4つに分けると理解しやすくなります。
業務の目的と対象範囲
最初に、何のためにシステムを作るのかを明確にします。
- どの仕事の問題を解決するのか
- 誰がシステムを使うのか
- どこからどこまでをシステム化するのか
- 今回は何を対象外にするのか
目的や範囲が曖昧だと、必要性の低い機能が増えたり、重要な機能が抜けたりします。
機能要件
機能要件とは、システムで「何ができる必要があるか」を表す要件です。
注文管理システムなら、次のような内容が当てはまります。
- 注文を登録できる
- 注文番号や氏名で検索できる
- 発送状態を変更できる
- 利用者の権限によって操作を制限できる
- 発送後に購入者へメールを送れる
画面名やボタン名を決めるだけでなく、利用者がどの仕事を完了できる必要があるかを考えます。
非機能要件
非機能要件とは、機能以外に求める品質や条件です。
たとえば、次のような内容があります。
- 画面をどの程度の速さで表示するか
- 何人が同時に利用できるか
- 障害が起きたとき、どの程度の時間で復旧するか
- 誰がどの情報を見られるようにするか
- 初めて使う人でも操作しやすいか
- 将来の利用者やデータの増加に対応できるか
「速い」「安全」「止まらない」のような曖昧な表現では、満たしたか判断できません。必要に応じて、時間や件数などの測れる条件へ具体化します。
データ・外部連携・運用などの条件
システムを実際に使い続けるには、機能と品質以外の条件も必要です。
- どのデータを保存し、どのくらいの期間残すか
- ほかのシステムと、どの情報をやり取りするか
- 現在のシステムからデータをどう移すか
- 誰が利用者登録や設定変更を行うか
- バックアップや障害対応をどうするか
- 法律、社内規則、予算、期限などの制約
どこまでを要件定義書へ記載するかは、会社やプロジェクトによって異なります。大切なのは、開発や利用開始に必要な条件を関係者が確認できる状態にすることです。
要件定義はどう進める？
要件定義は、依頼を聞いて書類にまとめるだけの作業ではありません。関係者から情報を集め、矛盾や抜けを確認し、合意できる内容へ整理します。
関係者から要求を集める
まず、業務担当者や利用者へ聞き取りを行います。現在の仕事を観察したり、既存の資料や画面を確認したりすることもあります。
ここでは、欲しい機能だけでなく、次の点も確認します。
- 現在どのような手順で仕事をしているか
- どこに時間がかかっているか
- どのようなミスや困りごとがあるか
- 誰がどの場面で使うか
- 変えてはいけないルールはあるか
整理して優先順位を決める
集めた要求には、重複や矛盾が含まれることがあります。また、予算や期限のため、すべてを同時に実現できない場合もあります。
そこで、要求を整理し、「必ず必要」「できれば必要」「今回は対象外」などの優先順位を決めます。
優先順位は開発側だけで決めません。業務への影響、費用、実現の難しさなどを関係者で確認します。
具体的な要件にして合意する
次に、要求を、満たしたか判断できる要件へ具体化します。
たとえば、「注文をすぐ探したい」という要求なら、「注文番号、氏名、注文日を指定して検索できる」と整理できます。
作成した要件は、依頼側と開発側で確認します。認識の違い、抜け、矛盾、実現が難しい条件がないかを話し合い、合意した内容を要件定義書などへ記録します。
要件定義は誰が行う？
要件定義は、開発会社やシステム担当者だけで完結する作業ではありません。
主に次のような人が関わります。
- システムを利用する業務担当者
- 導入を決める責任者
- 社内の情報システム担当者
- プロジェクトを管理する担当者
- 要件を整理する担当者
- 設計・開発・テストを担当する人
- 運用や保守を担当する人
プロジェクトによって役職や分担は異なります。
重要なのは、実際の業務を知る人と、システムとして実現できるか判断する人が協力することです。利用者が参加しないまま進めると、完成したシステムが現場の仕事に合わない可能性があります。
要件定義と基本設計の違い
要件定義と基本設計は、主に決める内容が異なります。
| 比較項目 | 要件定義 | 基本設計 |
|---|---|---|
| 主な問い | 何が必要か、どの条件を満たすか | 要件をどのような仕組みや画面で実現するか |
| 内容の例 | 注文番号・氏名・日付で検索できる | 検索画面の項目、結果一覧の表示方法を決める |
| 主に使う目的 | 依頼側と開発側で作る対象を合意する | 開発者が実装へ進める形に具体化する |
簡単にまとめると、要件定義は「何が必要か」、基本設計は「利用者から見える形で、どう実現するか」を具体化する工程です。
ただし、実際の資料名や工程の分け方は会社によって異なります。名前だけで判断せず、その工程で何を決めるのか確認しましょう。
要件定義と受入テストのつながり
要件定義で決めた内容は、完成したシステムを受け入れてよいか判断するときの大切な基準になります。
たとえば、要件として「注文番号、氏名、注文日で検索できる」と決めたなら、完成後にそれぞれの条件で注文を検索できるか確認します。
また、「店舗担当者が注文受付から発送までの仕事を完了できる」という業務上の目的も、利用開始前の確認に関係します。
このように、要件定義で決めた内容をもとに、利用者の目的や仕事上の要望を満たすか確認するのが受入テストです。
要件が曖昧だと、完成後に「どの状態なら受け入れてよいのか」を判断しにくくなります。そのため、要件を具体的にし、確認できる形で残しておくことが重要です。
要件定義でよくある疑問
要件定義書を作れば完了ですか？
書類を作ることだけが目的ではありません。
関係者が内容を理解し、認識の違いを解消し、合意できていることが大切です。また、開発中に要件を変更する場合は、影響する費用、期限、設計、テストなどを確認して管理します。
要件定義ですべてを細かく決めるのですか？
すべての画面配置やプログラムの作り方まで決めるとは限りません。それらは設計で具体化することがあります。
一方で、満たすべき条件や重要な制約が曖昧なままでは設計できません。「何を要件定義で決め、何を設計で決めるか」は、プロジェクトの進め方に合わせて確認します。
開発途中で要件を変更できますか？
変更はできますが、設計、実装、テスト、費用、期限へ影響する可能性があります。
思いつきで追加せず、変更する理由と影響を確認し、関係者で合意して記録します。
初心者が参加するときは何に注意する？
分からない言葉や曖昧な表現をそのままにしないことが大切です。
「使いやすくする」「すぐ表示する」といった言葉が出たら、誰が、どの場面で、どの程度なら満たしたと判断できるのかを確認しましょう。
まとめ
要件定義とは、システムについて、なぜ必要か、何が必要か、どの条件を満たすべきかを関係者で整理し、合意する作業です。
ポイントを振り返りましょう。
- 要求は「こうしたい」という希望、要件は満たすべき具体的な内容や条件
- 機能だけでなく、性能、安全性、運用、データ、制約なども整理する
- 依頼側と開発側が協力し、対象範囲や優先順位を決める
- 基本設計では、要件をどのような画面や仕組みで実現するか具体化する
- 要件定義で決めた内容は、受入テストで受け入れ可能か判断する基準になる
まずは「作ってほしい機能を並べるだけでなく、システムの目的と満たすべき条件を関係者で決める作業」と覚えておきましょう。