金融系システムで BDD が効く理由──Gherkin 構文で仕様とテストを一致させる開発手法

金融系システムの開発現場で BDD（Behavior-Driven Development：振る舞い駆動開発）が広く使われているのは事実です。金融システムは、次のような特徴を持つため BDD の仕組みがうまく噛み合います。

• 複雑な業務ルール
• 極めて高い品質要求
• 絶対に失敗できない決済処理

実際の現場では、BDD を単なるテスト手法としてではなく、**「ビジネスの要求を、そのまま自動テストのコードに直結させる仕組み」**として運用しています。本記事では、金融システムにおける BDD の具体的な使われ方を整理します。Gherkin 構文の書き方から現場の開発フロー、そして近年注目される AI エージェントとの相性まで扱います。

1. 最大の特徴：Gherkin 構文による「仕様の共通言語化」

金融開発における最大の敵は、**「ビジネス部門（銀行員・証券アナリストなど）と、開発エンジニアの間の認識のズレ」**です。これを解消するために、BDD では自然言語（日本語や英語）に近い Gherkin（ガーキン）構文で仕様を書きます。

Gherkin は主に次の 3 つのキーワードで構成されます。

• Given（前提） — テストを実行する前の状態
• When（もし〜のとき） — 発生させるアクション
• Then（ならば〜となる） — 期待される結果

金融システムでの具体例（口座振替の仕様）

フィーチャ: 口座振替による出金処理

  シナリオ: 残高が十分にある場合の正常な出金
    前提   ユーザーAの口座残高が 50,000円 である
    かつ   その口座は「アクティブ（有効）」である
    もし   ユーザーAが 30,000円 の出金をリクエストした
    ならば 出金処理が成功すること
    かつ   ユーザーAの口座残高が 20,000円 になっていること

  シナリオ: 残高不足によるエラー判定
    前提   ユーザーAの口座残高が 10,000円 である
    もし   ユーザーAが 30,000円 の出金をリクエストした
    ならば 出金処理が「残高不足エラー」で拒否されること
    かつ   ユーザーAの口座残高は 10,000円 のままであること

Gherkin は英語キーワード（Feature / Scenario / Given / When / Then / And）だけでなく、日本語を含む多言語のローカライズに対応しています。上記のように日本語で書けば、非エンジニアであるビジネス担当者が見ても「仕様が正しいか」を一目で確認できます。

2. 現場での実際の開発フロー（3 つのステップ）

現場では、Cucumber（Ruby / Java / JavaScript など）や SpecFlow（.NET 系。開発終了しており、後継の Reqnroll への移行が進んでいる）といった BDD フレームワークを使い、以下の流れで開発を進めます。

ステップ①：3 者（Three Amigos）による仕様定義

開発を始める前に、「ビジネス担当者（PO）」「開発者」「テスター（QA）」の 3 者が集まり、Gherkin 構文でシナリオを確定させます。この場で例外パターンや境界値（例：残高がちょうど 0 円のときはどうするか？）を徹底的に洗い出します。この 3 者会議は BDD の世界で Three Amigos と呼ばれます。

ステップ②：仕様書がそのまま「自動テストコード」に変身する

確定した Gherkin のテキストファイル（.feature ファイル）をテストツールに読み込ませると、各ステップ（前提・もし・ならば）に対応するテストコードの「枠組み（メソッド）」の雛形が自動生成されます。

開発者は、その枠組みの中に「実際にデータベースの数値を書き換える処理」や「API を叩く処理」といった裏側のロジックを実装します。この接着剤にあたるコードは Glue Code（グルーコード）、あるいは**ステップ定義（Step Definition）**と呼ばれます。

# Cucumber (Ruby) のステップ定義例
前提('ユーザーAの口座残高が {int}円 である') do |balance|
  @account = Account.create!(owner: 'A', balance: balance)
end

もし('ユーザーAが {int}円 の出金をリクエストした') do |amount|
  @result = @account.withdraw(amount)
end

ならば('ユーザーAの口座残高が {int}円 になっていること') do |expected|
  expect(@account.reload.balance).to eq(expected)
end

ステップ③：Red → Green と回帰テストの自動化

最初はプログラムが未実装なので、テストは当然「Red（失敗）」になります。ここが起点です。

その後、エンジニアが本番コードを実装し、テストが「Green（成功）」になれば開発完了です。このシナリオはそのまま「仕様書であり、同時にいつでも実行できる自動テスト（回帰テスト）」としてシステムに残り続けます。

3. なぜ金融システムで BDD が効果的なのか？

金融システムで BDD が重宝される理由は、主に次の 3 つです。

「動く仕様書」になり、ドキュメントの陳腐化を防げる

金融システムは長期間運用されるため、**「ドキュメントと実際のコードの乖離（ドリフト）」**が致命傷になります。BDD なら、コードを変更してもテストが通っている限り、仕様書（Gherkin ファイル）と実装が一致していることが継続的に検証されます。仕様書が「読むだけの資料」ではなく、CI で毎回実行される「動く仕様書（Living Documentation）」になるのが最大の価値です。

MkDocs で .feature をドキュメントとして公開する

この「動く仕様書」は、ドキュメントサイトジェネレーターの MkDocs と組み合わせると、ビジネス部門が読める Web ドキュメントとして公開できます。主に 2 系統のアプローチがあります。

• mkdocs-gherkin-plugin — 単に .feature を整形表示するだけでなく、Cucumber の実行結果（ndjson メッセージ）を Markdown に差し込むプラグイン。各シナリオが今 Pass / Fail のどちらなのかまでドキュメントに反映されるため、「この仕様は現在 Green です」と示せます。

  pip install mkdocs-gherkin-plugin

  # mkdocs.yml
  plugins:
    - gherkin

• gherkin2mkdocs — .feature を docs/ 配下の .md に変換し、CI で MkDocs サイトを生成するビルド型。テスト結果まではひも付けず、仕様の可読化に振り切ったシンプルな構成です。

• pymdownx.snippets（PyMdown Extensions） — 専用プラグインも変換ステップも要らない、最も軽量な方法。Material for MkDocs にバンドルされている拡張で、--8<-- 記法を使ってコードブロックに .feature の中身をそのまま差し込むだけです。ビルド時に元ファイルが読み込まれるため、仕様書の実体は常に 1 つの .feature に保てます。

  # mkdocs.yml
  markdown_extensions:
    - pymdownx.snippets
    - pymdownx.superfences

  <!-- docs 内の .md に記述。gherkin ハイライトで .feature を埋め込む -->
  ```gherkin
  --8<-- "features/account_withdrawal.feature"
  ```

「今この仕様が通っている証拠」を監査で求められる金融の文脈では mkdocs-gherkin-plugin、まず仕様を読める形で公開したいだけなら gherkin2mkdocs か pymdownx.snippets、という使い分けになります。いずれも仕様書・テスト・公開ドキュメントを 1 つの .feature に一本化できる点が本質です。

膨大な「計算パターン（マトリクス）」を網羅できる

金融では「金利」「手数料」「税金」など、条件の組み合わせが膨大になります。BDD ツールには Scenario Outline（シナリオアウトライン）という機能があり、「条件データの一覧表」を流し込むだけで、何十パターンものテストを 1 つのシナリオで一気に実行できます。

  シナリオアウトライン: 出金可否の判定マトリクス
    前提   口座残高が <残高> 円 である
    もし   <出金額> 円 の出金をリクエストした
    ならば 結果が <判定> となること

    例:
      | 残高   | 出金額 | 判定         |
      | 50000 | 30000 | 成功         |
      | 10000 | 30000 | 残高不足エラー |
      | 30000 | 30000 | 成功         |
      | 0     | 1     | 残高不足エラー |

境界値（残高ちょうど = 出金額のケースや、残高 0 円のケース）を表形式で並べられるため、金融特有の「網羅性の証明」が読みやすい形で残せます。

AI エージェントとの相性が良い

「Given / When / Then」という構造化されたテキストは、LLM（AI エージェント）が解釈しやすい形式です。AI に「この Gherkin の仕様を満たすプログラムを書いて」と指示したり、逆に「このコードから Gherkin の仕様書を起こして」と依頼したりする際の精度が上がります。

曖昧な自然文で AI に指示を出すと、解釈のブレやハルシネーション（もっともらしい嘘）、実装のドリフトが起きやすくなります。これを「前提・もし・ならば」の形式に落とし込むことで、入力と期待出力の境界を明示でき、AI の暴走を抑えやすくなります。

4. Gherkin 以外にも記法はある──それでも Gherkin が選ばれる理由

BDD／仕様記述の記法は Gherkin だけではありません。それでも金融をはじめ現場で Gherkin が事実上の標準になっているのは、「自由な自然言語」と「コード」という 2 つの極の“ちょうど中間”に位置しているからです。

主な代替記法と、それぞれの弱点

なぜ Gherkin なのか

• 「読めるが、実行できる」を両立する — 自由な自然文は誰でも読めるが曖昧で機械が解釈できず、コード（RSpec 等）は厳密だがビジネスが読めない。Gherkin は Given / When / Then という最小限のキーワード文法だけを課すことで両立させます。「前提・アクション・結果」という因果モデルは、人が振る舞いを説明するときの自然な構造そのものです。
• “ちょうどよい”制約がツール化を可能にする — 文法が緩すぎる Concordion ではステップ雛形の自動生成や再利用が難しくなります。Gherkin は構造が決まっているからこそ、.feature からのテスト骨格生成・パラメータ抽出・Scenario Outline の表展開が成立します。
• Ubiquitous Language（ドメイン駆動設計）との親和性 — 仕様書・会話・コードで同じ用語を使えるため、金融で最も怖い「認識のズレ」を減らせます。
• エコシステムと先行者利益 — Cucumber が多言語（Ruby/Java/JS/.NET…）で普及し、IDE 補完・CI 連携・多言語ローカライズ・膨大な事例が揃った結果、「標準だから選ばれる」正のループが回っています。FitNesse や Gauge が技術的に劣るわけではなく、ここで差がつきました。

要するに Gherkin の本質は、**「自由すぎず・厳密すぎない、ビジネスと開発とツールの三者が同時に扱える最小公倍数の文法」**である点にあります。

まとめ

実際の金融プロジェクトにおける BDD は、「テストの技法」というよりも、**「ビジネスの言葉（要件）を、途中で翻訳ミスすることなく、そのままコードとテストに落とし込むための共通言語システム」**として機能しています。

• Gherkin 構文でビジネスと開発の認識ズレをなくす
• 仕様書がそのまま自動テストになり、ドキュメントの陳腐化を防ぐ
• Scenario Outline で金融特有の膨大なパターンを網羅できる
• 構造化された仕様は AI エージェントとの相性が良い

昨今の AI 開発においても、AI に曖昧な指示を出すのではなく「Given / When / Then」の形式で要求を渡すことで、ハルシネーションやドリフトを最小限に抑えられます。BDD の価値は、AI 時代になって改めて見直されていると言えるでしょう。