受入テストは新しい要望を反映させる場じゃねぇんだよ

はじめに

受入テストのタイミングで、
「ここ、やっぱり変えたいです」
「この機能も追加できませんか？」
みたいな話が出ること、ありませんか？
受入テストのあるあるなのではと、私は思っています。

事前に
「受入テストは、要件定義・設計どおりに作られているかを確認する場です」
と説明していても、発生しちゃうんですよね。
それが原因で発注側と開発側が揉めることもあるのではと。

ただ、このタイミングで色々と要望を言いたくなる発注側の気持ちもわかります。
アプリ／システム開発って、大きなお金がかかります。

実際に触れる段階まで来ると、
「せっかくだから、ここも改善したい」
「今なら一緒に直せるんじゃない？」
と思うのも自然です。
しかも、実際にアプリ／システムを触ってみないと気づけないこともあります。
なので、受入テストで追加要望が出ること自体を否定したいわけではありません。

ただ、一つだけ強く言いたいです。
受入テストは、何でもかんでも言っていい場じゃねぇんだよ！

あくまで、
「要件定義・設計で合意した内容どおりに開発されているか」
を確認する場です。

ここを曖昧にしたまま進めると、発注側・開発側の認識がズレます。
そして、プロジェクトが一気に荒れます。

今回は、受入テストで追加要望が出たときに、発注側と開発側ができるだけ平和に進めるための考え方を書いてみます。

受入テストって、本来何を確認する場？

まず今回の記事では、
「要件定義・設計で合意した内容どおりに、アプリ／システムが開発されている」
ことを前提にします。

つまり、
・要件定義で決めた内容
・設計で整理した仕様
・レビューで合意した内容
に沿って、開発側がちゃんと作っているケースです。

この場合、受入テストは、
「要件定義・設計で合意した内容どおりに、アプリ／システムが開発されているかを確認して、受け入れてよいか判断する場」です。

なので、本来の受入テストでは、
・仕様どおりに動いているか
・想定していた画面や導線になっているか
・業務でちゃんと使えるか
・想定外の不具合がないか
などを確認します。

逆に言うと、
「やっぱりこの機能も欲しい」
「この画面、根本的に作り変えたい」
「運用を変えたから、仕様を大きく変えたい」
みたいな話は、“受入確認”とは別の話です。

もちろん、ちょっとした仕様調整なら、現場判断で対応できることもあります。大きな仕様変更や機能追加でも、事前に追加工数や追加予算を確保しているなら問題ありません。

ただ、
「受入テスト中だから、その場で全部対応してもらえる」
という感覚で進めてしまうと、めちゃくちゃ危ないです。

受入テストは、
“新しい機能を追加したり、仕様を大幅に作り変えたりする場”
ではありません。

要望を言うのはOK。でも何でも対応してもらえるわけじゃない

ここまで読むと、
「じゃあ、受入テストでは何も言っちゃダメなの？」
と思う人もいるかもしれません。
そんなことはありません。

実際のプロジェクトでは、受入テストのタイミングで初めて気づくこともあります。
要件定義・設計の文章だけでは、お互いに同じ認識で進めていたつもりでも、実際の画面や操作感を見ると、「あれ、思ってたのと違うな」となることもあります。

なので、
「認識していた内容と違う」
「この仕様だと実業務で困る」
「運用上、最低限ここは調整したい」
と相談すること自体は、まったく悪いことではありません。

受入テストでは、
・認識齟齬に対する改修相談
・文言やレイアウトの微調整
・導線の軽微な改善
・運用を踏まえた調整レベルの仕様変更
などは起きます。

新機能に近い要望でも、内容が軽微で、開発ベンダー側の許容範囲で対応できるなら、調整として対応できることもあります。

ただし、それはあくまで開発ベンダー側が、
「この範囲なら対応できます」
と判断できる場合の話です。

発注側が一方的に、
「これくらい簡単ですよね」
「受入テスト中だから対応してください」
と決めるものではありません。

大きな仕様変更や機能追加でも、
・追加工数を確保する
・追加予算を確保する
・スケジュールを調整する
という形で、開発側と合意して進めるなら問題ありません。

大事なのは、
「これは受入テストの範囲なのか」
「追加開発として扱うべきなのか」
を、お互いに整理しながら話すことです。
問題は、追加要望が出ることそのものではありません。

発注側が、
「受入テスト中だから対応してもらえるはず」
「これくらいなら当然やってもらえるはず」
と考えてしまうことです。
この考え方は、発注側と開発側の関係にヒビを入れます。

開発側としても、当然のように追加対応を求められ続けると、プロジェクトに協力しようという気持ちや、より良いシステムを一緒に作っていこうという意識を持ちにくくなります。

良いシステムを作るには、発注側と開発側の信頼関係が大事です。
その関係を壊してしまう進め方は、結局、発注側にとってもマイナスです。

そして、開発側も、
「受入テストで言われたから対応しないといけない」
「揉めたくないから、とりあえず受けておこう」
と安易に受け入れるのは良くありません。

何でも受け入れてしまうと、スケジュールはどんどん苦しくなります。
追加工数に対する費用をもらえなければ、開発側の赤字にもつながります。

結果として、発注側・開発側のどちらにとっても不幸な進め方になってしまいます。

じゃあ、どう歩み寄るべきか

ここまで書いてきたように、受入テストで追加要望が出ること自体は、ある程度仕方ないと思っています。

実際に触ってみないと気づけないこともあります。
リリース前だからこそ改善したくなる気持ちも自然です。

だから大事なのは、
「追加要望をゼロにすること」
ではありません。

大事なのは、
「追加要望が出たときに、どう整理して歩み寄るか」
です。

個人的には、一番良いのは、
「必要な追加工数を確保したうえで対応する」
ことだと思います。

追加開発が必要なら、その分の費用やスケジュールを調整する。
そのうえで、お互いに納得した状態で進める。これが一番健全です。

ただ、現実には、
「予算を追加するのは難しい」
「スケジュールを大きく延ばせない」
というケースもあります。

そういう場合は、
・全額ではないが、開発ベンダー側が納得できる追加費用を支払う
・優先度の高いものだけ対応する
・大幅な仕様変更や機能追加は次フェーズへ見送る
・無償で対応可能な範囲を、開発側と相談する
といった形で、落としどころを探すことになります。

ここで大事なのは、
「受入テストだから無条件で対応してもらえる」
ではなく、
「追加要望には、追加のコストや調整が発生する」
という前提で話すことです。

発注側と開発側が対立するのではなく、
「どうすれば現実的に進められるか」
を一緒に考えられる状態が、最終的には一番平和に進みます。

まとめ

受入テストは、要件定義・設計で合意した内容どおりにアプリ／システムが開発されているかを確認して、受け入れてよいか判断する場です。

なので、本来は新しい機能を追加したり、仕様を大きく作り変えたりする場ではありません。
ただ、実際にアプリ／システムを触ってみて初めて気づくことがあるのも事実です。だから、受入テストで追加要望が出ること自体を悪いことだとは思いません。

大事なのは、その要望が、
・不具合なのか
・認識齟齬なのか
・軽微な調整なのか
・追加開発として扱うべきものなのか
を整理することです。

発注側は「受入テスト中だから当然対応してもらえる」と考えない。
開発側も「言われたから何でも受ける」と安易に判断しない。

お互いに受入テストの目的を理解したうえで、必要なコストやスケジュールも含めて、現実的な落としどころを探すことが大事だと思います。

受入テストは、発注側と開発側が揉めるための場ではありません。
合意した内容を確認して、より良い形でリリースに向かうための場です。
その前提をお互いに持てているかどうかで、プロジェクトの進み方は大きく変わります。

この記事が、発注側・開発側のどちらにとっても、受入テストでの追加要望との向き合い方を考えるきっかけになれば嬉しいです。
そして、少しでも平和に進むプロジェクトが増えたらいいなと思います。