一応納期は守ってくれたんですけど、バグが多くて結局手直しに時間がかかってます…
ベトナムチーム、納期はきっちりですが品質にばらつきが出るのも“あるある”なんですよね。
ちゃんとレビューしてくれてると思ってたのに…
そこが落とし穴なんです。彼らの“完了”の基準と日本側の期待にズレがあることが多いんですね。
はじめに
ベトナムとのオフショア開発では「納期は守られているのに、品質に問題がある」という悩みが頻出します。本記事ではその背景にある原因と、品質を安定させるための具体的な対策を「5つ」に絞ってご紹介します。
品質トラブルのよくあるケース
筆者も実務で何度も経験してきましたが、以下のようなトラブルは特に発生しやすく、かつ初期段階では見落とされがちです。重要なのは、表面的な原因ではなく「なぜそれが起きたのか？」という背景を読み解き、仕組みで防止することです。
- 表示崩れが大量に発生したまま納品
- あるプロジェクトでは、レスポンシブ対応が指示に含まれていたものの、PC画面では問題ないがスマホ画面で大幅なレイアウト崩れが発生。納品時には「対応済」と報告されていたが、実際にはスマホ環境でのテストが一切されていなかった。
- APIの例外処理が未実装
- バックエンド連携の機能で、APIの正常系のみ実装され、タイムアウトや400エラー時の処理がすべて抜けていた。確認したところ「画面が表示されたので完成と思った」との回答。
- 単体テストの実施報告が虚偽
- 「テスト済」と報告されていたモジュールの動作に不具合が多発。確認すると、実際は単体テストは1件のみであり、他は目視確認だった。報告はExcelをコピーしていただけだった。
ベトナムオフショア開発の品質問題を防ぐための5つの必須対策
対策①：Definition of Done を明文化してズレを防ぐ
日本とベトナムで「完了」の定義が異なると、品質のギャップが生じやすくなります。日本ではドキュメントの整備、レビューの完了、テスト結果の記録なども含めて「完了」としますが、ベトナムでは「とりあえず動けばOK」と認識されるケースも。
対策ポイント：
- ドキュメント更新済み
- 単体テスト完了
- コードレビュー通過済み
- バグゼロ、または既知バグの明示
これらを「Definition of Done（完了の定義）」として明文化し、契約前やキックオフ段階で共有しましょう。
対策②：コードレビューのルールを整備し、ダブルチェックを必須化する
ベトナム側で「動くからOK」と判断されたコードでも、日本の品質基準では未達であることがあります。これは、動作する＝完成という価値観の違いに起因します。たとえば、仕様に記載されていない細かい例外処理、エラーメッセージの文言、非機能要件（パフォーマンスやアクセシビリティ）など、日本では「品質の一部」として扱われる項目が、ベトナム側では優先度が低い、もしくは考慮されていないことがあります。その結果、「とりあえず動くコード」が納品され、あとで修正や追加対応が必要になるケースが発生します。
対策ポイント：
- 日本側エンジニアとベトナム側リーダー、双方でコードレビューを実施
- レビューコメントはRedmineやGitHubのPRなどで記録に残す
- コーディング規約やLint設定を共通化する
対策③：テストケースを事前に共有し、検証観点のズレを防ぐ
「テストした」と言っても、確認観点がズレているケースは非常に多いです。たとえば、ベトナム側は画面が表示されることだけを確認し「OK」と判断する一方で、日本側はボタンの文言、境界値のテスト、レスポンス速度などまで含めて確認が必要だと考えている場合があります。こうした“テストの期待値”のギャップを放置すると、表面的な確認だけでテスト完了とされ、リリース後に重大なバグが見つかる可能性があります。品質担保のためには、あらかじめどのような観点でテストすべきかを明示・共有し、期待値を揃えることが極めて重要です。
対策ポイント：
- 単体・結合テスト観点をExcelなどで一覧化し、事前に共有
- 不具合が起きやすいパターンを重点的に網羅
- テスト結果はスクリーンショットやログとともに提出してもらう
筆者もエビデンスを作成してもらいましたが、どんな手順で表示された画面なのかなど一切説明がなく、ただ画面のキャプチャが貼られていただけということもありました。具体的に手順を書くなどを指定しないと使えないものになります。
対策④：品質チェックリストを導入して、納品前の確認を徹底
作業完了の判断を個人に任せると、属人的でばらつきが出ます。例えば、あるメンバーは細かいUIのズレまで丁寧にチェックする一方で、別のメンバーは「画面が表示されればOK」と判断してしまうことがあります。
このようなばらつきは、同じチームであっても品質の安定性に大きな影響を与えます。また、納品先や上司に対する「確認済み」の報告が、実際には十分な確認を経ていないケースも見受けられます。こうした問題を防ぐには、チェック項目を明文化し、誰が見ても判断基準が同じになるようにすることが必要です。
対策ポイント：
- 品質チェックリストをテンプレート化（例：UI確認、文言チェック、レスポンシブ対応など）
- チェックリストに基づく自己レビューをベトナム側に義務づける
- チェック済みであることを納品時に明示してもらう
対策⑤：CIツールやバグ管理ツールで品質を“見える化”
ツールを活用することで、品質状態を客観的かつリアルタイムに把握できます。特に、開発の進捗や不具合の発生状況、テストの実行結果といった情報を手動で管理するのは時間も手間もかかり、見落としの原因になります。CI（継続的インテグレーション）やバグトラッキングツールを導入することで、こうした情報を自動で収集・可視化でき、品質リスクの早期発見とチーム内での情報共有が円滑になります。また、定量的な指標で進捗や品質を判断できるようになるため、属人的な判断に頼らず、データに基づいた改善が可能になります。
対策ポイント：
- GitHub Actions や GitLab CI で静的解析・ユニットテストを自動実行
- Jira や Redmine でバグや進捗を管理し、対応状況を見える化
- テストやレビューのログを蓄積し、振り返りや改善に活用
ベトナムとのオフショア開発では、納期遵守に重点が置かれる一方で、品質が後回しにされることがあります。特に、現地チームは「納期を守ることが信頼の証」と強く意識しており、品質や完成度が多少未達であってもまずは予定通りに提出しようとする傾向があります。
筆者も過去に、見た目は一見完成しているが中身がほとんど仮実装というモジュールを受け取ったことがあり、品質担保の大切さを痛感しました。
しかし、適切な対策を講じれば、品質も安定させることは十分に可能です。
Definition of Done の共有、コードレビューの徹底、テスト観点の明示、チェックリストの運用、自動化ツールの活用。これら5つの対策は、筆者が実際にプロジェクトで導入し、明らかに成果物の安定性が向上したと感じたものです。場当たり的な修正や属人的な判断に頼らず、再現性のある開発プロセスを構築するためにも、これらの対策を実践していくことが重要だと強く感じています。
