非エンジニアがBDD（振る舞い駆動開発）を学んで気づいた技術とビジネスの「行間」の埋め方

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の124週目の記事です！
3年間連続達成まで残り35週となりました！

はじめに

ログラスでテクニカルサポートを担当している田中です。

ログラスのテクニカルサポートは、エンジニアやデザイナー、プロダクトマネージャーと密に連携しながら、日々の顧客サポートや品質向上に取り組んでいます。私は入社後、サポートの専門性を高め、より上流工程からプロダクト品質に寄与したいと考え、現在はQA（品質保証）の領域についても知見を深めています。

今回はチーム内でのコミュニケーションや、仕様理解の助けとして学んだ 振る舞い駆動開発（BDD：Behavior-Driven Development） という考え方についてお話しします。

1. 技術とビジネスの「行間」を埋める難しさ

プロダクト開発の現場にいると、同じ一つの機能開発であっても、立場によって見ている景色が全く異なることに気づかされます。

例えば、開発チームが作成する正確な「仕様書」は、実装に基づいた信頼できる情報源です。しかし、それをそのままビジネスサイドへ共有しても、スムーズな理解に繋がらないことがあります。なぜなら、ビジネスサイドや顧客が本当に知りたいのは、仕様の仕組みそのもの以上に 「それによって実際の業務や運用がどう変わるのか」 という点だからです。

技術とビジネスの間に立ち、この二つの間にある「行間」を埋めようとするとき、次のような葛藤に直面したことはないでしょうか。

• 情報の取捨選択と仕分けの難しさ
  開発側の正確な仕様を大切にしつつ、顧客視点で何を強調すべきか。その情報の濃淡をつけるための言葉選びや、視点の置きどころを考えること。
• 「確信」を持って伝えきるための理解を深めるプロセス
  仕様の裏側にある意図や影響範囲を正しく理解することや、ビジネスサイドからの「お客様の運用はどう変わる？」という問いに対しての自信ある回答。

こうした「視点のズレ」を埋め、両者の対話をよりスムーズにする手法を模索する中で、BDDというアプローチが大きなヒントになりました。

2. BDDで見つけた「具体例」という共通言語

BDDを学ぶ中で得た最大の発見は、共通理解を構築するために 「具体的なシナリオ（具体例）」 を用いるというアプローチでした。

特定の機能開発であっても職種によって抱く関心事は異なります。

• 開発側：コードの整合性やシステムの内部状態といった技術的な関心事
• ビジネス側：ユーザー体験や提供価値といったドメインの関心事

このようなギャップを埋めるために、抽象的な言葉ではなく 「もし〜なら、こうなる」 という共通の具体例をもとに会話を進めていくことが、BDDの核となるアプローチです。
さらに、この「具体例」を誰でも同じ形式で書けるように整理したのが、Given/When/Thenというフレームワークです。

例えば、エンジニアと仕様をすり合わせる際、このフレームワークを使って具体的な挙動を書き出します。

• 前提（Given）：ユーザーがログイン画面にいる
• もし（When）：パスワードを3回間違えたら
• ならば（Then）：アカウントをロックし、再設定メールを送る

Given / When / Then とは？
BDDでシステムの振る舞いを記述するための標準的な形式です。

• Given（前提）：システムがどのような状態にあるか
• When（もし〜したら）：ユーザーがどのような操作を行うか
• Then（ならば〜なる）：その結果、何が起きるべきか

このように「具体例」を型に当てはめて会話をすることで、コミュニケーションの質が明確に変化します。

BDDは決してエンジニアだけのものではありません。 こうして共通言語を持つことで、エンジニアとビジネス側の双方が同じ目線で「プロダクトがどうあるべきか」を深く対話できるようになります。立場を越えて本質的な議論ができるようになることこそ、BDDがチームにもたらす真の価値だと感じています。

3. シナリオがチームの「資産」になる

BDDのシナリオには、チーム間のコミュニケーションを円滑にすること以外にも価値があります。それが、「生きているドキュメント（Living Documentation）」という考え方です。

私たちが作成する資料やドキュメントは、開発が進むにつれて実態とズレてしまいがちです。しかし、この「具体例（シナリオ）」をベースに管理することで、以下のような未来が見えてきます。

1. 仕様と実態を同期させやすくなる: ビジネスサイドと合意した「具体例」をそのままテストの条件に活用することで、開発が進んでもドキュメントと実際の挙動が乖離しにくい土台を作れます。
2. 誰でも読める仕様書になる：専門用語ではなく「具体例」で書かれているため、新しく入ったメンバーでもすぐに仕様を理解できます。

この積み重ねが、チーム全員で立ち戻れる**共通の「基準点」**になっていく。そう考えると、日々の仕様理解や資料作成も、単なる作業ではなくチームの資産を積み上げる大切な一歩に感じられます。

4. まずは「具体例」から始めてみる

今回BDDを学んで得た一番の収穫は、技術とビジネスの境界線上で感じる難しさを解消するヒントは、一つの「具体例」を差し出す工夫にあると気づけたことです。

そして、今回学んだことを知識として終わらせるのではなく、まずは日々の業務の中で、Given/When/Thenのフレームワークを使ってシナリオを一つ書いてみることから始めていこうと思います。

今後もエンジニアリングとビジネスの間に立つテクニカルサポートとして、チーム全員が同じ景色を見てプロダクトに向き合える状態を目指していきたいです。

5. 学びのきっかけになった本

今回の記事を書くにあたり、大きなヒントを得たのが以下の書籍です。BDDの考え方を「探索（Discovery）」と「定式化（Formulation）」というステップにわけて、非常に分かりやすく解説してくれています。

• BDD Books - 探索： 振る舞い駆動開発(BDD)を用いて、正しいソフトウェアを正しく構築するための、ビジネス側と開発側での共通理解の構築

  • チームの垣根を越えてどのように共通理解を作っていくかが丁寧に描かれています。職種の壁を感じている方に、まず手に取ってほしい一冊です。

• BDD Books - 定式化： 具体例をビジネス文書かつ、実行可能なドキュメントに変換する

  • 今回触れた「Given/When/Then」を、チームの資産（ドキュメント）としてどう残していくかが深掘りされています。「ドキュメントを資産化する」という考え方に触れ、日々の業務が、チームの未来を支える重要なステップであると確信させてくれました。

非エンジニアの方でも読みやすく、明日からの仕事にすぐ活かせる内容ばかりなので、ぜひ手に取ってみてください。