EARSとは何か
EARS（Easy Approach to Requirements Syntax、イアース）は、要件を曖昧さなく書くための構文ガイドラインです。2009年に英国Rolls-Royceの研究者Alistair Mavinらが提案し、自動車・航空・宇宙など安全性が重視される業界で広く採用されてきました。近年はソフトウェア開発でも、特に受入条件や非機能要件を書く場面で使われています。
EARSの本質はシンプルで、要件を 「どんな条件で・システムが・何をする」 という決まったパターンで書くというものです。日本語の自然文でありがちな主語の省略、条件と振る舞いの混在、可能性のある状態の見落としを防げます。
なぜユーザーストーリーだけでは足りないのか
ユーザーストーリーは、Why（なぜ作るのか）を共有するのに優れた形式です。
管理者として、ユーザーをメールアドレスで検索したい。なぜなら、問い合わせ対応時に5秒以内に該当ユーザーを見つけたいから。
しかしこれだけでは、開発者が「何をどう実装すべきか」を確信して進められません。
- 検索結果は何件まで表示するのか？
- 大文字小文字を区別するのか？
- ヒットしなかった場合の挙動は？
- 接続エラーの場合は？
これらをすべて自然文で書くと、「〜の場合は〜する。ただし〜であれば〜」のような複雑な日本語になり、解釈の余地が生まれます。EARSはここを構文で揃えます。
ユーザーストーリーで Why を共有し、EARS で受入条件と非機能要件を曖昧さなく定義する。この組み合わせが現代の要件記述のスタンダードになりつつあります。
EARSの5つのパターン
EARSには5つのテンプレートがあり、状況に応じて使い分けます。
パターン1: ユビキタス（Ubiquitous）
常に成り立つ振る舞い。
The 〈システム〉 shall 〈振る舞い〉.
〈システム〉は〈振る舞い〉する。
例:
検索システムは、入力値を1MB以下に制限する。
The search system shall limit the input value to 1MB or less.
「常時」「いつでも」「どんな状況でも」という性質の要件に使います。非機能要件（性能・セキュリティ・可用性）の多くがこれに該当します。
パターン2: イベント駆動（Event-driven）
特定の出来事が起きたときの振る舞い。
When 〈トリガー〉, the 〈システム〉 shall 〈振る舞い〉.
〈トリガー〉のとき、〈システム〉は〈振る舞い〉する。
例:
ユーザーが検索ボタンをクリックしたとき、検索システムは1秒以内に結果を表示する。
When a user clicks the search button, the search system shall display results within 1 second.
ユーザー操作・外部APIからの通知・タイマーなど、明確なきっかけがある要件に使います。
パターン3: 状態駆動（State-driven）
ある状態にある間の振る舞い。
While 〈状態〉, the 〈システム〉 shall 〈振る舞い〉.
〈状態〉の間、〈システム〉は〈振る舞い〉する。
例:
ユーザーがログインしている間、検索システムは検索履歴を保存する。
While a user is logged in, the search system shall save the search history.
ログイン中・処理中・メンテナンス中など、ある時間幅で続く状態に紐づく要件に使います。
パターン4: オプション（Optional feature）
機能が有効化されている場合のみの振る舞い。
Where 〈機能フラグ〉, the 〈システム〉 shall 〈振る舞い〉.
〈機能フラグ〉の場合、〈システム〉は〈振る舞い〉する。
例:
多言語対応が有効な場合、検索システムは検索結果を選択言語で表示する。
Where multilingual support is enabled, the search system shall display results in the selected language.
エディションごとに有無が変わる機能、設定でオン・オフできる機能に使います。
パターン5: 望まない振る舞いへの対処（Unwanted behavior）
例外的な状況での振る舞い。
If 〈望まない条件〉, then the 〈システム〉 shall 〈対処〉.
〈望まない条件〉の場合、〈システム〉は〈対処〉する。
例:
検索クエリが空の場合、検索システムはエラーメッセージを表示する。
If the search query is empty, then the search system shall display an error message.
エラー・タイムアウト・バリデーション失敗・接続障害など、想定外の状況への対応を漏れなく記述するのに使います。ユーザーストーリーで抜け落ちやすい異常系を網羅できるのが、このパターンの大きな価値です。
複合パターン
実務では2つを組み合わせることもあります。
While 〈状態〉, when 〈トリガー〉, the 〈システム〉 shall 〈振る舞い〉.
例:
オフラインモードの間、ユーザーが検索を実行したとき、検索システムはキャッシュから結果を表示する。
自然文との比較
同じ要件を自然文で書いた場合とEARSで書いた場合を見比べてみます。
自然文（曖昧）
商品検索機能では、検索結果が見やすく表示される必要がある。エラーが起きた場合は適切に処理する。
問題点:
- 「見やすい」とは具体的に何件、どんな並びか？
- 「適切に処理」とは何をするのか？
- どんなエラーを想定しているのか？
EARS（明確）
ユビキタス: 商品検索システムは、検索結果を1ページあたり20件まで表示する。
ユビキタス: 商品検索システムは、検索結果を関連度の降順で並べる。
イベント駆動: ユーザーが検索ボタンをクリックしたとき、商品検索システムは1秒以内に結果を表示する。
望まない振る舞い: 検索クエリが空の場合、商品検索システムは「キーワードを入力してください」と表示する。
望まない振る舞い: 検索処理が3秒を超えた場合、商品検索システムは「タイムアウトしました」と表示する。
開発者が手戻りなく実装でき、テスト担当者が漏れなくテストケースを書けます。
ユーザーストーリーとEARSを組み合わせた完成形
実務では次のように組み合わせます。
## US-101: 商品検索機能
ユーザーストーリー（Why）
店舗マネージャーとして、商品名で在庫を検索したい。
なぜなら、顧客から問い合わせを受けた際に、その場で在庫の有無を答えたいから。
受入条件（What、EARS）
- ユビキタス: 商品検索システムは、検索結果を1ページあたり20件まで表示する。
- ユビキタス: 商品検索システムは、検索結果を在庫数の降順で並べる。
- イベント駆動: ユーザーが検索ボタンをクリックしたとき、商品検索システムは1秒以内に結果を表示する。
- イベント駆動: 検索結果が0件のとき、商品検索システムは「該当する商品がありません」を表示する。
- 状態駆動: ユーザーがログインしている間、商品検索システムは過去5件の検索履歴を表示する。
- オプション: 詳細検索オプションが有効な場合、商品検索システムはカテゴリと価格帯による絞り込みを許可する。
- 望まない振る舞い: 検索クエリが空の場合、商品検索システムはエラーメッセージを表示する。
- 望まない振る舞い: 在庫DBに接続できない場合、商品検索システムは「現在検索できません」を表示する。
非機能要件（EARS）
- ユビキタス: 商品検索システムは、99.9%の可用性を保つ。
- イベント駆動: 同時リクエスト数が100を超えたとき、商品検索システムはレート制限を適用する。
ユーザーストーリーが「なぜ作るか」、EARSが「何をどう作るか」を担当します。両者を切り分けることで、それぞれの粒度が適切に保たれます。
EARSを書くときの注意点
注意1: 「shall」を使う
EARSでは「shall（〜する）」を使い、「should（〜すべき）」「may（〜してもよい）」と区別します。日本語の場合は「〜する」と言い切る形にし、「〜すべき」「〜したい」を避けます。
注意2: システム名を主語にする
「ユーザーが〜できる」ではなく「システムが〜する」と書きます。要件の主体は常にシステム側です。
良い例:
- ✅ 検索システムは、検索結果を1秒以内に表示する。
悪い例:
- ❌ ユーザーは、検索結果を1秒以内に得られる。
注意3: 数値を含める
「速い」「多くの」のような形容詞は避け、数値で書きます。
良い例:
- ✅ 1秒以内に
- ✅ 100件まで
- ✅ 99.9%以上
悪い例:
- ❌ 速やかに
- ❌ 大量の
- ❌ 高い可用性で
注意4: 一文一要件
複数の条件・振る舞いを1文に詰め込まない。「〜の場合は〜し、また〜のときは〜する」と書きそうになったら、2文に分割します。
注意5: パターンを混ぜない
「When 〜 while 〜 if 〜」のように3つも4つも組み合わせると、自然文と変わらない曖昧さが戻ってきます。複合は2つまで。それ以上必要なら、別の要件として書き直します。
EARSを使う・使わない場面の使い分け
すべての要件をEARSで書く必要はありません。
EARSを使うとよい場面
- 受入条件（Acceptance Criteria）
- 非機能要件（性能・セキュリティ・可用性）
- 異常系・エラー処理
- API契約（リクエスト・レスポンスの仕様）
- 状態遷移を含む機能
EARSを使わなくてよい場面
- ユーザーストーリーのWhy部分（自然文の方が伝わる）
- ステークホルダー向けの概要説明
- ビジネスゴール・KPIの記述
- 大まかな初期構想（粒度が早すぎる）
EARSの導入ステップ
Step 1: ユーザーストーリーを先に書く
Story Builder で「誰が・何を・なぜ」を書き出します。
Step 2: 受入条件をEARSの5パターンで分解
ストーリーごとに、ユビキタス・イベント駆動・状態駆動・オプション・望まない振る舞いの観点で受入条件を書きます。網羅性のチェックリストとして機能します。
Step 3: 非機能要件を追加
性能・セキュリティ・可用性などをユビキタスとイベント駆動で追加します。
Step 4: スコープ評価へ
要件が出そろったら、Scope Manager（FM法）で「ビジネス価値・現場で使えるか・技術コスト」の3軸評価を行い、何を作るかを決めます。
まとめ
EARSは、要件の曖昧さを構文の力で減らすツールです。覚えるべきは5パターンだけで、
- ユビキタス（常に）
- イベント駆動（〜のとき）
- 状態駆動（〜の間）
- オプション（〜の場合）
- 望まない振る舞い（〜となった場合）
ユーザーストーリーと組み合わせることで、Why と What の両方を漏れなく記述できます。複雑な業務システム、安全性が重要なシステム、大規模プロジェクトでは特に効果を発揮します。
関連記事 / 関連ツール
要件記述でお困りなら
複雑な業務要件をEARSで整理する支援も行っています。
参考文献
- Alistair Mavin et al. "Easy Approach to Requirements Syntax (EARS)" (2009)
- ISO/IEC/IEEE 29148:2018（Systems and software engineering — Life cycle processes — Requirements engineering）