EARS記法とは｜要件を1文で書く5つの型を日本語の例文で解説

要件定義書に「パスワードを再設定できること」と1行だけ書いてあったとします。読んだ人は全員うなずきます。ところが実装が始まると、再設定用リンクは何分使えるのか、未登録のメールアドレスにはどう返すのか、と質問が出てきます。1行の中に、まだ決めていないことが何個も残っていたわけです。

EARS記法は、この1行を「どんなときに、システムが、どうするか」の決まった型で書き直す方法です。型は5つしかありません。型に当てはめていくと書けない部分が出てきて、そこがまだ決まっていない場所だと分かります。

Beekleでは普段、受入条件を日本語のGherkinで書いています。ただ、要件の書き方はGherkinだけではありません。1文で決まりを書き切るEARSという書き方もできます。この記事では、EARSの5つの型を日本語の例文つきで説明し、Gherkinとの違いまで見ます。

EARS記法とは、要件を決まった型の1文で書く方法です

EARSは Easy Approach to Requirements Syntax の略です。英Rolls-Royceのアリスター・メイヴィン（Alistair Mavin）氏らが、ジェットエンジン制御システムの耐空性規則を分析する中で作り、2009年に発表しました。

基本の形は1つです。

英語：While 〈前提となる状態〉, when 〈きっかけ〉, the 〈システム名〉 shall 〈システムの応答〉.

日本語：〈状態〉である間、〈きっかけ〉が起きたとき、システムは、〈応答〉すること。

状態ときっかけは、必要なときだけ書きます。どちらも無ければ「システムは、〜すること」だけが残ります。主語はいつもシステムで、文末は言い切ります。英語の shall は日本語の「〜すること」にあたり、「〜が望ましい」「〜できるとよい」とは書きません。

自由に書ける文章より窮屈に見えます。役に立つのは、その窮屈さです。条件を書く場所と、応答を書く場所が分かれているので、「エラーのときは適切に処理する」と書こうとすると、どのエラーのときか、何をするのかを、それぞれの場所に書くよう求められます。

EARSの5つの型と、日本語の例文

型は、条件の種類で分かれます。

1. 常に守ること（Ubiquitous）

英語：The 〈システム名〉 shall 〈応答〉.

日本語：システムは、〜すること。

条件がなく、いつでも成り立つ決まりです。この型だけはキーワードがありません。

例：システムは、パスワードをハッシュ化して保存すること。

性能やセキュリティのように、特定の操作に結びつかない決まりがこの型になります。

2. 何かが起きたとき（Event driven、When）

英語：When 〈きっかけ〉, the 〈システム名〉 shall 〈応答〉.

日本語：〜したとき、システムは、〜すること。

例：利用者がパスワード再設定を要求したとき、システムは、登録済みのメールアドレス宛に再設定メールを送ること。

利用者の操作、外部からの通知、決まった時刻の到来のように、きっかけがはっきりしている要件に使います。

3. ある状態の間（State driven、While）

英語：While 〈状態〉, the 〈システム名〉 shall 〈応答〉.

日本語：〜である間、システムは、〜すること。

例：アカウントがロックされている間、システムは、パスワード再設定の要求を受け付けないこと。

ログイン中、処理中、メンテナンス中のように、しばらく続く状態に結びつく要件です。「とき」は一瞬の出来事、「間」は続いている状態、と分けます。

4. その機能がある場合（Optional feature、Where）

英語：Where 〈機能が含まれる〉, the 〈システム名〉 shall 〈応答〉.

日本語：〜の場合、システムは、〜すること。

例：二要素認証を有効にしている場合、システムは、新しいパスワードを設定する前に確認コードの入力を求めること。

契約プランや設定によって、あったりなかったりする機能に使います。

5. 望まないことが起きた場合（Unwanted behaviour、If / Then）

英語：If 〈望まない出来事〉, then the 〈システム名〉 shall 〈応答〉.

日本語：〜した場合、システムは、〜すること。

例：期限が切れた再設定用リンクが使われた場合、システムは、再設定をやり直すよう案内すること。

入力の誤り、期限切れ、外部サービスの障害など、起きてほしくない場面でどうするかを書きます。「再設定できること」のような1行から抜けやすいのが、この型の要件です。

日本語にすると、4と5はどちらも「場合」になります。4は機能があるかどうか、5は起きてほしくない出来事、と中身で区別します。

型を2つ組み合わせる（Complex）

英語：While 〈状態〉, when 〈きっかけ〉, the 〈システム名〉 shall 〈応答〉.

例：メンテナンス中である間、利用者がパスワード再設定を要求したとき、システムは、受付を停止していることを表示すること。

キーワードが2つ以上入る要件は、複合（Complex）と呼ばれます。

「パスワードを再設定できること」をEARSで書き直す

冒頭の1行に戻ります。5つの型を順に当てると、次の6文が出てきます。

システムは、パスワードをハッシュ化して保存すること。
利用者がパスワード再設定を要求したとき、システムは、登録済みのメールアドレス宛に再設定メールを送ること。
システムは、再設定用リンクを発行から1時間後に無効にすること。
未登録のメールアドレスで再設定が要求された場合、システムは、登録済みのときと同じ完了メッセージを表示すること。
期限が切れた再設定用リンクが使われた場合、システムは、再設定をやり直すよう案内すること。
使用済みの再設定用リンクがもう一度使われた場合、システムは、パスワードを変更しないこと。

1行だった要件が6文になりました。増えた5文は、新しく思いついた機能ではありません。元の1行を読んだ人が、それぞれ頭の中で補っていた内容です。補い方が人によって違うので、実装したあとで食い違いが見つかります。

書いている途中で手が止まる文も出ます。「再設定用リンクを発行から何時間後に無効にするか」が埋まらないなら、書き方でつまずいたのではなく、まだ誰も決めていなかったということです。事業側へ聞きに行く質問が1つ見つかりました。

EARSで書くときに崩れやすい4か所

主語を利用者にしてしまう。「利用者は、再設定メールを受け取れる」ではなく「システムは、再設定メールを送ること」と書きます。何を作るかを決める文なので、主語は作る対象にします。
形容詞で済ませてしまう。「すぐに」「大量の」「安全に」は、読む人によって思い浮かべる数字が違います。「1時間後に」「5回まで」のように、数えられる形にします。
1文に2つの応答を入れてしまう。「メールを送り、あわせて履歴に記録すること」と書くと、片方だけ実装された状態を合格にするのか判断できません。2文に分けます。
条件を3つ以上重ねてしまう。「〜である間、〜したとき、〜の場合」と続けると、読む人が条件の組み合わせを頭の中で解くことになります。要件を分けます。

EARSとGherkinは何が違うのか

再設定メールの要件を、日本語のGherkinで書くとこうなります。

シナリオ：登録済みユーザーが再設定メールを要求できる
  前提 登録済みユーザー「田中」のメールアドレスが存在する
  もし 田中がパスワード再設定を要求する
  ならば 田中のメールアドレス宛に再設定メールが送信される
  かつ 再設定用リンクは1時間後に無効になる

EARSの文には「利用者」と書いてありました。Gherkinには「田中」がいます。EARSが書くのは、どんな場合にどうあるべきかという決まりです。Gherkinが書くのは、その決まりが守られていると確かめられる具体的な1場面です。

この差は、書いたあとの使い道に出ます。EARSの文は短いので、一覧にして抜けを点検しやすい。性能やセキュリティのように、場面にしにくい決まりもそのまま書けます。Gherkinのシナリオは長くなりますが、前提と操作と結果がそろっているので、そのまま自動テストになり、お客さんが画面で確かめる手順にもなります。

Beekleが普段Gherkinを使っているのは、お客さんと同じシナリオで確かめられるからです。お客さんもシナリオテストできるように日本語で書き、同じシナリオを自動テストにしています。EARSで決まりを1文ずつ書き出してから、確かめたいものをGherkinのシナリオにする、という順番でも書けます。Gherkinの書き方はGherkin入門にまとめています。

受入条件を全部手で書くのは、かなり大変です

1行の要件が6文になり、その1文ずつにシナリオが付きます。機能が増えるほど、書く量もレビューする量も増えていきます。私たちも、実案件でこれを全部手で書いてレビューするのが大変だったので、「PM on Rails」というシステムを作りました。

PM on Rails｜要求からGherkin、実装、動作確認までをつなぐ実案件でGherkinや受入条件を全部手書きしてレビューするのが大変だったので、Beekleが自社で作り、実際の開発で使っている開発管理システムです。要求をユーザーストーリーとGherkinに整理し、決まっていない点は質問に戻し、確定した仕様をAIエージェントの実装と動作確認につなげます。現在はベータ版で、一般公開に向けてウェイティングリストを受け付けています。ウェイティングリストに登録する

よくある質問（FAQ）

Q. EARS記法の5つのパターンは何ですか？

A. 常に守ること（Ubiquitous）、何かが起きたとき（Event driven、When）、ある状態の間（State driven、While）、その機能がある場合（Optional feature、Where）、望まないことが起きた場合（Unwanted behaviour、If / Then）の5つです。キーワードを2つ以上組み合わせた要件は、複合（Complex）と呼ばれます。

Q. EARSは日本語でも書けますか？

A. 書けます。主語を「システムは」に固定し、文末を「〜すること」で言い切り、条件を「〜したとき」「〜である間」「〜の場合」「〜した場合」で書き分けます。Where と If はどちらも「場合」になるので、機能があるかどうかの話か、望まない出来事の話かを中身で区別します。

Q. EARSとGherkinは、どちらを使えばよいですか？

A. 決まりを短く一覧にして抜けを点検したいならEARS、決まりが守られているかを具体的な場面で確かめたいならGherkinです。Beekleは、お客さんもシナリオテストできるように日本語のGherkinを使っています。EARSで決まりを書き出してからGherkinのシナリオにする書き方もできます。Gherkinの書き方はGherkin入門で説明しています。

Q. EARSとユーザーストーリーは何が違いますか？

A. ユーザーストーリーは、誰が何をしたいのか、なぜ必要なのかを書きます。EARSは、そのためにシステムがどう振る舞うかを1文ずつ書きます。「登録済みユーザーがパスワードを再設定できる」がユーザーストーリー、「利用者がパスワード再設定を要求したとき、システムは、再設定メールを送ること」がEARSです。ユーザーストーリーの書き方はUser Storyの書き方にあります。

Q. EARSは誰が作ったのですか？

A. 英Rolls-Royceのアリスター・メイヴィン（Alistair Mavin）氏らが、ジェットエンジン制御システムの耐空性規則を分析する中で作り、2009年に発表しました。

参考：Alistair Mavin, EARS: Easy Approach to Requirements Syntax