日越オフショア開発が遅延：ベンダーを替えるべきか

#納期遅延は結果であり、まだ原因ではない

赤くなった計画表は、なぜ赤くなったかを説明してくれません。同じ「2スプリント遅延」という症状でも、発生メカニズムはまったく異なります。

• スコープが増えたのに、ベースラインが更新されていない。
• ビジネス要件が、受入条件に変換できる粒度まで明確になっていない。
• 日本側の意思決定に複数回の承認が必要なのに、ベトナム側は元のスケジュールを維持している。
• BrSEが言葉を伝えるだけで、意図や受入条件を明確にしていない。
• ベンダーに、約束した技術力または要員が不足している。
• 品質不足により、修正・再テスト・課題再オープンのループが発生している。
• 現在のアーキテクチャでは、一つの変更がシステムの広範囲に影響する。

JUAS IT2026では、品質が計画どおりにならなかった172件のプロジェクトについて、「ベンダーのスキル不足」が59.9%でした。一方、「計画時の考慮不足」と「想定以上の現行業務・システムの複雑さ」も、それぞれ48.8%です。これはベトナムオフショアに限定したデータではありませんが、重要な示唆があります。組織がまだ理解していない計画上の欠陥や複雑さは、ベンダーを替えるだけでは解消しません。

したがって、最初の問いは「このベンダーは悪いか」ではありません。

明日チーム全員を入れ替えたとき、遅延の原因まで新チームへ移るのではないか。

#検証軸1：デリバリーデータは信頼できるか

実行チーム自身が見積もった進捗率だけで、スポンサーは判断できません。「80%完了」は、どのスコープの80%なのか、どの受入条件を通過したのか、残りにどれだけリスクがあるのかが分からなければ意味を持ちません。

私は通常、次の成果物から事実のベースラインを再構築します。

ベンダーが実データを開示し、差異を説明し、誤りが見つかれば報告を修正するなら、立て直しの土台は残っています。すべての数値がスライドの中にしかないなら、スポンサーには「継続」か「変更」かを判断する材料がまだありません。

#検証軸2：現チームに立て直す能力があるか

信頼できる立て直し計画は、「残業を増やす」「要員を増やす」「納期厳守に努める」という一覧ではありません。チームが遅延の発生メカニズムを理解し、そのメカニズムを変更できることを示す必要があります。

要件確認、設計、実装、レビュー、テスト、デモまで通る、小さな一気通貫の作業を一つ選びます。短い検証サイクルで、次の5点を観察します。

1. 実装前に、要件が受入条件へ変換されているか。
2. リスクを発見時に報告するか、定例会まで保持するか。
3. 両側の実際の意思決定者が、合意したフローで応答するか。
4. Definition of Doneが、未完成の成果物を本当に止めるか。
5. 不具合の後、該当箇所だけでなく仕事の進め方も変わるか。

これは一つのチケットを早く閉じる競争ではなく、デリバリーシステムの学習と修正能力を検証するものです。現チームには、新チームがまだ持たない業務知識があります。立て直し能力を証明できるなら、その知識を維持する方が全員交代よりリスクが低いことがあります。

反対に、運用を変えずに同じ約束を繰り返すのは赤信号です。立て直し計画は、成果物と行動が変わって初めて意味を持ちます。

#検証軸3：発注側がプロジェクト資産を管理できているか

管理権があるとは、発注側がすべてを自社運用することではありません。一人の担当者または一つのベンダーアカウントが代替不能なボトルネックになっても、事業としてプロジェクトを継続できる状態を意味します。

最低限、次を確認します。

• ソースリポジトリを所有する組織、管理権限者、コミット履歴の完全性。
• クラウド、ドメイン、CI/CD、監視、外部サービスアカウントの所有者。
• 現在のドキュメントから環境を再構築できるか、一人だけが手順を知っているか。
• データスキーマ、マイグレーション、バックアップ／リストア手順を検証済みか。
• バックログ、課題、テスト証跡、意思決定ログをエクスポートできるか。
• コード、データ、アカウントの所有権が契約でどう定義されているか。

これらが発注側の管理外にある状態で、引き継ぎ計画より先にベンダー変更を宣言すると、データと知識をさらに失う可能性があります。セキュリティ違反、資産の引き渡し拒否、所有権紛争の兆候がある場合は、法務と情報セキュリティを直ちに関与させる必要があります。一般的な記事は、実際の契約書の確認に代わるものではありません。

#判断マトリクス：「継続」か「変更」だけではない

3軸を検証すると、スポンサーが選べる介入策は現実的に4つあります。

重要なのは、会社全体の変更だけが介入策ではないことです。多くのプロジェクトでは、End-to-Endで責任を持つ一つのロールを交代するか、発注側に立つ独立した人材が事実のベースラインとガバナンスを再構築する必要があります。

この責任範囲は日越BrSE・デリバリーマネジメントで説明しています。言語を伝えるだけの役割との違いは、BrSEの4段階成熟度モデルを参照してください。また、「日本品質」がオフショアで失われる理由では、暗黙知を検証可能な基準へ変える方法を解説しています。

#私がガバナンス修正を優先する条件

次の多くが成立するなら、私はベンダー変更より先にガバナンスを修正します。

• ベンダーに不利な内容を含め、実データを開示する。
• 主要メンバーが業務を理解し、独立評価に協力する。
• 繰り返す問題の中心が、要件、意思決定権、または不明確なDefinition of Doneにある。
• 小さな作業を、新しい運用方法で要件から受入まで通せる。
• 発注側も、自らの責任範囲を修正することに合意する。

「ガバナンス修正」は会議を増やすことではありません。通常は報告階層を減らし、意思決定権を明確にし、IssueとRiskを分け、実装前に受入条件を定義し、品質を早く見えるようにすることです。

#私がベンダー変更を検討する条件

次の重大な条件が一つ以上あれば、ベンダー変更は妥当な選択肢になります。

• 報告内容をソースコード、ビルド、テスト結果、実行環境と照合できない。
• ベンダーが説明を繰り返し変える一方、ベースラインや立て直し計画を更新しない。
• 約束された主要メンバーが参加せず、結果に責任を持つ権限を備えた代替者もいない。
• 検証用の小さな作業でも、要件・レビュー・品質の同じ問題が再発する。
• リポジトリ、インフラ、ドキュメント、データへのアクセスが、正当な理由なく遅れ続ける。
• セキュリティ、コンプライアンス、契約上の違反について正式なエスカレーションが必要である。

変更を決めた後も、目的は旧ベンダーとの議論に勝つことではなく、事業継続性を守ることです。

#移行チェックリスト：古い負債を新チームへ持ち込まない

新チームがスコープを引き受ける前に、少なくとも次の成果物群を確定します。

1. コードとビルド： リポジトリ、ブランチ戦略、タグ／リリース、依存関係、Secret一覧、ビルド・デプロイ手順。
2. インフラ： 環境構成図、クラウドアカウント、ドメイン、証明書、CI/CD、監視、バックアップ、リストア。
3. データ： スキーマ、マイグレーション、データ辞書、外部連携、アクセス権、セキュリティ要件。
4. プロダクト： 承認済みスコープ、バックログ、受入条件、既知の制約、保留中の判断。
5. 品質： テストケース、最新結果、欠陥バックログ、本番障害、未テスト範囲。
6. アーキテクチャ： システムコンテキスト、依存関係、ADR、技術的負債、過去のトレードオフの理由。
7. 運用： Runbook、アラート、過去の障害、SLA／OLA、外部サービスの連絡先。
8. 商務・法務： 所有権、ライセンス、再委託、引き渡し義務、移行後のデータ削除要件。

検証されていないドキュメント一式を渡し、新チームに「全部再見積もりしてください」と依頼してはいけません。まず、小さなスコープをビルド・実行・テストできる状態にします。その後、新チームの実測デリバリー速度で計画を引き直します。

Web資産については、22項目の検収・引き渡しチェックリストでドメイン、ホスティング、ソースコード、アカウントを追加確認できます。より大きなシステムでは、実際のアーキテクチャ、データ、コンプライアンス要件に合わせて拡張してください。

#スポンサーが次の会議で聞くべき3つの質問

1. 「現在の進捗を証明するビルドはどれで、受入条件を通過していない部分はどこですか」
2. 「今後2週間で、実施タスクだけでなく、どの仕組みが変わりますか」
3. 「今日移行するとしたら、まだ自社で管理できていない資産または知識は何ですか」

この3問によって、会議の焦点は証拠、仕組み、事業継続性に戻ります。検証のたびに回答が明確になるなら、プロジェクトには立て直す余地があります。曖昧なままなら、スポンサーには介入レベルを上げるための根拠が蓄積されています。

#よくある質問

#何週間遅れたらベンダーを替えるべきですか？

すべてのプロジェクトに適用できる週数はありません。遅延を、事業価値、クリティカルパス、移行コスト、検証済みの立て直し能力と合わせて評価します。法令対応の必須経路での1週間は、延期可能なモジュールの1か月より重大な場合があります。

#人を追加すれば遅延を取り戻せますか？

バックログを分割でき、環境とドキュメントがオンボーディングに耐え、実行能力が本当のボトルネックである場合に限ります。要件や意思決定権がボトルネックなら、増員によって待ち行列と調整コストが増えるだけです。

#発注側に技術者がいない場合、どう評価すればよいですか？

スポンサー側に立つ独立した第三者を入れ、ベースライン再構築、成果物確認、判断ゲートの進行を任せます。その第三者は、評価中に同時に後継チームを販売すべきではありません。「ベンダーを替える」という結論に明確な利益相反が生じるためです。

私は、日本の顧客、ベトナムのチーム、システムアーキテクチャの交点で直接プロジェクトを担当しています。遅延の原因を整理し、ガバナンス修正、主要ロール交代、管理された移行を判断する必要があれば、現在の状況を共有してください。最初からベンダー変更を前提にせず、既存の成果物とデリバリーリスクから確認します。