1. オフショア開発の際の受け入れテスト（UAT）とは
オフショア開発の受け入れテストとは、納品されたシステムが正常に動くかテストをする行為です。受け入れテストは、UAT（User Acceptance Test）や検収テスト・承認テストなどとも呼ばれます。
受け入れテストは基本的に依頼する側が行うのが一般的です。ただし、受け入れテストを外部に委託する方法もあります。また、受け入れテストが行われるタイミングは、ソフトウェアテストの最後に行われるのが一般的です。
受け入れテストはあくまで依頼者側が受入れをするかどうかのテストであるため、システムが正常に動くかどうかの確認だけでなく、依頼したシステムを作るのにかかった期間や費用・ミスがあった際の対応など、総合的に判断する必要があります。
2. オフショア開発で問題が発生する原因はなにか
オフショア開発を行うにあたって発生しやすい原因は下記のとおりです。
2-1. 言語の違い
オフショア開発は国外に依頼するため、言語の違いでトラブルに発展しやすいです。国によっては、日本語だけでなく英語も通じないケースもあるでしょう。
また、中国やインドなどでは地域によって使っている言語も異なる場合があるため、言語によるすれ違いが起きやすいと言えます。
ベトナムやフィリピンなど親日家が多く、日本語が理解できる場合であってもトラブルに発展する可能性があるため注意が必要です。日本独自の和製英語や略語を無意識に使用してしまうと、相手に意味が通じない可能性があります。
また、二重否定といわれる日本語の言い回しも、意味が間違って伝わる可能性が高いです。例えば、「問題ないとは言えない」という文には「問題ない」と「言えない」という否定文が2度使われているため、問題があるのかないのか外国人には理解できない場合が多いです。
2-2. 文化・国民性の違い
文化や国民性の違いもトラブルの原因になりやすいです。特に日本人は真面目で勤勉な国民性があるため、日本人の基準で考えていると不満やイライラが募ってしまうケースも少なくありません。
特に文化の違いとして多くあげられるのが、日本人と比較して自分や家族の時間を大切にしている点です。たとえミスがあって早急に対応が必要になる場合であっても、家族との予定や休日だからという理由で対応が遅くなる場合もあります。
また、宗教観の違いも大きく異なるケースが多いです。例えば、「〇〇時にミーティングをしたい」と伝えても「お祈りの時間なので無理です」といった返答がある可能性もあります。
2-3. 距離的問題による管理不足
物理的な距離が遠いと、オンラインであってもすれ違いが起きる可能性が高くなります。なぜなら距離が遠くなるほど時差が発生するためです。時差があると、お互いがコミュニケーションが取れる時間が限られてしまうため、管理不足の原因になるでしょう。
たとえ時差が3時間しかないとしても、8時間労働だとして、1日のうち5時間しかお互いにコミュニケーションが確保できる時間が取れません。また、上述したように日本人と比較して自分の時間を優先する傾向があるため、ランチ時間や退勤時間ぎりぎりの場合は、対応してもらえない可能性もあるでしょう。
3. オフショア開発における受け入れテスト（UAT）の目的・重要性は？
受け入れテストの目的は、納品されたシステムが問題ない品質であるか確かめるために行われます。具体的には、「求めている要件が満たされているか」「使用した際に問題は起きないか」「実際の利用環境であっても快適に稼働するか」などがあげられます。
また、運用テストだけでなく、中長期的に依頼可能かどうかを見極めるためにも行われます。中長期的に依頼するためには、システムの品質だけでなく必要な費用やかかった時間、修正があった際の対応力やコミュニケーションに問題がないか、などが調査ポイントになるでしょう。
受け入れテストを疎かにしてしまうと、さまざまなトラブルに発展してしまう可能性が高くなります。実際に受け入れテストを怠ったばかりに大きなトラブルに発展してしまった例が、「厚生労働省」がリリースしたコロナウイルス陽性者との接触を確認するためのアプリ「COCOA」です。
COCOAはリリースからバグが続いており、正常に稼働するまで約4ヶ月間もかかってしまいました。原因は、厚生労働省が受け入れテストをしていなかったのが理由です。もちろん厚生労働省はITの専門家ではありませんし、状況的にもリリースを急ぎたかったのかもしれません。
しかし、結果的に使いにくいアプリをリリースしたことで、多くの税金と国民の信頼を失ってしまいました。もし、受け入れテストをしっかり行っていれば、大きな問題にはならなかったでしょう。このことからも受け入れテストはとても重要なプロセスだと言えます。
4. V字モデルでみる受け入れテストの解説
受け入れテストにおけるV字モデルとは、開発からリリースまでにおけるプロセスを開発工程とテスト工程に対比させるモデルのやり方です。V字の左側に開発工程を上から順番に記していき、右側に対応したテスト工程を示します。
V字の左右を比較すれば、実施されるテスト内容がどの工程を検証するのかを、視覚的に分かりやすくなる仕組みです。具体的なテスト内容を下記で解説します。
4-1. 単体テスト（ユニットテスト・コンポーネントテスト）
単体テストでは、独立しているプログラムをテストします。目的として、プログラムが正常に作動するかや、バグや不具合がないかを確かめるために行います。V字モデルの一番下に配置されるテストであり、一番基礎的なテスト内容だと言えます。
ユニットには「構成単位」という意味があり、コンポーネントには「部品や構成要素」という意味があるため、ユニットテストやコンポーネントテストとも呼ばれます。
4-2. 結合テスト
結合テストでは、完成したプログラム同士を組み合わせて、正常に動くかを検証するテストです。単体では正常に作動しても連動させた際に、不具合が発生してしまう可能性もあるからです。
特に、外部システムや社内システムと連携させた際に、不具合が起こりやすいです。外部のシステムと連動させる場合は、外部連動テストとも言います。
4-3. 総合テスト（システムテスト）
総合テストでは、全てのプログラムを組み合わせた完成品が正常に作動するかを確認するテストです。確認するデバイスも実際に用いられると予想されるデバイスで確認します。不具合やバグを見つける最終テストでもあるため、入念に行われるのが一般的です。
4-4. 受け入れテスト
総合テストをクリアしたシステムが、依頼した製品として十分に機能しているかを確認します。プログラムに問題がなくても、始めに依頼した要件を満たしていない可能性があるからです。また、今後の依頼先としての判断もこの段階で行います。
5. オフショア開発における受け入れテストの実施方法・テストの種類
受け入れテストの実施方法と種類を具体的に解説します。
5-1. 機能確認テスト
機能テストでは、納品されたシステムが正常に作動するかを確認します。例外処理やエラーの確認をするために、さまざまな検査がされるのが一般的です。また、前もってエラーが出る条件が分かっているのであれば、正しくエラーが表示されるかも確認する必要があります。
5-2. 疎通テスト
疎通テストでは、システム間の連携がスムーズに行われるかを確認します。レスポンスの早さやデータ通信の早さなど、処理時間に問題がないかが大切です。
特に処理速度が遅かったり、システム間の連携が遅いようであれば、後述する負荷テストも合わせて行うと、原因が解明できる可能性があります。
5-3. ユーザビリティテスト
実際に使用するユーザーを意識して、使用デバイスの操作感・サイト構築が利用しやすいかなどを確認するテストです。サイトやシステムを使用するうえで、有効さ・効率・満足度などを確認します。
5-4. 負荷テスト
負荷テストとは、システムに過度な負荷を与えた状態を確認するテストです。具体的には下記の内容を確認します。
■ パフォーマンステスト
想定される負荷の制限下において、どのくらいパフォーマンスが発揮できるかを確認します。
■ キャパシティテスト
どれくらいのアクセスやデータ使用量まで耐えられるかを確認します。
■ ストレステスト
想定以上の負荷を与えた際にどのような挙動をするか確認します。
■ ロングランテスト
長時間の稼働をした際にどのような挙動をするか確認します。
5-5. セキュリティテスト
システムの脆弱性や欠陥を探し出して、情報の漏洩やウイルス感染などが起こらないか確認します。特に、悪意のあるサイバー攻撃が行われた際の検証も必要です。
サイバー攻撃を受けた際にどのくらいの耐久力があるのか、攻撃された際にどのくらいの被害が予測されるのかを知っておくと、改善や対策が立てやすくなります。
6. オフショア開発における国内でのテスト内容
オフショア開発を利用した際に、国内で行うテスト内容は下記のとおりです。
6-1. 受け入れテスト
上述した受け入れテストです。社内で行うのも良いですが、発注側が慣れていない場合は第三者に外注して、受け入れテスト自体を外注するのも有効です。受け入れテストに不備があってシステムが上手く作動しなかった場合は、予想以上のコストがかかる可能性があるためです。
予算は必要になりますが、第三者の意見でフラットな感覚でテストをしてもらえるでしょう。ただし、オフショア開発を依頼している会社に受け入れテストを依頼してしまうと、ブラックボックス化してしまうため、必ず違う会社に依頼しましょう。
6-2. オフショアテストでの積み残し分のテスト
積み残しとはバックログとも言われ、手が回らなかったシステムや案件を指します。依頼内容に足りない内容や、後からつけ足したシステムのテストをします。
6-3. セキュリティテスト
ウイルスやハッカー攻撃などからシステムを守れるかを確認します。また、システム内に情報を漏洩させるプログラムが混入されていないかなどを確認します。
7. オフショア開発における受け入れテストで重視な点とは
オフショア開発を利用するうえで、受け入れテストの重要なポイントは下記のとおりです。
7-1. 重要な項目を優先的にテストする
受け入れテストでは、重要な項目から確認しましょう。依頼する内容によって異なりますが、システムが正常に動くかはもちろん、上述したテスト方法を参考に、優先順位や重要度が高い項目を重点的にテストするのがおすすめです。
7-2. 仕様変更部分を優先的にテストする
依頼の途中に仕様変更があった場合や、仕様変更部分を依頼した際は優先的にテストしましょう。また、仕様を変更したことでバージョンが違っていて上手く作動しないケースも多いです。
単体では問題なく稼働していたシステムも、組み合わせた際に問題や不具合が起きる可能性が高いからです。
7-3. 実際の環境化でテストする
実際に使用予定のデバイスやサーバーなど、使用環境を実際の使用状況に合わせてテストしてください。誤ってテスト用のバージョンをそのまま使ってしまったり、テスト用のプログラムのまま書き換え忘れてしまう可能性があるからです。
8. オフショア開発における受け入れテストの流れ
オフショア開発で受け入れテストを行う際は、下記の流れを参照してください。
8-1. 全体の計画
受け入れテストを行う目的や実施方法、実施スケジュールなど全体の計画を立てます。一般的には開発者側がテスト計画書を作成します。
計画段階でオフショア開発の利用目的や要件定理・開発モデルなども事前に決めておくとスムーズに計画が進みます。特に、「どのようなプログラムがいつまでに必要なのか」を曖昧なまま進めてしまうと、実際に開発に取り組んだ際のミスや遅れにつながるでしょう。
開発モデルについても「ウォーターフォール型」と「アジャイル開発型」の2種類があり、開発目的に合わせて選定してください。アジャイル開発であれば、ユーザーの意見を取り入れながら開発できるため、仕様変更が多い案件におすすめです。
8-2. テスト環境の構築
計画書を元にしてテストで使用するデバイスやアカウントを準備します。また、テストの参加者にはシステムを利用したことのある人や、開発業務を担当している人が参加します。
不具合が起きないか確認するテストであるため、システムやシステムの目的を理解している人でテストをしてください。
8-3. テストの実施
実際にテストを実施します。テスト内容を項目にして管理表を作っておくとスムーズに作業が進みます。トラブルが発覚した際はその場で改善するか、時間がかかるようであれば後日改めて再テストを行いましょう。
9. オフショア開発における品質担保に必要な注意点
オフショア開発を利用するうえで、品質を確保するのに大切なポイントは下記の通りです。
9-1. 仕様書の精度を向上させる
精度の高い仕様書を作りましょう。依頼相手は外国人であるため、日本人の感覚とはズレが生じやすくなります。「これくらいはやってくれるだろう」「ここまでやるのが普通」などといった価値観は文化の違いによって通じない可能性があります。
そのため、仕様書は具体的に細かく作るように意識して、仕様書自体の精度を向上させる必要があります。
9-2. 要件定義を明確にする
要件や定義は明確にしましょう。曖昧な言葉づかいや言い回しが遠回りだと、正しく条件や内容が伝わりません。依頼先のスタッフは外国人であるため、曖昧だったり言い回しが遠いと、相手に正しく伝わらないからです。
特に必須条件であったり納期などは、「だいたい」や「これ位」といった言葉は使用しないで、明確に伝えましょう。
9-3. コミュニケーションを密に取る
コミュニケーションはこまめに取ってください。コミュニケーションが不足していると管理不足になりやすく、現地でどのように開発が行われているか、どこまで開発が進んでいるかなど不透明な状態でプロジェクトが進んでしまいます。
特に言語や文化が違い、時差もある海外とのコミュニケーションは気が引けてしまうとは思いますが、積極的にコミュニケーションを取っていくほうがオフショア開発は上手くいきます。
10. まとめ
オフショア開発を成功させるためには、受け入れテストを実施することが鍵になります。受け入れテストを疎かにしてしまうと、システムが正常に動かなかったり、リリースができなかったりする可能性が出てきてしまいます。
受け入れテストには多くのポイントややり方があるため、上述した内容を踏まえてミスのないようにテストしてください。また、文化や言語が違うため、ある程度相手に合わせる必要性があり、こまめなコミュニケーションも怠らないようにしましょう。
「オルグローラボ」では、ベトナムへのオフショア開発をサポートしています。ベトナムは近年国をあげてIT技術に力を入れているため、高い技術力があり低価格で依頼可能です。オルグローラボをご利用頂ければ、ベトナムへのオフショア開発の始め方をサポートさせて頂きます。
