「要件定義」という言葉は、IT業界を目指している人や、配属されたばかりの新人PM・BrSEであれば一度は耳にしたことがあるはずです。ただ、具体的に何を決める工程なのか、なぜそれほど重要だと言われるのかを、きちんと説明できる人は意外と多くありません。
この記事では、飲食店オーナーからオンライン予約システムの開発を依頼された場面を例に、要件定義がシステム開発の中で果たす役割と、基本設計・詳細設計との違いをわかりやすく解説します。
- 要件定義が、システム開発の中で具体的に何を決める工程なのか
- 「要件定義」という言葉が、IT文脈とビジネス文脈で指す意味の違い
- 要件定義・基本設計・詳細設計の違い
- 要件定義でのズレが、後工程でどんな問題につながるか
<この記事もおすすめ！>
\株式会社PRUMのメディア/
要件定義とは、システム開発で「何を作るか」を決める工程
たとえば、あなたが個人経営の飲食店のオーナーから、「電話予約が大変だから、ネットで予約できるようにしてほしい」と開発を依頼されたとします。この「ネットで予約できるようにしてほしい」という要望だけでは、実際に何を作ればいいのかまだ分かりません。
何時から何時まで予約を受け付けるのか、1回の予約で何名まで対応するのか、当日キャンセルはどう扱うのか。こうした具体的な条件を一つずつ決めていく作業こそが、要件定義です。
要件定義の目的は、要望を実現可能な仕様に落とし込むこと
先ほどの例で言えば、「予約をネットで受け付けたい」という漠然とした要望は、次のような具体的な仕様に落とし込む必要があります。
- 何時から何時まで予約を受け付けるか
- 1回の予約で何名まで対応するか
- 当日キャンセルはどう扱うか
こうして、開発チームが実際に作業できる形まで要望を整理し直すことが、要件定義の目的です。オーナーの頭の中にある要望を、そのままの言葉で開発チームに伝えても、実際に作るべきものの形は見えてきません。要望を聞き取り、実現可能な形に整理し直す工程が必要になるのです。
要件定義は上流工程の最初のステップ
こうしたヒアリングと言語化が終わって初めて、画面のレイアウトを決める基本設計や、プログラムの中身を組み立てる下流工程に進むことができます。要件定義は、システム開発全体の中でも最初に着手する工程であり、ここでの決定内容が、その後のすべての工程の土台になります。
システム開発全体の流れの中で要件定義がどこに位置づけられるかをより詳しく知りたい方は、システム開発の流れを徹底解説：企画から運用まで「失敗しない」全工程ガイドもあわせてご覧ください。「要件定義」という言葉は、実はIT業界の中でも、使われる場面によって少し意味合いが変わります。次はその違いを見ていきましょう。
「要件定義」は、
IT文脈とビジネス文脈で指しているものが少し違う
同じ「要件定義」という言葉でも、システム開発の現場で使われる場合と、経営やコンサルティングの文脈で使われる場合とでは、指している内容が少し異なります。
システム開発の文脈では「システムに必要な機能」を定義する工程
システム開発の現場で「要件定義」と言うときは、多くの場合、システムが持つべき機能を定義する工程を指します。先ほどの予約システムの例であれば、次のような機能を、システムに実装すべき機能として具体化していく作業です。
- 予約機能
- キャンセル機能
- 管理画面での空席確認機能
経営・コンサルの文脈では「業務課題解決に必要な条件」を指す
一方、経営やコンサルティングの文脈で「要件定義」と言うときは、システムの機能そのものよりも、業務上の課題を解決するために必要な条件を指すことが多くなります。飲食店側の視点で考えると、「電話予約対応にかかる人件費を減らしたい」という経営課題があり、それを解決するために次のような条件が挙がってくる、という順序です。
- オンライン化
- 予約確認の自動通知
どちらの文脈も間違いではなく、「システムの機能」と「業務課題を解決するための条件」という、見ている粒度が違うだけだと理解しておくと混乱しません。この違いを踏まえたうえで、要件定義がシステム開発の他の工程とどう違うのかも整理しておきましょう。
要件定義・基本設計・詳細設計は、決める粒度が異なる
要件定義のあとには、基本設計、詳細設計という工程が続きます。この3つは、同じ「何かを決める」工程でありながら、決める粒度がそれぞれ異なります。
- 要件定義：
「何を作るか」を決める（例：予約機能、キャンセル機能が必要） - 基本設計：
「どう作るか」の大枠を決める（例：予約フォームの画面レイアウト、予約データの保存方法の大枠） - 詳細設計：
基本設計をプログラム単位まで具体化する（例：予約ボタンを押したときにどの処理が動き、どんな形でデータベースに保存されるか）
要件定義は「何を作るか」、基本設計は「どう作るか」を決める
要件定義で「予約機能が必要」と決まったら、次の基本設計では、その予約機能を実現するために「予約フォームの画面レイアウトをどうするか」「予約データをどのように保存するか」といった、実現方法の大枠を決めていきます。
要件定義が「作るべきものの一覧」だとすれば、
基本設計はその一覧を実現するための「設計図の骨組み」にあたります。
詳細設計は、基本設計をさらにプログラム単位まで落とし込む
基本設計で決めた大枠は、詳細設計の工程でさらに細かく具体化されます。「予約ボタンを押したときにどの処理が動き、どんな形でデータベースに保存されるか」というレベルまで踏み込んで決めるのが詳細設計です。このように、要件定義から詳細設計に進むにつれて、決める内容はどんどん具体的かつ細かくなっていきます。逆に言えば、最初の要件定義の段階で決めた内容にズレや漏れがあると、その影響は後の工程すべてに響いてしまいます。
要件定義でのズレが、後工程での手戻りにつながる
要件定義は、システム開発の一番最初に行う工程だからこそ、ここでの認識のズレが、後になって大きな問題として表面化しやすいという特徴があります。
要件の認識違いは、テスト段階や運用開始後に発覚しやすい
たとえば、先ほどの予約システムの例で、次のようなズレが起きているケースを考えてみましょう。
- オーナーの思い込み：
当日キャンセルも無料で対応してもらえる - 実際に定義された仕様：
当日キャンセルにはキャンセル料が発生する
このようなズレは、要件定義の段階では見過ごされ、テスト段階や、最悪の場合は運用が始まってから発覚することが少なくありません。工程が進んでからズレに気づくほど、修正には多くの時間とコストがかかります。
要件定義には、丁寧なヒアリングと合意形成が欠かせない
こうしたズレを防ぐには、要件定義の段階で、丁寧なヒアリングを行い、決めた内容を関係者全員で合意しておくことが欠かせません。ヒアリングで具体的に何を聞き、どう進めればいいのかについては、要件定義の進め方・手順とヒアリングのコツを扱った記事で詳しく解説する予定です。
また、決めた内容を認識のズレなく残しておくための文書化の方法については、要件定義書の書き方を扱った記事で紹介します。どちらも、要件定義を安心して進めるための土台になる内容です。
まとめ：要件定義は、システム開発全体の土台を決める工程
要件定義とは、依頼主の漠然とした要望を、開発チームが実際に作業できる具体的な仕様に落とし込む工程であり、システム開発全体の中でも最初に着手する上流工程です。
要件定義・基本設計・詳細設計は、決める内容の粒度が異なるだけで、要件定義で決めた内容がその後のすべての工程の土台になります。だからこそ、要件定義の段階での認識のズレは、後工程での大きな手戻りにつながりやすいのです。
まずはこの記事で紹介した位置づけを理解したうえで、次は要件定義書の書き方や、ヒアリングの具体的な進め方についても学んでいきましょう。
