EOR（Employer of Record、現地雇用代行サービス）を活用してインドのエンジニアと開発を進めていても、チーム人数が増えたからといって自動的にGCC（Global Capability Center、現地法人拠点）へ移行すべきとは限りません。GCCを設立する判断は、「自社として現地でどのような戦略的機能と責任を担わせたいか」という目的から始まります。単なる契約形態の切り替え手続きとして捉えてしまうと、雇用関係、知的財産権、開発環境、日々の設計判断の引き継ぎに重大な不備が生じ、現場の開発を混乱させる原因になります。

拠点化の合図は人数より「任せる機能」

ジェトロはGCCを、ITサービスや研究開発など特定の機能を担う拠点と説明しています。EORで個々の人材と働く段階から、拠点が設計、採用、品質、運用の一部を継続して担う段階へ進むなら、組織の持ち方を検討する理由になります。費用だけでなく、意思決定の速さ、技術の蓄積、現地管理者の必要性を見てください。

参考：ジェトロ「インドにグローバル・ケイパビリティー・センター（GCC）を置く魅力」（2025年5月29日）

GCCとEORの違いは、両者の選択軸を整理しています。移行を考えるときは、いまのEORで困っていることを具体化します。技術責任者が不在なのか、採用や評価を自社で管理したいのか、長期の研究開発を拠点へ任せたいのか。課題が違えば、必要な拠点の形も変わります。

判断の前には、現行体制でできている仕事も書き出します。EORのままでも職務要件が明確で、技術リーダーと意思決定の経路が機能しているなら、急いで移る必要があるかを再検討できます。逆に、自社の採用基準や製品知識を現地組織へ蓄積したいなら、どの機能から拠点へ渡すかを決めます。移行の理由が費用だけなのか、組織の役割なのかを分けてください。

移行前に契約と人の状態を一覧にする

最初に確認するのは、EOR事業者との契約期間、終了通知、雇用主との関係、従業員へ示した条件です。既存メンバーが新しい法人へ当然に移ると想定せず、本人への説明、雇用条件、必要な手続きを個別に確認します。労働法や社会保障の適用は雇用条件や事業所によって変わるため、現地の法務・労務専門家を交えて進めます。

インド労働・雇用省の雇用主向けハンドブックは、社会保障を含む制度の適用条件を整理しています。個別の移行手続きの代わりになる資料ではありませんが、確認すべき制度を洗い出す出発点になります。

参考：インド労働・雇用省「Compliance Handbook for Employers Under the Four Labour Codes」

従業員への説明では、誰が新しい雇用主になるか、報酬や福利厚生、勤続期間の扱い、問い合わせ先がどう変わるかを曖昧にしないことが大切です。個別の条件と法的手続きは契約や所在地で異なるため、移行日を先に公表する前に、EOR事業者と現地専門家を交えて確認します。

開発の引き継ぎは、人事の切り替えと別に計画する

成果物の権利とアクセスの帰属を確認する

契約主体が変わる際は、ソースコードや成果物の帰属権利、機密情報の取り扱い、クラウドアカウントの所有権、PC端末やデータの保管場所を網羅的に確認します。現行のEOR事業者経由で利用しているアカウントをそのまま承継できるのか、新拠点用のアカウントへ新規移管する必要があるのか。誰が移管を承認し、旧アカウントのアクセス権をいつ停止するかを定義します。

進行中の仕事を新旧体制へ振り分ける

開発中の機能やプロジェクトについては、移行の基準日を1日だけ設定して機械的に切り替えるのではなく、「旧体制下で完了・納品するタスク」「新体制側で着手するタスク」「移行期間中に双方が並行して検証するバッファ期間」を明確に区分します。テストや本番リリースの責任者が不在となる期間を作らないようにします。現地に新たなテックリードを登用する場合も、設計判断の委譲範囲を段階的に拡張していくステップを踏みます。

並行期間と旧アカウントの停止を決める

移行実施計画には、①旧契約で完結させる業務スコープ、②新拠点で引き受ける業務スコープ、③新旧体制が並行して検証を行う期間、④旧アカウントを完全停止・回収する期日を個別のタスクとして記載します。各工程には責任者と完了を確認できる記録を設定します。たとえば開発中の機能であれば、旧体制側でコードを引き渡し、新体制環境で結合テストを再実行し、受け入れ担当者が問題ないことを確認したうえで旧権限を回収します。カレンダーの日付を合わせるだけでなく、「誰が何を確認できたら次のフェーズへ進むか」というマイルストーンを定義することが移行の成否を分けます。

「拠点が動く状態」を移行完了の条件にする

現地法人の登記や各種契約の手続きが完了しても、現場のエンジニアリングが停滞しているのであれば移行が完了したとは言えません。新たな現地リーダーの下でタスクの優先順位が円滑に決定され、コードレビューが回り、インシデント発生時の連絡網が機能し、旧契約に基づくアクセス権が漏れなく回収されたことを確認して初めて移行完了と判断します。移管初期の一定期間は、採用人数や稼働時間の規模を追うことよりも、意思決定の滞留やドキュメントの引き継ぎ漏れがないかを注視する方が、拠点の健全な立ち上がりにつながります。

移行に関するご検討の際は、現行メンバーの担当領域、将来的に現地拠点へ移管したい機能、進行中の開発ロードマップ、希望する移行時期を整理してお知らせください。ZenNxt Labsが提供する人材選定・技術評価・稼働設計支援のスコープと、EOR事業者や現地の法務・労務専門家と進める法人・雇用手続きとを明確に切り分けて設計することで、開発を止めないための移行計画を立てられます。

お問い合わせはこちら