読書メモ。2025年25冊目。
『The BDD Books - Discovery』を読んでの感想となります。（2025/3/30記載）
本の概要
本書籍は、振る舞い駆動開発(Behavior Driven Development, BDD)や受け入れテスト駆動開発(Acceptance Test-Driven Development, ATDD)の発見フェーズを最大限に活用する方法を提供します。 書籍内では、優れたコラボレーション手法を具体例で示しており、実用的なガイドとなっています。 本書籍は、SpecFlowの作成者と書籍『The Cucumber for Java Book』の著者によって書かれました。
本書籍は、プロダクトオーナー、ビジネスアナリスト、開発者、テスターなど、ソフトウェアの仕様とデリバリーに携わるすべての人を対象としています。 本書籍では、なぜBDDが誕生した理由の説明から始まり、ビジネスチームとデリバリーチームのメンバー間のコラボレーションを最大限に活用するためのテクニックを説明します。
これは、協調して作成した仕様と生きたドキュメントを活用して開発を成功させるために必要な特定の技術的なプラクティスを含む、開発プロセス全体をガイドするBDD Booksシリーズの1冊目です。
引用：
動機
- 開発チームがその一員ではなくチームとして要件にどう近づくか考えている。
- 今利用しているGherkinが本当に目的に合っているか分かっていない。
- 『Agile Testing Condensed』で紹介されていた実例マッピングをもっと学びたい。
感想
『Agile Testing Condensed』で興味を持った実例マッピングの効果が確信に近づけることができました。
特に、プロダクトオーナーや開発チームの誰かが要件や仕様を理解するのではなく、プロダクトに関わる全員で要件・仕様に向き合えることに魅力を感じています。
直近の開発を通し、POが要求をもとに要件を考えて、開発チームに要件と仕様を受け渡した場合、充分な引継ぎをしない限り要求と開発チームに距離が生まれることを感じています。
自分達よりユーザーに近い人間がユーザーからの要求から出した答えがある場合、開発者が取り掛かるべきなのは答えのため、要求のことを十分に考える思考が持てないためと考えています。
それと同様に、プロダクトオーナーが出した要件に対して、チーム内の誰かが設計・仕様調整を行ったものを、他の誰かが実装する場合、その実装者は要件から距離が生まれると感じています。
また、むしろ悪いのは引継ぎが十分ではない場合は、要件から前任者と同じ設計・仕様調整を行うことにもなります。
個人的に役割の違いや、余計な役割を増やすことによって発生する、このような課題を不充分な引継ぎを充分にして解消するのではなく、
役割を必要最小限にしたうえで、考えるプロセスを共有することで解消できないかと考えていました。
その要望に対してBDD、実例マッピングは最適な気がしています。
特にこのDiscoveryの内容で自信を持つことができました。業務に充てていきます。
続けてFormulationも読んでいきます。
忘れたくないメモ
■要件に向き合うために
具体例があると、プロダクトの要件に対して異なる視点を持つ人たち全員が、作業の現実に向き合って議論ができる。
製品の振る舞いを定義し、具体例を運用することで、チームはより迅速なフィードバックを取得し、顧客が必要とする製品を提供できる。
BDDは、対話を通じてプロダクトオーナーが要件を常に理解している訳ではないという問題を明らかにする。
■コンテキストを揃える
強調して要件定義を行う中で得られる共通理解により、要件定義からデリバリーまでのスムーズなフローが保証される。
中断とコンテキストスイッチを排除することで、より効率的で予測可能なデリバリープロセスが実現可能となる。
協調した議論と共有の語彙の作成に投資することから始めることで実現が可能となる。
■要件とソフトウェアの繋がり
BDDが橋渡しとなり、ビジネス担当者がプロセス全体を通して参加し続けることで、要件とソフトウェアの繋がりを維持することができる。
どのテストも具体例の1つであり、それぞれの具体例は求められるシステムの振る舞いを表現したものとなる。
■要件が持つ複雑さと仮定の発見
ユーザーストーリーによってチームは要件を発見する。
具体例に注目することで、ルールの理解を探索することができ、それが複雑さと仮定の発見につながる。
■明確な具体例
明確な具体例は、アプリケーションまたはそのフィーチャーの1つがどのように振る舞うべきかについての具体的な使い方の説明となる。
すべての具体例は、振る舞いをコンテキスト、アクション、結果(outcome)の組み合わせとして説明できる。
■アジャイルテスト
アジャイルテストの基本コンセプトは、問題がコードベースに追加されないようにすること。
テスターは、バグを防止のため欠陥の多くの原因となる要件の議論に参加する。
テスターは、矛盾を指摘したり、具体例を特定したり、エッジケースを検討したりすることで支援ができる。
■自動テストの効果
自動化のレベルが高くなると、手動の回帰テストに費やす時間が少なくなり、探索的な検証により多くの時間を費やすことができる。
■シナリオを生きたドキュメントにする
シナリオを生きたドキュメントとして使用するため、利用者がシナリオに容易にアクセスできるようにする。
シナリオが生きた構造を構成していると、シナリオがアプリケーションでサポートされているか常に確認できる。
ビジネス担当者が、私たちの解決策がどのような期待を満たすことができないか知ることができます。
■ビジネスチームを巻き込む
発見のプラクティスにビジネスチームのメンバーをうまく巻き込めなければ、投資に対して十分なリターンが得られない。
チームをまたいだ協調作業が得意になるまで、自動化ツールには焦点を合わせない。
■開発が正しい方向に進んでいることを関係者全員に保証する
BDDは協調に焦点を当てており、チーム全体が理解する明確な要件につながる。
BDDを通じて具体例を発見することで、優れたテストケースとドキュメントが得られる。
明確な具体例を考え出すことで、チームメンバー全員がユーザーストーリーの理解に積極的に立ち向かう必要がある。
■BDDの典型的な間違い
BDDをツールと見なすこと。
BDDをGiven/When/Thenのテンプレートに記入するなどの機械的なプロセスであると考えること。
■計画的な発見
ソフトウェア開発は学習するプロセス。開発する過程で最初は知らなかったことを発見する。
要件ワークショップ中に発生する発見は、「計画的な発見」。
具体例は、私たちがすでに知っていることを説明し、私たちの仮定に疑問を投げかけ、意図的な発見のための会話を支える。
■実例マッピングの運用
具体例とルールを収集すべき際の厳密な順序はない。
ファシリテーターは、議論が付箋に記録され、全員が書き留めた内容に同意しているか注意を払う。特別な役割ではなく、チームの誰でもなることができ、ローテーションすることが良い。
作成した実例マッピングは失わないことが重要。
■構造化された会話の確立
構造化された会話は、あらかじめ定義された形式に準拠し、アイデアの交換を円滑にする。
ミーティングではさまざまな役割の代表者が早い段階で要件の理解に立ち向かうことが重要。。
そのため、双方向のコミュニケーションが必要となり、チーム全体で積極的に協調するように促すべき。
コミュニケーションに問題がある場合、根本原因を特定し、解決する方法を理解することが重要。
■要件ミーティング
ミーティングは短くすることで頻繁にスケジュールできる。
頻繁に開催することで様々な人がミーティングに参加することができ、共有所有権を向上させられる。
ミーティングを記録することでまだ理解していないことに焦点を合わせ続けることができる。
どこにも行かない議論は止め、答えられない疑問点として記録する。
アウトプットすべてが全員によって同意されなければならない。
■学習のタイミング
ソフトウェア開発は学習するプロセス。
問題について学べば学ぶほど、問題解決が容易になる。
ソフトウェア開発を開始する前に、異なる視点を持つメンバーが要件を一緒に分析することで、より効果的になる。
■具体例について
具体例は、コンテキスト、アクション、結果の3つの部分に分割されたもの。
ルールは簡潔で抽象的な説明を提供し、具体例は正確で具体的な説明を提供する。
具体例は1つのルールのみを示す。
具体例の表現はあいまいにしない。明確な具体例を指定することで、コンテキスト、アクション、結果はすべて明確で具体的なデータを指定する必要がある。
それぞれの具体例はある1つのルールを表し、説明されている振る舞いに直接関連する具体的なデータにのみ言及する。明確な具体例を用いて要件をすばやく調査し、求められている内容を全員が正確に理解する。
要件をよりよく理解することで、バグの未然防止を実現するが、「良いカバレッジ」の達成を忘れるべきという意味ではない。要件ワークショップの外でデリバリーチームが行うべき。
ワークショップを終了する前に、具体例をいくつかの具体例に分割して、それぞれが1つのルールに焦点を当てているかを検討する。
■要件ワークショップのタイミング
プロジェクト全体を通して週に数回、短時間のワークショップとして開催するのが吉。
■自動化のタイミング
実装開始前にシナリオを自動化する。
実装とは別に実施したり、実装が完了してから実施する場合、BDDの利点を減らす。
■スクラムにおけるBDD
バックログリファインメントの代わりに、短時間の実例マッピングのセッションを定期的に開催することがお勧め。チームが次スプリントのために十分なストーリーが準備できたら、いつでもキャンセルできる。
具体例からシナリオを定式化するのは難しいため、プランニングの準備やプランニング中にシナリオを定式化することはお勧めしない。シナリオを定式化するための最良のアプローチは、ストーリーの実装パイプラインにタスクとして含めること。
これらのシナリオを自動化しながら、解決策の設計についてさらに学習し、この知識を残りのシナリオの定式化に組み込む。
重要な具体例は、全体像を描き、必要のある設計上の判断を明らかにするため、いくつかの重要な具体例でストーリーを説明すると、タスクのプランニングが容易になる。
タスクをシナリオに合わせることにより、チームは実装中に期待する振る舞いに焦点を絞ることができ、ストーリーの実装に関するフィードバックが早く得られる。
結果、ストーリーが完全に実装される前に、手動テストを開始できる。
機能の開発が進むにつれ、透明性が向上し、開発チームとプロダクトオーナーの間の信頼が高まる。
■ビジネスチームの不参加
テストとテスト自動化の実行方法に関する明確なガイダンスを導入でき、アドホックで混沌としたテスト戦略よりも優れているが、ビジネスチームに参加することによって得られる大きなメリットを獲得できない。
■プロダクトオーナー負荷
最終的に、プロダクトオーナーがアプリケーションの実装に必要な情報を提供する必要がある。
BDDは、ビジネスチームとの早期の直接的なコミュニケーションに焦点を当て、誤解を減らし、やり直しを減らすことで、コミュニケーションの効率を向上させる。
チームによって作成されたシナリオが、プロダクトオーナーが作成していた仕様の代わりになる。
■スコープ調整
シナリオは、ストーリーの機能的な分割を提供し、時間のプレッシャーにさらされているときに優先度の低い振る舞いを特定して延期することにより、スコープを減らす機会を提供する。
