最近、参加したアジャイル開発の研修で、テストの役割について深く考える機会がありました。今回は、その研修を通じて得た学びを、個人的な視点でまとめます。特定の研修の詳細を避け、一般的な気づきとしてお伝えします。

目次

学び：前工程で品質を作り込む
- 演習問題：仕様の曖昧さを体験してみよう
- 仕様表現の手法
まとめ

学び：前工程で品質を作り込む

研修を通じて最も印象に残ったのは、「品質は後工程のテストだけで担保できるものではない」 という点です。

テストを後工程（実装後）に依存しすぎると、以下のようなリスクが高まります。

手戻りの増加によるスケジュールの遅延
修正コストの肥大化

特に、「チーム間での認識のズレが、実装後の不具合の根本原因になる」 という指摘には、強く共感しました。

実例による仕様
新機能開発時に、あらかじめ「受け入れ条件」を具体的な実例で明確にすることで、プロダクトの仕様とテスト条件が一致します。これにより、曖昧な言葉によるミスコミュニケーションを未然に防ぐことが可能になります。

演習問題：仕様の曖昧さを体験してみよう

この学びを体感するために、オリジナルから変更した簡単な演習問題を紹介します。以下の条件で、請求金額を計算してみてください。

受け入れ条件

4つのプラン：ライト（3万+0.5万/人）、スタンダード（8万+1.5万/人）、プレミアム（15万+2万/人）、VIP（25万+3万/人）

開催場所による変動：東京（100%）、大阪（95%）、地方（85%）

割引：30名超の参加で15%割引、または特別クーポンで5%割引（両方適用不可）

Q. 請求金額はいくら？
「プレミアムプラン」を選択、場所は「大阪」、参加人数「70名」、特別クーポンを使用した場合。

予想される回答例
人によって結果が分かれるかもしれません。計算してみて、なぜ答えが揃わないかを考えてみてください。

パターンA：約77万円
- （基本料金 15万＋人数分 70万） × 0.95（大阪） × 0.95（クーポン）＝約77万円
パターンB：約78万円
- 基本料金 15万＋（人数分 70万 × 0.95（大阪） × 0.95（クーポン））＝約78万円

このように、仕様が曖昧だと解釈が分かれます。Gherkinのような明確な記述で防ぎましょう。

仕様表現の手法

この認識の齟齬を解決する手段として紹介されたのが、Gherkin形式の記述です。Gherkinは、具体的な条件と期待される結果をセットで示すことで、実装前にチーム全員の認識を強制的に同期させる手法です。

Scenario: 大阪で35名がプレミアムプランを利用する場合
  Given プレミアムプランを選択している
  And 参加人数は35名である
  And 開催場所は大阪である
  And 特別クーポンを使用している
  When 申込みを確定する
  Then 最終請求金額は 767,125 円になる

文章だけで仕様を伝えると、どうしても個人の「暗黙のルール」が入り込みます。Gherkinのように具体的な実例を用いることで、手戻りやミスコミュニケーションを劇的に減らすことができます。

まとめ

この研修を通じて、テストは「不具合を見つける作業」だけでなく「前工程で認識を揃え、品質を組み込む活動」であると再認識しました。抽象的な言葉ではなく「実例」を用いることで、手戻りやミスコミュニケーションを劇的に減らすことができると感じました。

個人的には、この学びを今後のプロジェクトに活かしていきたいと思います。アジャイル開発の現場で、テストの位置づけを改めて考える良い機会でした。