なぜ「日本品質」はベトナムオフショアでそのまま再現されないのか？

「日本品質」がベトナムオフショアで再現されない最大の理由は、エンジニアの技術力ではありません。日本側が当たり前すぎて口にしない品質基準——つまり暗黙知——が、海を渡る時点で消失しているからです。基準が伝わっていないものは、どんなに優秀なチームでも作れません。

TL;DR (Executive Summary)

  • 課題： ベトナムオフショアの成果物が「仕様通り動くのに品質が低い」と感じられるのは、日本側の品質基準の大半が暗黙知のまま伝わっていないため。
  • 解決策： 「察する」前提の仕様書、暗黙のレビュー基準、報連相のタイミング感覚という3つのギャップを特定し、明示知に変換する4点セット（Definition of Done・サンプル駆動仕様・レビュー観点表・エスカレーションルール）で埋める。
  • 結果： 品質が「個人の意識」ではなく「プロセスの仕組み」として再現可能になり、レビュー指摘と手戻りの往復が大幅に減る。

私はデリバリーマネージャーおよび日越市場のBrSE（ブリッジSE）として14年間、日本の発注側とベトナムの開発現場の両方に立ってきました。9万店舗以上が利用する日本のSaaSを4年間デリバリーした経験から断言できるのは、「品質問題」と呼ばれるものの多くは、実は「伝達問題」だということです。

「品質」の定義が、そもそも両国で違う

デリバリーの現場から見ると、「品質」という言葉は日本とベトナムで指している範囲が違います。

観点 日本側の暗黙の定義 ベトナム側のデフォルトの定義
完成の基準 仕様＋「気配り」（エッジケース、使い勝手） 仕様書に書かれた通りに動くこと
エラー処理 ユーザーが迷わない丁寧なメッセージ エラーが落ちずに処理されること
帳票・UI 桁揃え・禁則処理・体裁まで含めて品質 データが正しく表示されること
「できました」の意味 テスト・体裁確認まで済んだ状態 主要ケースが動いた状態

重要なのは、どちらも間違っていないということです。ベトナム側の定義は、グローバルなソフトウェア開発では標準的なものです。問題は、日本側が右列の基準で発注しながら、左列の基準で検収することにあります。書かれていない基準で検収される側から見れば、これは「後出しの仕様変更」と同じです。

品質が消失する3つの暗黙知ギャップ

ギャップ1：「察する」前提で書かれた仕様書

日本の仕様書は、同じ文化圏の読み手が行間を補完することを前提に書かれています。「適切に処理する」「いい感じに表示する」「通常の業務フローに従う」——これらは日本人の同僚になら通じますが、文化的文脈を共有しないチームには情報量ゼロの記述です。

行間が読めないのではありません。行間に書かれているものが、そもそも文化の外には存在しないのです。

ギャップ2：レビュー基準が暗黙のまま

「コードレビューはしている、でも品質が上がらない」という相談をよく受けます。中身を見ると、日本側レビュアーの指摘が「命名が分かりにくい」「ログが足りない」「この体裁は受け入れられない」の繰り返しになっています。

これは、レビューで個別に指摘している内容が基準書として存在していないことのサインです。基準が明文化されていなければ、開発者は毎回レビュアーの頭の中を当てに行くしかなく、同じ指摘が無限に再生産されます。

ギャップ3：「報連相」のタイミング感覚

日本の現場では「悪い報告ほど早く」が常識です。一方ベトナムの現場では、問題を自力で解決してから報告するのが誠実さだと考える傾向があります。エンジニア本人は責任感から黙って頑張っているのに、日本側からは「問題を隠していた」と映る——この非対称が、納期直前の「実は動いていません」を生みます。

これは誠実さの問題ではなく、「いつ・何を・誰に報告すべきか」のルールが暗黙のままだという問題です。（この構造はITアウトソーシングプロジェクトの70%が失敗する理由で書いた「責任の断絶」と地続きです。）

解決策：暗黙知を明示知に変換する4点セット

私が日越プロジェクトを立て直す際、最初の2週間で必ず整備するのが次の4点です。

  1. Definition of Done（完成の定義） — 「仕様通り動く」の先にある品質条件をチェックリスト化し、タスクの受け入れ条件に組み込む。ログ出力、異常系の挙動、UI体裁の基準まで含める。
  2. サンプル駆動の仕様書 — 「適切に処理する」と書く代わりに、入力と期待出力の具体例を3つ並べる。正常系1つ、境界値1つ、異常系1つ。例は形容詞より雄弁です。
  3. レビュー観点表 — レビューで出た指摘をその都度観点表に追加し、「人がレビューする」から「基準でレビューする」へ移行する。3ヶ月続ければ、その会社専用の品質基準書が出来上がります。
  4. エスカレーションルール — 「15分調べて分からなければ質問する」「リスクに気づいたら解決前に一報する」を明文化し、早い報告を評価すると宣言する。ルール化しない限り、文化的デフォルトが勝ちます。

ポイントは、これらが全て**「人の意識を変える」のではなく「仕組みに落とす」**アプローチだという点です。意識への期待は文化の壁を越えませんが、チェックリストは越えます。

よくある質問

ベトナム人エンジニアの技術力は本当に問題ないのですか？

コアの技術力は十分に高く、特に若いエンジニア層の習得速度は日本と遜色ありません。差が出るのは技術力ではなく、ドメイン知識（日本の商習慣・帳票文化・業務フロー）と品質基準の共有度です。後者は採用では解決できず、プロセスでしか解決できません。

仕様書を全部詳細に書くのはコストが高すぎませんか？

全てを詳細化する必要はありません。コストを掛けるべきは「文化的暗黙知が含まれる箇所」だけです。CRUD処理の仕様は1行で十分ですが、帳票の体裁・エラーメッセージ・業務例外の扱いはサンプル付きで書く——この濃淡の判断こそが、両国の現場を知る人間（BrSEやデリバリーマネージャー）の価値です。

もし現在、ベトナムのオフショアチームとの間で「何度言っても品質が揃わない」と感じている場合、それは高い確率でチームの能力ではなく基準の伝達の問題です。状況を整理したい方は、お気軽に課題を共有してください。専門領域と時間的余裕に合う案件であればご返信いたします。