コードを書く前に、要求をハッキリさせるシンプルな方法
**対象**: ソフトウェア開発者
**発表者**: (ご自身のお名前)
「もっとユーザーに優しいUIにしてください」
...優しいって、具体的にどういうこと？
「システムは高速に応答すること」
...高速って、何秒以内？
「通常時とエラー時で処理を分けてほしい」
...通常時っていつ？どんなエラーを想定？
「この機能は、よしなに実装しておいて」
...仕様を読んでも、どうすればいいか不明...
これらの曖昧さが、手戻りやバグの原因になります。
私たちが普段使っている言葉には、5つの「落とし穴」が潜んでいます。
複数の意味に解釈できてしまう
「適切な」など基準が不明確
1文に複数の要求が混在
エラー処理などが抜けている
要求を満たしたか確認できない
これらの問題が、開発終盤での「思っていたのと違う！」という悲劇を生み出します。
自然言語に“ちょっとしたルール”を加えるだけで、要求を明確にするフレームワークです。
新しいツールは不要
誰が読んでも同じ理解
要求がテストのヒントに
もともとは航空宇宙業界（ロールス・ロイス社）で、エンジンの制御システムなど、非常に高い安全性が求められる分野で生まれました。
EARSの構文は、時間的な順序に基づいたシンプルな構造です。
〜である間
要求が有効になるための
継続的な**状態**や**モード**
〜が起きたとき
システムの応答を引き起こす
特定の**イベント**
〇〇は
応答する責任を持つ
**システム**や**コンポーネント**
〜しなければならない
システムが実行すべき
必須の**アクション**
この構造が、要求に必要な「いつ」「どんな状況で」「何が」「どうなる」を強制的に明確にします。
まずは、最もよく使う3つの基本パターンを覚えましょう。
Ubiquitous
常に有効なシステムの基本的な制約やルール。
構文:
The <システム名> shall <振る舞い>.
例:
「システムは、患者データへの不正アクセスを防止しなければならない。」
Event-Driven
何かの「きっかけ」に対するシステムの応答。
構文:
When <きっかけ>, The <システム名> shall <振る舞い>.
例:
「「送信」ボタンがクリックされたとき、フォームデータは検証されなければならない。」
State-Driven
特定の「状態」における継続的な振る舞い。
構文:
While <状態>, The <システム名> shall <振る舞い>.
例:
「システムがメンテナンスモードである間、すべてのユーザーアクセスは制限されなければならない。」
基本パターンに加えて、これらも非常に強力です。
Unwanted Behavior
エラーや障害など、予期せぬ事態への対応。
構文:
If <望ましくない条件>, then The <システム名> shall <振る舞い>.
例:
「ネットワーク接続が失われた場合、システムは自動的に再接続を試みなければならない。」
Optional Feature
特定の条件でのみ有効になる機能やバリエーション。
構文:
Where <機能が含まれる場合>, The <システム名> shall <振る舞い>.
例:
「プレミアムサブスクリプションが有効な場合、ユーザーは限定コンテンツにアクセスできなければならない。」
「エラーをログに記録する」
(いつ？ どんなエラーを？)
If データベース接続に失敗した場合, then システムは shall エラーメッセージをログファイルに記録する。
→ いつ、何をするかが明確に！
「ユーザーはログインできる」
(失敗した場合は？ アカウントがロックされていたら？)
When ユーザーが有効な認証情報を入力し「ログイン」ボタンをクリックしたとき, the システムは shall ユーザーをダッシュボードにリダイレクトする。
If ユーザーが無効な認証情報を入力した場合, then the システムは shall 「認証情報が正しくありません」と表示する。
→ 正常系と異常系の振る舞いが明確に！
ユーザーストーリーの「受け入れ基準」をEARSで記述するのが非常に効果的です！
As a 顧客,
I want to ログインできるようにしたい,
so that 注文履歴を確認できる
...「何を」「なぜ」作るかは分かるが、「どう動くべきか」の詳細は曖昧になりがち。
受け入れ基準を
EARSで記述
When ユーザーが有効なIDとパスワードでログインしたとき, the システムは注文履歴画面を表示しなければならない。
If ユーザーが無効なIDまたはパスワードを入力した場合, then the システムはエラーメッセージを表示しなければならない。
While アカウントがロックされている間, the システムは全てのログイン試行を拒否しなければならない。
「何を」作るべきかがハッキリするので、コーディングに集中できます。
仕様の解釈違いによる「思ってたんと違う！」が激減します。
要求がテストケースのヒントに。「When」はトリガー、「shall」は期待結果です。
POやQAと「同じ言葉」で話せるようになり、認識のズレを防ぎます。
EARSは、自然言語の要求を「明確」で「検証可能」にするためのシンプルなフレームワークです。
5つの基本パターンを覚えるだけで、すぐに始められます。
曖昧な要求に悩んだら、この質問を投げかけてみましょう:
「いつ(When/If)？ どんな状態で(While)？
何が(The system)？ どうなる(shall)のか？」
明日から使えるEARSで、開発をもっとスムーズに進めましょう！
(ご自身のお名前)
（メールアドレスやSNSなどの連絡先）