多くのグローバル・ケイパビリティ・センター（GCC）が失敗するのは、インドのエンジニアの能力が足りないからではありません。本社側がそのセンターを「コストの良いアウトソーシングベンダー」として扱い、初日から組織の一部として責任を持って育てようとしないことが原因です。順序を正しく設計すれば、GCCは持続的な競争優位になります。順序を誤れば、コードは出てくるものの、決して「自分たちのチーム」だと感じられない組織ができあがってしまいます。
まず決めるべきは人数目標ではなく「規模」
計画すべきチーム規模には、スタートアップ規模（5〜15人）、小規模（15〜40人）、中規模（40〜150人）、エンタープライズ規模（150人以上）があります。それぞれ異なる失敗パターンを持っています。6人程度のスタートアップ規模のセンターは、構造の欠如によって機能不全に陥ります——全員が一人の疲弊したリーダーに報告し、知識は特定の個人の頭の中にしか存在しません。一方、100人規模のセンターは、時期尚早な過剰構造によって機能不全に陥ります——チームがまだ必要としていない段階で、本社のプロセスをそのままコピーした階層構造を持ち込んでしまうのです。自分たちが本当にどの段階を構築しようとしているのかを見極め、3年後に到達したい姿ではなく、今のその段階に見合ったリーダーシップとプロセスの成熟度を用意しましょう。
プロジェクトのためではなく、センターのために採用する
プロジェクト単位の人員配置は、ポジションを素早く埋めることを最適化します。しかしGCCが最適化すべきは、3年後もそこにいる人材です。そのためには、本物の水準を持つ面接プロセス、本社のレベルを「模倣」ではなく「反映」する透明なキャリアラダー、そしてアウトソーシングの日当ではなく現地のシニアエンジニア市場に基づいた報酬水準への投資が欠かせません。2年目に定着率を崩壊させる最も確実な方法は、1年目にせっかく良い人材を採用しておきながら、レベルや報酬を過小評価することです。
必要になる前にガバナンスとセキュリティを組み込む
すでに本番環境向けのコードを出荷しているセンターに、アクセス制御や監査ログ、データ取り扱いポリシーを後付けするのは、痛みを伴ううえに時間もかかります。最初の採用の時点からこれらを組み込みましょう——ISO 27001に沿ったアクセス管理、人事と連動した実効性のあるオンボーディング／オフボーディングのチェックリスト、そして規制対象の顧客にサービスを提供する場合はデータレジデンシーに関する明確なルールです。これは、本社のセキュリティ・コンプライアンスチームからの信頼を得る最も早い方法でもあります——求められる前に、すでに管理体制が整っていることを示すのです。
誰かが運営の責任者にならなければ、誰もならない
施設管理、現地の給与計算、法令遵守、IT環境の整備、たまに発生する国境をまたぐ出張へのビザサポート——これらはいずれもエンジニアリングの仕事ではなく、最初のエンジニアリングリーダーの机の上に積み上げられるべきものでもありません。15〜20人を超えて成長するセンターには、たとえパートタイムであっても、必要性を強く感じる前の段階で専任の運営責任者が必要です。
カルチャーは意図的に決めるものであり、副産物ではない
本社の自然な延長のように感じられるセンターは、働き方を意図的に揃えています——同じスプリントのリズム、同じ「完了」の定義、そしてプロダクトの背景やロードマップの議論への同じアクセス権です。逆に、ベンダーの孤立した拠点のように感じられるセンターは、そもそもそうしたアクセスを与えられていません。インドのチームが優先事項を又聞きでしか知らされていないなら、そのアウトプットもどこか「又聞き」のような質になったとしても不思議ではありません。
将来的な完全内製化への道は残しておく
ビルド・オペレート・トランスファー（BOT）方式——パートナーがセンターを立ち上げて運営し、成熟した段階で所有権を引き渡す方式——を採れば、ベンダーとの関係に永久に縛られることなく、今すぐスピードを手にすることができます。この選択肢を実際に行使するかどうかにかかわらず、あらかじめそれを交渉に含めておくことでインセンティブの整合性が保たれます。パートナーは、あなたを依存させ続けるためではなく、良好な状態で引き渡すことを前提にセンターを構築することになるのです。
ここまで述べてきたことは、決して特別なものではありません。どんな組織設計の意思決定にも当てはめるべき、ごく普通の規律です。ただ、オフショアチームの場合はスピード重視の圧力によって省略されがちなだけです。長く続くセンターとは、最初の採用の時点から「速さ」と「長く使えるように作ること」を同じ一つの要件として扱ってきたセンターなのです。