振る舞い駆動開発（BDD）とは？TDDとの違いからGherkin記法の活用まで徹底解説

振る舞い駆動開発（BDD: Behavior-Driven Development）とは、ソフトウェア開発手法の一つです。テスト駆動開発（TDD: Test-Driven Development ）から派生したアプローチで、ソフトウェアの「振る舞い」に焦点を当てて開発を進めます。

BDDの概要としては以下のようになります。

 BDDの最大の特徴は、開発者、QAエンジニア、プロダクトオーナー（PO）など、プロジェクトに関わる関係者(ステークホルダー)全員が協力して仕様を決めていくことにあります。

その際、全員が理解できる「共通言語」を用いて対話することで、ユーザーにとって真に価値のある機能を具体化していきます。

つまりBDDは、単にテストを自動化する技術ではなく、チームのコミュニケーションを円滑にし、ビジネスの成功を目指すための開発文化へと導く手法と言えるでしょう。

BDDを理解する上で、多くのエンジニアが疑問に思うのが「TDDと何が違うのか？」ということです。どちらも「テスト（もしくは期待される動作）を事前に定義する」という点では共通していますが、その目的や視点は大きく異なります。

目的と視点の違い

TDDとBDDの最も大きな違いは、何をもって「正しい」とするかの視点にあります。TDDは、主に開発者の視点から「コードが仕様書通りに正しく実装されているか」を検証します。そのため、テストは個々の機能（ユニット）が設計仕様に基づいて正しく動作することを保証する役割を持ちます。

一方、BDDはユーザーやビジネスの視点に立ち、「システムが期待通りに正しく振る舞うか」を検証します。この「振る舞い」が、すなわちビジネス上の価値となります。

TDDは、実装の詳細（How）をテストするには非常に有効ですが、その機能が本当にユーザーの課題を解決するのか、ビジネス上の価値（What, Why）につながるのか、ということまでは保証できません。

開発者以外のステークホルダー、例えばプロダクトマネージャーやビジネスアナリスト、顧客との間に依然として仕様に対する「認識の壁」が存在するならば、これが手戻りやコミュニケーションコストの増大につながっていくのです。

以下の表は、TDDとBDDの目的と視点の違いをまとめたものです。

 このように視点を変えることにより「コードの正しさ」と「ビジネスやユーザーにとっての価値」との間のギャップを埋めるアプローチとして、BDDが注目されており、アジャイル開発におけるコミュニケーション課題を解決する手法としても期待されています。

コミュニケーションとドキュメントの違い

TDDとBDDでは、テストが果たすドキュメントの役割も異なります。

TDDで書かれるテストコードは、実行可能な設計仕様として利用できますが、その内容はプログラミング言語で記述されるため、実装スキルを持っていなければ正確に読み解けません。

それに対して、BDDでは後述するGherkin（ガーキン）という自然言語に近い記法でシナリオを記述します。

このシナリオは、容易に理解できるため、チーム全員の共通理解を促す「生きた仕様書」として利用できます。

仕様が変更されればシナリオも更新され、テストも追随するため、ドキュメントが陳腐化することはありません。

この「生きた仕様書」が、開発者とQAやビジネス担当、PO、顧客といったビジネス側のステークホルダーとの認識の齟齬を埋め、コミュニケーションの円滑化に効果を発揮します。

以下の表は、TDDとBDDのドキュメントとしての違いをまとめたものです。

BDDとATDDとの関係性は？

BDDと比較される開発手法としてATDD（ Acceptance Test-Driven Development: 受け入れテスト駆動開発）も挙げられます。ATDDは、顧客が定義した「受け入れ基準」をテストとして記述し、開発を進める手法です。

BDDはATDDの考え方を包含しつつ、「対話のプロセス」や「共通言語の利用」をより重視することで、コミュニケーションの側面を強化したアプローチと位置付けられます。

ATDDについて以下の表にまとめました。

BDDにおける対話と共通理解を具体的に形にするのが、Gherkinという記法です。Gherkinは、誰でも読み書きしやすいように設計され構造化された自然言語による準形式的な記法です。

Gherkinは、プログラミングの知識がなくてもシステムの振る舞いをシナリオとして記述できるため、チームの「共通言語」として利用できます。

ここでは、Gherkinの基本的な記述ルールを紹介します。

Gherkinの基本構文と例文（Given-When-Then）

Gherkinのシナリオは、幾つかのキーワードを使って構成されます。最も基本的な構造が Given-When-Then です。

これらのキーワードを使うことで、システムの振る舞いを明確に、かつ構造的に表現できます。以下にログイン機能の例を示します。 

Feature: ログイン機能
  ユーザーがIDとパスワードでシステムにアクセスできるようにする
 
  Scenario: ユーザーが正しいIDとパスワードでログインできる
    Given ログインページが表示されている
    When  正しいIDとパスワードを入力してログインボタンを押す
    Then  ホームページにリダイレクトされる

  Scenario Outline: 間違った情報ではログインできない
    Given ログインページが表示されている
    When  <ID> と <パスワード> を入力してログインボタンを押す
    Then  エラーメッセージが表示される

    Examples: 
      | ID         | パスワード  |
      | "user_a"   | "wrong_pass"  |
      | "wrong_id" | "password123" |

Scenario Outline と Examples を使うと、複数の異なるデータで同じシナリオを効率的にテストできます。これにより、正常系だけでなく、さまざまな異常系のパターンも網羅的に検証することが容易になります。

BDDの導入は、一度に全てを変えようとせず、小さく始めることが成功の鍵です。いきなり導入するのではなく、まずはチームの「対話」の文化を育むことから始めましょう。ここでは、BDDをスムーズに導入し、チームの文化として定着させるための実践的な4つのステップを紹介します。

Step1. 「3つのアミーゴ」を組織する

BDD実践の第一歩として最も推奨されるのが「3つのアミーゴ（Three Amigos）」と呼ばれるミーティングです。これは、特定のユーザーストーリーや機能について、以下の3つの異なる視点を持つ代表者が集まり、深く議論する場を指します。

 この「3つのアミーゴ」を組織することがBDD実践で最も重要となります。 

Step2. 最初の振る舞いを記述して小さく始める

まず初めに、プロジェクトの中から最もシンプルで理解しやすい1つのユーザーストーリーや機能を選びます。この選定された機能の「振る舞い」を、「3つのアミーゴ」で議論し、Gherkin記法を用いて記述します。この段階では対話による仕様の具体化に集中します。

この「3つのアミーゴ」ミーティングでは、抽象的な要求にとどまらず、具体的なユーザーシナリオやシステムの振る舞いについて徹底的に対話します。例えば、「ECサイトのログイン」という機能であれば、「ユーザーが正しいIDとパスワードを入力したらどうなるか」「間違ったIDを入力したらどうなるか」といった具体的な振る舞いを洗い出していきます。

この対話を通じて、それぞれの立場からの疑問や懸念を解消し、全員が納得する共通の理解を築き上げます。この共通理解こそが、後の「生きた仕様」の土台となるのです。 

Step3. 対話を重視しシナリオを洗練させる

Step2で記述したGherkinシナリオが、本当にビジネス要求を満たしているか、「なぜ」「どのように」といった疑問に明確に答えられているかを、全員で繰り返し問いかけます。疑問が解消され、全員が「この振る舞いで問題ない」と納得するまでシナリオを洗練させます。必要であれば、POが顧客への確認も行います。

このStepで認識の齟齬を徹底的になくし、関係者全員の共通理解を強固に形成することで後工程での手戻りを最小限に抑え、「生きた仕様」の品質を最大限に高めます。

Step4. 振り返りを実施しプロセスを改善する

最初のBDD実践を終えた後、チームでプロセス全体の振り返りを実施し、「3つのアミーゴ」のミーティングの進め方、Gherkinシナリオ記述の仕方、開発サイクルへの組み込み方など、改善できる点を見つけ出します。レトロスペクティブ（振り返り）の機会を設け、次の開発サイクルでの改善へつなげます。

この記事では、BDDの基本的な考え方から、TDDとの違い、そしてGherkin記法を使った実践方法までを解説しました。

BDDは、単なるテスト技法ではありません。

それは、開発の目的を「仕様通りに正しく作る（Doing things right）」ことから、「ユーザーにとって価値のある正しいものを作る（Doing the right thing）」ことへとシフトさせるための、強力な開発アプローチです。

もし現在の開発プロセスに課題を感じているなら、まずは「3つのアミーゴ」で集まり、1つの機能について対話することから始めてみてはいかがでしょうか。 

その小さな一歩が、チームを大きく変えるきっかけになるはずです。