要求定義の進め方と要求仕様書の書き方｜要望・要求・要件の違いと、関係者の要求を集めて優先順位をつける4ステップARTICLE

企画で「なぜやるのか」が決まったら、次は「システムに何を求めているのか」を言葉にする番です。この工程が要求定義です。

要求定義は、第1回で整理したとおり発注側が主役の工程ですが、実際には最も省略されやすい工程でもあります。企画から要件定義に飛んでしまい、「何を求めているのか」が言葉になる前に「どう作るか」の話が始まる。その結果、開発側は発注側の頭の中を推測しながら作ることになります。

本記事はシリーズ「発注側のための要件定義」の第3回として、要求定義の進め方と、その成果物である要求仕様書の書き方を扱います。

要求定義とは ―― 企画に基づいて「何を求めているか」を明確にする

要求定義は、企画で決めた目的に基づいて、システムに実現してほしいことを明確にしていく作業です。自分たちの頭の中にあるシステムのイメージを、開発側に正確に伝えるための工程と言えます。

ここで押さえておきたいのは、要求定義は開発側が一方的に聞き取るものではなく、双方が協力して行うものだということです。発注側は「何を求めているか」を言葉にする責任を持ち、開発側は「それは技術的にどう実現できるか」「どこが難しいか」を返します。このやり取りを通じて、要求は少しずつ具体的になっていきます。

要望・要求・要件の違い

要求定義を理解するうえで欠かせないのが、要望・要求・要件の3つの違いです。3つはすべて「同じことを言っている」のですが、抽象度が違います。

旅行の計画で考えると分かりやすくなります。

• 要望：「旅行に行きたい」。漠然とした願いです。
• 要求：「リゾート地に行ってゆっくりしたい」「最低でも7泊はしたい」「日本人の少ないところがいい」。何を求めているかが、言葉になっています。
• 要件：「ホテルは4つ星以上でベッドはダブル」「グルメはなくてもよいが、買い物ができる場所は必須」。満たすべき条件まで具体化されています。

すべて「旅行に行きたい」という同じ願いから出ていますが、下に行くほど臨場感のある具体的な内容になり、旅行会社（開発側）が提案できる状態に近づきます。

業務のシステムでも同じです。「営業の事務作業を楽にしたい」は要望、「訪問後の報告を10分で終えたい」は要求、「スマホの音声入力で報告を作り、上長に自動で通知する」は要件です。

要求定義は、要望を要求に整える工程です。言い換えると、発注側の「夢」を「理想」として語れるようにする段階です。それを「現実」の仕様に落とす要件定義は、次の工程になります。この違いを意識しておくと、要求定義の段階で細かい画面の話に入り込んでしまうことを防げます。

要求整理の4ステップ

要求定義は、次の4つのステップで進めます。それぞれに、次へ進むための条件があります。

1. 関係者の選定：プロジェクトに影響を与える人と、影響を受ける人を特定します。選び終えたら次へ進みます。
2. 要求の収集：面談、アンケート、既存資料の確認を通じて、関係者から具体的な要求を集めます。必要な材料がそろったら分析に進みます。
3. 要求の分析：集めた要求を整理し、重複や矛盾を解決し、実現の可能性と優先順位を評価します。順位がついたら文書化に進みます。
4. 要求仕様書の作成：分析した要求をもとに、明確な要求仕様書を作ります。関係者に承認されたら、次の要件定義の工程に進みます。

順番が大切なのは、前のステップが不十分だと、後のステップがやり直しになるからです。特に、関係者の選定が抜けていると、要求を集めて分析したあとに「あの部門に聞いていなかった」と分かり、収集からやり直すことになります。

以下、各ステップのポイントを見ていきます。

ステップ1：関係者を選定する

要求を取りまとめるために必要な登場人物を、企画の内容に応じて洗い出します。

関係者の例を挙げると、顧客（社内向けなら使う社員）、営業、マーケティング、商品企画、バックオフィス、カスタマーサポート、情報システム部門、法務・セキュリティ、運用を担うベンダー、分析チームなどです。

見落としやすいのは、「使う人」ではなく「条件を出す人」です。情報システム部門はセキュリティや既存システムとの連携の条件を、法務は契約や個人情報の扱いの条件を、運用ベンダーは保守の条件を持っています。こうした関係者を最初に入れておかないと、要求がまとまったあとに「その方式は認められない」と条件が出て、振り出しに戻ります。

ステップ2：要求を収集する

関係者から、システムに求めることを集めます。聞き方の例は次のとおりです。

• どんなシステムがあれば、業務が楽になるか
• どんな機能があれば、売上が上がるか
• どんな機能があれば、顧客が喜ぶか
• どんな機能なら、お金を出す価値があるか

集めるときのコツは、要求と一緒に「なぜ」を聞くことです。「〇〇の機能が欲しい」という要求の裏には、「今は△△に時間がかかっているから」という理由があります。理由が分かっていれば、次の分析で優先順位をつけるときの根拠になり、要件定義で別の手段を提案するときの材料にもなります。

この段階では、要求を絞りません。矛盾する要求が出てきても構いません。整理するのは次のステップです。

ステップ3：要求を分析する

集めた要求を整理し、矛盾や重複を解決して、優先順位をつけます。判断の軸は、企画で定めた目的です。

• 企画の目的に沿って、このシステムで何が必要かを見極める
• 最終的に得たい成果を明確にし、それを実現するために要求を整理する
• 機能に利害の衝突がある場合は、成果が大きいほう（売上の増加、コストの削減など）を優先する
• 効果がそれほど得られない機能は、優先度を下げる
• スケジュールと照らし合わせて、最終的な範囲を決める

優先順位をつけるときに便利なのが、効果と工数の2軸です。効果が大きく工数の小さいものを最優先にし、効果が小さく工数の大きいものは「やらない」と決めます。効果は発注側が、工数は開発側が判断できるので、この表は自然と両者のすり合わせの場になります。

「やらない」と決めたことは、消さずに記録しておきます。あとから「あの要求はどうなった」と蒸し返されたときに、いつ、なぜ落としたのかを説明できるからです。

部門間で要求がぶつかり、効果の比較だけでは決まらない場合は、プロジェクトオーナーの判断を仰ぎます。第1回で「オーナーを名前で決める」と書いたのは、まさにこの場面のためです。

ステップ4：要求仕様書にまとめる

分析して優先順位をつけた要求を、関係者の合意を得て文書にします。

要求仕様書に入れる項目は、目的、プロジェクト概要、現状分析、システム要求、システム概要、プロジェクト計画、収支計画です。企画書と重なる項目が多いのは、要求仕様書が企画書を土台にしているからで、現状分析や収支計画は企画書の内容を引き継いで構いません。

書くときのポイントは3つです。

• 細かいことより、要点が伝わるように書く：要求仕様書の段階で画面の細部まで書く必要はありません。数枚に収め、読んだ人が全体像をつかめることを優先します。
• 「誰が」「何のために」必要なシステムなのかをはっきりさせる：システムが満たすべき機能や性能の要求は、必ず「誰の、どんな目的のため」とセットで書きます。
• プロジェクト計画案を添える：いつまでに、どんな体制で進めるのかを、要求と一緒に示します。

要求仕様書が関係者に承認された時点で、要求定義は完了です。ここから先の、要求をシステムの条件に落とす作業は、開発側と一緒に行う要件定義になります。

効果的な要求整理のための3つのコツ

4ステップを進めるうえで、K.S.Rogers が支援の現場で重視しているコツを3つ挙げます。

• コミュニケーション：定期的にミーティングを設け、進み具合の共有と新しい要求の議論を行います。あわせて、チャットやプロジェクト管理ツールなど、思いついたときに意見を出せる経路を用意します。要求は会議の場だけで出てくるものではありません。
• 文書化：ミーティングや議論で合意したことは文書に記録し、参加者全員で共有します。要求に変更が生じたら、正式な手続きを通じて管理し、関係者に知らせます。「言った・言わない」を防ぐには、これしかありません。
• 検証：要求仕様書や文書化した要求を、関係者と一緒にレビューします。全員の理解と合意が得られていることを確認する場であり、要求がプロジェクトの目的に合っているかを最後に見直す場でもあります。

要求定義でよくあるつまずき

1. 集めた要望を、全部そのまま載せる

関係者から集めた要望を、分析せずにそのまま要求仕様書に並べてしまうケースです。矛盾した要求が同居し、優先順位もないため、開発側は何から手をつければよいか分かりません。「集める」と「決める」は別の作業です。

2. 条件を出す関係者を、あとから呼ぶ

情報システム部門や法務、運用ベンダーを、要求がまとまってから呼ぶケースです。前述のとおり、ここで条件が出ると振り出しに戻ります。使う人だけでなく、条件を出す人を最初から入れてください。

3. 要求が「機能の羅列」で、目的がない

「〇〇機能、△△機能、□□機能」と機能だけが並び、それぞれが誰の何のためなのかが書かれていないケースです。開発側は機能を作ることはできても、目的が分からなければ、より良い手段を提案することができません。機能には、必ず「なぜ」を添えます。

支援の現場で見た、要求整理の効果

オンライン診療プロダクトの開発体制を立て直した事例では、開発が進まない原因は開発そのものではなく、その手前の要求整理にありました。要件定義書がなく、プロダクトを実際に触らないと何が求められているのか分からない状態だったのです。

そこで最初に行ったのは、主要な立場の人に一通り話を聞き、それぞれの視点の課題を集めて整理し、レポートとして示すことでした。まさに、関係者の選定と要求の収集・分析にあたる作業です。要求が言葉になったことで、開発側は「何を作るべきか」を判断できるようになりました。

参考になる公的資料

• IPA「ユーザのための要件定義ガイド 第2版」：要求の獲得や関係者の合意形成について、発注側の視点で起きやすい問題と対策が整理されています
• IPA「情報システム・モデル取引・契約書（第二版）」：要件定義の前段階を発注側がどう担うかを含め、ユーザ企業とITベンダの役割が整理されています

要求の整理からご一緒します ―― K.S.Rogers の要件定義支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。関係者への聞き取りから、要求の分析、要求仕様書の作成まで、発注側の立場で伴走します。

まとめ

• 要求定義は、企画の目的に基づいて「システムに何を求めているか」を言葉にする工程で、発注側が主役です。ただし開発側と協力して進めます
• 要望（夢）・要求（理想）・要件（現実）は抽象度の違いです。要求定義は要望を要求に整える段階で、細かい仕様に入り込まないようにします
• 進め方は関係者の選定 → 要求の収集 → 要求の分析 → 要求仕様書の4ステップです。条件を出す関係者を最初から入れ、要求には「なぜ」を添え、効果と工数で優先順位をつけます
• 要求仕様書は数枚に収め、「誰が・何のために」が伝わることを優先します。承認されたら要件定義に進みます

次回は、要求仕様書を受けて開発側と一緒に行う要件定義書に書くこと（ビジネス要件とシステム要件、抜けやすい非機能要件）を扱います。シリーズの全体像は要件定義の進め方を、要求の整理について相談したい方はお問い合わせからお気軽にご連絡ください。