オフショア開発の品質管理はどう行う？QA体制とテストの進め方

オフショア開発の品質管理とは？

オフショア開発の品質管理とは、要件定義から保守運用までの各工程で品質基準を定め、その基準を満たしているかを確認しながら開発を進める活動です。テストの合否だけでなく、要件や設計の段階での認識合わせまで含めて考えます。

品質はテスト工程だけで決まるものではありません。要件定義・設計・テストの3層それぞれに確認の場を設けることが、拠点が離れた開発では特に重要です。

品質管理と品質保証（QA）の違い

品質管理は、品質目標の設定、進捗と不具合の管理、改善までを含む広い活動です。品質保証（QA）は、その中でも定めた基準を満たしているかを確認する役割を指します。開発チーム内で行うテストと、開発チームとは別の立場で行う確認を分けておくと、見落としに気づきやすくなります。

オフショア開発で品質がぶれやすい要因

拠点が離れていると、要件の解釈、仕様の認識、テストの判定基準がずれやすくなります。日本語の要件定義書の表現が曖昧なまま設計に進むと、後の工程での手戻りが大きくなります。発注側の受け入れ基準が開発側に共有されていなければ、テストは通ったのに業務では使えない、という状態も起こります。

オフショア開発のQA体制はどうつくる？

発注側は品質基準の合意と受け入れテストの実施を、開発側はレビューとテストの実行を担う形が基本です。どちらが何を決め、何を確認するかを工程ごとに定めておくと、後工程での認識のずれを抑えられます。

表の左の列は「決める・判断する」役割、右の列は「作る・確かめる」役割です。どちらか一方に偏ると、判定基準のずれに気づくのが遅れます。

発注側と開発側の役割分担

発注側の中心は、品質基準の合意、受け入れ基準の承認、受け入れテストの実施です。開発側は、レビュー、単体テストからシステムテストまでの実施、不具合管理、テスト結果の共有を担います。テストの合否を誰が決めるかを先に定めておくことが、役割分担の出発点になります。

BrSE（ブリッジSE）とQAリードの役割

BrSE（ブリッジSE）は、業務要件と仕様の間に入り、認識合わせを担います。QAリードはテスト計画と判定基準を管理し、テスト結果をまとめて報告します。この2つの役割を分けておくと、仕様の確認と品質の確認を並行して進められます。

開発チームとは別の立場でテストを確認する体制があるかどうかも、発注側が確認しておきたい項目です。当社では、ソフトウェア開発でMVP（実用最小限の製品）からエンタープライズまでの開発を、QA／テストで手動テストから自動化までを対象としています。

テストはどの工程で何を行う？

テストは目的の異なる工程に分けて進めます。前の工程で見つけるべき不具合を後ろに流さないことが、手戻りを小さくするポイントです。

1. 単体テスト：関数やクラス単位で、入出力と例外処理を確認する
2. 結合テスト：モジュール間の連携、APIの入出力、データの整合性を確認する
3. システムテスト：業務シナリオに沿って、画面からデータベースまで通しで確認する
4. 受け入れテスト（UAT）：発注側の環境で、実際の業務手順に沿って確認する
5. 回帰テスト：修正後に既存機能が壊れていないかを確認する

単体テスト・結合テスト・システムテストの役割

単体テストは作り手が実施し、不具合を早期に見つける役割を持ちます。結合テストはインターフェースのずれを、システムテストは業務シナリオの通し確認を担います。同じ「テスト」でも、見る対象と責任者が異なります。

受け入れテスト（UAT）の進め方

受け入れテストは、発注側の環境で業務シナリオに沿って実施します。合否の判定基準、確認するシナリオ、不具合の重大度の定義を着手前に合意しておくと、結果の解釈で迷いません。修正と再テストの範囲も、あらかじめ決めておきます。

テスト自動化はどこまで進める？

テスト自動化は、繰り返し実行する回帰テストのように、効果が出やすい範囲から始めます。すべてを自動化しようとすると、テストコードの保守に工数がかかります。手動テストは探索的な確認や画面の使いやすさの確認、自動テストは毎回同じ手順を繰り返す確認、という役割分担で考えると、対象を絞り込めます。

品質を保つために発注側が確認すべきことは？

見積もりの中身、レビュー体制、テスト計画、報告の頻度を、プロジェクトの立ち上げ時に確認しておきます。次の項目をチェックリストとして使うと、抜け漏れを防げます。

• 要件定義の合意：仕様の確定手順と変更時の扱いが決まっているか
• レビュー体制：設計レビューを誰が行い、指摘をどう記録するか
• テスト計画と判定基準：合否の基準とテスト範囲が文書化されているか
• 不具合管理：重大度の定義と、修正・再テストの範囲が決まっているか
• 進捗とテスト結果の共有：定例の頻度とレポートの形式が決まっているか
• 保守運用への引き継ぎ：環境、ドキュメント、テスト資産が引き継がれるか

見積もりとテスト工数の関係

見積もりに、レビュー工数とテスト工数が含まれているかを確認します。テストを開発の後ろに付く作業として扱うと、工数が足りずに確認が浅くなります。テスト設計をどの工程で行うかも、あわせて確認しておきます。

ドキュメントとレポートの確認項目

テスト計画書、テスト結果レポート、不具合一覧の3つは、定例で継続的に共有される形が望ましいです。レポートの粒度は、発注側が受け入れの判断に使えるかどうかで決めます。セキュリティ面の確認項目は、IPA（情報処理推進機構）が公開している資料を参考にすると、観点の抜けを減らせます。

オフショア開発の品質管理はどう進める？

立ち上げ期に決めた基準を、運用期に定期的に見直す流れで進めます。次の順序で組み立てると、体制を整えやすくなります。

1. 品質基準を決める：品質目標、受け入れ基準、重大度の定義を合意する
2. テスト方針を決める：工程ごとのテスト範囲と、誰が実施するかを決める
3. 報告ルールを決める：定例の頻度、レポートの形式、エスカレーションの経路を決める
4. テスト環境を整える：発注側の環境で受け入れテストができる状態にする
5. 実施と振り返り：テスト結果と不具合の傾向を定例で確認する
6. 基準を見直す：傾向に応じてテスト範囲と判定基準を更新する

立ち上げ期に決めること

立ち上げ期は、品質基準、テスト方針、報告ルール、テスト環境の扱いの4点を決めます。決めた内容を文書に残しておくと、担当者が変わっても判断がぶれにくくなります。ベトナムの開発事情については、JETRO（日本貿易振興機構）が公開する情報も参考になります。

運用フェーズでの見直し

運用期は、不具合の発生傾向を定例で振り返り、テスト範囲と判定基準を見直します。同じ種類の不具合が繰り返す場合は、テストの観点ではなく設計や要件定義の側に原因があることが多いです。品質・情報セキュリティのプロセスについては、ISO取得に向けて整備中です。

まとめ：品質管理体制はどこで見極める？

品質管理体制は、テスト計画を誰が作るか、結果をどう共有するか、受け入れテストをどう進めるかの3点で見極められます。体制図よりも、実際に使われるテスト計画書と結果レポートを見たほうが判断しやすくなります。

当社は2020年7月にベトナム・ハノイで設立し、20名以上の体制で100件以上のプロジェクトを手がけてきました。品質管理体制のつくり方や発注側の確認項目の整理について相談したい場合は、お問い合わせからご相談ください。