はじめに
あなたはこう思ったことはないでしょうか。
「この要件、解釈が分かれるんじゃないか」
「テストケースが書けない……これは本当に検証できる要求なの？」
「この要件、結局どこを実装すればいいの？」
要件定義の失敗は、プロジェクトのスケジュール遅延やコスト増に直結します。自然言語で書かれた要件には、本質的に以下のような問題が含まれがちです。
- 曖昧性：単語や表現に複数の意味があり、解釈が分かれる
- 不明確さ：精度、構造、詳細さが不足している
- 複雑さ：複雑な従属節や複数の関連する文が混在している
- 省略：必要な要求、特に望ましくない動作の処理が欠落している
- 重複：同じニーズを定義する要求の繰り返し
- 冗長性：不必要に多くの単語が使用されている
- 不適切な実装：「何を」行うべきかではなく「どのように」構築するかを記述している
- 検証不能性：実装後に真偽を証明できない要求
これらの問題に悩まされた経験があるなら、今回の記事はあなたの役に立つでしょう。
要件定義に「型」をもたらす技法、EARS（Easy Approach to Requirements Syntax）をご紹介します。自然言語のまま、しかし構造化されたテンプレートに要件を当てはめるだけで、要件の品質が飛躍的に向上します。
EARSの概要
EARSは、2009年にRolls-Royceのエンジニアらによって発表された要求エンジニアリングの技法です。元々は航空機エンジン制御システムの開発において、航空機安全認証規格（CS-E）の要求を解析・記述するために開発されました。
なぜEARSなのか
UMLやSysMLといった図式表記、あるいはZのような形式手法も、要求の明確化に有効です。しかし、これらの手法には課題があります。
- 元の要求を新たな表記に変換する必要があるため、翻訳エラーのリスクがある
- 新たな表記法の習得には訓練コストがかかる
- 要件作者は形式的な表記を避けがちで、支援ツールがないと実践が難しい
EARSのアプローチは異なります。制約付き自然言語（Constrained Natural Language）を採用し、図式表記への翻訳を不要にします。単純な構文ルールのみで、訓練コストを最小限に抑えながら、要件の明確化を実現します。
時間的論理に基づく一貫した構造
EARSの核心は、要件を以下の5つのテンプレートのいずれかに分類して記述することです。
<任意の事前条件> <任意のトリガー> the <システム名> shall <システム応答>
この構造は時間的論理（temporal logic）に従っています：
- 事前条件が満たされない限り、要件は発動しない
- トリガーが真となった時点で、要件が「発火」する
- システムは事前条件とトリガーが真となった場合のみ、システム応答を実行する必要がある
この一貫した構造が、要件の曖昧さを大幅に削減します。
5つの要求テンプレート
EARSでは、要件を以下の5つのタイプに分類して記述します。それぞれのテンプレートを確認していきましょう。
1. Ubiquitous（常時アクティブ）
システムが常に満たすべき動作を記述します。条件やトリガーを持たない、最も単純なテンプレートです。
<システム名> shall <システム応答>
例：
The control system shall prevent engine overspeed. （制御システムはエンジン過回転を防がなければならない。）
この要件は、システムが稼働している間、常に有効です。特定のイベントや状態に依存しません。
2. Event-driven（イベント駆動）
システム境界で検出された特定のイベントが発生したときに発動する要求です。
WHEN <任意の事前条件> <トリガー> the <システム名> shall <システム応答>
例：
When continuous ignition is commanded by the aircraft, the control system shall switch on continuous ignition. （航空機から連続点火が指示された場合、制御システムは連続点火をオンにしなければならない。）
この要件は、トリガー（連続点火の指示）が検出されたときのみ発動します。事前条件があれば、それが満たされて初めてトリガーが有効になります。
3. Unwanted behaviours（望ましくない動作）
失敗、外乱、予期せぬ事象への対応を記述します。If-Then構造で明示することで、望ましくない動作の処理を明確に区別します。
IF <任意の事前条件> <トリガー>, THEN the <システム名> shall <システム応答>
例：
If the computed airspeed fault flag is set, then the control system shall use modelled airspeed. （計算された空速の故障フラグが設定されている場合、制御システムは計算空速を使用しなければならない。）
このテンプレートは、システムが失敗や外乱に対処する方法を記述するために特別に用意されています。要件リストの中で「もし〜なら」という構造を持つ要件は、すべて望ましくない動作の処理と判断できます。
4. State-driven（状態駆動）
システムが特定の状態にある間、常に有効な要求です。
WHILE <特定の状態> the <システム名> shall <システム応答>
例：
While the aircraft is in-flight, the control system shall maintain engine fuel flow above XXlbs/sec. （航空機が飛行中の間、制御システムはエンジン燃料流量をXXlbs/sec以上に維持しなければならない。）
可読性向上のため、Whileの代わりにDuringを使用することもできます。意味は同じです。
5. Optional features（オプション機能）
特定の特徴を持つシステムにのみ適用される要求です。
WHERE <特徴が含まれる> the <システム名> shall <システム応答>
例：
Where the control system includes an overspeed protection function, the control system shall test the availability of the overspeed protection function prior to aircraft dispatch. （制御システムが過回転保護機能を含んでいる場合、制御システムは航空機の出航前に過回転保護機能の可用性を検証しなければならない。）
この機能は、システムに特定の機能が含まれているかどうかによって、要件が必要かどうかを判断するために使います。
テンプレートの分類フロー
要件をどのテンプレートに分類すべきか、以下のフローで判断できます。
flowchart TD
A[要件の分析] --> B{事前条件か？}
B -->|はい| C{条件の内容は？}
B -->|いいえ| D[Ubiquitous: 常時アクティブ]
C -->|状態| E[State-driven: WHILE/During]
C -->|特徴の有無| F[Optional features: WHERE]
C -->|イベント| G{望ましい動作？}
G -->|はい| H[Event-driven: WHEN]
G -->|いいえ| I[Unwanted behaviours: IF-THEN]
実践的な適用方法：4ステップ
では、実際に要件をEARS形式に変換する手順を見ていきましょう。以下の4ステップで進めます。
ステップ1: 要件の分析
元の要件文を読み、以下の3要素に分解します。
- 事前条件：要件が発動するための前提
- トリガー：要件を発動させるイベント・状態
- システム応答：システムがとるべき動作
例：
原文: “It must be demonstrated that, when a Fault or Failure results in a change from one Control Mode to another, the change occurs so that the Engine does not exceed any of its operating limitations.” （故障または障害によって制御モードが変更された場合、その変更によりエンジンが動作制限を超えないようにする必要がある。）
この要件を分析します：
| 要素 |
内容 |
| トリガー |
制御モードが変更されたとき |
| システム応答 |
エンジンを承認された動作範囲内に維持する |
事前条件はありません。トリガーは「モード変更」というイベントです。
ステップ2: テンプレートの選択
分析した要素から、どのテンプレートが適切かを判断します。
| 判断基準 |
テンプレート |
| 条件もトリガーもない |
Ubiquitous |
| 「もし〜なら」という望ましくない事象 |
Unwanted behaviours |
| 特定の状態の間 |
State-driven |
| 機能の有無によって適用が変わる |
Optional features |
| イベントが発生したとき |
Event-driven |
今回の例では、「モード変更」というイベントがトリガーなので、Event-drivenが適切です。
ステップ3: 要件の変換
選択したテンプレートに従って、要件を記述します。
EARS形式：
When the Engine Control System changes operational mode, the Engine Control System shall maintain the engine within approved operational limits. （エンジン制御システムが動作モードを変更した場合、エンジン制御システムはエンジンを承認された動作範囲内に維持しなければならない。）
原文の冗長な表現が、簡潔で明確な要件に変換されました。
ステップ4: 検証
変換した要件が、以下の基準を満たしているか確認します。
- 明確か：解釈の余地がないか
- 検証可能か：テストで真偽を確認できるか
- 網羅的か：必要な条件がすべて記述されているか
- 簡潔か：不必要な単語がないか
今回の例では、「承認された動作範囲」という表現が残っていますね。これは不明確さの残例です。実際の要件定義では、具体的な数値や条件に置き換える必要があります。
補足：複雑な条件句の処理
複数の条件が組み合わさった要件の場合、キーワードを組み合わせて表現できます。
例：
While the aircraft is on-ground, when reverse thrust is commanded, the control system shall enable deployment of the thrust reverser. （航空機が地面上にある間、逆噴射が指示された場合、制御システムは推力逆転装置の展開を許可しなければならない。）
この要件では、While（状態）とWhen（イベント）を組み合わせて、特定の状態でのみ発動するイベント駆動要件を表現しています。
補足：Webサービス開発での応用
航空機エンジン制御以外の分野でも、EARSは応用できます。
Webサービスの例：
| テンプレート |
例 |
| Ubiquitous |
The system shall encrypt all user passwords.
（システムは全てのユーザーパスワードを暗号化しなければならない。） |
| Event-driven |
When a user submits a payment, the system shall generate a receipt.
（ユーザーが支払いを送信した場合、システムはレシートを生成しなければならない。） |
| Unwanted behaviours |
If the payment gateway is unavailable, then the system shall queue the payment for retry.
（決済ゲートウェイが利用できない場合、システムは支払いをキューに入れて再試行しなければならない。） |
| State-driven |
While the user is logged in, the system shall maintain a session timeout of 30 minutes.
（ユーザーがログインしている間、システムは30分のセッションタイムアウトを維持しなければならない。） |
| Optional features |
Where the premium subscription is active, the system shall provide unlimited storage.
（プレミアムサブスクリプションが有効な場合、システムは無制限のストレージを提供しなければならない。） |
航空機という特殊な分野だけでなく、Webサービス開発でも同じロジックが適用できることがお分かりいただけると思います。
EARSの利点と限界
EARSの利点
Rolls-Royceの研究チームによるケーススタディでは、EARSを適用した結果、以下の改善が確認されました。
完全に排除された問題：
- 複雑さ：複合的な文が単純化された
- 省略：望ましくない動作の処理が明確になった
- 重複：一貫した構文により重複が検出しやすくなった
- 不適切な実装：「何を」行うべきかが明確になった
- 検証不能性：明確な条件と応答により、検証が可能になった
削減された問題： - 曖昧さ：構造化により解釈の幅が狭まった - 不明確さ：事前条件とトリガーの明示により精度が向上 - 冗長性：平均単語数が36.9から25.6に削減（約30%減少）
EARSの限界
ただし、EARS万能というわけではありません。以下の限界を理解した上で適用する必要があります。
残留する問題：
- 語彙の曖昧さ：事前条件が推論で理解されていても、明示的に記録されていない場合
- 一般的な不明確さ：高レベルの要件には本質的に含まれる不明確さ
適用上の注意点：
- サンプルサイズの限界：研究では36件の要件のみを対象
- 高レベル要件向け：システム分解の上位レベルに最も適しており、低レベルの設計要件への適用可能性は未検証
- 望ましい状態の欠如：「望ましくない状態」でのシステムの振る舞いを定義するテンプレートは未検討
これらの限界を踏まえつつ、EARSは高レベルのステークホルダ要件に対して、単純な構造が効率的かつ実用的なアプローチであるという仮説を支持する証拠を提供しています。
まとめ
EARSは、要件定義に「型」をもたらす単純ながら強力な技法です。5つのテンプレートに要件を分類するだけで、以下の効果が得られます。
- 曖昧さ、複雑さ、省略などの問題が大幅に減少
- 要件の検証可能性が向上
- 訓練コストが最小限で導入可能
- 自然言語のまま適用できるため、翻訳エラーのリスクがない
あなた自身の現場でも、ぜひ一度試してみてください。要件定義の品質が、確実に向上するはずです。
参考文献
- Mavin, A., Wilkinson, P., Harwood, A., Novak, M. (2009). “EARS (Easy Approach to Requirements Syntax)”. 17th IEEE International Requirements Engineering Conference, pp. 317-322.
|