基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
受入テストは修正がある前提で計画を立てる
次に、受入テスト計画を立てるにあたって気を付けるべきこととして、受入テストの計画は「修正がある前提」で立てるということについてお話しします。みなさんのプロジェクトでは、受入テストのスケジューリングをどのように行っていますか。受入テストで上がった指摘に対する修正について、計画に織り込んでいるでしょうか？
計画に含まれていないとしたら、必ず含めるようにしましょう。私は過去システムベンダーさんにスケジューリングをお願いした際、指摘0の前提で計画をいただいたことがありました。（受入テストは基本的にはユーザ側のタスクではありますが、機能の修正が必要になる場合にはベンダー側に修正を依頼することになるためリリースに向けてのスケジューリングは双方で相談の上で立てます。）
確かに、見つかってもいないバグや修正点について工数を見積もることはできませんが、だからと言って指摘0で見積もるのは極端すぎます。できないからこそ、仮定をおいて見積もることが重要です。ちなみに、このプロジェクトでは受入テストの半分くらいの工数/期間を指摘修正、再レビューに積んでいました。
最近リリースした機能だと受入テストが1週間くらい、指摘修正に3日くらい積んでいたかと思います。3日の内訳は最初の1日でプログラム修正、残り２日でテストとレビューというイメージです。ここで重要なのが、想定から外れた場合のリスケジュールです。
受入テストで修正点が見つかったら、まずは短期間（たとえば1日）で修正できるレベルのものかどうか見極めます。それが難しければ、レビューも含めると3日で完了させることが難しくなるので、この時点で計画の見直し、具体的にはQCD＋S*のどれをあきらめるか判断します。
ここで一般的にはまずCost（費用）とDelivery（期日）を天秤にかけます。すなわち残業してでも期日に間に合わせるか、残業せずにリリース日を遅らせるかです。（場合によっては残業もするし、期日も遅らせる、という「どちらも諦める」選択を取らざるを得ない場合もあるかも知れません。）
この場合、どちらを選ぶかはケースバイケースだと思いますが、残業してでも期日に間に合わせることを選んだ場合、Quality（品質）にもリスクを負うことも考慮に入れて選ばなければなりません。もちろん、期日はそう簡単に調整できるものではないかも知れませんが、状況が許せば期日の延長も選択肢に入れても良いと思います。
なお、あまり頻度は高くないと思いますがオプションとしてQuality（品質）をあきらめるということもあり得ます。つまり業務影響がそこまで大きくない問題であればそのまま一旦そのままリリースし、あとで落ち着いて直す、といった選択です。
運用回避が可能であったり、発生頻度等を考慮し許容できる内容であったりする場合はまずはリリースすればユーザは基本的な機能は使うことが出来るので、メリットとデメリットのバランスを考えて総合的にメリットの方が大きければ一旦リリースする判断をとることも、検討の余地はあると思います。
＊QCD＋S いくつかの定義がありますがここでは品質(Quality)、予算(Cost)、納品(Delivery)、スコープ（Scope）の4要素を指しています
受入テストで指摘が上がったときの考え方
最後に、受入テストで指摘が上がったときの考え方についてお話ししたいと思います。個人的には受入テストで指摘事項が上がること自体は悪いことだとは考えていません。指摘の内容によって、良い指摘と悪い指摘に分けられると思っています。
良い指摘について
良い指摘というのは、動作確認を行う中で言語化されていない要求が明確になったことによって発生したものであったり、明確に要件化されていたとしても受入テストを行った結果から見直す必要があったりするものです。たとえば「設計書の通りだけど、実際に動くものを見てみたら調整が必要になった」といったものです。他には、要件は満たしているが実装方法についてユーザ側から指定があるような場合もあります。
基本的にはユーザ側としては「何を作るか」を示し、「どう実現するか」という技術的な問題はベンダー側で決めていった方がシンプルな仕様で構築できることが多いのですが、実現方法に対してユーザ側で指定がある場合は、受入時に見直しをかけることもあります。 もちろんデータモデルに関わるような変更や、機能の根幹にかかわるような内容は要件定義や概要設計などの上流フェーズで拾うべきですが、画面のレイアウトに関わるものや、エラー発生時のメッセージの修正など軽微なものであれば動くものが出来上がってからの方がコミュニケーションしやすいこともあります。
概要設計レベルまではきちんとすり合わせを行って実装すべきですが、詳細設計レベルの内容などは全てを取り決めてから実装すると途方もない工数がかかってしまうので、「ひとまず作って見てもらう」というアプローチが有効な場合も多いと思います。
受入時にこうした指摘を拾うことで、より高い品質のプロダクトに育ててリリースすることが出来るので、こうした修正が発生した場合は「リリース前に直せてよかった」と前向きに捉えてよいと思います。先ほど受入テストのスケジューリングについて修正がある前提で受入テスト計画を立てる、という内容を書きましたが、この修正期間はバグをつぶす(=マイナスをゼロにする)だけでなく、よりよいプロダクトに育てるブラッシュアップ期間(=ゼロからプラスにする)でもあると捉えています。
悪い指摘について
逆に悪い指摘は、仕様に落とし込まれているにも関わらずその通りに実装されていないことによる指摘です。こうしたものは基本的には結合テストで拾い、受入テストでは指摘がないようにすべき内容です。こうした指摘が受入テストフェーズで上がってしまった場合には、どのプロセスに問題があったのか振り返って検証していきます。
概要設計から詳細設計への落とし込みに失敗したのか、実装時のミスなのか、テストでのミスなのか、レビューでも見落としてしまったのか、、、。どこで拾うべきだったのかを明確にすることで、次回以降の対策につなげることが出来ます。
なお、対策を講じる場合は対応工数も上がる場合が多いと思いますので、工数見積もりの見直しもセットで行うようにするのが良いと思います。この見直しを行わないと、せっかく立てた再発防止策も結局工数不足で実施できない、といった事態に陥る可能性があります。
おわりに
このコラムはもともと自分の備忘もかねての気づきメモを社内SNSで発信していたものが原型になっています。その後受入テスト関連でたびたび相談をもらうことがあり、受入テストについて知りたいという方が他にもいるかも知れないと思いコラム化に至りました。受入テスト関連で悩む方のヒントになれば幸いです。
