海外開発で品質の認識がずれる原因を、言語や国民性だけに求めることはできません。「正常に動くこと」の範囲、誰がどのテストを行うか、何をもって完了とするかが決まっていなければ、同じオフィスにいるチームでも判断は分かれます。

品質管理で先にそろえたいのは、細かな報告書の様式ではありません。利用者に必要な結果、守るべき品質、テストの担当、合否を判断する証拠、未解決の不具合を誰が承認するかです。海外の開発会社や海外拠点と着手する前に、この五点を一つの表にまとめることが出発点になります。

海外開発で品質の認識がずれる原因は何か

「日本側が期待する品質に届かない」という言い方だけでは、海外側は修正の対象を特定できません。機能が仕様どおり動くことを指すのか、反応にかかる時間、障害時の復旧、アクセス制御、保守しやすさまで含むのかで、設計とテストは変わります。

品質管理の出発点は、国ごとの仕事観を説明することではなく、対象システムに必要な結果を双方が判定できる基準として書き表すことです。「高品質」「十分にテスト済み」といった形容ではなく、「どの利用場面で」「何が起きず」「どの測定値または証跡で」「誰が合格とするか」を記します。

納期・機能・品質を比べる優先順位

品質だけを切り離して考えると、すべての不具合を解消するまで出せない計画になりがちです。一方、期限だけを優先すると、重要な利用経路やセキュリティ上の懸念を残したままリリースしかねません。そこで、利用者や事業への影響を基準に、必ず満たす条件と、承認を得て次回へ持ち越せる条件を分けます。

たとえば、決済や権限管理の不具合はリリースを止める一方、表示上の軽微なずれは対象端末と回避策を記録したうえで次回へ回す、といった決め方です。分類名よりも、事業への影響、発生条件、回避策、修正期限、承認者が記録されていることが重要です。

テスト可能な品質要求の作り方

国際標準化機構（ISO）と国際電気標準会議（IEC）の共同規格「ISO/IEC 25010:2023」は、情報通信技術の製品とソフトウェア製品の品質モデルを定義しています。同規格の概要では、このモデルを要求の定義、テスト目標、品質を管理する基準、受入条件の設定に使えるとしています。品質を一つの点数にせず、対象システムで必要な特性へ分ける土台になります。

参考：ISO公式「Product quality model」

性能・信頼性を測る利用場面と条件

機能要件は「注文を登録できる」のように書きやすい一方、性能や信頼性は後回しになりやすい領域です。しかし、同時利用数、応答時間、復旧に許される時間、利用端末、権限の境界が決まらなければ、テスト担当者は合否を判断できません。

非機能要件は、数値を置けば完成するわけでもありません。「通常時は何人が使うか」「繁忙時はどの操作が増えるか」「停止した場合にどの業務が止まるか」を先に書き、その条件に対応する指標を決めます。測定環境と本番の差も記録します。試験環境で計測した時間を、そのまま本番の保証値として扱わないためです。

利用者の結果を基準にした受入条件

英国政府のService Manualは、受入条件を、サービスが利用者の必要を満たした結果を確認するチェックリストとして説明しています。実装の詳細だけでなく、利用者が目的を達成できたかを完了の中心に置く考え方です。

参考：英国政府 Service Manual「Writing user stories」

たとえば「カンマ区切り形式（CSV）の出力ボタンを実装した」では、文字コード、権限、対象とする期間、件数上限、失敗時の案内が不明です。「権限を持つ担当者が期間を指定し、必要な列を含むファイルを取得できる」「上限を超えた場合は理由と次の操作が表示される」まで決めれば、開発側と受入側が同じ結果を確認できます。

工程と意思決定を含むテスト責任の分担

「テストは海外側、受入は日本側」という二分だけでは足りません。テストを設計する人、環境とデータを用意する人、実行する人、失敗を分類する人、再試験を確認する人、リリースを承認する人を決めます。一人が複数を担っても構いませんが、責任の空白は残さないことが前提です。

実装チームが持つ単体・結合テストの責任

実装を担当するチームには、コードと同時に単体テストを用意し、外部サービスやデータベースとの結合点を確認する責任を置きます。日本側はテスト件数だけで評価せず、重要な分岐、異常系、権限違い、再実行時の挙動が含まれているかをレビューします。

提出する証跡も先に決めます。自動テストの結果、対象バージョン、実行日時、失敗したケース、再試験結果が一つの変更へひも付いていれば、時差があっても「どの状態を確認したのか」を追えます。画面のスクリーンショットだけで変更や環境を一意に追えない運用では、変更を識別する番号、実行ログ、どの環境で確認したかを併記し、画像は補助資料として扱います。

業務側が持つ受入テストのシナリオと承認

受入テストは、開発者が仕様どおりに作ったことをもう一度確かめる工程ではありません。業務で必要な結果、データ、権限、例外処理を、利用部門またはプロダクト責任者が確認する場です。ただし、契約、規制、セキュリティの責任者が別に定められている場合は、その権限表に従います。テスト実行を開発側が支援しても、業務上受け入れられるかの判断者を曖昧にしないことが重要です。

日本側が用意するのは、実際の業務に近いシナリオ、匿名化したテストデータ、承認者、合否を記録する場所です。海外側は環境準備、問題の切り分け、修正、再試験を担います。受入判定に必要な変更を識別する番号、実行ログ、検証した環境を各責任者が変更のたびに更新すれば、どの確認と承認が残っているかを一枚の表で追えます。更新されない表は待ち状態を解消しないため、記録を更新する担当と期限も決めます。

未解決の不具合を含むリリース承認

テスト担当者は事実を報告できますが、事業上のリスクを引き受ける決定まで自動的に担うわけではありません。未解決の不具合がある場合は、影響、発生条件、回避策、修正予定を整理し、契約上の権限表で指定された責任者がリリース可否を決めます。通常はプロダクトや業務の責任者が候補になりますが、規制対象やセキュリティ上の理由でリリースを止める条件がある場合は、指定された承認者を追加します。

重大度の基準も、件数だけでなく影響から決めます。一件でも利用者の個人データを誤表示するなら、公開を止める判断になり得ます。多数発生していても、内部の開発環境だけで再現し利用者へ影響しないものなら、別の優先順位になります。

テスト結果・不具合・文書・運用準備を含む完了条件

デジタル庁の「標準ガイドライン実践ガイドブック」は、工程終了条件を明確にしつつ、システムの特性とリスクに応じて設定する必要があるとしています。「テストケースをすべて消化していること」だけで終わらせず、その後の対応まで記す考え方です。

参考：デジタル庁 標準ガイドライン実践ガイドブック

テスト工程の開始条件と終了条件

テスト仕様のレビュー、環境、データ、担当者、接続先との調整が終わっていないまま試験へ入ると、製品の不具合と準備不足を区別できなくなります。開始条件には、対象バージョンの固定、必要なアカウント、テストデータ、外部連携先、障害時の連絡先を含めます。

開始時に条件を満たせない場合は、黙って進めず、対象外にする範囲と後で確認する日を決めます。これにより、進捗率だけが上がり、重要な試験が未実施のまま残る事態を防ぎます。

未解決の不具合を持ち越す条件

すべてのプロジェクトで同じ種類の欠陥ゼロを終了条件にすると、軽微な表示差までリリースを止めるか、数字を合わせるために分類を変える運用になりかねません。終了条件は、停止対象の欠陥がゼロであること、その他の欠陥には承認者、回避策、修正時期があること、と分けます。ただし、安全、規制、契約、個人情報に関する欠陥は持ち越せない場合があるため、対象システムの基準を優先します。

再発防止が必要な問題は、個別修正だけで閉じません。要件の不足、レビュー観点の欠落、自動テストの対象外、環境差など、どの工程へ戻すかを記録します。品質管理表は、欠陥件数を報告するためだけでなく、次の変更で同じ見落としを減らすために使います。

海外公式事例：GitLabのテスト責任とリリース判断

世界各地でリモート開発を行うGitLabは、公開Handbookで、各機能チームが単体、結合、エンドツーエンドを含むテストのライフサイクルを所有するとしています。共有のテスト基盤を支える部門はありますが、機能チームに代わって日々のテストを書く中央組織ではありません。リリース準備の判断も、担当チームが自動チェックの結果を使って行います。

同社は、コミット前後の自動確認、必須のコードレビューを含むマージリクエストのパイプライン、テストを組み込んだデプロイのパイプライン、デプロイ後の監視と検証を組み合わせています。海外側を「実装する人」、日本側を「最後に検査する人」と固定するのではなく、変更を作るチームがテストを所有し、共通基盤が判断を支える形です。

参考：GitLab Handbook: Testing

この事例をそのまま移植する必要はありません。小規模なチームでは、開発者が単体・結合テストを所有し、利用部門の責任者が受入条件を持つ分担から始められます。最後に承認する人とリリースを止める条件は、契約・規制・セキュリティ要件に合わせて別途指定し、最低限、対象バージョンとテスト結果を追える証跡を残します。規模が大きくなったら、テスト環境や自動化を支える役割を加えます。

着手前に作る品質の合意表

品質計画を長い文書にする前に、変更単位で読み返せる表を作ります。導入で挙げた五点は、何を守り、誰がテストし、どの証拠で誰が判断するかを確認するためのものです。表では、その五点を「確認する品質」「利用場面」「合格とする条件」「テスト担当」「証跡」「確認者」「未達時の扱い」「最終承認者」の八列に分けて記録します。機能、性能、セキュリティ、運用移行など、対象ごとに一行ずつ置きます。

最初の会議で決める七つの問い

着手時には、次の問いへ双方が答えられる状態を目指します。

1. 今回の変更で守る利用者の結果は何か

2. 機能以外に確認する品質特性は何か

3. 誰がテストを設計・実行・再確認するか

4. どの環境、データ、バージョンを使うか

5. 合否を示す証拠はどこへ残すか

6. 未解決の不具合を誰が承認するか

7. 最終的なリリース可否を誰が決めるか

判断基準や承認権限が決まっていなければ、開発開始後に会議回数を増やすだけでは解消できません。要件整理の段階で、技術責任者、業務側の責任者、海外側リードが同じ表を確認します。要件を変更したときは、影響を受ける品質の観点、合否の基準、証跡、確認者、承認する責任者を更新し、リリース判断の前に再確認します。

品質の合意から決まる候補者とチームの要件

品質管理の仕組みが見えると、採るべき人材も明確になります。自動テストを設計できる人が必要なのか、業務シナリオを技術要件へ変換できるリードが必要なのかを分けられます。可用性目標、監視、障害時の復旧責任までチームへ持たせる場合は、サイト信頼性エンジニアリング（SRE）の経験が必要かも検討します。「経験豊富なエンジニア」という求人要件より、採用後に担う責任を明確にできます。

ZenNxt Labsでは、必要な人材像と開発状況の整理、現地で最高技術責任者（CTO）を務めたメンバーによる一次スクリーニング、稼働開始時の体制づくりを支援しています。品質管理を人員追加だけで解決しようとせず、まずテスト責任と完了条件から整理したい場合は、高度IT人材の採用支援についてご相談ください。