システム開発とUAT

UATって難しい

　今、（弊社的には）そこそこの案件のUATをやっています。初めてPLを任せた部下が取り仕切っていますが、ずいぶん苦労しているのを見ていると、やっぱりシステム開発にはUATに入ってみないと気づかないことがいろいろあるなあと思っています。

UATとは - IT用語辞典

今まで見たUATあるある
・情シスとユーザの役割分担でもめる
・ベンダ側の支援範囲を詰められておらず必要な支援が受けられない
・テスト要員確保がされていない
・ユーザがテストしようとしない
・テスト中に「こう動くはず」という謎理論（要求）が登場

定義されていない謎仕様が登場する

　機能要求にもユースケースにも要件定義にも基本設計にも登場していない仕様が登場するの、UATあるあるです。よく聞くと、情シスも加担していたりします。
　「こうだからこう動くはずだ」「この（特殊な商品やサービスに対する）考慮は当然されているはず！」といった説明を聞いていると、本当にあるんじゃないか？とか、思わず説得されそうになります（笑）。
　たまに、超絶気の利いた担当者さんが対応されていたりしますが、それを当然として受け取ってはいけませんね。設計書にある内容がすべてです。

マスタを投入して業務通りに動かしてみないと最終的にはわからない

　もう一つよくあるのは

「要求をちゃんと伝えたのだから、正しく実装されているはずです」

　あるあるですね。以前はUATの話をするとユーザからはよくこれを言われていました。で、「正しく実装されるかを確認するのは情シスの役目なんじゃないですか？」と続きます。

　しかし、業務システムにおいて、「要求をちゃんと伝えた」というのはあくまでユーザ側の「想い」であって、ちゃんと伝わっているかどうかは、究極的には、想定しているマスタをユーザ側で全部作り、その業務に携わっている人が実際の業務やサービスを想定しながら触ってみないとわかりません。これはもう、絶対にそうです。

　銀行などの大規模な開発であれば開発時にここまで準備してベンダを巻き込んでテストされています。でも、中小の会社でそこまでやる余裕は到底ありませんので、どうしてもUATで気づくことが多くなるんですよね。

　こういった事情があるので、UATはあくまでユーザ側が主体となるべきで、情シスは業務シナリオに沿ったテストでは管理やサポートにまわるべきなのですが、なかなかこの概念はユーザには理解されづらいですね。。。

ズレや認識齟齬は避けようがない

　そもそも論の話になってしまうのですが、まず、頭の中にあることをすべて言語化するのがそもそも無理です。要求を出して、ユースケースつくって、要件定義で要求を要件化し、基本設計でＩＦまで確認しても、そもそもユーザ同士でも細かいところではすりあっていない部分があるものです。

　さらに開発は複数でやることが多いので、設計者と開発者の間でもずれが出たりします。試験中に上がってきたチケットのやり取りをきっかけに設計者と開発者で言い争いが始まったこともあります。なぜ私がベンダー内の仲裁役になってるんだろうとか思ったことも。

リリース直前に致命的な問題に気づくあるある

　不具合やちょっとした認識齟齬が発生すること自体は、試験をきちんとやっていることの証でもあるので、恐れることはありません。扱いや納期を決めて、適切に取り扱っていけばよい。
　問題は、取り返せないタイミングでリリースを延期せざるを得ないレベルの致命的な問題が発覚してしまうことです。こうなると炎上します。

　基本的な考え方として「不具合だからリリースまでに死んでも直せ！」といった考えを捨てることです。多くのユーザは、何も言わなければ「要求通りじゃないんだから伝えればすぐ直してくれる」と思ってます。

　設計までは、要求を出せばそれを仕様にしてくれました。でもテストフェーズは、不具合であっても、対応するかどうかというのは判断が必要になるという考え方が必要になります。
　この考え方を事前に握っておくだけで、進行はずいぶん楽になります。そのうえで、大事なことは早め早めにテストするように、試験計画段階でユーザ側の体制も含めて握っておくことでリスクはずいぶん低減されます。

　と、そこまでやっても、担当者レベルで「そんな時間あるわけないでしょ」「いつテストできるか？そんなの、その日になってみないとわかんないよ」なんて言われるのが業務システムの怖いところ。。。
　こういったときには、とにかく状況を可視化させて、ユーザ側のリーダーに危機意識を持ってもらうことしかないんだろうなあと思っています。