「要件定義って英語で何て言う？」「SRSとBRDって何が違うの？」——グローバルチームで要件定義を担当するエンジニアが最初にぶつかる壁だ。
「要件定義」に対応する英語は一つではない。SRS・BRD・FRS・PRDなど複数の呼び方があり、現場によって使い分けられている。用語の整理から始めないと、会議も文書作成も迷走する。
この記事では、「要件定義」の英語表現と5種類のドキュメント種別の違い、要件分類・ヒアリング・文書化・レビュー・変更管理で使えるフレーズ30選、現場必須の用語集20選を完全網羅する。
これ一本で英語要件定義の全体像をつかめる。
「要件定義」を英語で言うと？5つのドキュメント種別を整理する
「要件定義」に相当する英語は、現場やプロジェクトの性質によって異なる。代表的な5種類を整理しよう。
SRS・BRD・FRS・PRD・Use Caseの違い
| 略称 | 正式名称 | 日本語 | 主な用途 |
|---|---|---|---|
| SRS | Software Requirements Specification | ソフトウェア要件仕様書 | システム全体の機能・非機能要件を体系化 |
| BRD | Business Requirements Document | ビジネス要件定義書 | ビジネス目標・課題・ニーズを定義 |
| FRS | Functional Requirements Specification | 機能要件仕様書 | 機能要件に特化して詳細化 |
| PRD | Product Requirements Document | プロダクト要件ドキュメント | プロダクト開発の方向性・機能を定義 |
| Use Case | Use Case Specification | ユースケース仕様書 | ユーザーとシステムの相互作用を記述 |
現場でどれを使うべきか
受託開発・エンタープライズ案件では「SRS」が標準的だ。スタートアップや内製開発では「PRD」が多く使われる。ビジネス側が主導するプロジェクトでは「BRD」から始まり、技術チームが「FRS」に落とし込むケースが多い。
どのドキュメントを使うかは現場によって異なる。重要なのは「どれを指しているか」を会話の最初に合わせることだ。「Are we creating an SRS or a BRD here?」と確認するだけで認識のズレを防げる。
要件を英語で分類・整理するフレーズ（①〜⑥）
要件の種類と優先度を英語で正確に区別することが、要件定義の精度を決める。
Functional / Non-functionalを区別するフレーズ
① “This is a functional requirement: the system shall [機能の説明].”
（これは機能要件です：システムは[機能の説明]するものとします。）
「shall」は要件文書の必須表現。「will」や「should」より強い義務を示す。
② “This is a non-functional requirement: the system must achieve [X]% uptime under [負荷条件].”
（これは非機能要件です：[負荷条件]下でシステムは[X]%の稼働率を達成しなければなりません。）
非機能要件は必ず数値を添える。「高い可用性」では要件として機能しない。
③ “Let me break this down into functional and non-functional requirements before we go deeper.”
（深掘りする前に、機能要件と非機能要件に分けて整理しましょう。）
ミーティング中に要件が混在してきたとき、整理を促す一言だ。
MoSCoW法で優先度を整理するフレーズ
④ “This is a must-have for [バージョン / リリース]. Without it, the product cannot ship.”
（これは[バージョン/リリース]のmust-haveです。これなしでは製品をリリースできません。）
MoSCoW法（Must / Should / Could / Won’t）は要件の優先度整理のグローバル標準だ。
⑤ “This feature is a should-have — important but not blocking the first release.”
（この機能はshould-haveです——重要ですが、最初のリリースをブロックするものではありません。）
⑥ “This is a nice-to-have. We’ll include it if time and resources allow, otherwise it moves to the backlog.”
（これはnice-to-haveです。時間とリソースが許せば含めます。そうでなければバックログに移します。）
要件定義プロセス①：ヒアリング・引き出しフレーズ（⑦〜⑫）
要件定義の質はヒアリング力で決まる。「何が欲しいか」ではなく「なぜそれが必要か」を引き出すフレーズを押さえよう。
ステークホルダーから要件を引き出すフレーズ
⑦ “Could you help me understand the business goal behind this requirement?”
（この要件の背景にあるビジネス目標を教えていただけますか？）
「What」（何が欲しいか）より「Why」（なぜ必要か）を先に聞く。目的を理解すれば、より良い実装案を提案できる。
⑧ “What problem are we trying to solve with this feature? Who experiences this problem most?”
（この機能で解決しようとしている問題は何ですか？誰が最もこの問題を経験していますか？）
⑨ “What does success look like for this requirement? How will we measure it?”
（この要件の「成功」とはどのような状態ですか？どう測定しますか？）
測定可能な成功基準がない要件は、後の検証で「できた／できていない」の判断ができなくなる。
曖昧な要件を明確化するフレーズ
⑩ “Can you give me a concrete example of this use case in action?”
（このユースケースが実際に動く具体的な例を教えていただけますか？）
抽象的な要件を具体化する最も効果的な方法は「具体例を求めること」だ。
⑪ “Are there any constraints — budget, timeline, or technical — we need to account for?”
（考慮すべき制約——予算・スケジュール・技術——はありますか？）
⑫ “What happens if we don’t implement this? What’s the business impact of leaving it out?”
（これを実装しない場合、どうなりますか？含めないことのビジネスへの影響は？）
「実装しない場合のインパクト」を聞くことで、本当に必要な要件かを炙り出せる。
ヒアリング・議論フレーズのさらなる実践例は、エンジニアの英語要件ヒアリング術も参考にしてほしい。
要件定義プロセス②：文書化・仕様記述フレーズ（⑬〜⑱）
口頭で合意した内容を英語の要件文書に落とし込むフレーズ。「書き方の型」を持つことが、読み手に伝わる仕様書を作る鍵だ。
要件を文書に書き落とすフレーズ
⑬ “The system shall [機能の説明] when [トリガー条件].”
（システムは[トリガー条件]のとき、[機能の説明]するものとします。）
要件文の基本型。「The system shall」で始め、トリガー条件を添えると実装者が迷わない仕様になる。
⑭ “Given [前提条件], when [アクション], then [期待結果].”
（[前提条件]が与えられたとき、[アクション]を行うと、[期待結果]となる。）
「Given / When / Then」はBDD（振る舞い駆動開発）形式の受け入れ基準テンプレートだ。テストと要件を紐づけたい場合に特に有効。
⑮ “The acceptance criteria for this requirement are: [リスト].”
（この要件の受け入れ基準は：[リスト]です。）
受け入れ基準（Acceptance Criteria）は、「要件が完成したと見なせる条件」だ。すべての要件に紐づけることが英語仕様書のベストプラクティス。
制約・前提・スコープ外を記述するフレーズ
⑯ “This requirement is out of scope for [バージョン] and will be addressed in [将来のバージョン].”
（この要件は[バージョン]のスコープ外であり、[将来のバージョン]で対応予定です。）
⑰ “This requirement depends on [システム / チーム / 決定事項]. It cannot be implemented until [依存先] is resolved.”
（この要件は[システム/チーム/決定事項]に依存しています。[依存先]が解決されるまで実装できません。）
⑱ “Open questions: [未解決事項リスト]. Owner: [担当者]. Target resolution date: [日付].”
（未解決事項：[未解決事項リスト]。担当者：[担当者]。解決目標日：[日付]。）
英語仕様書・設計書の全セクションの書き方は、英語仕様書・設計書の書き方も参考にしてほしい。
要件定義プロセス③：レビュー・承認フレーズ（⑲〜㉔）
要件のベースライン化（合意・凍結）まで完了して、はじめて要件定義は完了する。レビューと承認を英語でスムーズに進めるフレーズを押さえよう。
レビューを依頼するフレーズ
⑲ “Please review the requirements document and provide feedback by [日付]. Focus especially on Section [X].”
（[日付]までに要件定義書をレビューしてフィードバックをお願いします。特にセクション[X]に注目してください。）
⑳ “I’d like to confirm our shared understanding: [要件の内容]. Is that correct?”
（共通認識を確認したいのですが：[要件の内容]。これで正しいですか？）
「shared understanding」という表現は合意の確認に広く使われる。「Do you understand?」より対等なニュアンスで、ステークホルダーとの関係を良好に保てる。
㉑ “We have a few open questions before we can baseline these requirements: [未解決事項リスト].”
（要件をベースライン化する前に、いくつかの未解決事項があります：[未解決事項リスト]。）
承認・ベースライン化を確認するフレーズ
㉒ “Could you sign off on these requirements? We need your approval before we proceed to design.”
（これらの要件を承認していただけますか？設計に進む前に承認が必要です。）
「sign off」は書面・口頭どちらの承認にも使える表現。意思決定者に使う定番フレーズだ。
㉓ “These requirements are now baselined. Any further changes will go through the change control process.”
（これらの要件はベースライン化されました。以後の変更は変更管理プロセスを通じて行います。）
ベースライン宣言は重要だ。「合意した」と「ベースライン化した」は別物で、後者はその後の変更に正式な手続きを求める。
㉔ “This requirement has been reviewed and approved by [承認者] on [日付]. Version: [v1.0].”
（この要件は[日付]に[承認者]によってレビュー・承認されました。バージョン：[v1.0]。）
要件変更・スコープクリープ対応フレーズ（㉕〜㉚）
要件定義後の「やっぱりこれも追加したい」は現場の宿命だ。変更を管理し、スコープクリープを防ぐフレーズを持とう。
要件変更を管理するフレーズ
㉕ “This is a change request — it’s outside the original scope. I’ll assess the impact on timeline and budget.”
（これは変更要求です——当初のスコープ外です。スケジュールと予算への影響を評価します。）
スコープ外の要求を「change request」として明確に位置づけることが、変更管理の第一歩だ。
㉖ “Adding this requirement would require approximately [X] additional days and [Y] additional cost. Do you want to proceed?”
（この要件を追加すると、約[X]日と[Y]の追加コストが必要です。進めますか？）
変更の影響を数字で示すことで、意思決定者が「追加するかどうか」を正しく判断できる。
スコープクリープを防ぐフレーズ
㉗ “This is scope creep — it wasn’t part of the original requirements. Can we defer it to the next release?”
（これはスコープクリープです——当初の要件には含まれていませんでした。次のリリースに延期できますか？）
「scope creep」という言葉を使うことで、追加要求が問題であることを相手に明確に伝えられる。
㉘ “If we add [新要件], we need to either extend the deadline or remove [既存要件] from this release. Which do you prefer?”
（[新要件]を追加するなら、期限を延長するか[既存要件]をこのリリースから外す必要があります。どちらを選びますか？）
「追加するなら何かを犠牲にする」というトレードオフを明示することで、無制限な追加を防げる。
㉙ “The requirements have been updated. See revision [v1.X] for the latest changes and the change log.”
（要件が更新されました。最新の変更と変更ログはリビジョン[v1.X]を参照してください。）
㉚ “This change has been approved through the change control process. The updated requirements are now baselined.”
（この変更は変更管理プロセスで承認されました。更新された要件がベースライン化されました。）
スコープ変更管理の詳細なフレーズは、エンジニアの英語スコープ・変更管理術も参考にしてほしい。
現場でよく出る要件定義英語用語集20選
要件定義の現場で頻出する英語用語をまとめた。会議中に出てきたとき即座に理解できるよう、手元に置いておこう。
ドキュメント種別・要件の種類
| 英語用語 | 日本語 | 使い方のポイント |
|---|---|---|
| Functional Requirement | 機能要件 | 「何をするか」を定義 |
| Non-functional Requirement | 非機能要件 | 「どのように動くか」を定義（性能・可用性・セキュリティ等） |
| Acceptance Criteria | 受け入れ基準 | 要件が完成したと見なせる条件 |
| User Story | ユーザーストーリー | 「〜として、〜したい、なぜなら〜」の形式で要件を記述 |
| Use Case | ユースケース | ユーザーとシステムの相互作用を記述 |
| MVP | 最小実行可能製品 | 最小限の機能でリリースできる状態 |
| MoSCoW | 優先度分類法 | Must / Should / Could / Won’tで要件を分類 |
プロセス・承認・変更管理の用語
| 英語用語 | 日本語 | 使い方のポイント |
|---|---|---|
| Baseline | ベースライン | 合意・凍結された要件の基準点 |
| Stakeholder | ステークホルダー | プロジェクトの利害関係者 |
| Sign-off | 承認 | 書面・口頭どちらの承認にも使える |
| Change Request | 変更要求 | ベースライン後の要件変更を申請する文書 |
| Change Control | 変更管理 | 変更要求を審査・承認するプロセス |
| Scope Creep | スコープクリープ | 合意範囲を超えた要件の追加・拡大 |
| Traceability | トレーサビリティ | 要件と設計・テストの追跡可能性 |
| Gap Analysis | ギャップ分析 | 現状と目標状態の差を分析すること |
| Dependency | 依存関係 | 他のシステム・要件・チームへの依存 |
| Constraint | 制約 | 設計・実装上の制限条件 |
| Assumption | 前提条件 | 設計が成立するための前提 |
| Open Question | 未解決事項 | まだ決まっていない要件上の問い |
| Backlog | バックログ | 今回のスコープ外・将来対応の要件リスト |
英語要件定義を成功させる3つのコツ
「What」より「Why」を先に定義する
「ログイン機能が欲しい」という要求を聞いたとき、すぐに実装の話をするのではなく “What’s the business goal behind this?” と目的を聞く。目的が明確になると、より良い解決策を提案できるし、不要な要件を削ぎ落とすこともできる。英語要件定義の場では、この「Why first」の姿勢が信頼されるエンジニアの証だ。
要件は「shall / must / should」で強さを統一する
同じ文書内で「shall」と「should」と「will」が混在すると、どの要件が必須でどれが推奨かわからなくなる。RFC 2119という国際標準に基づき、「shall / must」＝必須、「should」＝推奨、「may」＝任意と統一することで、文書全体の解釈が一致する。最初にチームで「この文書の用語定義」を合意するのが効果的だ。
すべての要件に「受け入れ基準」を紐づける
「ユーザーが商品を検索できる」という要件だけでは、「何件表示されればOKか」「レスポンスタイムは何秒以内か」が不明確だ。Acceptance Criteriaを各要件に紐づけることで、実装者・テスター・ステークホルダーの全員が「完成の定義」を共有できる。英語要件定義書の品質は、Acceptance Criteriaの精度で決まると言っても過言ではない。
まとめ：英語要件定義は「用語×型×プロセス」で完全制覇できる
「要件定義」に対応する英語はSRS・BRD・FRS・PRDなど複数あり、現場によって使い分けられる。用語を正確に理解したうえで、フレーズの型とプロセスを組み合わせることで、英語での要件定義業務を完全にこなせる。
今日からできることをまとめる：
- 要件定義の場では「BRDとSRSのどちらを使うか」を最初に確認する
- 要件の優先度はMoSCoW（Must / Should / Could / Won’t）で整理する
- 要件文は “The system shall [機能] when [条件].” の型で書く
- 受け入れ基準（Acceptance Criteria）をすべての要件に紐づける
- スコープ外の要求は即座に “This is a change request.” と宣言する
- 用語集の20語を手元に置き、会議中に迷わず使えるようにする
用語・型・プロセスの3つを手に入れた今、次の英語要件定義の場で1つフレーズを使ってみよう。
コメント