Global Capability Center（GCC）の立ち上げでは、採用した人数、稼働率、従来拠点との費用差が報告しやすい数字です。GCCは日本語でグローバル・ケイパビリティ・センターと呼ばれます。しかし、人が増えたことや予算内で運営できたことだけでは、製品開発が速くなったのか、品質が上がったのか、拠点に知識や経験が蓄積したのかは分かりません。

Key Performance Indicator（KPI）は、重要業績評価指標を意味します。KPIは拠点の任務から逆算し、会社が実現したい成果、GCCが担う貢献、その途中の変化、確認する頻度の順に決めます。本稿では、開発を担うGCCを想定し、人数だけに頼らない評価軸と運用方法を解説します。

KPIの出発点はGCCの任務

「インドに開発拠点を作る」という計画だけでは、適切なKPIを選べません。例えば、既存製品の開発を速める拠点と、データ・AIの共通基盤を作る拠点では、測る成果が異なります。まず、12か月後にGCCが所有する製品・業務と、本社にもたらす変化を一文で定義します。

Infosys Business Process Managementは、事業目的、GCCの貢献、選んだKPI、確認する周期を一つのvalue map（価値のつながりを示す図）で結ぶ方法を紹介しています。例えば、製品を利用者へ届けるまでの時間、アイデアが試作から本番利用へ進むまでの期間、自動化の導入度などを、提供開始を速める目的と関連づけます。（参考：Infosys Business Process Management “GCC Success Factors”）

実務では、次の四段階で一枚にまとめます。

1. 会社の目的：何を良くしたいか
2. GCCの責任：拠点が所有する成果は何か
3. 変化の証拠：途中と結果を何で測るか
4. 運用：誰が、どのデータを、いつ確認するか

この順序なら、「20人を採用する」という活動量を、「決済機能の改善を安定して届けるチームが必要」という本来の目的へ結び直せます。人数は能力を作るための入力であり、利用者や事業に届いた成果とは分けて扱います。

開発GCCを測る五層のKPI

1．事業・製品の成果

最上位には、GCCが担当する製品や業務の成果を置きます。例として、機能提供までの期間、担当する機能の利用率、申込完了率など、対象となる顧客行動の完了率、業務処理時間、担当領域の売上・費用への影響があります。GCCだけで決められない成果は、本社の製品責任者との共有指標にします。

「売上」だけでは拠点の日々の改善と距離がある場合、担当する機能の利用、処理成功率、問い合わせ削減など、GCCの仕事が会社の成果へ至る途中の変化を測る指標を置きます。ただし、その指標を改善しても会社の成果が変わらなければ、仮説を見直します。

2．開発の流れ

計画から本番提供まで、作業がどこで止まるかを測ります。候補には、着手から提供までの時間、デプロイ頻度、仕様・権限・環境の待ち時間、計画した項目の完了率があります。個人のコード行数やチケット数は、価値や難易度を表さないため、人事評価の中心には置きません。

DevOps Research and Assessmentは、現在のソフトウェア開発指標を五つ示しています。変更のリードタイム、デプロイ頻度、失敗したデプロイからの復旧時間、変更失敗率、本番で発生した障害に起因する予定外デプロイの割合です。速さと安定性を別々に見ながら、時間とともにどう変化したかを確認できます。これらは原則として、対象となる一つのアプリケーションまたはサービスを定めて測ります。文脈が異なるアプリケーション、チーム、組織全体の値を単純にまとめて順位付けせず、GCCのスコアカードへ入れる場合も対象サービスと集計範囲を併記します。（参考：DevOps Research and Assessment “Software delivery performance metrics”）

3．品質・信頼性・リスク

リリース後の重大不具合、変更失敗率、復旧時間、合意したサービス水準、脆弱性や監査指摘の解消時間などを使います。不具合件数だけでは、利用規模や重大度が分かりません。重大度、影響した利用者、検知経路、再発の有無を分けます。

品質指標を厳しくしすぎてリリースを止めると、表面上の失敗率だけが下がることがあります。開発の速さと安定性を対にし、変更を小さく安全に届けられているかを確認します。

4．人材と能力

採用した人数より、必要な能力を持つ人がどの役割を担えるかを見ます。欠かせない役割の充足までの時間、入社後に期待する役割を単独で担えるまでの期間、重要な分野を複数人で担当できるか、社内異動、欠かせない役割を担う人の定着などが候補です。

研修受講数は活動量であり、能力の証明ではありません。研修後に設計レビューを担当できた、障害対応の主担当になった、別チームへ知識を展開したなど、仕事上の変化と組み合わせます。Infosys Business Process Managementも、人材指標として、学習の速さ、社内異動、現地リーダーの登用、欠かせない役割を担う人の定着を挙げています。

5．本社との連携と運営

本社からの指示量ではなく、意思決定が進む状態を測ります。決定待ちの時間、期限を過ぎても他チームの対応を待っている項目、責任者が決まっていない課題、レビュー回答までの時間、同じ論点の再協議などが候補です。関係者満足度を取る場合は、総合点だけでなく、情報の十分さ、判断の速さ、成果への信頼を分けます。

会議数や文書数を増やすこと自体は成果ではありません。会議後に決定、担当者、期限が残り、未解決事項が減ったかを見ます。日本側だけ、インド側だけを評価するのではなく、共同の運営指標として扱います。

スコアカードの具体例

表のすべてを採用する必要はありません。一つの目的に指標を増やしすぎると、更新作業が目的になります。各目的に結果を示す指標を一つか二つ、途中の変化を示す指標を一つか二つ置き、意思決定に使われないものは外します。

成長段階ごとに変わる重点

立ち上げ期：運営可能性と基準値

最初の数か月は、目標達成率だけでなく、役割、開発環境、アクセス、レビュー、障害対応が機能するかを確認します。必要な役割の充足状況、環境の準備、最初の提供、決定待ちを測り、以後の比較に使う基準値を記録します。基準値がない段階で、他社の数値をそのまま目標にしないことが大切です。

安定期：速度と品質の両立

継続して提供できる段階では、開発の流れと品質を中心にします。提供が速くなっても障害が増えていないか、品質を守るために承認待ちが長くなっていないかを対で見ます。人材面では、重要な役割を一人だけに依存していないかを確認します。

拡張期：事業価値と能力の展開

複数チームや製品へ広がる段階では、GCCが所有する製品範囲、共通資産の再利用、現地リーダーの登用、新しい能力の実際の業務での利用などを重視します。

2024年の共同調査では、インドのGCCの50%超がポートフォリオまたは変革を担う拠点へ移行したとされています。規模ではなく、任される成果の変化を追います。（参考：GCC市場の共同レポート）

指標の定義表に必要な八項目

KPI名だけを共有すると、本社と現地で計算方法がずれます。各指標に、目的、定義、計算式、分母、データ元、更新責任者、確認頻度、判断基準を記載します。「離職率」なら、自己都合のみか、対象とする期間の平均在籍人数を分母にするか、異動を含むかまで決めます。

目標値は、最初から一つの数字に固定せず、基準値、許容範囲、注意が必要な範囲を分ける方法があります。その範囲を超えたときは、誰が原因を確認し、どの会議で判断するかも決めます。数値を報告して終わるのではなく、採用、優先順位、技術改善、権限移譲の判断へつなげます。

KPIが悪化したときの診断順

指標が悪化したときは、すぐに現地チームの評価へ結びつけず、まずデータの定義と取得方法を確認します。集計する期間、分母、除外条件、集計元が前月と同じでなければ、変化ではなく計算の仕方の違いかもしれません。

次に、GCCの担当範囲で変えられる要因と、本社や他チームに依存する要因を分けます。変更のリードタイムが延びた場合、実装時間、レビュー待ち、環境の準備、事業判断の待ち時間を分解します。合計時間だけを現地の開発評価に使うと、改善すべき場所を誤ります。

原因が見えたら、各対策の効果を確認する日を設定します。レビュー待ちが原因なら、承認者の追加や回答期限の設定を行い、次の月次会議で待ち時間の変化を確認します。複数の施策を同時に始める場合も、どの指標へ影響すると考えたのかを記録します。

最後に、指標そのものが目的に合っているかを見直します。提供件数が増えても利用率や品質が変わらないなら、件数を増やす活動が会社の目的につながっていない可能性があります。KPIは評価を固定するためではなく、拠点へ任せる仕事、権限、人材、技術投資を更新する判断材料として使います。

Targetの公式事例に見る製品目標との接続

米国小売企業Targetは、ベンガルールのGCCを本社の延長と位置づけています。同拠点の製品責任者は、技術と分析によって事業成果を届け、製品の予算と短期・長期の目標を管理する役割です。求人には、四半期のObjectives and Key Results（OKR）への責任も記載されています。OKRは、目標と主要な成果を対応させる管理方法です。（参考：Target “Director Product Management”）

ここで参考になるのは、GCCだけの活動指標を別に作るのではなく、担当製品の結果と共通の目標へつなげることです。採用した人数や開発件数は必要でも、それらが利用者、費用、提供の速さ、品質のどれを変えたかまで確認します。

小規模なGCC検証に必要な最小セット

初期チームでは、担当する事業・製品の結果を示す指標を一つ、開発の流れを一つ、品質を一つ、人材を一つ、連携を一つ選ぶところから始めます。週次では障害、待ち時間、提供計画を確認し、月次では製品成果、能力、人材の変化を確認します。四半期には、GCCへ任せる範囲を広げるか、役割や運営を見直すかを判断します。

GCCとは？日本企業がインド開発拠点を作る方法では、拠点の基本と段階的な立ち上げを解説しています。当社のインドGCC立ち上げ支援では、小規模な専属チームで、人材要件、会議、レビュー、報告、評価指標を検証します。人数ではなく会社の目的につながる運営を設計したい場合は、お問い合わせください。