「要望」「要求」「要件」は別物——役割別観測点を同じ座標系に変換するSaaS要件定義8ステップ地図

想定読了時間: 30分（detailsを展開する場合 40分）

先に全体像だけ掴みたい場合は、TL;DR → 「変換の全体像」 → 「実務チェックリスト」 → 「次アクション」だけ読めば十分です。必要なStepだけ後から参照してください。

TL;DR

• PdM・デザイナー・エンジニア・QA・EMは、それぞれ「自分の観測点から見た真実」を言っている。議論が迷子になるのは誰かが間違っているからではなく、各観測点の声を同じ座標系に変換するプロセスが無い可能性がある。
• 「要望」「要求」「要件」は別物。要望（生の声）→要求（need+制約+条件）→要件（検証可能な粒度）という変換の段階として扱うと、いまどこにいるかが判別できる。
• requirementの最小定義は「need（必要）＋制約＋条件」。これが揃っていない状態で合意すると、受入テストで「そういう意味じゃなかった」が発生する。
• B2B SaaSでは非機能（監査ログ/権限/データ/運用/SLO）を後付けすると、手戻りだけでなく失注・更新失敗リスクになりうる。Step5（機能＋非機能（品質））で先出しするのが安全。
• 8ステップは「上流→下流への変換地図」。各Stepは変換の関門であり、読み終えたら「いまどのStepの議論をしているか」を問えるようになることがゴール。

はじめに

開発現場でこんな声を聴きました。

「認識がずれていた」「受け入れ直前に仕様変更が入った」「非機能を後から追加したら設計をやり直すことになった」「自分の話をどの場面で伝えればよいか迷った」「そう思っていても言い出せなかった」

どれも「誰かが悪い」ではありません。原因を掘っていくと、いつも同じ構造に行き着きます。PdM・エンジニア・デザイナー・QA・EM、それぞれが自分の観測点から見た真実を話しているのに、それを同じ座標系に変換する手順がない。だから議論が迷子になり、後工程で地雷を踏む。

この記事は、そういった声を踏まえて「変換プロセス」を8ステップの地図として整理したものです。完璧な手順書ではなく、「いまどこにいるか」を判別するための座標軸として使ってください。

私は、B2B SaaSのプロダクト開発の中でこの構造を繰り返し目にしてきました。同じ課題を持つチームの役に立てれば幸いです。

対象読者 / 前提

• SaaSのPdM/EM/テックリード/エンジニア/デザイナー/QA/データサイエンティストなど、要件定義に関わるすべての職種
• 「要件」という言葉が、目的・要望・仕様・設計を全部飲み込んで議論が迷子になる
• 非機能（セキュリティ/監査/運用）が後から刺さって手戻りする
• B2Bでは「業務（ユースケース）の制約」が強く、UI/UXだけを最上流に置くと落とし穴にハマりやすい

こんな場面に覚えがあるなら、この記事が効く:

• いま自分の観点を主張すべきなのか、それとも黙っておくべきなのか分からない
• 自分の話をどのタイミングで出せばいいのか判断できない
• いまこの場で議論すべきじゃない、と伝えたいが根拠がない

なぜ迷子になるか

議論が迷子になる原因は「言葉の使い方が雑」ではなく、役割ごとに見えている世界が違うという構造問題です。

役割	何を見ている	「要件」と言うとき何を指しがちか
PdM	事業目標・顧客の痛み・優先順位	解決すべき課題（Why/What）
EM	組織能力・スコープ・リスク	実現可能な範囲と制約
テックリード	アーキテクチャ・依存関係・負債	技術制約・非機能・設計判断
フロントエンドエンジニア	UI実装・コンポーネント設計・ブラウザ挙動	画面の振る舞い・インタラクション・表示条件
バックエンドエンジニア	API設計・データモデル・ビジネスロジック	入出力仕様・処理条件・エラーハンドリング
SRE/DevOpsエンジニア	可用性・デプロイ安定性・監視・インシデント対応	SLO/SLA・アラート条件・運用性・回復性
デザイナー	ユーザーの行動・文脈・感情	体験として成立する条件
QA	品質・テスト可能性・例外	検証可能な受け入れ条件
データサイエンティスト	データ品質・計測・モデル前提	入力条件・評価指標・精度要件
法務	契約・規制・コンプライアンス	守るべき制約と証跡
CS/サポート	顧客の運用課題・問い合わせパターン	使える・壊れない・困ったとき助けを求められる条件

全員が「自分の観測点から見た真実」を言っています。それが悪いのではなく、各観測点からの声を同じ座標系に変換するプロセスが無いことが問題です。この記事の8ステップは、その変換装置として使えます。

B2B SaaSの現実

要件の混同は、単なる"ドキュメントの問題"ではなく、受注・更新・監査対応のスピードと品質に直結しやすい。

ゴール（読了後にできること）

• いま議論している"要件"が、どの階層の何なのか（Why/What/How）を切り分けられる
• 「要望」「要求」「要件」の違いを説明でき、いま扱っているものがどれかを判別できる
• 上流の曖昧さを、検証可能な要件（受け入れ条件）まで変換できる
• SaaS特有の非機能を「後付け」にしないチェックができる

変換の全体像（読み進める前に）

各役割の「言いたいこと」を、同じ座標系に変換するプロセスが8ステップです。「要望→要求→要件」のどこで変換が起きるかを先に示します。このマップを頭に入れると、「いまどの役割の、どの観点の話をしているか」が判別でき、話を整理すべきStepに戻すかそのStepで決めるべき合意を取るかの判断が即座にできます。迷子のまま議論を続けることを止められます。

まず、「要件」と「設計」を分離する

実務の混乱で多いのは、「要件（What）」に「設計（How）」が混ざったまま議論が進むことです。混ざると、責任境界と粒度が揺れて、合意できないまま前に進みます。

ここでは、混ざりを止めるために「要件の最小定義」を固定します。

標準（ISO/IEC/IEEE 29148:2018）では requirement を次の趣旨で定義しています。

• requirement: need（必要）を表現し、constraints（制約）とconditions（条件）を伴う statement

ここから実務に落とすと、最低限これだけ守るとブレが減ります。

• need: 誰が、何のために、何を必要としているか（1文で書ける）
• 制約: 外部から課される制限（法規、予算、既存システム、契約など）
• 条件: どの状況で成立するか（管理者のみ、月末処理時のみ、など）

裏付け: ISO/IEC/IEEE 29148:2018 の用語定義（requirement/constraint/condition） https://www.iso.org/obp/ui/en/#!iso:std:72089:en

「要望」「要求」「要件」を分けて扱う

「要件」と「設計」の分離に加えて、もうひとつ実務で頻繁に起きる混同があります。「要望」「要求」「要件」を全部まとめて"要件"と呼ぶことです。

この3つは、変換の段階（構造化の度合いと検証可能性）が異なります。以下の表は ISO/IEC/IEEE 29148 の requirement 階層を基に、日本語の実務用語として整理したものです（規格の直接引用ではありません）。

グローバル標準では「要望」に相当するカテゴリがない

実は、グローバルの主要標準やフレームワークには「要望」に相当する独立した成果物カテゴリは定義されていません。

標準/フレームワーク	公式な成果物階層	「生の声」の扱い
ISO/IEC/IEEE 29148	Stakeholder Req → System Req → Software Req	elicitation process への input（成果物階層ではない）
BABOK (IIBA)	Business Need → Requirement	Need はプロセスの入力であり成果物カテゴリではない
CPRE (IREB)	Elicitation → Documentation → Validation	生の声は elicitation の source/input
Wiegers/Beatty	Business Req → User Req → Functional Req	"Feature request" は分析前の素材

共通しているのは、生の声（未構造化の入力）はプロセスへの input として認識されるが、成果物の正式な階層（artifact tier）としては定義されないという点です。実務では Voice of the Customer (VoC)、Feature Request、Wish List などの用語で扱われますが、いずれも標準用語ではありません。

つまり、グローバルでは「生の声は requirement engineering が受け取る素材であり、構造化された requirement とは別の世界に置かれる」という前提で動いています。生の声を requirement の一種として扱うことは想定されていないため、そもそも混同が起きにくいフレームワーク設計になっています。

一方、日本語の実務では「要件」という一語が目的から仕様まで全部を飲み込みがちです。本記事の「要望→要求→要件」の三層は、グローバル標準では暗黙的に分離されている elicitation input を、明示的に一つの階層として可視化した実務向けの整理 です。「いま自分が扱っているものが構造化前の素材（要望）なのか、構造化済みの要求なのか、検証可能な要件なのか」を判別するための座標軸として使ってください。

用語	英語対応	定義	状態
要望	Want / Wish / Request	ステークホルダーの生の声。未構造化・未検証。グローバルでは elicitation input として扱われ、requirement 階層には含まれない	need/制約/条件が未分離
要求	Requirement（広義） / Stakeholder Requirement	needを構造化し、制約・条件を付与したもの	need + 制約 + 条件が分離済み。検証方法は未確定
要件	Requirement（狭義） / Software Requirement	実装・検証可能な粒度まで落としたもの	need + 制約 + 条件 + 検証方法が揃っている

先ほど固定した ISO 29148 の定義 requirement = need + 制約 + 条件 を基準にすると:

• 要望は need すら未分離の状態。「検索を速くしてほしい」「ログを出したい」など
• 要求は need + 制約 + 条件 が分離されたが、検証方法は未確定。「管理者が、月末締め作業のために、過去30日分の全取引を一覧できる必要がある（監査要件による制約）」
• 要件は need + 制約 + 条件 + 検証方法 が揃った状態。曖昧語が排除され、閾値・条件・振る舞いが明記されている

具体例：同一テーマで三層を比べる（「取引履歴の確認」）

B2B SaaSの管理機能を例に、同じテーマが三層でどう変化するかを示します。この例は後述の Step6「曖昧語 → 検証可能」でも共通ドメインとして使います。

要望（生の声）

「管理者が、過去の取引をパッと確認できるようにしてほしい」

• 「過去」がいつからか不明（1週間？1年？）
• 「パッと」の速度定義なし
• 「確認」が画面表示なのかCSVエクスポートなのかも未定
• 誰のために・何のために必要なのか（need）が未分離

要求（need + 制約 + 条件）

「管理者が、月末締め作業のために、過去30日分の全取引を一覧できる必要がある（監査要件による制約）」

• 誰が: 管理者
• 何のために（need）: 月末締め作業
• 制約: 監査要件（外部から課される）
• 条件: 30日分・一覧形式
• ただし「一覧」のUI実現方法・表示速度の閾値・検証方法はまだ未定 → 要求であって要件ではない

要件（need + 制約 + 条件 + 検証方法）

条件: 管理画面〈取引履歴〉にて期間デフォルト「直近30日・最大1万件」で検索した場合、(1) UIをブロックしない（ローディング表示・キャンセル可能）、(2) 失敗時はユーザーが次の行動を取れる（リトライ/エラー原因の表示）。あわせて search_latency_ms / search_error_count / search_timeout_count を計測し、2週間の実測データでSLO案（目標値）を決める。

検証: 代表シナリオで(1)(2)を手動確認し、計測イベントが出ることを確認。SLO数値は次スプリントで更新。

• 曖昧語「パッと」は「UIをブロックしない + 計測して閾値を実測で決める」に変換
• 検証方法が明記されている（何を確認すれば完了か合意できる）
• 注: 閾値（「3秒以内」など）を先に固定したくなりますが、根拠なく数字を置くと受入テストで揉めます。不確実性が高い段階では「測り方を固定 → 実測で決める」の順序が安全です（Step6も同じ方針です）

この変換はどこで起きるか

全体図は冒頭の「変換の全体像」セクションを参照してください。「いま議論しているものは要望か、要求か、要件か？」を判別できると、Step間の行き来（「もう1段構造化が必要」「まだ検証方法が無いから要件ではない」）の判断が明確になります。

よくある混同パターン

• 要望をそのままバックログに入れる: need/制約/条件が未分離のままStoryにすると、実装中に「何を満たせば完了か」が曖昧になり、手戻りが起きる
• 要求を要件と呼んで合意する: 検証方法が無いまま合意しているため、受入テスト時に「そういう意味じゃなかった」が発生する
• 要件に要望を混ぜて議論する: 粒度が違うものを同じ場で議論すると、具体化と発散を同時にやることになり、議論が収束しない

手順：準備（Step0）＋上流→下流に変換する8ステップ（Step1〜8）

「要件」を一段ずつ"翻訳"していく前提で、準備（Step0）＋Step1〜8 を使います。
ポイントは、各Stepの成果物の目的と境界を固定して、議論の迷子を防ぐことです。

Step	何を確定するか	出力（例）	要望/要求/要件
0	問題と成功の定義	Problem Statement / 成功指標	（前提）
1	事業目的とガードレール	KPI/OKR・制約・優先順位	（前提）
2	誰のneedか（衝突も含む）	Stakeholder requirements	要望→要求へ変換
3	仕事の流れ（例外含む）	Workflow / Use Case	要求の具体化
4	価値提供の能力（Outcome）	Capability / Product requirements	要求の具体化
5	機能＋非機能（品質）	Functional / NFR	要求→要件へ変換
6	検証可能な要求（SRS粒度）	Software requirements（ID付き）	要件の確定
7	受け入れ条件と検証方法	AC / Verification plan	要件の検証設計
8	実行単位（作業）	Epic/Story/Task	要件→作業へ分解

Step 0: 問題/機会（Problem / Opportunity）

• 目的: 「そもそも何が問題で、成功は何か」を観測可能な形で定義する
• 入力: 現場の痛み、機会、競合、規制変化
• 出力: 問題仮説、対象顧客、成功の定義（測り方）、非ゴール

よくある誤解 / 境界（Step0）

• ここで解決策（UI/DB/API）を固めない。固めると以降のStepが全部"後追い正当化"になる
• 「成功」は"気持ち"ではなく、最低でも観測方法（何を見たら成功か）まで落とす

Step 1: 事業目的（Business objectives）

• 目的: 作る理由（伸ばす指標）と、守る制約（ガードレール）を固定する
• 入力: 会社/事業の目標、期限、予算など
• 出力: KPI/OKR、優先順位、守るべき制約（例: セキュリティ基準）

よくある誤解 / 境界（Step1）

• ここは「要件（What）」ではなく「上位目的（Why）」
• KPI（伸ばす）とガードレール（守る）を混ぜない。混ぜると意思決定の優先順位が壊れる

Step 2: ステークホルダー要求（Stakeholder needs / expectations）——要望→要求の変換点

• 目的: 「誰のneedか」を明示し、要求の衝突を見える化する
• 入力: PdM/CS/営業/法務/運用/顧客の期待（ここに「要望」が入ってくる）
• 出力: Stakeholder requirements（Need + 制約 + 条件 + 優先度/根拠）
• 変換: このStepで「要望（生の声）」を「要求（構造化されたneed）」に変換する

よくある誤解 / 境界（Step2）

• 「APIを作れ」「DBをこうしろ」はHow（手段）なので、need/制約/条件に翻訳して別欄に退避する
• ここで衝突（短期売上 vs 運用安定など）を意思決定（優先順位と境界の合意）まで落とさないと、後工程で"仕様の矛盾"として表面化する

Step 3: ユーザー業務要件（Workflow / Use Case）

• 目的: ユーザーが仕事を終える流れ（例外含む）でWhatを表現する
• 入力: 現行業務フロー、例外、判断基準
• 出力: 達成事項、例外、入出力、権限（誰が何をできる/できない）

よくある誤解 / 境界（Step3）

• 画面遷移（UI）を作り込む前に、まず業務の分岐と例外（頻度が高い/痛い）を押さえる
• 「誰が承認するか」「締め処理はいつか」など、業務の条件が抜けると要件が検証不能になる
• スコープ調整が必要なら「要件（機能）を削る」より「不要なユースケース（使わない流れ）を削る」へ寄せる（後工程の矛盾が減る）

Step 4: プロダクト要件（Product requirements）

• 目的: 業務（Step3）を、プロダクトとして提供する能力（capability）にまとめ直す
• 入力: Step 1〜3
• 出力: 価値提供としての要件（Outcome）、非ゴール、制約（法規/契約/SLA）

よくある誤解 / 境界（Step4）

• 機能の羅列に落ちると"作ること"が目的化する。Outcome（何ができるようになるか）へ寄せる
• ここで「契約/SLA/法規」などの制約が抜けると、後工程で仕様変更が発生しやすい

Step 5: ソリューション要件（Functional / Non-functional）——要求→要件の変換点

• 目的: capabilityを「機能要件」と「非機能要件（品質）」へ分解し、実装・運用の土台を作る
• 入力: プロダクト要件
• 出力: Functional requirements / NFR（可用性、性能、セキュリティ、監査、運用など）
• 変換: このStepから「要求」を「要件」（検証可能な粒度）へ落とす作業が始まる

B2B SaaSでは「非機能の後付け」は事業リスクになりやすい

非機能（監査ログ、権限、データ保持/削除、SLO/SLA、障害時運用）は、受注・更新・監査対応・信頼に直結しやすく、後工程で発覚すると設計のやり直しになりがちです。

裏付け: 品質特性（NFRの観点）= ISO/IEC 25010:2023 https://www.iso.org/standard/78176.html / ログ管理 = NIST SP 800-92（2006年発行だが現在も最終版） https://csrc.nist.gov/publications/detail/sp/800-92/final / セキュリティ要求の標準化 = OWASP ASVS https://owasp.org/www-project-application-security-verification-standard/

非機能チェック項目（Step5）

• 監査ログ: 何を/誰が/いつ/どの粒度で残すか
• 権限: 役割（RBAC等）と例外（代理・退職・委任）
• データ: 保持期間、削除（論理/物理）、エクスポート、リージョン
• 観測性: 重要イベントの計測（メトリクス/ログ/トレース）とアラート方針
• プライバシ/規制: 取り扱い区分、マスキング、同意、監査要求（該当する場合）
• アクセシビリティ: 対象顧客/調達要件として必要か（該当する場合）
• 運用: アラート条件、復旧手順、切り戻し、データ修復
• SLO/SLA: まずは仮説でよいので「何をSLIにし、どの目標値にするか」または「決め方」を書く

（AIコンポーネントを含む場合のみ）後から追加できない項目:

• 証跡: モデルの判断根拠・訓練経緯のログ/技術文書（事後に再現不能）
• 評価指標: 精度・公平性・閾値（デプロイ前に定義しないと比較基準がなくなる）
• データ起源/品質: 学習データの来歴と品質（取得時点から追跡しないと消える）
• 人間の監督: AIの判断に人間が介入・上書きできるフロー（システム設計に組み込む必要あり）
• 攻撃/誤誘導テスト: プロンプトインジェクション・敵対的入力への対策（テスト計画に含めないと抜けやすい）

Step 6: システム/ソフトウェア要件（SRS相当）

• 目的: 実装可能な粒度まで落とし、検証可能な要件にする（合意可能にする）
• 入力: Step5
• 出力: Software requirements（曖昧語を排除し、条件/振る舞い/閾値を明記。できればID付与）
• 変換: ここで「要件」が確定する。曖昧語の排除と検証方法の紐づけが完了した状態

裏付け: SLI/SLO/SLAの整理と「測り方/目標の決め方」= Google SRE Book https://sre.google/sre-book/service-level-objectives/ / 継続改善の測定枠組み = DORA Research https://dora.dev/research/

よくある誤解 / 境界（Step6）

• 「速い」「使いやすい」「安全」は要件として不十分。観測可能な指標（閾値）か、検証方法へ落とす
• How（DB/アーキ）を混ぜると設計の自由度が落ちる。必要なら"制約"として明示し、根拠を添える

例（曖昧語 → 検証可能）:

• NG: 「検索結果を速く表示する」
• OK（不確実性前提・暫定）: 「条件: 直近30日・最大1万件のデータを対象に、検索は(1) UIをブロックしない（ローディング/キャンセル可能）、(2) 失敗時はユーザーが次の行動を取れる（リトライ/原因が分かるエラー表示）。あわせてsearch_latency_ms/search_error_count/search_timeout_countを計測し、2週間の実測データでSLO案（目標値）を決める」
• 検証: 代表シナリオの手動テストで(1)(2)を確認し、計測が入っていること（イベントが出ること）を確認する。SLOの数値は次スプリントで更新する

Step 7: 受け入れ条件（Acceptance criteria）と検証計画

• 目的: 「満たした」の定義を先に合意し、出戻りを減らす
• 入力: 各要件
• 出力: AC（Given/When/Thenなど）と、検証方法（テスト/レビュー/分析/検査）

よくある誤解 / 境界（Step7）

• 「動く」だけでは不十分。NFRは"検証方法"までセットにしないと後から揉める
• SaaSでは運用検証（監視/アラート/復旧手順）を受け入れに含めないと、本番事故につながる

Step 8: バックログ化（Delivery unit）

• 目的: 要件（What）を、実行可能な作業単位（Howの一部）に分解して進捗管理できるようにする
• 入力: 要件＋受け入れ条件
• 出力: Epic/Story/Task（優先度・依存関係つき。要件/ACへリンク）

よくある誤解 / 境界（Step8）

• バックログは"要件そのもの"ではない（要件の意図・制約・受入条件をタスク文だけに閉じ込めない）
• 最低限、Story/Taskから「どの要件/どのACを満たす作業か」へ追跡できるようにする
• DoR/DoDが無いと、要件の未確定が開発へ流れ込み、手戻りが増える
• 情報の見える化が崩れると、要件の意図が一部の人の頭の中に閉じる。要件・AC・意思決定の一次情報は、関係者が同じ場所で参照できる形に置く

ハマりどころ（典型パターン）と戻し方

1) UI（How）から始めてしまう

• サイン: 画面の話が進むのに、成功条件や制約が曖昧
• 戻し方: Step 0〜2に戻って「誰のneedか」「成功の定義」を1文で固定
• 補足（B2B）: UI/UXの議論自体は必要だが、業務要件の制約を置き去りにすると「使いやすいが選定されない」状態になり得る。まず業務（ユースケース）を固定する

2) 要件（What）に設計（How）が混ざる（要件に設計を混ぜるな）

• サイン: 「DBは〜」「APIは〜」が要件として語られる
• 戻し方: need/制約/条件に分解し、Howは別欄（設計メモ）に退避

3) 非機能が後付けになる

• サイン: 受け入れ直前で監査ログ/権限/データ削除が話題になる
• 戻し方: Step 5で非機能のチェックリストを先に通す

4) "将来必要かも"を先に作る（YAGNI違反）

• サイン: 使う顧客が未確定なのに拡張点だけ増える
• 戻し方: いま検証するneedに紐づく最小範囲に切る（将来仮説は別バックログへ）

5) 要望をそのままバックログに入れる

• サイン: 「〜してほしい」がそのままStory/Taskになっていて、完了条件が曖昧
• 戻し方: まずStep 2で要望→要求に変換する（need/制約/条件を分離）。そこから検証方法を紐づけて要件にしてからバックログ化する

このやり方が通用しないケース

前提が違えば効きません。前提を外して使うと逆効果になることがあるため、先に書いておきます。

• ケース1: Step0〜8を回しても、要件起因の手戻りや認識齟齬が減らない（むしろ増える）
  • 例: 仕様変更回数/差し戻し/インシデントが改善せず、会議時間だけ増える
• ケース2: 「階層分け」が目的化して、探索（発見）が止まる
  • 例: 不確実性が高いのに、Step6の粒度を先に固定して学習速度が落ちる
• ケース3: 非機能を早く書いたのに、重要リスク（契約/監査/運用）が後から刺さる
  • 例: 「監査ログは必要」までは書いたが、誰が何を監査するかが未定で設計がやり直しになる

別の見方（手戻りの別の原因）:

• 仮説A: 手戻りの主因は要件ではなく、依存関係/アーキ/チーム構造にある（手順を整えても効きにくい）
• 仮説B: 手戻りの主因は「書き方」ではなく「意思決定の遅さ（権限/優先順位/合意形成）」にある
• 仮説C: 不確実性が高い局面では、要件の厳密化より「プロトタイプ/実験（計測込み）」が支配的に効く

どう確かめるか:

• 2〜4週間だけでよいので、(a) 要件起因の仕様変更回数、(b) 差し戻しPR数、(c) 運用起因インシデント数、(d) 主要ステークホルダーの認識齟齬（週次で1問アンケート）を追う
• 改善しない場合は、手順そのものではなく「どの仮説が外れているか（A/B/C）」を疑って、介入点を変える

例外運用: 何としてもリリースする局面（Fast track）

SaaSでは「期限（契約・競合・法規・顧客都合）」が支配的で、多少の不確実性を抱えたままでも出す必要がある場面があります。
このときは"Stepを省く"のではなく、守るものを固定して手順を絞り込みます。

• 守るべきこと（最低ライン）:
  • Step0/1: 成功の定義とガードレール（期限そのものも制約として明文化）
  • Step5/6: 非機能の最低ライン（監査ログ/権限/データ/運用/観測）と、検証可能な表現（または検証方法）
  • Step7: 受け入れ条件＋切り戻し条件（どの状態なら撤退するか）
• 手順の絞り方:
  • Step2〜4は「誰のneedか」「例外は何か」「Outcomeは何か」を30分でメモ化し、衝突だけ可視化して先送りしない
  • Step8は「影響範囲を小さく」する（限定公開、ロールアウト段階、Feature Flag等）ことを"要件"として書く
  • スコープ縮小は、機能の切り捨てよりも「不要なユースケースを捨てる」単位で行うと、後戻りが減りやすい
• 出した後の戻し（必須）:
  • 48時間以内に Step2〜6 を"事後要件化"して、次の変更の地雷（監査/運用/データ）を残さない

実務チェックリスト

次のチェックを"毎回"通すだけでも、迷子率は下がります。

• いま扱っているのは要望か、要求か、要件か？（粒度と検証可能性で判別する）
• これはどの階層か？（目的/Stakeholder/業務/プロダクト/Solution/SRS/受入/バックログ）
• needは1文で言えるか？（誰が、何のために、何が必要か）
• 制約と条件が分離されているか？
• 検証可能か？（受入条件と検証方法が紐づくか）
• SaaS特有の非機能が抜けていないか？（権限/監査/データ保持/削除/SLO等）
• 要件・受け入れ条件・意思決定の一次情報が、関係者に見える（参照できる）形になっているか

定量が無い場合の「どう測るか」（KPI例）

社内事情でBefore/Afterの実測が出せない場合は、測り方だけでも書くと説得力が上がります。

• 手戻り: 要件起因の仕様変更回数、差し戻しPR数
• リードタイム: 企画→リリースまでの日数、要件確定→実装着手までの日数
• 品質: リリース後の運用起因インシデント数、監査指摘数
• 運用: 障害検知〜復旧までのMTTR、アラートのノイズ率

次アクション（行動への橋渡し）

読了後に試せる最小の一歩を示します。

1. いまチームで「要件」として議論しているものが、要望か要求か要件かを判別する（粒度と検証方法の有無で判断）
2. Step5の非機能チェックリストをまだ通していなければ、次の議論の前に通す
3. 定量で追うなら、要件起因の仕様変更回数と差し戻しPR数を2〜4週間記録する（改善の有無の最小証拠）

うまくいかない場合は、手順よりも「どのハマりどころが刺さっているか」と「通用しないケースのどれが当てはまるか」を先に確認してください。

まとめ

この記事で伝えたかったことは、要件定義は「正しいドキュメントを作ること」ではない、ということです。

PdM・エンジニア・デザイナー・QA・EM、それぞれが持つ観測点の違いを認めた上で、同じ座標系に変換するプロセスを共有する。その結果として「いま何を議論すべきか」「何が決まれば次に進めるか」が見える状態になる。8ステップはそのための地図です。

「通用しないケース」で書いたように、手順を整えるだけでは解けない問題もあります。それでも「要望か要求か要件か」を問う習慣が一つあるだけで、迷子になる時間は確実に減ります。

B2B SaaSのプロダクト開発に関わる方にとって、何かひとつでも明日の現場で使えるヒントになれば幸いです。

参考リンク

• ISO/IEC/IEEE 29148:2018（Terms and definitions）: https://www.iso.org/obp/ui/en/#!iso:std:72089:en
• ISO/IEC 25010:2023（品質特性モデル）: https://www.iso.org/standard/78176.html
• Google SRE Book - Service Level Objectives（SLI/SLO/SLA）: https://sre.google/sre-book/service-level-objectives/
• DORA Research（継続的改善・観測性/SLOの位置付け）: https://dora.dev/research/
• NIST SP 800-92（Security Log Management）: https://csrc.nist.gov/publications/detail/sp/800-92/final
• OWASP ASVS（セキュリティ要求の標準化）: https://owasp.org/www-project-application-security-verification-standard/
• Martin Fowler - YAGNI: https://martinfowler.com/bliki/Yagni.html
• SWEBOK v3.0（ソフトウェア要件工学の知識体系。Requirement / SRS の概念基盤）: https://www.computer.org/education/bodies-of-knowledge/software-engineering/v3
• Fred Brooks "No Silver Bullet — Essence and Accidents of Software Engineering", IEEE Computer Vol.20 No.4, 1987: https://doi.org/10.1109/MC.1987.1663532