業務標準化・集約はなぜ必要か？　AI時代に加速するGBS（グローバル・ビジネス・サービス）の理由

ある大手日本企業の経理財務部門の責任者と、GBS（グローバル・ビジネス・サービス）の導入について議論したときのことです。

標準化を進め、AIを導入する。それが時代に合ったやり方であり、業務を1カ所に集めることにこだわる必要はない――そう言われました。

反論するのは難しくありませんでした。難しかったのは、反論した後に何を言うべきか、です。

本寄稿は、その問いへの答えです。

このプロセスを正しく踏んだ結果が、集約しないという結論になることもあります。組織の規模が小さい場合や、現行体制の効率化余地がまだ大きい場合は、集約のコストがメリットを上回ることがあります。

しかしながら、経験則として、大規模な企業の多くは、このプロセスを正しく踏んだ結果として、集約によるメリットが結果的に大きくなります。それは集約が正解だからではなく、スケールの論理が大規模組織においてより強く働くためです。
 

次世代GBSへの動かし方

正しいプロセスは理解できます。問題は、それをどうやって社内で動かすことだ――そういう声もよく聞きます。

過去のBig Bang型の集約推進が、現場に深い傷を残してきたケースは多いと言えます。報告ラインを一気に変え、移行後の品質が落ち、現場が混乱した。その経験が集約への警戒を生んでいます。

もう一つ、見落とされがちな失敗があります。AIを個別の業務に後付けするやり方です。部門ごとの取り組みは、ほぼ例外なく散発的な実験で止まります。既存の仕組みにAIを貼り付ける"bolt-on AI"は限られた効率化しか生みません。効果を生むのは、プロセスの土台から組み込む"built-in AI"の発想です^*2。

*2 出典：“EY.ai Value Blueprints,” EY website, www.ey.com/en_be/services/ai/value-blueprints （2026年7月6日アクセス）

次世代GBSへの移行は、この発想を政治的な摩擦を最小化しながら根付かせる取り組みです。

• まず、現状のまま移管します。報告ラインを変えず、目的はデータを1つの場所に置き、AIが部門をまたいで参照できる状態をつくることです。この段階では、集約とも呼ばなくていいです。
• 次に、隣接した状態でプロセスをつくり直します。人が全てを確認する前提をやめ、リスクが高い場面や人の経験が競争力になる場面だけ人を戻す設計に切り替えます（EYはこれを"design-for-zero"と呼びます^*3）。摩擦の少ない場所から進め、根拠は積み上がります。
• 最後に、検証済みの標準を企業全体に展開します。この段階で、GBSは業務を集めて処理する場所から、AIエージェントと人の働き方を組織全体で統括する拠点、グループ全体のインテリジェンス・ハブに変わります^*3。

*3 出典：“How agentic AI can transform GBS into an enterprise intelligence hub,” EY website, www.ey.com/en_dk/insights/consulting/the-role-of-gbs-in-an-agentic-ai-future（2026年7月6日アクセス）

この流れは、集約ありきの実行計画ではありません。Built-in AIを前提に、設計・検証・意思決定を段階的に進める現実的な方法です。
 

問いを持つ組織が、次の一手を持つ

冒頭の企業の責任者との議論は、今も続いています。

ただ、最近の対話のトーンは少し変わってきました。集約すべきかという問いから、何から手をつけるかという問いへ。その変化が、議論を前に進めています。

AI時代に変わったのは、集約の必要性ではありません。集約をコスト削減の目的として語っていた時代が終わったということなのです。

そしてこの問いは、GBS部門だけのものではありません。何を最適化するために、何を切り分け、何を集約し、何を留保するか――事業側とGBSが共に持つべき設計の問いです。

この問いに対する答えを設計する機能として持っている組織だけが、次の一手を持つことができます。