要件定義という言葉はよく耳にするものの、
「実際に何をしているのか分からない」と感じる方が多いのではないでしょうか。

特に現場に入りたての頃は、実装やテストといった開発工程に関わることが多く、
要件定義については「最初にやる工程らしい」という程度の理解に留まりがちです。

そのため、
「要件定義って何をしているのだろう」
と疑問に思う場面も少なくありません。

本記事では、要件定義の役割について、
具体例を交えながら分かりやすく整理していきます。

要件定義とは、「システムが満たすべき条件（要件）を明確にし、関係者間で合意する工程」です。

ここでいう「要件」とは、
「システムが何を実現すべきか」という条件を指します。

システム開発は、顧客の「やりたいこと（要望）」から始まります。

しかし、この要望を具体化せずに開発側へそのまま委ねてしまうと、
完成したものが「思っていたものと違う」という事態が発生しやすくなります。

さらに、「予算」「人員」「技術的な制約」といった要因により、そもそも実現が難しいケースもあります。

そのため、要件定義では以下のようなやり取りを繰り返します。

• 顧客の要望を整理する
• 実現可能性を開発側で検討する
• 実現方法や制約を踏まえて提案する
• 顧客が提案内容を確認・調整する

このプロセスを繰り返し、
最終的に「これを作る」という合意内容を定義します。

要件定義は、
「要望」と「現実（制約）」のすり合わせを行い、
実現可能な形に落とし込む工程とも言えます。

また、顧客がすべてを明確にできるとは限らないため、
開発側が質問や提案を通じて要件を具体化していくことが重要です。

要件定義とよく混同されるのが「設計」です。

両者の違いは、以下のように整理できます。

• 要件定義：何を作るか（What）
• 設計：どのように作るか（How）

例：ユーザーがログインできる機能。

• 要件定義
  ユーザーがIDとパスワードでログインできる

• 設計
  認証方式はJWTを使用する
  パスワードはハッシュ化して保存する

要件定義の段階で設計の話をしてしまうと、
後から要件変更があった際に柔軟に対応できなくなります。

そのため、「What」と「How」を意識的に分けることが重要です。

要件定義は、一般的に以下のような流れで進みます。

「要望」と「要求」は似ていますが、本記事では以下のように定義します。

• 要望：顧客の主観的なやりたいこと
• 要求：具体化されたニーズ

例：勤怠管理システム。

本節では、要件定義の流れを具体的なケースに当てはめて整理します。

顧客の初期的な要望は、抽象的な状態で提示されることが一般的です。

（例）
「社員の勤怠を管理したい」

※この段階では、業務フローや必要な機能は明確になっていません。

開発側がヒアリングを通じて、要望を具体的な要求へと整理します。

（例）

• 「出勤・退勤時刻を記録したい」
• 「スマートフォンから打刻できるようにしたい」
• 「月ごとの勤務時間および残業時間を集計したい」

要求を整理し、開発側が以下のような観点で検討します。

• 業務要件として妥当か（業務フローとの整合性）
• 技術的に実現可能か
• コスト・スケジュールに収まるか

必要に応じて、要求の取捨選択や優先度付けも行います。

検討結果を踏まえ、開発側から具体的な実現案を提示します。

（例）

• 「Webアプリケーションとして提供する」
  → PCおよびスマートフォンのブラウザから利用可能とする

• 「打刻方法はブラウザベースとする」
  → 専用アプリ開発は行わない（開発コスト・期間を考慮）

• 「既存の人事システムとの連携は行わない」
  → 初期リリースでは単体運用とし、将来的な拡張を検討する

また、必要に応じて以下のような観点も提示します。

• 機能の優先度（必須 / 任意）
• スコープ（今回対応範囲）
• トレードオフ（コスト・品質・スピード）

提案内容について、顧客側で妥当性を確認します。

• 業務上問題なく利用できるか
• 必要な機能が満たされているか
• 不足・過剰な要件がないか

必要に応じて、再度要望の修正・追加をします。

顧客と開発側で内容に合意し、
「何をどこまで実現するか」を確定します。

この合意内容が、以降の設計・実装の基準となる「要件」となります。

• 要件定義は「何を作るか（What）」を決める工程
• 要望と制約をすり合わせ、実現可能な形にする
• 開発側が主体的に要件を具体化していくことが重要

要件定義は単なる前工程ではなく、
プロジェクト全体の品質を左右する重要な工程です。

次回は、実際に要件をどのように洗い出し、整理していくのかを解説します。