最近、参加したアジャイル開発の研修で、テストの役割について深く考える機会がありました。今回は、その研修を通じて得た学びを、個人的な視点でまとめます。特定の研修の詳細を避け、一般的な気づきとしてお伝えします。
目次
学び：前工程で品質を作り込む
研修を通じて最も印象に残ったのは、「品質は後工程のテストだけで担保できるものではない」 という点です。
テストを後工程（実装後）に依存しすぎると、以下のようなリスクが高まります。
- 手戻りの増加によるスケジュールの遅延
- 修正コストの肥大化
特に、「チーム間での認識のズレが、実装後の不具合の根本原因になる」 という指摘には、強く共感しました。
実例による仕様
新機能開発時に、あらかじめ「受け入れ条件」を具体的な実例で明確にすることで、プロダクトの仕様とテスト条件が一致します。これにより、曖昧な言葉によるミスコミュニケーションを未然に防ぐことが可能になります。
演習問題：仕様の曖昧さを体験してみよう
この学びを体感するために、オリジナルから変更した簡単な演習問題を紹介します。以下の条件で、請求金額を計算してみてください。
受け入れ条件
- 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のように具体的な実例を用いることで、手戻りやミスコミュニケーションを劇的に減らすことができます。
まとめ
この研修を通じて、テストは「不具合を見つける作業」だけでなく「前工程で認識を揃え、品質を組み込む活動」であると再認識しました。抽象的な言葉ではなく「実例」を用いることで、手戻りやミスコミュニケーションを劇的に減らすことができると感じました。
個人的には、この学びを今後のプロジェクトに活かしていきたいと思います。アジャイル開発の現場で、テストの位置づけを改めて考える良い機会でした。