BDDの考え方を取り入れ、複雑な要件の開発に立ち向かおう

こんにちは、ハコベル開発チームの坂東です。

プロダクト開発に携わっていると、

• エンジニアごとに実装イメージが異なる
• コードレビューの段階で要件についての議論が発生する
• QA 終盤で実装漏れに気づき、慌てて修正する
• スプリントレビューで仕様の取り違いを指摘される

などの問題に直面することはありませんか？

こうした問題は、複雑な要件の開発が多いチームほど深刻になりがちです。

そこで私たちのチームでは、「実装前にシステムの振る舞いを洗い出し、チーム全員で合意形成を行う」ことを重視しています。

今回は、その具体的なアプローチと合わせて、取り組む際のポイントや注意点についてもご紹介します。以下でスライドでも公開していますのでぜひご覧ください。

https://speakerdeck.com/rickyban/sohutoueanozhen-ruwu-inizhao-mu-si-fu-za-nayao-jian-nokai-fa-nili-tixiang-kau

---

背景： 複雑な要件の開発に伴う課題

私たちのチームはスクラムをベースにした開発スタイルを採用しており、エンジニア・QA・PdM のメンバー構成で動いています。

私たちのチームが新しく進めることになったプロジェクトは、複数のサービスを組み合わせて連携するという性質のもので、連携に伴う事前処理や事後処理、エラーハンドリングなどに気を配る必要があり、通常の開発よりも複雑な要件が多い状況でした。

このような背景で、私たちは以下のような課題に直面していました。

1. 要件の曖昧さ
   複雑な要件のユーザーストーリーでは細部の挙動が詰め切れておらず、エンジニアごとに異なる前提で実装を進めてしまって、コードレビュー時に認識の齟齬が発覚する

2. 実装漏れと手戻り
   スプリントレビューや QA 工程で「想定していた仕様が実装されていない」ことに気づくと、修正や仕様の再確認が必要になり、スプリントゴールの達成やベロシティが不安定になる

3. チーム内認識の不一致
   エンジニア・QA・PdM の各メンバーがそれぞれ異なる理解を持って開発を進めるため、最終的な成果物に対する「期待値のズレ」が生じる

---

解決策：実装前に振る舞いを洗い出す

こうした課題を解消するために、私たちのチームでは「実装前にシステムの振る舞いを洗い出す」というアプローチを導入しています。

ポイントは ビヘイビア駆動開発 (BDD) の考え方を取り入れ、システムの振る舞いに関してチーム全員の認識を揃えること です。

1. チーム全員で要件の振る舞いを洗い出す

まずは、機能要件やユーザーストーリーが曖昧なまま実装に入らないように、チーム全員で合意をとる場を用意します。

システムの振る舞いは　Gherkin 記法 でシナリオをまとめています。

Gherkin 記法とは

システムの振る舞いを記述するためのフォーマット。

Given-When-Then の構造を用いて、シナリオを人間が読める形式で定義。
主にビヘイビア駆動開発（BDD）でよく用いられる。

参考: Cucumber 公式 Gherkin リファレンス

正常系シナリオ例：ユーザーのサインアップ

例えば、以下のようなシナリオを考えてみましょう。

• ユーザーがサインアップできる

Gherkin 記法で記述すると、以下のようになります。

   Given [ユーザー] サインアップ画面を開いている
   When [ユーザー] ユーザー名、ユーザー ID、パスワードなど必須項目を入力し、登録ボタンを押す
   Then [ユーザー] サインアップに成功し、ダッシュボード画面へ遷移する

ここでシナリオに対するメンバー全員の認識のズレがあれば、その場で議論を行い、合意形成を取ります。

例えば「住所も必須項目じゃないの？」「メール送信はいつ行うのか？」といった議論が発生するでしょう。振る舞いを出す過程で要件がクリアになり、議論の呼び水になるのがポイントです。

チームで合意が取れた場合、以下のようにシナリオに追記しておくことで 「ユーザーは住所も入力する必要がある」、「システムはユーザーに登録完了メールを送信する」 という振る舞いも明確になります。

   Given [ユーザー] サインアップ画面を開いている
-  When [ユーザー] ユーザー名、ユーザー ID、パスワードなど必須項目を入力し、登録ボタンを押す
+  When [ユーザー] 名前、住所、ユーザー ID、パスワードを入力し、登録ボタンを押す
   Then [ユーザー] サインアップに成功し、ダッシュボード画面へ遷移する
+  Then [システム] ユーザーに登録完了メールを送信する

異常系シナリオ例：必須項目のバリデーション

次に、異常系のシナリオを考えてみましょう。

• ユーザー名が 256 文字以上の場合、サインアップに失敗する

異常系も同様に、振る舞いを洗い出します。

   Given [ユーザー] サインアップ画面を開いておく
   When [ユーザー] ユーザー名は256文字以上とした上で、必須項目を埋め、登録ボタンを押す
   Then [ユーザー] サインアップに失敗し、ユーザー名が長くて失敗することを確認できる

ここでも、「ユーザー名の文字数によるバリデーションが必要なんだ」「エラーメッセージはどうするか」 といった会話や議論が発生し、要件がブラッシュアップされていきます。

エラーメッセージの内容が決まった場合、シナリオに追記しておきます。

   Given [ユーザー] サインアップ画面を開いている
   When [ユーザー] ユーザー名に 256 文字以上を入力し、登録ボタンを押す
-  Then [ユーザー] サインアップに失敗し、ユーザー名が長くて失敗することを確認できる
+  Then [ユーザー] 「ユーザー名が長すぎます。入力内容をご確認ください」というエラーメッセージーが表示され、サインアップに失敗することを確認できる

このように正常系・異常系も含めて、システムの振る舞いを洗い出すことで、チーム全員での合意形成を図ります。

---

取り組みを進める際に気をつけること

私たちが実装前に振る舞いを洗い出す際に意識しているポイントは以下のとおりです。

1. PBI 着手直後に全員で集まる
   エンジニアが実装を始める前に、PBI ごとにチーム全員が集まり、シナリオを洗い出します。

   合意形成を後回しにしないことで、認識ズレの早期発見や手戻りの削減につながります。

2. 漏れなく洗い出す
   システムの振る舞いを洗い出す際には、以下の観点を意識します。

   • 正常系: 満たしたい要件の主要な機能
   • 異常系: エラーハンドリングやバリデーション
   • デグレチェック: 既存機能に影響を与えないか

   これらを意識することで、PBI の実装で必要な修正箇所をカバーでき、実装後になって初めて見落としに気づく、といったことがなくなりました。

3. 各ステップの主語を明示する
   私たちのチームの工夫として、Gherkin 記法の 各ステップで [ユーザー] や [システム] などの主語をつけるようにしています。主語をはっきりさせることで、思わぬ認識ズレを防ぐことができます。

   そもそも言葉自体の定義が揺れることを防ぐため、ユビキタス言語 を共有しておくのも効果的です。

---

振る舞いを洗い出す取り組みの効果と課題

こうした取り組みを進めてきた結果、以下のような効果と課題が見えてきました。

効果

1. 手戻りの削減とベロシティの安定化
   曖昧な点を事前に徹底的に洗い出し、要件を明確にしてから実装を行うことで、後工程での大きな修正が減少し、スプリント全体のベロシティが安定しました。

2. 迅速な意思決定
   エンジニア、QA、PdM が一堂に会して議論することで、仕様に対する疑問や懸念が即時に解消されます。これにより、迅速な意思決定が可能になりました。

3. QA 工程へのスムーズな連携
   Gherkin 記法で定義したシナリオを テストシナリオ として再利用することで、QA チームとの連携がスムーズになりました。QA チームはシナリオをもとにテストケースを作成し、要件に基づいたテストを実施することができます。

4. ドキュメントとしての活用
   各 PBI の実装時に洗い出したシナリオはドキュメントとして残しているので、後から振り返ることもできます。関連する機能の要件定義を行う際や、新たにチームに加わったメンバーのオンボーディングにも活用しています。

課題

一方で、この取り組みには以下のような課題もあります。

1. 全員参加のコスト
   チーム全体で時間をとってディスカッションするため、スプリントのスケジュール調整や会議時間の確保が必要です。PBI の内容によっては少人数で進める、見積もりポイント数の大きい PBI に対してのみ行う など、柔軟な運用を行なっています。

2. 作成したシナリオを維持するコスト
   いざ開発を始めると、要件の変更や仕様の追加が発生することがあるでしょう。その際、この取り組みでは要件の変更があるたびにシナリオを修正する必要があります。シナリオの維持にはコストがかかりますが、シナリオが古い内容で放置されていると逆に誤解を生む原因になるため、定期的な見直しを心がけています。

まとめ

「実装前にシステムの振る舞いを洗い出し、チーム全員で合意形成を行う」ことは、複雑な要件の開発において非常に効果的です。

特に Gherkin 記法 で要件をシナリオ化すると、

• 認識のズレを最小化
• テストシナリオやドキュメントとして再利用可能
• 手戻りを減らし、結果的に開発スピードと品質を両立できる

といったメリットが得られます。

一方で、シナリオを洗い出して全員で合意を取るという作業は一定のコストがかかるため、コストとメリットのトレードオフを考慮しながら取り組むことが重要です。

もし「最近開発チケットの要件が複雑化していて、手戻りや認識ズレが増えてきた」と感じる方がいれば、ぜひ本記事の取り組みを参考にしてみてください。