①開発のブラックボックス化
オフショア開発においては日本と海外のオフショア拠点と地理的・時間的に隔たった空間でそれぞれの業務を行うため、どうしても開発の実態が日本の発注側から見えにくいという課題があります。
加えて国をまたいだ言語や文化、商習慣などのギャップにより、さらに輪をかけて状況の把握を難しくしています。
開発がブラックボックス化することによって「開発の実際の進捗が見えない」「品質の状態がわからない」といった事態が発生し、ソフトウェアテストを実施する後工程においてはじめて問題が露見。
開発が完了していると認識していた機能が実は未完成だった、といった開発スケジュールの遅延や、品質が求める水準に達していないことが発覚し、手戻りやそれに伴うコスト超過が発生してしまう、というのはオフショア開発におけるありがちな失敗事例の1つです。
またオフショア開発会社にソフトウェアテストまで含めて一括で発注をしているケースも多く、その場合開発だけでなくテストまでもがブラックボックス化し、最悪の場合テストの最終工程である発注側の受け入れテストにおいて全ての問題が発覚することもあります。
問題の発覚が遅れれば遅れるほど手戻りや修正コストが大きくなるため、可能な限りブラックボックス化を防ぎ、少しでも早い段階で事態を正確に把握して手を打つことが、オフショア開発プロジェクトにおいては特に重要となります。
②求める品質レベルとの乖離が発生しやすい
オフショア開発においては、基本的に日本側の要件をオフショア開発先の言語に翻訳し、それをもとに現地で開発を進めるという形を取ります。
日本側で作成したドキュメント自体に記載の曖昧さやロジックの矛盾が含まれていたり、あるいは翻訳の過程で誤った内容に変換されてしまうこともあり、それらが原因となって仕様自体に欠陥が生じることがあります。
仕様バグの発生はそのまま実装工程での不具合の作りこみにつながり、品質水準の低下原因の1つとなります。
また品質に対する意識の違いや、仕様に対する認識齟齬なども品質に影響を与える要因となります。
いずれの場合においても、早期に品質のレベルを把握した上で、求めるレベルとのギャップがあれば品質を引き上げるアプローチをとることが重要です。
これらのオフショア開発課題を解決する上で有効なのが、オフショアでのソフトウェアテストです。
より正確に言えば、「オフショア開発と同じ国にテストチームを組織し、第三者検証を行う」ということです。
なぜそれが有効なのか、その理由について以下で紹介いたします。