EARS（簡易要件構文法）を理解し、AIへの要件提示をより効果的にする方法を学ぶ

著者: MakerNeo
最終更新: 2026-04-05 14:54:59
タグ:

Index

ソフトウェア開発やシステムエンジニアリングにおいて、要件の品質はプロジェクトの成功に直接影響します。あいまいまたは不明確な要件は、開発プロセスでのエラー、コスト増加、プロジェクト遅延を引き起こす可能性があります。EARS（Easy Approach to Requirements Syntax、簡易要件構文法）は、規範化された自然言語表現を通じて要件記述を改善するための軽量かつ構造化された手法です。これは、2009年にAlistair Mavinとロールス・ロイスPLCチームによって航空エンジン制御システムの耐空性規制の分析のために開発され、IEEE RE09会議で初めて発表されました。その後、EARSは大規模な組織や学術機関で広く採用されています。

EARSの定義と核心理念

EARSの核心は、自然言語の親しみやすさを活用しつつ、「いつ」「もし」「ならば」などの特定のキーワードや文型を使用して要件表現を制約することで、あいまいさや不整合を減らすことにあります。特別なツールは不要で、トレーニングコストも低く、通常半日以下で習得可能です。初心者から経験豊富なエンジニアまで適しており、特に複雑なシステム要件を扱う際に優れた効果を発揮します。研究によれば、EARSは自然言語要件におけるあいまいさ、冗長性、論理的不完全さなどのエラーを効果的に削減します。標準化された構造を提供することで、異なる作成者による要件の一貫性を保ち、ステークホルダーが理解しやすく、レビューしやすいものにします。

開発背景

EARSの開発は、ロールス・ロイスPLCが航空エンジン制御システムの耐空性規制を分析する際の実際のニーズに由来します。Alistair Mavinとそのチームは、これらの規制における要件が類似のパターンを持ち、潜在的なあいまいさや複雑さを伴うことを発見しました。要件を抽出・簡素化することでEARSのフレームワークを構築し、2009年のIEEE RE09国際要件工学会議で発表しました。その後、Bosch、Daimler、Dyson、Honeywell、Intel、NASA、ロールス・ロイス、Siemensなど、グローバルな多くの組織で採用されています。また、中国、フランス、ドイツ、スウェーデン、英国、米国の大学でも教育内容に取り入れられており、学術および産業界での高い受容性を示しています。

EARSの利点

EARSは、実践で検証された以下の10の主要な利点を提供します：

  1. 自然言語要件のエラーを削減または排除。
  2. 要件をシンプル、一貫性、理解しやすく、スタイルの偏りを排除。
  3. トレーニング時間が短い（半日以下）、テストケースと整合し、レビューが容易。
  4. 初心者と専門家の両方がより良い初稿を作成し、繰り返しを削減。
  5. アクティビティ図や状態図などのモデルを補完し、要件の可視化を強化。
  6. 個人およびチームのコミュニケーションを向上させ、プロジェクトリスクを軽減し、チームの流動性を向上。
  7. 経験豊富なエンジニアに適し、明確なフレームワークを提供。
  8. 複雑な要件を体系的に処理し、より明確で実装可能に。
  9. 学習曲線が低く、新規ユーザーが迅速に改善。
  10. Bosch、Daimler、Dyson、Honeywell、Intel、NASA、ロールス・ロイス、Siemensなどの大規模組織で検証済み。

従来の制約のない自然言語要件と比較して、EARSは開発プロセスの変動性とリスクを大幅に低減し、要件の不明確さによる手戻りやコスト増加を削減します。例えば、制約のない自然言語要件は誤った解釈や実装の偏りを引き起こす可能性がありますが、EARSは「…のとき、システムは…すべき」といった構造化された文型を通じて、要件のテスト可能性と明確性を確保します。

EARSの構文とパターン

EARSは以下のような汎用的な構文構造を提供します：

  • 汎用構造：「<オプションの前提条件> の場合、<オプションのトリガー条件> のとき、<システム名> は <システム応答> しなければならない。」
  • ルール：
    • 0個以上の前提条件
    • 0または1つのトリガー条件
    • 1つのシステム名
    • 1つ以上のシステム応答

これに基づき、EARSは以下の6つの主要なパターンを定義します：

タイプ テンプレート 例
汎用パターン (Ubiquitous) xxx は xxx すべきである 携帯電話の重量は XX グラム未満であるべきである
状態駆動パターン xxx の場合、xxx は xxx すべきである 飛行機が飛行中でエンジンが稼働している場合、制御システムはエンジンの燃料流量を xx ポンド/秒以上に維持すべきである
イベント駆動パターン xxx のとき、xxx は xxx すべきである 飛行機が連続点火指令を発したとき、制御システムは連続点火を開始すべきである
オプション機能パターン xxx の条件下で、xxx は xxx すべきである 制御システムに過速度保護機能がある場合、飛行機の離陸前に、制御システムは過速度保護機能の有効性をテストすべきである
望ましくない動作パターン もし xxx ならば、xxx は xxx すべきである 計算空速が利用できない場合、制御システムはモデル空速を使用すべきである
複雑パターン （期待される動作）…の場合、…のとき…、…のとき…すべき
（異常動作）…の場合、…のとき…、もし…すべき		 飛行機が地上にある場合、逆推力指令を受け取ったとき、制御システムは逆推力装置を起動すべきである

これらのパターンは、単純な機能記述から複雑な条件ロジックまで、要件工学のさまざまなシナリオをカバーし、EARSを通じて効果的に表現できます。例えば、「飛行機が連続点火指令を発したとき、制御システムは連続点火を開始すべきである」は典型的なイベント駆動要件であり、「制御システムに過速度保護機能がある場合、飛行機の離陸前に、制御システムは過速度保護機能の有効性をテストすべきである」はオプション機能パターンの有用性を示します。

実際の応用と事例

EARSは航空、自動車、ソフトウェア開発などの分野で広く適用されています。例えば、ロールス・ロイスは航空エンジン制御システムの要件分析にEARSを使用し、耐空性規制の明確性と実装可能性を確保しました。BoschやSiemensなどの組織も、EARSを採用して要件工学プロセスを改善し、プロジェクトリスクを軽減しています。

具体例として、要件の明確化があります。あいまいな要件「システムはネットワーク接続を切断すべきである」は、EARSを用いて「切断ボタンが押されたとき、ソフトウェアはネットワーク接続を切断すべきである」と改善され、トリガー条件とシステム応答を明確にします。この改善は、要件のテスト可能性を高め、開発プロセスでの誤解を減らします。

また、EARSはテストケースとも密接に関連します。例えば、「飛行機が連続点火指令を発したとき、制御システムは連続点火を開始すべきである」は、特定の条件下でのシステムの正しい応答を保証するテストシナリオに直接変換できます。

例1：ユーザー認証機能

-Advisor: - 従来の記述：

「システムはユーザーのログインを便利にし、エラー時に通知を表示すべきである。」

  • EARSによる改善： ユーザーが ユーザー名とパスワードを入力し、「ログイン」ボタンをクリックしたとき、システムは データベースと一致するかを検証しなければならない。もし 検証に失敗した場合、システムは 「ユーザー名またはパスワードが間違っています」という通知を表示しなければならない。

EARSタイプ：イベント駆動型（トリガー動作）＋条件型（エラー処理）。

例2：データ保存機能

  • 従来の記述：

    「ユーザーが内容を編集した後、システムは自動的に保存するのが望ましい。」

  • EARSによる改善：

    ユーザーが 編集ボックスでの入力を5秒以上停止したとき、システムは 現在の内容を下書きボックスに自動保存しなければならない。

EARSタイプ：イベント駆動型（時間トリガー）。

例3：権限管理

  • 従来の記述：

    「管理者はユーザーの投稿を削除できるが、通常のユーザーはできない。」

  • EARSによる改善：

    ユーザーが 投稿の削除を試みたとき、システムは その役割が「管理者」かどうかを確認しなければならない。もし 役割が管理者でない場合、システムは 「権限不足」の通知を表示し、削除操作を阻止しなければならない。

EARSタイプ：条件型（権限確認）＋イベント駆動型（ユーザー動作）。

例4：システム性能制約

  • 従来の記述：

    「ページの読み込みが遅すぎてはいけない。」

  • EARSによる改善：

    システムは ユーザーがリクエストを開始してから2秒以内にページ内容を返さなければならない（ネットワーク遅延を除く）。

EARSタイプ：制約型（明確な定量指標）。

EARSの核心的な改善点のまとめ

  1. あいまいな言葉の排除：
    • 従来：「望ましい」「便利に」→ EARS：「すべき」「しなければならない」。
  2. トリガー条件の明確化：
    • 従来：トリガーのタイミングを省略 → EARS：「…のとき」「もし…」。
  3. 複合要件の分割：
    • 従来：1文で複数の要件を混在 → EARS：検証＋通知など複数に分割。
  4. 非機能要件の定量化：
    • 従来：「遅すぎない」→ EARS：「2秒以内」。

これでかなり明確になったのではないでしょうか。AI時代において、AIと要件をやり取りする際にはEARSを採用するのが最適です。これにより、AIは私たちの要件を明確に理解できます。同じ先進的なモデルを使用する場合でも、EARSを使うことで他の人より大きくリードできます。

他の要件記述方法

EARS（簡易要件構文法）以外にも、要件の明確さ、テスト可能性、追跡可能性を高めるための構造化された要件記述方法がいくつか存在します。以下に、代表的な方法とその特徴を紹介します。

1. ユーザーストーリー（User Stories）

適用シーン：アジャイル開発、製品要件記述 形式：

として [役割]、私は [機能]を望む、その理由は [価値/目的]。

例：

従来の記述：「ユーザーはパスワードをリセットできるべきである。」 ユーザーストーリーによる改善： 「パスワードを忘れたユーザーとして、メールでパスワードをリセットしたい、その理由はアカウントに再びアクセスできるようにするため。」

利点：

  • ユーザー視点と価値を強調し、技術的詳細の過度な記述を回避。
  • アジャイル開発での要件分割や優先順位付けに適している。

欠点：

  • 厳密な構文制約がなく、あいまいさが残る可能性がある。
  • 詳細を明確にするために受け入れ基準（Acceptance Criteria）の補足が必要。

2. ユースケース（Use Cases）

適用シーン：システムの対話プロセス記述 形式：

  • アクター（Actor）：誰が操作を行うか？
  • 主要フロー（Main Flow）：正常な場合のステップ。
  • 代替フロー（Alternative Flow）：異常または分岐状況。

例：

従来の記述：「ユーザーがシステムにログインする。」 ユースケースによる改善： ユースケース名：ユーザー認証 アクター：登録ユーザー 主要フロー：

  1. ユーザーがユーザー名とパスワードを入力。
  2. システムが認証情報を検証。
  3. システムがホームページを表示。 代替フロー：
    • A1: 検証失敗 → システムが「ユーザー名またはパスワードが間違っています」と通知。

利点：

  • 複雑な対話プロセスを記述するのに適している。
  • 構造化が強く、開発者がビジネスロジックを理解しやすい。

欠点：

  • 記述に時間がかかり、単純な要件には不向き。
  • 詳細すぎると要件ドキュメントが膨大になる可能性。

3. Gherkin構文（BDD：ビヘイビア駆動開発）

適用シーン：自動化テスト、受け入れテスト駆動開発（ATDD） 形式：

Given [初期条件]、 When [トリガーイベント]、 Then [期待される結果]。

例：

従来の記述：「ショッピングカートは合計金額を計算できるべきである。」 Gherkinによる改善：

シナリオ：ショッピングカートの合計金額計算
  Given ユーザーが3つの商品をカートに追加した
  When ユーザーが「決済」ボタンをクリックしたとき
  Then システムは正しい合計金額（税込）を表示すべきである

利点：

  • 自動化テストコード（例：Cucumber）に直接マッピング可能。
  • ビジネス担当者と技術者が共同で記述でき、コミュニケーションの誤差を軽減。

欠点：

  • テスト可能な要件にのみ適用可能で、制約やアーキテクチャ要件には不向き。

4. 要件パターン（Requirement Patterns）

適用シーン：複雑なシステム要件（例：セキュリティ、性能要件） 形式：業界のベストプラクティスに基づく標準テンプレート。

例（セキュリティ要件パターン）：

従来の記述：「システムは不正アクセスを防止すべきである。」 パターンによる改善： 「システムはすべての機密APIエンドポイントにJWTベースの認証を実装し、有効なトークンが提供されないリクエストにはHTTP 403を返すべきである。」

利点：

  • 業界標準の表現方法を提供し、あいまいさを軽減。
  • コンプライアンス要件（例：GDPR、ISO 27001）に適している。

欠点：

  • チームが関連パターンに精通している必要があり、学習コストが高い。

5. デシジョンテーブル（Decision Tables）

適用シーン：複雑なビジネスルール（例：価格設定、リスク管理ロジック） 形式：異なる条件下でのシステム動作を表形式で記述。

例（Eコマース割引ルール）： ユーザー種別 注文金額 プロモーション 割引率
新規ユーザー ≥100元 なし 5%
既存ユーザー ≥200元 ダブル11 15%

利点：

  • 複数の条件の組み合わせロジックを直観的に表示。
  • テストケースの設計が容易。

欠点：

  • ルールが明確で条件が限定的な場合にのみ適用可能。

適切な方法の選び方

方法 適用シーン 核心的な利点
EARS 機能要件（ソフトウェア/ハードウェア） 構文がシンプルでテスト可能性が高い
ユーザーストーリー アジャイル開発、製品要件 ユーザーの価値を強調
ユースケース 複雑な対話プロセス（例：銀行システム） 構造化が明確
Gherkin 自動化テスト要件 テストコードに直接生成可能
要件パターン コンプライアンス、セキュリティ要件 標準化され、あいまいさが少ない
デシジョンテーブル 複数条件のビジネスルール ロジックの組み合わせを直観的に表示

「システムはXの条件下でYをするべき」という要件ならEARSが最適、「ユーザーが何を望むか」ならユーザーストーリー、「この機能をどうテストするか」ならGherkinが適しています。

推奨組み合わせ：

  • ユーザーストーリーでマクロ要件を記述し、EARSまたはGherkinでルールを詳細化。
  • デシジョンテーブルで複雑なビジネスロジックを処理し、ユースケースで対話プロセスを記述。

これらの方法を活用することで、より明確で実行可能な要件を効率的に記述できることを願っています！ 🚀