システム開発の現場で、「そんなつもりで書いたんじゃないのに」「この条件の時、どう動くか書いていない」といったコミュニケーションの齟齬に悩まされていませんか？

日本語は文脈に依存しやすい言語です。そのため、良かれと思って書いた丁寧な文章が、エンジニアにとっては「曖昧で実装できない指示」になってしまうことが多々あります。

そんな要件定義の悩みを一掃するのが、今回ご紹介するEARS（Easy Approach to Requirements Syntax）記法です。イギリスのロールス・ロイス社で生まれた「絶対にミスが許されない現場の書き方」を、初心者の方でもすぐに実践できるようにわかりやすく解説します。

EARS（イヤーズ）記法とは？ロールス・ロイスが生んだ究極のテンプレート

EARS（Easy Approach to Requirements Syntax） は、一言でいうと 「誰が書いても、誰が読んでも、解釈のズレが起きないようにシステム要件を書くためのテンプレート」 です。

この記法は、世界的なメーカーであるイギリスのロールス・ロイス社のエンジニアらによって考案されました。わずかな仕様の誤認が重大な事故に直結する「究極の正確性」が求められる現場で、複雑な仕様を厳格に記述するために生み出された手法です。

なぜEARSが必要なのか？「曖昧な日本語」が招く開発の悲劇

普通に文章で要件を書こうとすると、以下のような問題が発生しがちです。

  • 「適当なタイミングで通知を出す」 → 具体的にいつ？
  • 「エラー時は赤くする」 → 全てのエラー？通信エラーだけ？
  • 「ユーザーは情報を閲覧できる」 → ログインしていなくても？

EARSを導入すると、文章が強制的に構造化されるため、こうした「条件の抜け漏れ」や「主語の欠如」を物理的に排除できます。

EARSを構成する「6つの基本パターン」と具体例

EARSは、以下の6つのパターンだけで構成されます。スマートコーヒーメーカーを例に、それぞれの書き方を見ていきましょう。

1. 常時型 (Ubiquitous)

特定の条件がなく、「常に」動作すべき振る舞いを記述します。

  • キーワード： なし（直接記述）
  • 要件文： 本機は、現在時刻をディスプレイに表示しなければならない。

2. イベント駆動型 (Event-driven)

「何かが起きた瞬間」の動作を記述します。

  • キーワード： WHEN（〜の時）
  • 要件文： WHEN 抽出ボタンが押された時、本機はコーヒーの抽出を開始しなければならない。

3. 望ましくない動作型 (Unwanted Behavior)

エラーや例外系など、「もし〜なら（困る状況）」を記述します。

  • キーワード： IF（もし〜なら）
  • 要件文： IF 水タンクが空であるなら、本機は警告ランプを点滅させなければならない。

4. 状態駆動型 (State-driven)

「特定の状態にいる間」の継続的な制限や動作を記述します。

  • キーワード： WHILE（〜の間）
  • 要件文： WHILE クリーニングモードの間、本機は抽出ボタンの操作を無効化しなければならない。

5. オプション型 (Optional)

特定の機能やハードウェアがある場合のみ適用される要件を記述します。

  • キーワード： WHERE（〜がある場合）
  • 要件文： WHERE ミル機能が搭載されているモデルでは、本機は豆の挽き具合設定メニューを表示しなければならない。

6. 複雑な型 (Complex)

複数の条件が組み合わさった条件下のみ適用される要件を記述します。

  • キーワード： WHILE, WHERE, IF, WHEN の組み合わせ
  • 要件文： WHILE 省エネモードの間、IF 水の温度が80度以下なら、WHEN 抽出ボタンが押された時、本機は加熱ランプを点滅させなければならない。

比較表：EARSの6つのパターンまとめ

パターン キーワード 使用シーン 例文
常時型 なし 常に必要な機能 本機は時刻を表示しなければならない。
イベント駆動型 WHEN 操作やトリガーがあった時 ボタンが押された時、抽出を開始しなければならない。
望ましくない動作型 IF エラーや例外が発生した時 水がないなら、警告を表示しなければならない。
状態駆動型 WHILE 特定の状態にある間 メンテナンス中は、ボタンを無効にしなければならない。
オプション型 WHERE 特定の構成・環境の時 ミルがあるなら、挽き方の設定を表示しなければならない。
複雑な型 組み合わせ 複数の条件が重なる時 省エネ中かつ水温低下時にボタンが押されたら加熱を優先しなければならない。

実践のコツ：文末を「〜しなければならない（Shall）」で統一する

EARSのもう一つの重要なポイントは、文末を 「〜しなければならない（Shall）」 で統一することです。

日本語の仕様書では「〜のこと」「〜とする」「〜可能とする」など表現がバラつきがちですが、これらを「〜しなければならない」に統一することで、それが「願望」ではなく「必須の要件」であることを明確にします。


「ポイント：主語を明確にする」

「本機は（システムは）〜しなければならない」という形で、常に「誰が（何が）」動くのかをセットで書く癖をつけましょう。

まとめ：EARSで「伝わる仕様書」へ

EARS記法は、単なる書き方のルールではありません。要件をこの型に当てはめようと考える過程で、「条件の漏れ」や「例外処理の考慮不足」に自分自身で気づけるようになるのが最大のメリットです。

プロジェクトの初期段階でEARSを導入すれば、手戻りが減り、開発スピードと品質は劇的に向上するはずです。

まずは、次の仕様書の1行を WHEN や IF から書き始めてみてはいかがでしょうか？最後まで読んでいただきありがとうございました。この記事が、あなたの現場での要件定義をスムーズにする一助となれば幸いです。