【ITニュース解説】Write the Acceptance Tests Before the Agency Writes the Automation

システム開発を外部の専門業者に依頼する際、プロジェクトを始める前に私たちがすべき非常に重要なことの一つに、「受け入れテスト」を自分たちで具体的に作成し、それを契約書に含めるという考え方がある。これは、特にAIを活用したシステムを開発する場合に、開発プロジェクトにおける「完了」という漠然とした概念を、明確な基準で定義するために非常に役立つ。

通常、「完了」という言葉は、人によって解釈が異なる感覚的なものになりがちだが、受け入れテストという具体的な基準があれば、「これらのテストがすべて成功すれば、その機能は完成したと言える」と誰もが納得できる状態を作り出すことができる。これにより、後からの認識のズレや、不必要な手戻りを大幅に減らし、プロジェクトをスムーズに進めることが可能になる。

一般的なシステム開発では、まず「要件」を定義する。「問い合わせに自動で返信する機能」といったものがこれに当たる。しかし、要件は「何を作るか」という機能の概要を記述するのに対し、受け入れテストは「どのような状況で、システムがどう振る舞うか」という具体的な動作を記述する点が大きく異なる。記事では、AIワークフローを例に挙げて、同じ「問い合わせに返信する」という機能であっても、音声メモ、過去に問い合わせたことがある見込み客、あるいは怒っている顧客からの問い合わせといった「実際の入力」によって、システムが取るべき行動が全く異なる可能性があると指摘している。このため、抽象的な要件だけではなく、具体的な動作を示す受け入れテストを作成することが非常に重要になるのだ。

受け入れテストの書き方には、推奨されるシンプルなフォーマットがある。これは主に三つの要素から構成される。一つ目は「id」で、テストケースを識別するためのユニークな番号だ。二つ目は「given」で、「もし～ならば」という形で、テストの前提条件やシステムへの入力データを具体的に記述する。これはシステムが特定の状況に置かれた状態を想定する。三つ目は「expect」で、「～であるはずだ」という形で、その前提条件に対してシステムがどのような結果を出すべきか、期待される出力や動作を記述する。さらに、「human_approval」という項目を設けて、そのテストケースでシステムが自動処理を完結させるべきか、それとも最終的に人間による確認や承認を挟むべきかを示す。

具体的な例を見てみよう。例えば、「id: AT-01」のテストケースでは、「given: 不明な電話番号からのWhatsAppメッセージで営業時間について尋ねられた場合」という条件に対して、「expect: 承認済みライブラリからの自動返信が業務の返信時間内に送信され、CRMにWhatsAppをソースとするリードが作成される」という結果を期待し、「human_approval: false」なので完全に自動で処理されるべきだと定義する。一方で、「id: AT-02」のように、「既存顧客が見積もり済みの注文について割引を要求した場合」という条件では、「expect: 返信の下書きが作成され、送信はされず、担当者に通知が送られ、CRMの取引情報は変更されない」という結果を期待し、「human_approval: true」として人間による承認が必要であると定める。これは、金銭や顧客との関係に影響する機微な内容の場合、システムにすべてを任せず、人間の最終確認を挟むべきだという考え方を示す。他にも、同じ人物からのメッセージとWebフォームからの入力が短時間で行われた場合にCRMで連絡先が重複しないようにするテスト（AT-03）や、外部のCRMシステムとのAPI連携でエラーが発生した場合にメッセージをキューに入れて再試行し、それでも失敗したら担当者にアラートを送るような異常系処理のテスト（AT-04）なども含まれる。これらの具体例は、システムの多様な挙動を網羅的に考慮し、テストで確認することの重要性を示している。

受け入れテストを作成する際には、いくつかの実践的なヒントがある。まず、「given」の項目には、可能な限り実際のメッセージやデータの一部（個人情報を削除したもの）を使うべきだ。これにより、テストの現実性と網羅性が高まる。次に、システムが正常に動作する「ハッピーパス」のテストだけでなく、エラー発生時、データ重複時、サービス対象外の場合、営業時間外といった「失敗ケース」のテストも同程度、あるいはそれ以上書くべきだ。これにより、予期せぬ問題が発生した際のシステムの振る舞いを明確にできる。また、金銭のやり取り、価格の提示、顧客への謝罪など、ビジネスに大きな影響を与える可能性のある処理には必ず「human_approval: true」とマークし、人間の確認プロセスを組み込むべきである。これはシステムに任せきりにせず、リスクを管理するための重要な視点だ。さらに、誰がいつテストを実行するかを事前に合意しておくことも大切だ。通常、開発を依頼した外部業者はシステム納品前にこれらのテストを実行し、私たちはシステムが変更されるたびに、これらのテストの一部を再実行することに合意する。作成したテストは、関連するワークフローマップの隣に、共有リポジトリや共有ドライブで管理し、いつでも参照できるようにしておくことが望ましい。

このような受け入れテストを事前に定義しておくことは、ビジネス上のメリットも大きい。開発業者から提出される提案書は、より具体的で正直な内容になる。例えば、「スマートなルーティング」のような漠然とした項目は、具体的な受け入れテスト（AT-05からAT-09など）に置き換えられ、何が実現されるのかが明確になる。また、開発費用に関する交渉も、それぞれのテストを達成するために必要な工数を具体的に示すことで、より建設的かつ透明性の高いものになるだろう。

このように受け入れテストを事前に明確に定義することは、単にシステムの品質を高めるだけでなく、プロジェクト全体の透明性を向上させ、開発に関わるすべての関係者間の認識のズレを防ぎ、最終的にプロジェクトの成功に大きく貢献する極めて有効な方法である。システムエンジニアとして、このような視点を持つことは、高品質なシステム開発をリードするために不可欠なスキルとなる。