EARS×Gherkin｜要件定義からデモ／シナリオテストまでを生成AIで一直線につなぐ

このワークフローが解決する問題

従来の業務システム開発には、次の構造的な分断がありました。

• ビジネスサイドが書く要件は、自然文で曖昧。何度も仕様確認のラリーが発生する
• エンジニアが書くテストコードは、ビジネスサイドが読めない。受入確認は別途口頭で行われ、再現性がない
• デモとテストと仕様書が別々のドキュメントとして存在し、すぐに乖離する

このワークフローでは、EARS と Gherkin を生成AIで橋渡しすることで、3つを1本の線につなぎます。

全体像

{{EARS_GHERKIN_WORKFLOW}}

この4ステップを順に見ていきます。

STEP 1: ビジネスサイドが要件を書く

業務知識を持つ人（プロダクトオーナー、業務担当者、企画）が、自分のスキルセット内で書ける形式で要件を整えます。技術用語は不要です。

1-A: ユーザーストーリーで Why を共有する

Story Builder で「誰が・何を・なぜ」の3要素を書き出します。

店舗マネージャーとして、商品の在庫が閾値を下回った段階で通知を受けたい。
なぜなら、発注リードタイム（3日）を確保するため、欠品の3日以上前に気づきたいから。

1-B: EARS で受入条件と異常系を書く

ユーザーストーリーだけでは「具体的にどう動くべきか」が決まらないので、EARS の5パターンで受入条件を分解します。

• ユビキタス：商品検索システムは、検索結果を1秒以内に表示する
• イベント駆動：ユーザーが検索ボタンをクリックしたとき、システムは結果を表示する
• 状態駆動：ユーザーがログインしている間、システムは検索履歴を保存する
• オプション：詳細検索が有効な場合、システムは絞り込みUIを表示する
• 望まない振る舞い：検索クエリが空の場合、システムはエラーメッセージを表示する

このステップのアウトプット

ストーリー1本＋EARS5〜10件のテキストファイル。Markdown でも Notion でも構いません。業務担当者が読んで意味が分かる粒度であることが必須です。

STEP 2: 生成AIで EARS を Gherkin に変換

整えた要件を、生成AIに次のようなプロンプトで投げます。

あなたはBDDエンジニアです。次のユーザーストーリーとEARS要件を、Gherkin（Feature／Scenario／Given／When／Then）に変換してください。

制約：
- 1 EARS = 1 Scenario を原則とする
- 状態駆動の前提は Given に置く
- ユビキタス要件は Background または各 Then に含める
- 異常系は独立した Scenario に分ける
- ステップは業務イベント単位で書き、UI操作の細部は書かない

要件：
（ここに STEP 1 のテキストを貼る）

これで Gherkin の下書きが数秒で得られます。EARS と Gherkin の対応関係を理解しているAIなら、EARS→Gherkin 変換ルールに従った下書きを返します。

このステップでエンジニアがやること

• AIが生成した Gherkin を読み、ビジネスサイドの意図と一致しているか確認する
• 過剰な抽象化や、技術的な前提の漏れを補う
• Background に括り出すべき共通前提を整理する
• Scenario Outline で表現できそうな箇所を表形式に変換する

AI は8割の下書きを作り、エンジニアは2割の補正だけに集中できます。

STEP 3: 同じ Gherkin からデモを作る

Gherkin が固まったら、エンジニアはステップ定義を実装します。BDDフレームワークを選びます：

• UI シナリオ：Playwright BDD（推奨）／Cypress Cucumber
• API シナリオ：Cucumber.js／pytest-bdd
• 業務ロジック：Behave（Python）／SpecFlow（.NET）

デモとして使う

Gherkin は実行すると、各ステップが画面に表示されながら自動でクリック・入力していく動画のような形になります。これをそのままステークホルダーに見せれば、「Scenario: 在庫切れ前通知」という業務シナリオが実際に動く様子を確認してもらえます。

従来のデモでは「ここにこういう機能があります」と説明する必要がありましたが、Gherkin デモは業務シナリオが画面で動いている様子そのものです。受入確認のラリー数が劇的に減ります。

STEP 4: 同じ Gherkin がそのままシナリオテストになる

デモを動かすために書いたステップ定義は、CIで毎回のプッシュ／PRに対して実行されます。

• 新しいPR を出すたびに全シナリオが回る
• 失敗すれば「Scenario: 在庫切れ前通知 で Then の通知メール送信が失敗した」と業務的な単位で原因が報告される
• 新機能追加で既存シナリオが壊れたら即座に検知できる

仕様書としての副次効果

Gherkin ファイル自体が、常に最新の・実装と乖離しない仕様書になります。新しく入ったメンバーは Gherkin を読めば、業務上どういうシナリオがサポートされているかを正確に理解できます。Excel仕様書のように陳腐化しません。

このワークフローが効く理由

1. 各役割が得意な層で作業する

2. 中間成果物が壊れない

EARS と Gherkin はどちらも構文が決まっているので、どこかが変わっても他に伝える形式が固定されています。「曖昧な日本語の要件をどう解釈するか」という不毛な議論が消えます。

3. デモとテストが同じファイルから生まれる

「デモ用に作ったコードはテストになっていない」「テストはあるがデモができない」という従来の問題が消えます。1つの Gherkin が両方を兼ねます。

4. 異常系を漏らさない

EARS の「望まない振る舞い」パターンと Gherkin の Scenario が1対1で対応するため、ビジネスサイドが書いた異常系シナリオは必ずテストに反映されます。異常系の検討を業務サイドの責任にできるのがこのワークフローの大きな利点です。

導入にあたっての注意点

注意1: AIの出力を鵜呑みにしない

生成AIは「Gherkin らしい形」のテキストを出すのは得意ですが、業務知識は持っていません。エンジニアとビジネスサイドの両方が出力をレビューする工程は必須です。

注意2: ステップの再利用性を意識する

「Given ユーザーがログインしている」のような共通ステップは、最初から Background や共通定義に切り出して、Feature をまたいで使い回せるようにします。プロジェクト初期にステップ定義の命名規約を決めておくと、後々のメンテコストが大きく下がります。

注意3: 全テストを Gherkin にしない

純粋な計算ロジックや、データ変換のテストは、ユニットテストの方が早く書けます。Gherkin は業務シナリオの検証に集中させ、ピラミッド型のテスト戦略の最上層として位置付けます。

注意4: シナリオが多すぎると CI が重くなる

UIシナリオは1件あたり数秒〜数十秒かかります。100件を超えてきたら、並列実行・タグでの絞り込み・スモークテストとフルテストの分離など、実行戦略を考えます。

このワークフローを Beekle で導入するには

Beekleでは、ゼロスタート（初期費用0円）で次の支援が可能です。

• Story Builder でのユーザーストーリー整備
• EARS テンプレートに沿った要件定義の伴走
• 生成AIプロンプトのカスタマイズ（社内用語・業界用語への対応）
• Playwright BDD によるシナリオテスト基盤の構築
• CI/CD 統合と運用体制の整備

まとめ

EARS×Gherkin ワークフローは、要件定義の質と開発速度を同時に上げる、現代の業務システム開発のベストプラクティスです。

• STEP 1：ビジネスサイドが EARS で要件を曖昧さなく言語化する
• STEP 2：生成AIが Gherkin に機械的変換する
• STEP 3：エンジニアがステップ定義を実装し、デモとして見せる
• STEP 4：同じ Gherkin が CI のシナリオテストとして残り続ける

「要件と実装の乖離」「デモとテストの二重実装」「異常系の検討漏れ」が同時に解消されます。長期運用が前提の業務システムで特に効果を発揮します。

関連記事 / 関連ツール

• EARS（要件記述構文）入門
• Gherkin入門｜Given/When/Then の書き方
• ユーザーストーリーの書き方完全ガイド
• スコープ管理（FM法）の使い方
• Story Builder（無料ツール）
• Scope Manager（無料ツール）

このワークフローを試してみたい方へ

無料相談を予約する / ゼロスタートを詳しく見る