ユーザー受け入れテストについて学ぶ

Cameron: 皆さん、こんにちは。Cameron Johnson と申します。Trailhead のリードコンテンツライターをしています。今日は、ビジネスアナリストのエキスパートである Derny にお話を伺っていきます。Dernie、あなたについて教えてください。Salesforce ではどのような仕事をされていますか?

Dernie: こんにちは。Dernie Hashemzadeh と申します。私は Salesforce で、ビジネス分析のプロフェッショナルで構成されるチームを率いています。私たちの仕事、つまり BA チームのメンバーの仕事は、簡単に言えば、企業とテクノロジーチームの間の調整役です。BA としての主な役割は、事実を明確にし、人とテクノロジーを結び付け、販売組織がテクノロジーソリューションを実装できるように導くことです。

Cameron: 素晴らしいですね。では、あなたは Salesforce のビジネスアナリスト、Salesforce 社内の BA ということですね?

Dernie: そうです。

Cameron: 今日私が Dernie にお話を伺っているのは、ユーザー受け入れテスト (UAT) の主なトピックについて説明するためです。長くて言いにくいので頭字語である UAT を使っていこうと思いますが、今日の話の目的を紹介します。まず、UAT とは何か? BA (ビジネスアナリスト) は UAT にどう関わっているのか? UAT がプロジェクトの成功にとって重要なのはなぜか? その後で、Dernie にヒントやコツ、ベストプラクティスを紹介していただこうと思います。では、皆さんと Dernie の準備ができているなら、最初の質問に行きましょう。UAT とは何ですか?

Dernie: User Acceptance Testing (ユーザー受け入れテスト) を表す頭字語です。率直に言えば、稼働開始前の最後のフェーズです。通常は、プロジェクトまたは機能強化がテクノロジーチームによって徹底的にテストされた後、Sandbox で UAT が行われます。つまり、品質保証、品質エンジニアリングがあって、そのフェーズに合格して UAT へと進みます。実際には、本番リリース前の承認のために、エンドユーザーがプロジェクトに対して実施するテストです。テストにはさまざまなステークホルダーを含めることができます。たとえば、ビジネスのステークホルダー、エンドユーザー、BA や IT チームを含めることもできます。通常、テストにはテストケースが必要です。その結果は合格または不合格のいずれかになります。先ほども言いましたが、UAT の全体的な目標は、最初に要求された機能が実際に提供されていることを確認することです。また、システムとツールがビジネスでの使用に十分であることを証明することでもあります。

Cameron: 合格か不合格というのは、文字どおりプロジェクトの稼働を開始できるかできないかという意味ですね。つまり決行か中止か。

Dernie: はい、そのとおりです。ですから、稼働開始前の最後のチャンスと考え、しっかりと精査します。

Cameron: わかりました。ところで、具体的には何が必要なのでしょうか? たくさんのテストを行うようですが、厳密には何が必要ですか? UAT を実施するためにどのようなことを行う必要がありますか?

Dernie: 準備ですね。とにかく山ほどの準備があります。特に BA の立場から見て UAT で肝心なのは、テストケースの実行を計画することです。誰がやるのか? タイムラインの確認。何をテストするのか? 実際のところ、UAT の多くは正式に自分で操作してテストしてみることです。その時点までは、特にビジネスの観点から、そして Salesforce BA の観点からも、キーボードやマウスを使ってシステムをテストしていません。UAT は、BA とエンドユーザーやその他のビジネスのステークホルダーが新しいシステムをテストする場所と言えます。最後に、UAT で重要なのは、正式な UAT サインオフを得るという形式です。先ほど言われたように、「青信号」、「合格」、「準備完了」ということですね。

Cameron: わかりました。ビジネスアナリストは UAT に深く関わっているとおっしゃいましたが、ほとんどの場合、UAT における BA の役割は何ですか?

Dernie: 良い質問です。最も単純に言えば、Salesforce BA は、先ほども言いましたが、企業とテクノロジーチームの間の調整役だと思います。BA の目標は、テクノロジープロジェクトの明確さと品質を追求することです。品質追求の重要な部分が、プロジェクトの UAT フェーズです。提供される製品または拡張機能が、企業が期待している品質と期待を実際に満たしていることを確認することです。

Cameron: なるほど。あなたの経験では、BA がいつも UAT を担当するのですか?

Dernie: チーム、プロジェクト、また会社によって違うと思いますので、一概には言えませんが、私のチームが Salesforce でどのようなことをしているかについてお話しすることはできます。UAT フェーズでの品質追求の例として、私たちが担当する重要な仕事に UAT テスターの選定があります。また、UAT テスターにもさまざまなタイプがあります。通常、BA は UAT を主導し、調整します。多くの場合、BA が、定義されたテスター、承認者を含め、UAT テストスクリプトを作成します。最終ステップとして、BA はビジネスのステークホルダーからテストスクリプトがすべての期待を満たしているという正式なサインオフを書面で受け取ります。データがシステムに設定済みで、稼働準備ができていることを BA が検証することも少なくありません。私のチームの BA は大体、プロジェクトに関わる主なキーペルソナを使用して主要な機能をテストしています。最後のステップは、UAT を調整することです。最終ステップでは、稼働に向けてリリースする前に、書面による正式なサインオフがあることを確認します。

Cameron: わかりました。たくさんの準備を行うけれども、先ほどおっしゃっていたように、BA も実際に操作してテストをするということですね。

Dernie: はい、そうです。

Cameron: あなたは明らかに Salesforce エコシステムの観点でお話しされていますが、UAT は Salesforce 独自のものではありませんよね? 理論的には、Salesforce とは何の関係もない製品やプロジェクトを立ち上げたとしても UAT が適用されますから。

Dernie: はい、そのとおりです。

Cameron: 一応確認のためお聞きしました。

Dernie: 同じことですね。つまり同じ考え方ということです。Salesforce プラットフォームであろうと、テクノロジーのように特定のものであろうとなかろうと、UAT を行う必要がある理由は、企業が「はい、これは正常に機能します。稼働準備ができました」と言う最後のステップだからです。

Cameron: 汎用的ということですね。Salesforce 独自のものではない。わかりました。では、なぜ BA が関わるべきなのでしょうか? 前の質問を蒸し返すようですが、膨大な準備がありますよね? BA が関わらなかった場合、どのような問題が起きますか?

Dernie: まず、質問にお答えすると、BA の役割 が UAT にとって不可欠である理由は、開発中のシステムの機能と意図を BA が理解しているからです。プロジェクトプロセスを遡れば、BA がビジネス要件定義の初期の段階で重要な役割を果たしていることがわかります。したがって、プロジェクトライフサイクルの UAT フェーズの時点で、BA はすでにプロジェクトの各担当者と関係を築いています。また、BA はもともと几帳面であるため、潜在的な問題を見つける助けにもなります。

Cameron: なるほど。もし誰かが UAT だけを担当していたら、全体像を把握していないかもしれない。UAT にまで至る、それ以前のミーティングに参加していなかったから、ということですね。とても納得できますね。

Dernie: ええ、そのとおりです。理想的な状態は、BA がプロジェクトの開始時から参加し、プロジェクトチームと共にすべての要件定義とエンゲージメントを行うことです。

Cameron: 完全に理にかなっていますね。その他のベストプラクティスにはどのようなものがありますか? あなたは UAT と BAS で豊富な経験をお持ちですよね。他にもさまざまなことを経験されていると思います。Salesforce で行っているベストプラクティスとして、初めて UAT を行う BA や、UAT について学んでいる方たちに、どのようなことをお勧めしますか?

Dernie: そうですね。役に立つヒントをいくつか紹介します。まず最も重要なのは準備だと思います。入念な準備をすること、それが UAT の成功につながると思います。また、リソースの選定をはじめ、UAT 準備の基本的なチェックリストで検討すべき項目について大まかに説明すれば、Salesforce の私のチームでは、UAT 用の Slack チャネルを作成し、そこで状況更新を行う頻度を決めて設定します。通常は私たち BA が UAT のスケジュールを作成します。たとえば、特定のプロジェクトについて考えます。キックオフが必要か? 毎日のミーティング、状況更新、トリアージを計画する必要があるか? 次にプロセスを確立します。たとえば、バグの報告や質問をするためのプロセス。どのようなプロセスがあるか? それからテストケースを作成します。カバーするテストシナリオを実際に作成し、テストの手順を詳しく説明します。最後に、通常は UAT テストを行う実際の Sandbox の検証ポイントがあります。そこで確認するのは、テストデータの準備ができているか? 使用する Sandbox の特定。それから、UAT の最後に行う総括ミーティングなどのスケジュールについて考えます。正式に完了とするのか? それについてどう準備するか? 準備することが山積みです。

Cameron: 私たちが考えていないバックエンドでの作業がたくさんあるんですね。でも誰かが確実にやらなければならない。

Dernie: はい、そのとおりです。

Cameron: では、最後にいい話で締めくくりましょう。何かためになる経験談を教えてください。差し支えない程度で結構です。UAT が適切に計画されていなかった経験はありますか? もちろん、担当者はあなたではありせん。あなたが担当していればうまくいったでしょうから。UAT がうまくいかなかったという話を聞いたことがありますか? その場合はどうなりましたか?

Dernie: はい、あります。問題が起きると当然のことですがストレスを感じます。けれども、認識すべき重要な点は、それが UAT の目的であるということです。先ほども言いましたが、目的はシステムがエンドユーザーの期待どおりに機能することを確かめることです。そのときにギャップが明らかになることがあります。私自身も UAT が十分に堅牢ではない状況を経験したことがあります。たとえば、主要なテストケースが欠けていたことがあります。テスターが適格ではなかった可能性があります。テスターの役割を本当に理解していなかったか、その分野の知識があまりない人を私たちが選んでしまったのかもしれません。一例として挙げるプロジェクトは、私が参加していた大きなプロジェクトでした。テストスクリプトは現実を反映したものではありませんでした。また、実際の UAT テスターは、その分野のエキスパートでもエンドユーザーでもありませんでした。最終的にどうなったかというと、お客様である企業が UAT をサインオフしました。ところが、システムが本番で稼働すると、大きなギャップが見つかりました。この状況では、プロジェクトのプロセス、特にプロジェクト全体の早い段階で他の問題もありました。もし、UAT でギャップが明らかになっていれば、コードが本番環境にプッシュされず、多くのお金と時間を節約できたでしょう。重要なポイントは、UAT で問題が発生したとしても、しっかりと計画されていれば、それは良いことだと思います。

Cameron: なるほど。プロジェクトにとっては、稼働できないのは悪いことだと思うだろうけれども、稼働する前に見つけたから実際には良いことだというわけですね。あなたの経験談の場合は稼働する前に見つけられなかったようですね。それほどうまくいかなかった。興味深いですね。では、今日の目的をもう一度挙げながら、話した内容をまとめていこうと思います。まず、UAT とは何か、BA がどのように関わっているかについて説明していだきました。要約すると、ほとんどの場合、ビジネスアナリストは最初のステップから最後のステップまで関わっているので、UAT はビジネスアナリストによって主導されるということでした。UAT がプロジェクトの成功にとって重要なのはなぜか? これは最後の経験談でよく理解できたと思います。また、有益なベストプラクティスもたくさん紹介していだきました。Dernie、今日はお時間をいただきありがとうございました。感謝いたします。UAT について実に多くのことを学びました。

Dernie: こちらこそありがとうございました。今日はお話ができて良かったです。

Cameron: さようなら。

Dernie: さようなら。