ハノイとホーチミンの人種が違う——ベトナム開発で“土地の個性”を武器にする実践ガイド
- Daisuke Neigisi
- 11月12日
- 読了時間: 7分
まず最初に：本タイトルの「人種」は比喩表現です。差別的意図は一切なく、**ハノイ（北部）とホーチミン（南部）それぞれの“ビジネス文化・働き方の個性”**を示すために使っています。本記事では、その違いを理解し、プロジェクト成功確率を上げるための体制設計・コミュニケーション設計までを具体的に解説します。
誰のための記事か
これからベトナムオフショア開発を始めたいが、やり方がわからない企業
すでに始めたが炎上・停滞している企業
新規事業を立ち上げたいが、要件整理～開発～運用までの推進方法が不明な企業
企画から運用監視まで一気通貫で任せたいが、何から手をつけるべきか迷っている企業
まずは相談先を一本化したい企業
TomorrowFuture株式会社（TF）は日越デュアルショアで、上流（企画・要件）から運用監視までの一気通貫を支援しています。本記事は実戦的な設計図としてお使いください。
概観：ハノイとホーチミンの“性格差”を一言で
ハノイ（北部）：堅実／設計重視／規律と合意形成を尊ぶ／品質・手戻り抑制に強み
ホーチミン（南部）：スピード／市場志向／プロアクティブ／試作・仮説検証に強み
成功のコツは“どちらが良いか”ではなく、「自社プロジェクトのフェーズと性質」に最適化して使い分けること。
典型的な強み・弱み（現場感に基づく仮説）
観点 | ハノイ（北部） | ホーチミン（南部） |
得意領域 | 大規模案件、官公庁・金融系に近い厳密性、設計/レビュー工程 | スタートアップ的開発、PoC/プロトタイプ、UI改善の素早い反復 |
マネジメント相性 | ウォーターフォール寄りの工程管理、成果物ベースの合意 | アジャイル/スクラム、変更受容性、顧客開発 |
コミュニケーション | 合意に時間をかけるが齟齬が少ない | 初速が速いが前提が変わると軌道修正の対話が要 |
リスク | 仕様確定が曖昧なままだと停滞 | 要件定義が浅いと品質ばらつきや技術負債化 |
適するフェーズ | 要件定義～基本設計～結合試験 | アイデア検証～UI改善～グロース施策 |
※地域差は“傾向”であり、チームごとの差も大きい点は必ず留意してください。
失敗パターンは「地の利のミスマッチ」から起きる
要件が曖昧なのに、詳細設計・見積りを急ぐ
→ ハノイ側は精緻化を求め、時間がかかる／南部側は走り出すが後で手戻り。
“早く作る”前提で南部に任せ、品質基準が曖昧
→ デリバリーは早いが、受入時に品質議論が発生し、結局遅延・コスト増。
日本側の意思決定がボトルネック
→ 日次の小さな合意が溜まり、週次で大きな齟齬に。ブリッジSEの決裁範囲が狭すぎるのも典型。
アジャイル用語だけ導入して“儀式化”
→ スプリントレビューが単なる進捗会に。価値検証（KPI/KGI）に紐づいていない。
“勝ち筋”テンプレ：フェーズ別の都市・体制の当てはめ
フェーズA：0→1（仮説検証・スピード命）
推奨：ホーチミン主導＋日本側PdM/デザイナー密着
体制：PM（日本）– PdM/UX（日本）– Dev（HCMC）– QA（Hanoi or HCMC）
鍵：KPI定義 → 2週スプリント → 隔週ユーザーテスト → データで意思決定
フェーズB：1→10（機能拡張・品質担保）
推奨：ハノイで設計・レビュー強化＋南部で機能追加の平行稼働
体制：アーキ/レビュー（Hanoi）– 開発（HCMC）– QA（Hanoi）– SRE（Hanoi）
鍵：**非機能要件（性能・監視・可用性）**の明文化、変更管理のルール化
フェーズC：運用定着（SRE/監視/コスト最適化）
推奨：ハノイ中心でSRE/監視運用、南部はグロース小隊
体制：SRE（Hanoi）– Ops（Hanoi）– Growth Squad（HCMC）
鍵：SLO/SLI、オンコール、コストモニタリング（FinOps）、障害事後レビュー
ブリッジSE/PMの設計が「すべて」を左右する
悪い設計：通訳係に留まり決裁権なし／課題と原因を分離できない／スプリントで価値を語れない
良い設計：
語学＋開発実務の両輪（設計/レビューを“自分で”できる）
決裁権限（ストーリーポイント/受入基準/軽微な仕様変更の即時判断）
リスクを見える化（バーンダウン、欠陥密度、MTTR、テックデット残高）
TFのデュアルショアでは、日本側PM/BAが意思決定を握り、ハノイ（品質・SRE）×ホーチミン（開発速度）を一枚絵で統制します。
契約と見積り：炎上を呼ぶ“地雷”と回避策
地雷1：成果物定義が曖昧
回避：WBSと受入基準（DoD）を契約添付。UI/UXはワイヤー/プロトタイプも合意文書に。
地雷2：アジャイルなのに固定スコープ前提
回避：時間・材料（T&M）＋明確なベロシティで管理。スプリント毎に優先度をリシャッフル。
地雷3：テスト責任の所在が不明確
回避：品質責任分界（ベンダーQA範囲/発注側受入範囲）と障害SLAを明確化。
地雷4：為替・人月単価の変動吸収なし
回避：為替トリガー条項と単価改定条件を事前合意。国内・越側のミックス比率を調整可能に。
実務チェックリスト：着手前にこれだけは決める
[ ] ビジョン→KGI→KPI→主要ユースケース（1枚で説明できるか）
[ ] 優先度付きバックログ（MoSCoW）と受入基準（DoD）
[ ] 都市配分：ハノイ=設計/QA/SRE、HCMC=実装/PoC/UI改善（※プロダクト特性に応じて変更）
[ ] ブリッジSEの決裁範囲（ストーリー変更閾値、工数±%許容）
[ ] スプリントカレンダーと定例（デイリー/レビュー/レトロ）
[ ] メトリクス：リードタイム、欠陥密度、リリース頻度、MTTR、ベロシティ
[ ] 監視設計：SLO/SLI、オンコール体制、障害報告テンプレ
[ ] 契約条項：成果物/受入/変更管理/為替/単価/知財/守秘
[ ] 退避計画：ロールバック、DR、バックアップ、鍵管理
[ ] 移管計画：ドキュメント標準、コード規約、ナレッジベース
ケース：よくある“詰まり”とTFの解き方
ケース1：要件が定まらず、見積りがブレる
症状：見積りがスライドし続ける／誰も決めきれない
処方箋：2週間のディスカバリースプリントでKPI仮説→プロト→ユーザーテスト→再見積り。
体制：PdM（日本）× UX（日本）× Dev（HCMC）× 実装レビュー（Hanoi）
ケース2：受入でバグが多く、信頼が落ちる
症状：E2Eテストで落ちる／UIのズレ
処方箋：ハノイQA主導のテスト設計（テスト観点表、境界値、データ条件）＋CIでの静的解析。
体制：QA/テスト設計（Hanoi）× 実装（HCMC）× 受入（日本）
ケース3：運用で障害対応が後手
症状：復旧が遅い／原因分析が属人化
処方箋：SRE（Hanoi）でSLI/SLO定義→アラートノイズ削減→**事後レビュー（5 Whys）**標準化
技術スタックと共通ルール（例）
共通：Gitフロー、PRテンプレ、Lint/Format、コードオーナー、ADR（Architectural Decision Record）
品質：静的解析（言語別）、単体/結合/契約テスト、自動E2Eは主要顧客導線のみから開始
運用：監視（メトリクス/ログ/トレース）、デプロイ戦略（Blue/Green or Canary）、Feature Flag
ドキュメント：C4モデル（System/Container/Component）、Notion/Confluenceで検索可能性担保
言語：設計・課題は日本語-英語併記（誤読を減らす）
予算感とスケジュールの考え方（目安）
ディスカバリー（2～4週間）：PdM/UX/Tech Lead少数精鋭。**仮説の切り出しと“作らない決断”**が目的。
MVP開発（6～12週間）：南部中心で実装、北部がレビュー・QA。価値検証を伴走。
運用定着（継続）：SRE/監視・改善サイクル＋グロース小隊。KPI改善に投資を集中。
同じコストでも、都市の使い分け次第で“時間価値”が大きく変わるのがベトナム開発の妙味です。
まずはここから：最小構成の“お試し”プラン（例）
2週間ディスカバリー
成果：KPI、ユーザー要件、スコープ境界、UIワイヤー、概算見積り
4週間MVPスプリント×1（HCMC主導、Hanoiレビュー）
成果：動くプロト、受入基準に基づくレビュー、次スプリントの優先度
運用・モニタリング導入（Hanoi）
成果：監視ダッシュボード、SLO、アラート運用、障害時の役割分担
ここまでで“走りながら学ぶ”体験を、低リスク・短サイクルで提供します。
まとめ：土地の個性を“戦略アセット”に
ハノイの強み＝設計・品質・運用
ホーチミンの強み＝速度・仮説検証・UI改善
日本側が司令塔となり、適材適所で編成することで、QCDの同時達成に近づけます。
無料相談のご案内（Note読者限定）
現在の課題の棚卸し（30分）
都市配分と体制のラフ設計
最初の2～4週間で“何をやらないか”を決めるセッション
「まずは相談」からで大丈夫です。
企画・要件定義・システム開発・運用監視まで、一気通貫でTomorrowFuture株式会社が伴走します。
コメント