- システム開発において顧客・ユーザーのニーズ・要望を収集・整理・構造化して「何を作るべきか」を明確にするプロセスのこと。要件定義の前工程として位置づけられる
- 「要求（何をしたい）」を「要件（何を作る）」に変換するプロセスでここで誤りや漏れがあると後工程で大きな手戻りコストが発生するシステム開発の最重要フェーズの一つだ
- ウォーターフォール開発では要求分析→要件定義→設計という流れで最初に実施される。アジャイル開発ではユーザーストーリーとして継続的に実施されるが、どちらの方法論でもユーザーニーズの正確な把握が開発成功の鍵になる
【深掘り】これだけ知ってればOK！
要求収集の代表的な手法を理解しよう。インタビュー：ステークホルダーと1対1で深く掘り下げる。ワークショップ：複数のステークホルダーが一堂に集まって議論する。観察（エスノグラフィー）：実際の業務現場を観察してユーザーが意識していないニーズを発見する。アンケート：多数のユーザーから広く意見を収集する。プロトタイピング：画面モックアップを見せて要求を確認・精緻化する。
要求分析のよくある失敗パターンを理解しよう。「何が欲しいか」を聞いて「どう作るか」に答えてしまう：ユーザーが「Excelで管理したい」と言ったとき「なぜExcelなのか」を深掘りすると「データを一覧で比較したい」という本質的なニーズが出てくる。ステークホルダーの抜け漏れ：使う人だけでなく承認者・監査者・システム連携先なども要求に含まれる。
要求分析の成果物として要求仕様書（SRS：Software Requirements Specification）を作成することが多い。IEEE 830規格が要求仕様書の国際標準として参照されることがある。要求仕様書には機能要求・非機能要求・制約要求・ユースケース・シナリオが含まれ、開発チームとステークホルダーの間の合意文書として機能する。
よくある誤解
要求分析は要件定義と同じことだと思っている
要求分析はユーザーの「こうしたい・こういう問題がある」というニーズを収集・整理する工程だ。要件定義は要求分析の成果を「システムはこの機能を持つ」という仕様として定義する工程だ。要求分析が先にあって要件定義が後に来る。
ユーザーが言ったことをそのまま要求として受け取ればよいと思っている
ユーザーが表明する要求の背後には「真のニーズ（本当に解決したい問題）」がある。「Excelで管理したい」というユーザーの発言の背後に「データを効率的に比較・集計したい」という本質的ニーズが隠れている場合が多い。「なぜ」を問い続けることが要求分析の核心だ。
会話での使われ方
ユーザーが「現在のシステムに機能を追加したい」と言っていますが、「なぜその機能が必要か」を深掘りしたら業務フロー全体を見直した方が根本解決になると分かりました。
要求分析担当者が表面的な要求の背後にある本質的なニーズを発見した場面。
非機能要求が曖昧なまま開発を始めると後から問題になります。「応答時間は2秒以内」「99.9%の稼働率」という具体的な数値で非機能要求を定義しましょう。
プロジェクトマネージャーが非機能要求の数値化の重要性を指摘している場面。
ユーザーストーリーにAcceptance Criteriaを追加しましょう。「いつ、この機能が完成したとみなせるか」を具体的に書くことでUATの基準にもなります。
スクラムマスターがユーザーストーリーの受入基準の重要性を説明している場面。
【まとめ】3つのポイント
- ユーザーニーズを収集・整理・構造化して「何を作るべきか」を明確にする工程：要求分析での誤りや漏れは後工程で大きな手戻りコストを生むため「ユーザーが言ったことではなくなぜそれが必要かという本質的ニーズ」を把握することが開発成功の鍵だ
- 機能要求・非機能要求・制約要求の3種類を網羅的に定義する：「何ができるか」という機能要求だけでなく「どのくらいの性能・稼働率が必要か」という非機能要求と技術・法令・予算の制約要求を漏れなく定義することが品質の高いシステム開発の前提だ
- ユーザーストーリー形式で要求を表現して「誰のため・なぜ必要か」を明確にする：「As a [役割], I want [目的], So that [価値]」というユーザーストーリー形式は要求の背後にある価値を明確にしてUATの受入基準との連携も容易にする
よくある質問
-
Q要求分析と要件定義はどう違いますか？
-
A
要求分析はユーザーのニーズを収集・整理する工程です。要件定義は要求分析の成果を「システムが持つべき機能・品質」という仕様として定義する工程です。要求分析→要件定義という順序で行われます。
-
Q非機能要求にはどんなものがありますか？
-
A
パフォーマンス（応答時間・スループット）・可用性（稼働率）・セキュリティ（認証・暗号化）・拡張性（将来の利用者増加への対応）・保守性・ユーザビリティなどが代表的な非機能要求です。
-
Qユーザーストーリーとユースケースはどう違いますか？
-
A
ユーザーストーリーはアジャイル開発で使われる「誰が・何をしたい・なぜか」を簡潔に表現した要求の単位です。ユースケースはUMLの表記法でユーザーとシステムのインタラクションを詳細に記述したものです。
-
Q要求分析のインタビューで気をつけることは何ですか？
-
A
「どうすれば解決できるか（解決策）」ではなく「なぜその問題が困るのか（問題）」を聞くことが重要です。ユーザーは解決策を語りがちですが、本質的な問題を理解することが要求分析の目的です。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| ニーズ | ニーズを押さえると本記事の理解がさらに深まります。顧客が抱える「満たされていない欲求・必要性」を指すマーケティングの基礎概念のこと。製品・サービスはこのニーズを満たすために存在する |
| ステークホルダー | ステークホルダーとの関係を知ると全体像がつかみやすくなります。ステークホルダーの主要な特徴と用途を理解することで、関連する技術・制度・概念を正確に把握できるようになる |
| アジャイル開発 | アジャイル開発を押さえると本記事の理解がさらに深まります。小さな単位で「作って試す」を繰り返す、スピード重視のプロジェクトの進め方のこと！ |
| アイコン | アイコンを押さえると本記事の理解がさらに深まります。アプリやファイル、操作ボタンなどをひと目でわかる小さな絵で表したもの、それがアイコンだ |
| 仕様書 | 仕様書との関係を知ると全体像がつかみやすくなります。システムやアプリを作るための、詳細な設計図でありルールブックのことだよ！ |
【出典】参考URL
https://www.ipa.go.jp/sec/publish/tn09-007.html ：IPAの要求工学関連資料
https://jstqb.jp/ ：JSTQBのソフトウェアテスト標準（要求の検証）
https://e-words.jp/w/%E8%A6%81%E6%B1%82%E5%88%86%E6%9E%90.html ：IT用語辞典「要求分析」
コメント