BDDを整える。

＝ Given/When/Thenを、業務の言葉からGherkin書式に整形

BDDが初めての方は、先にそもそも BDD とは・どんな場面で使うかをどうぞ。

① 整形機と型チェック

前提・操作・結果を1行ずつ入れると、右側にGherkin書式のシナリオと、良いシナリオの型チェック結果がリアルタイムに表示されます。「＋ And行を追加」で条件や確認したい結果を増やせます。

Feature / Scenario（任意）空欄でも整形できます

Feature（機能名） Scenario（シナリオ名）

前提（Given）シナリオが始まる前の状態

操作（When）利用者や外部から起きること

結果（Then）確認したい状態

キーワード表記

日本語（前提/もし/ならば）英語（Given/When/Then）

Gherkin 記法

—

② 良いシナリオの型チェック

見ているのは①Whenが複数でないか（1シナリオ1振る舞い）②Thenに数字・状態語などの検証可能な結果があるか③クリック・SQLなど実装寄りの言葉が混ざっていないか、の3点です。断定はせず、目安としての注意表示です。

🔒 入力した文章はこの端末の中だけで整形・チェックされ、外部には送信されません（送信ゼロ）。

そもそも BDD とは

「どう振る舞うか」を、業務の言葉で先に合意する。

BDD は Behavior-Driven Development（振る舞い駆動開発） の略です。作るものを「前提・操作・結果」の形で書き、開発者だけでなく企画や営業、利用者も同じ言葉で読める状態にしてから作り始めます。Dan North が提唱したとされ、書き方の約束が Gherkin（Given / When / Then）です。

身近なたとえでは、料理の注文を「この具材で、この火加減で、こう仕上げてほしい」とお店と客が同じ言葉で確認するようなものです。近い言葉の TDD は、コードの単位で先にテストを書くリズムに主眼があります。BDD はその手前で、何を実現したいかを業務の言葉でそろえることに主眼があります。

どこで・どんな場面で使うか

要件定義・受入条件を決める打合せ

「この画面でこう操作したら、こうなる」を、顧客と開発者が同じ文で確認します。
受入テストの手順書づくり

業務側の担当者が読める文で書いておくと、受入テストの観点が抜けにくくなります。
アジャイル開発の受入条件

ユーザーストーリーごとに、完成とみなす条件をシナリオとして書く使い方があります。
SES・受託での顧客との仕様合意

仕様書の文章があいまいなときに、具体的な例で認識のずれを早めに見つけられます。
ITパスポート・基本情報・応用情報・プロジェクトマネージャ

テストや開発手法の用語として、TDD や受入テストと並んで出てくることがあります。

知らないと何が困るか

認識のずれが完成後に見つかる。「思っていたのと違う」は、文章ではなく具体的な例で確認していないと起きやすくなります。
TDD との違いがあいまいなまま話が進む。コードの単位のテストなのか、業務の振る舞いの合意なのかを区別できると、会話が噛み合います。
業務の人が読めない仕様になる。実装寄りの言葉だけで書くと、確認してほしい人が確認できなくなります。

上の整形機で、前提・操作・結果を業務の言葉で入れて、シナリオの形になる様子を試してみてください。

BDDとは

「振る舞い」を、業務の言葉で合意してから作る。

BDD（振る舞い駆動開発, Behavior-Driven Development）は、ソフトウェアがどう振る舞うべきかを、開発者だけでなく企画・営業・利用者を含めた関係者が同じ言葉で合意してから作っていく考え方です。提唱者としてDan Northの名前が知られています。前提（Given）・操作（When）・結果（Then）という形でシナリオを書くと、専門知識がなくても読める「実行可能な仕様」になり、Cucumberのような一般的なツールを使えば、そのシナリオをテストとして実行することもできる、とされます。

TDDとの関係

BDDとTDD（テスト駆動開発）は対立するものではなく、TDDの外側で「振る舞い」を扱うものとして説明されることが多いとされます。TDDはコードの単位（関数・クラス）に対して「先にテストを書く」リズムに主眼を置くのに対し、BDDはその手前で「そもそも何を実現したいか」を業務の言葉で合意することに主眼を置く、という整理がよく見られます。両者の境界の引き方は流派や現場によって異なる部分もあり、ここでの説明も一般的な整理の一つです。

Given/When/Thenの意味

前提（Given） — シナリオが始まる前の状態。
操作（When） — 利用者や外部から起きる操作・イベント。
結果（Then） — その結果として確認したい状態。

⚠️ 本ページの分類・説明は一般的な整理の一例です。用語の使い方や境界の引き方は書籍・現場により異なる場合があります。

💡 BDD・DDD・MSA・TDDは、どれか1つを選ぶものではありません。同じプロダクトの開発で同時に使われる考え方です（例: DDDでドメインを整理し、その振る舞いをBDDのシナリオで合意し、TDDでコードに落とし込み、必要ならMSAで分割の単位を検討する、といった具合）。開発プロセス全体の流れは「開発プロセスを整える」、工程の呼び方は「開発工程を整える」もあわせてどうぞ。

このツールについて

前提（Given）・操作（When）・結果（Then）を業務の言葉で入れると、Gherkin書式のシナリオに整形します。1シナリオ1振る舞いか、結果は検証できるか、実装寄りの言葉が混ざっていないかを機械的にチェック。英語キーワード（Given/When/Then）と日本語キーワード（前提/もし/ならば）を切り替えられます。送信ゼロ。

前提（Given）・操作（When）・結果（Then）を入れると、Gherkin書式（英語⇔日本語キーワード「前提/もし/ならば」切替）に整形。Whenが複数でないか・Thenに検証可能な結果があるか・実装語の混入がないかを機械的にチェックし、断定せず注意表示。

主な機能

Given/When/ThenをGherkin書式に整形（英語／日本語キーワード切替）
「＋ And行を追加」で複数条件・複数確認結果に対応（最大5行）
良いシナリオの型チェック：1シナリオ1振る舞い・検証可能な結果・実装語混入を機械検出
Feature/Scenario名の入力・ワンクリックコピー
BDDの提唱者Dan North・TDDとの関係（通説）・実行可能仕様の解説
送信ゼロ・ブラウザ内完結（保存もしない）

💻 エンジニア 📚 資格の勉強

よくある質問

Q. BDDとは何ですか？

A. BDD（振る舞い駆動開発）は、ソフトウェアがどう振る舞うべきかを、開発者だけでなく企画・営業・利用者を含めた関係者が同じ言葉で合意してから作っていく考え方です。提唱者としてDan Northの名前が知られています。前提（Given）・操作（When）・結果（Then）という形で書くシナリオが、合意のための共通言語になります。

Q. Gherkinとは何ですか？

A. Given/When/Thenのようなキーワードを使ってシナリオを書くための決まった書式です。英語キーワードのほか日本語キーワード（前提/もし/ならば）にも対応しており、Cucumberのような一般的なツールに読み込ませると、そのままテストとして実行できる「実行可能な仕様」になります。

Q. BDDとTDDはどう違いますか？

A. 対立するものではなく、TDDの外側で「振る舞い」を扱うものとして説明されることが多いとされます。TDDはコードの単位に対して先にテストを書くリズムに主眼を置き、BDDはその手前で「そもそも何を実現したいか」を業務の言葉で合意することに主眼を置く、という整理がよく見られます。境界の引き方は流派や現場により異なります。

Q. 「良いシナリオの型チェック」は何を見ていますか？

A. ①Whenが複数でないか（1シナリオ1振る舞いか）②Thenに数字や状態語など検証可能な結果があるか③クリック・SQLなど実装寄りの言葉が混ざっていないか、の3点を機械的に見ています。断定はせず注意表示にとどめています。

Q. 入力した文章はどこかに送信されますか？

A. いいえ。整形もチェックもすべてこの端末（ブラウザ）の中だけで行われ、サーバーへは一切送信されません。保存もされないので、タブを閉じると入力内容は消えます。

入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。