【システム開発】要件定義の具体的な進め方と注意点、４ステップでわかりやすく解説

要件定義を任されたものの、何から手をつければいいのか分からない。クライアントへのヒアリングにも、何を聞けばいいのか自信が持てない。そんな悩みを抱えている人は少なくありません。この記事では、飲食店オーナーからオンライン予約システムの開発を依頼された場面を例に、要件定義を進める基本的な4つの手順と、ヒアリングで押さえておきたいポイント、つまずきやすい失敗パターンを解説します。

システム要件定義を進める、基本的な4つの手順

もし飲食店オーナーから「ネットで予約できるようにしてほしい」と依頼を受けたとき、いきなりヒアリングを始めても、話があちこちに広がってしまい、うまく要件をまとめられません。そのため要件定義は、次の4つの手順で進めると整理しやすくなります。

• 現状の業務や課題を整理する
• あるべき姿（ゴール）を明確にする
• 必要な機能・条件を洗い出し、優先順位をつける
• 要件定義書としてまとめ、関係者の合意を取る

①現状の業務や課題を整理する

最初に行うのは、現状の業務がどうなっているかを整理することです。飲食店の例であれば
「1日に何件くらい電話予約を受けているか」
「予約の聞き間違いによるトラブルがどの程度起きているか」
といった現状を確認します。現状を整理せずにいきなり「欲しい機能」を聞き始めると、本当に解決すべき課題を見失ったまま話が進んでしまいます。

②あるべき姿（ゴール）を明確にする

現状が整理できたら、次に「この開発によって、どんな状態になっていたいか」というゴールを明確にします。

「電話対応にかかる時間を減らしたい」なのか、「予約ミスによるクレームをなくしたい」なのか、オーナーが本当に実現したいことを言語化しておくことで、この後の機能の取捨選択がぶれなくなります。

③必要な機能・条件を洗い出し、優先順位をつける

ゴールが定まったら、それを実現するために必要な機能や条件を洗い出します。このとき、思いついた機能をすべて同列に扱うのではなく、優先順位をつけることが重要です。

• 優先度が高い例：
  予約の受付機能、予約内容の確認機能
• 優先度が低い例：
  ポイント機能、SNS連携機能

限られた予算や期間の中では、優先度の高いものから着手できるよう整理しておくことで、後の判断がスムーズになります。

④要件定義書としてまとめ、関係者の合意を取る

最後に、ここまで整理してきた内容を要件定義書としてまとめ、オーナーをはじめとする関係者に確認してもらい、合意を取ります。要件定義書の具体的な書き方や必要な項目については、要件定義書の書き方を扱った記事で詳しく解説しています。

この4つの手順を押さえたうえで、次はヒアリングそのものの進め方について見ていきましょう。

システム要件定義のヒアリングで、押さえておきたいポイント

4つの手順のうち、特に難しく感じられやすいのが、現状整理や機能の洗い出しのもとになる「ヒアリング」です。ここでは、ヒアリングで押さえておきたい2つのポイントを紹介します。

「何が欲しいか」だけでなく「なぜ必要か」まで聞く

オーナーから「予約をキャンセルできるようにしてほしい」という要望が出てきたとき、その機能だけを聞いて終わらせるのではなく、「なぜその機能が必要なのか」まで踏み込んで聞くことが大切です。

• 「何が欲しいか」だけを聞いた場合：
  キャンセル機能を作ればいいと考え、無料キャンセルの仕様で実装してしまう
• 「なぜ必要か」まで聞いた場合：
  「当日キャンセルによる仕入れロスを減らしたい」という背景が分かり、当日キャンセルには手数料を設定する仕様にたどり着ける

背景まで理解しておくことで、オーナーの要望をより正確に満たす仕様を提案できるようになります。

現場の担当者と決裁者、両方の意見を聞く

もう一つ大切なのが、意見を聞く相手を一人に絞らないことです。飲食店の例であれば、実際に予約対応をしているスタッフと、オーナー（決裁者）とでは、見えている課題が異なることがあります。決裁者だけにヒアリングして進めてしまうと、現場の実情に合わない仕様になってしまうことがあります。現場の担当者からは日々の業務での困りごとを、決裁者からは経営上の狙いを、それぞれ聞いておくことで、双方が納得できる要件に近づけます。ヒアリングのコツを押さえたうえで、次は多くの人がつまずきやすいポイントも確認しておきましょう。

システム要件定義の進め方で、つまずきやすいポイント

要件定義に慣れないうちは、進め方を知っていても、実際にはつまずいてしまうことがあります。代表的な2つのパターンを紹介します。

ヒアリング内容をそのまま要件にし、実現性を確認していない

オーナーから出てきた要望を、そのまま要件として要件定義書に書いてしまい、実現できるかどうかを確認しないまま進めてしまうケースです。たとえば、「予約と同時に自動で会員ポイントを付与してほしい」という要望が、既存の会員システムとの連携が技術的に難しいことに、実装段階になって初めて気づく、といったことが起こります。要望を聞いた時点で、実現可能かどうかを開発チーム内で確認しておくことが欠かせません。

途中で要望が増え続け、スコープが際限なく広がる

もう一つのつまずきが、ヒアリングを重ねるうちに「これもできますか」「あれも欲しいです」と要望が次々に追加され、当初決めていた範囲（スコープ）がどんどん広がってしまうケースです。

• スコープを決めていない場合：
  要望が出るたびに対応を検討し、いつまでも要件定義が終わらない
• スコープを決めている場合：
  「今回の対象範囲に含まれるか」を基準に、追加要望を次のフェーズに回すかどうか判断できる

要件定義書にスコープを明記しておくことは、こうした際限のない広がりを防ぐためにも役立ちます。

まとめ：要件定義は、手順とヒアリングの質で成果が変わる

要件定義は、現状整理、ゴールの明確化、優先順位づけ、要件定義書としてのまとめという4つの手順で進めることで、迷わずに取り組めるようになります。あわせて、ヒアリングでは「なぜ必要か」まで聞き、現場と決裁者の両方の意見を聞くことを意識しましょう。実現性の確認とスコープの明確化を怠らなければ、途中でつまずきやすいポイントも避けられます。

Q&A｜要件定義の進め方・ヒアリングに関するよくある質問

ヒアリングは何回くらい行うのが一般的ですか？

プロジェクトの規模によって異なりますが、1回のヒアリングですべてを聞き出そうとせず、初回で全体像をつかみ、2回目以降で詳細を詰めていくというように、複数回に分けて進めるのが一般的です。

クライアントがITに詳しくない場合、どう進めればいいですか？

専門用語を使わず、身近な例に置き換えて説明することを意識しましょう。「データベース」ではなく「予約情報を保存しておく場所」というように、相手が普段使っている言葉に近づけて確認すると、認識のズレを防ぎやすくなります。

優先順位のつけ方に迷った場合はどうすればいいですか？

「その機能がないと業務が回らないか」を基準に考えると判断しやすくなります。業務上必須の機能を優先度高、あれば便利という機能を優先度低として整理すると、限られた予算の中でも取捨選択がしやすくなります。

ヒアリングした内容は、その場でまとめるべきですか？

ヒアリング中はメモや議事録の作成に集中し、要件としての整理は後でまとめて行うほうが、聞き漏らしを防げます。ヒアリング直後に記憶が新しいうちに整理を始めることをおすすめします。

スコープを決めたあとに、どうしても追加したい要望が出てきたらどうすればいいですか？

今回のスコープには含めず、次のフェーズや追加開発として切り分けることを検討しましょう。すべてを1回の開発に詰め込もうとすると、当初のゴールの達成自体が遅れてしまうことがあります。