ソフトウェア企業の上海・北京2拠点を支える中国ITサポート

要点: ある欧州のソフトウェア企業は、グローバルIT標準をひとつだけ運用し、中国の2拠点もその標準に乗る「もう2つの拠点」に過ぎないと考えていた。だが実際に上海と北京から上がってくるチケットは、そのグローバル標準がまったく想定していなかった類のものばかりだった——誰も英語では起票したがらないサービスデスク、一度も実測されたことのない越境ネットワーク回線、そして本社ポリシーがどう書かれていようと現地法人にそのままのしかかるコンプライアンス義務。

ある欧州の企業向けソフトウェア会社のグローバルIT責任者のもとに、上海オフィスのオフィスマネージャーからメッセージが届く。スタッフが欧州のサービスデスクにチケットを起票しなくなり、問題は代わりに——あるいはまったく解決されないまま——グループチャット上で、中国語で、たまたま解決策を知っている誰かによって、非公式に処理されるようになっているという。責任者の最初の反応は、チケットシステムには存在理由があるとみんなに念押しすることだった。しかしより本質的な問いは、45人規模のオフィスがそもそもなぜそれを使わなくなったのか、である。

本稿は、そのIT責任者、あるいは欧州や北米のテクノロジー・ソフトウェア企業でIT部門を任され、会社の拠点が上海の本社オフィス（約45人）と北京の営業オフィス（約15人）にまで広がった人に向けて書かれている。これは実名の顧客ではなく、事例に基づく複合的なシナリオである——ただし、このパターンはBrocentが繰り返し目にしてきたものであり、それは同社自身の歴史とも重なる。Brocentは2007年に北京で創業し、2016年から香港オフィスを運営し、2021年からはシンガポールに本社を置いている。その顧客基盤のかなりの部分が、まさにこのプロファイルに当てはまる——アジアにおける唯一の拠点が中国であり、地球の反対側にある本社から遠隔で運営されている外資系テクノロジー企業だ。

この業界: アジアでの唯一の拠点が中国であるソフトウェア企業

欧州に本社を置くエンタープライズソフトウェア、開発者向けツール、産業用ソフトウェア、専門SaaS企業がアジアに進出する際、しばしば拠点をひとつだけ開設する。そしてその拠点は、シンガポールや日本ではなく中国であることが多い。潜在的なエンタープライズ顧客、システムインテグレーションのパートナー、場合によっては自社のデリバリーやエンジニアリング人材の最大の集積地が、すでに中国にあるからだ。結果として生まれるオフィスは、単なる小さな営業拠点であることはまれだ。エンジニア、導入コンサルタント、カスタマーサクセス担当者からなる、本格的なデリバリーや研究開発拠点であることが多く、比較的小規模な営業チームと並んで機能する。親会社が、すべてのプロジェクトのために欧州からスタッフを飛ばすより、中国現地に製品・デリバリー能力を構築するほうが効率的だと判断したためだ。

1、2年のうちに2つ目の拠点が続くことも多く、最初が上海であればほぼ確実に北京、逆であれば上海に開設される。中国におけるエンタープライズソフトウェアの営業は、買い手、政府関係、システムインテグレーションのパートナーが集中するごく少数の都市に集中しているためだ。結果として、数百キロメートル離れた2つの拠点が、会社のアジア全体のデリバリーと営業を合わせてカバーすることになる——しかし、それらは「ITサイト」として計画されたことは一度もない。それらは採用の意思決定の産物であり、インフラの意思決定の産物ではない。そして多くの場合、IT部門は、自社がすでに本格的な中国事業を持っており、たまたま中国にいる数名のリモート社員ではないことに、最後に気づく側になる。

シナリオ: 2都市60人、オフィスマネージャー1人、そして重ならないタイムゾーン

複合シナリオはこうだ。上海の本社オフィスには約45人——エンジニアリング、導入、カスタマーサクセス、そして一般管理機能——が在籍し、これに北京の営業オフィス約15人が加わる。営業担当者やパートナー対応スタッフが中心で、デスクに向かうよりクライアントとのミーティングに多くの時間を費やす。どちらの都市にも専任のIT担当者はいない。現地ITに最も近い存在は、上海のオフィスマネージャーで、彼女はリース契約や宅配便、給湯室の備品管理も兼任しながら、「Wi-Fiが落ちたらベンダーに連絡する」という非公式な追加業務を引き受けている。それ以外のすべて——ID管理、エンドポイントポリシー、ヘルプデスク、セキュリティツール、コラボレーションスタック——は、欧州本社の小規模なITチームが所有し運用している。

このチームの実力は確かで、彼らが構築したグローバル標準も実際に堅牢だ——単一のIDプロバイダー、統一されたエンドポイント構成、ひとつのコラボレーションスイート、ひとつのチケットシステム、どこでも一貫して適用されるひとつのセキュリティポリシー。問題は時計にある。上海と北京は、時期にもよるが欧州本社よりおおむね6〜8時間進んでおり、これは2拠点の勤務時間全体が、欧州チームが出社する前か退社した後のどちらかに完全に収まることを意味する。上海で朝9時にノートPCが認証できないというチケットは、早くても欧州チームの昼前まで拾われない——その頃には、上海のスタッフはすでに回避策を見つけているか、その日はあきらめているか、グループチャットで同僚に聞いているかのいずれかだ。これら3つの結果のいずれも、どこのサービスデスク指標にも表れない——これこそが、この問題が欧州側からこれほど長く見えないままでいる理由である。

実際の問題その1: 中国語で実際に機能するサービスデスクであること

欧州のサービスデスクは英語で運営されている。英語が会社全体の共通言語だからだ。上海のエンジニアリング・デリバリー担当者、そして北京の営業チームの相当数は、業務をこなすには十分な英語力を持っているが、時間的プレッシャーのもとで、見知らぬ担当者に対して第二言語で技術的な問題を正確に説明することに、必ずしも自信を持っているわけではない。実際に起きるのは、助けを求められなくなることではなく、静かに問い合わせをやめてしまうことだ。中国語なら2分で説明できるチケットが、放置されたり、非公式に回避されたり、問題が大きくなってからようやくエスカレーションされたりする。これは研修の問題でも、規律の問題でもない。言語とタイムゾーンが重なった問題であり、単一のグローバルサービスデスクが、どれだけ優れた運営をしていても、単独で完全には解決できないものだ——だからこそ、欧州の時計に合わせた英語のサービスデスクではなく、中国の営業時間中に実際に中国語で機能する24時間365日のヘルプデスクがあるかどうかで、問題が大きくなる前に報告される件数が変わってくる。

実際の問題その2: 越境ネットワークのパフォーマンスは想定ではなく実測すべきである

欧州のITチームがコラボレーションスタック、VPN、監視ツールを構築する際には、比較的均一なグローバルネットワーク体験を前提にしている。この前提は他の海外拠点では成り立つからだ。しかし中国オフィスについて、この前提が確実に成り立つとは限らない。その正直な理由は、特定のサービスがブロックされているとか、見出しになるような帯域幅の数字があるといったことではない。中国とそれ以外のインターネットとの間の越境接続は、経路によって、時間帯によって、どのクラウドリージョンやサービスが関わるかによって挙動が異なり、しかもその挙動は時間とともに変化する、という点にある。唯一責任ある姿勢は、想定するのをやめて実測を始めることだ。上海と北京のチームが実際に依存しているアプリケーションを、その拠点から、人々が実際に使う時間帯にテストし、シンガポールや東京のオフィスでうまくいった前提ではなく、実際に観測された結果をもとに設計する。憶測ではなく知っておくべき事実がひとつある。中国本土におけるMicrosoft 365は、別運営のサービスとして提供されている（歴史的には、一般に「世紀互聯（21Vianet）」の名で知られるライセンスを受けた現地事業者を通じて運営されている）。これは、多くの欧州チームが慣れ親しんでいるグローバル版Microsoft 365テナントとは、運用面で実質的に異なる点であり、このプラットフォームを避ける理由ではなく、中国オフィスが必要とする具体的なワークフローがグローバル版と同じように動くと想定する前に、実際にテストすべき理由である。

実際の問題その3: エンドポイント管理とソフトウェア配布は挙動の異なる回線の上で行われる

欧州・米州のユーザーを念頭に設計され、一連のクラウドエンドポイントから会社の全ノートPCにOSアップデート、セキュリティパッチ、アプリケーションパッケージをプッシュするグローバルなエンドポイント管理プラットフォームは、コラボレーションスタックと同じ実測の問題に直面する。欧州や米国のオフィスでは誰にも気づかれずに一晩で完了するパッチサイクルが、より長く変動の大きい経路を経由する上海や北京のデバイスでは、異なる挙動を示すことがある——これも、何かが特定的にブロックされているからではなく、実際に配信される体験を、他の場所での挙動から推測するのではなく、中国オフィスから実測しなければならないためだ。実務的な対処は、たいてい劇的なものではなく、アーキテクチャ上のものだ。大容量パッケージのローカルキャッシュや地域配布ポイント、欧州ではなく中国の営業時間に合わせたパッチウィンドウのスケジューリング、単一のグローバル平均ではなく拠点ごとにエンドポイントの適合率を報告する監視——単一平均は、中国特有の問題を静かに覆い隠してしまう。これはまさにインフラ展開の領域であり、拠点ごとにパッチ適合率の低下に消火活動で対応するのではなく、配布アーキテクチャを一度で正しく整えることが求められる。これはITインフラ展開がカバーする範囲の仕事だ。

実際の問題その4: 本社にはハードウェア調達と発票への対応プロセスがない

欧州の財務チームは、欧州のITベンダーからの請求書を処理する方法を知っている。しかし通常、中国でノートPC、モニター、ネットワーク機器を調達するための確立されたプロセスを持っておらず、「発票（ファーピャオ）」——中国の法人が調達を正しく計上・経費処理するために必要な公式な税務インボイスにも馴染みがない。発票は単なる外国語の領収書ではなく、独自のコンプライアンス要件を持つ、規制された特定の書類の種類である。これを放置すると、結果はたいてい2つの失敗パターンのいずれかになる。上海の誰かが個人のクレジットカードで機器を購入し、財務が処理方法を知らない発票をめぐって何か月も払い戻しのために格闘するか、あるいは、誰も自分が正しくやっているという確信を持てないためにハードウェア調達が静かに滞り、スタッフは他の場所であれば会社が到底許容しないほど長く、古い機器で我慢することになる。どちらも技術的な問題ではない。どちらもプロセスの問題であり、ローカルの調達と請求書発行の実務をすでに熟知している中国拠点のパートナーであれば、これを上海オフィスと欧州の財務機能の間で繰り返される摩擦点としてではなく、サービスの通常業務のひとつとして吸収できる。

実際の問題その5: 等保とPIPLの義務は、本社ポリシーに関わらず現地法人にのしかかる

会社のグローバル情報セキュリティポリシーは欧州で作成され、ほぼ間違いなくGDPRを基準にしている。そしてそれは実際に優れたポリシーである。しかしそれ単独では、中国において十分ではない。ネットワークセキュリティ等級保護制度（等保、MLPS）と個人情報保護法（PIPL）は、上海と北京のオフィスを運営する中国の法人に具体的に紐づく義務を課す——データ分類とシステムの等級付け要件、関係するシステムに応じたセキュリティ評価と届出義務、そしてGDPRとは実質的に異なる越境データ移転に関する規則である。どれだけよく書かれた欧州のプライバシーポリシーであっても、これらの義務を履行するものではなく、「グローバルポリシーですでにカバーしている」という主張は、中国の規制当局の前では通用しない。これは、グローバル標準と現地の実情との間のギャップが最も大きい領域のひとつであり、間違えれば、単にユーザーが不便を感じる程度では済まない、実質的な規制上のリスクを伴う——だからこそ、これは一度限りの法務プロジェクトとして書類を整えて終わりにするのではなく、マネージドITセキュリティサービスのもとで継続的なサービス関係の一部として扱われるべきものである。

通常、何がこの問題を表面化させるのか

このような状況にある企業が、自主的に中国のIT体制の見直しに着手することはまれだ。たいてい、何か具体的な出来事がそれを議題に押し上げる。多くの場合、本稿冒頭で描いたような場面——チケットが正式なキューから静かに消え、グループチャット上の非公式な対応として再浮上するパターンに、本社の誰かが最終的に気づき、疑問を持つ、というものだ。時には、中国におけるデータ取り扱いとコンプライアンスについて鋭い質問を投げかける顧客やパートナーのデューデリジェンス質問票がきっかけとなり、正直な回答が気まずいものであることが判明する。時には、セキュリティインシデントやニアミスが、グローバルなセキュリティスタックが中国オフィスから実際どう機能しているか、誰も検証したことがなかったという事実を露呈させる。そして時には、単純に成長がきっかけとなる——上海から市場をカバーする3人だけで始まった北京オフィスが15人のチームに成長し、3人には機能していた場当たり的な体制が、15人には明らかに機能しなくなる。

Brocentの見解: 失敗の本質は放置ではなく思い込みである

正直に言えば、こうだ。アジアでの唯一の拠点が中国であるという欧州や北米のソフトウェア企業が、中国オフィスをないがしろにするのは、多くの場合、放置によるものではない。経営陣はたいてい真剣に向き合っており、グローバルIT標準もたいてい実際に優れている。本当の失敗の本質は、その標準が中国にもそのまま通用すると思い込んでしまうことにある。実際には、言語、タイムゾーン、越境ネットワークの挙動、現地の調達と発票処理、そして独自のコンプライアンス体制という、いくつかの具体的な要素が、意図的な調整なしにはそのまま持ち込めない。

Brocentの見解は、2007年に北京で創業し、それ以来まさにこの種の外資系テクノロジー企業のITを運営してきた経験に基づいている。現実的な答えは、グローバル標準を捨てて中国向けに独自のものを一から構築することでもなければ、グローバル標準がまったく調整を必要としないふりをすることでもない。それは、短く、意図的に選び抜かれ、文書化された「中国例外リスト」だ——一度だけ決定し、書き留め、実際に現地で責任を負う人物が所有する——サービスデスクが中国の営業時間内に中国語でどう機能するか、エンドポイント配布が中国の回線に合わせてどう設計されるか、現地の調達と請求書発行がどう機能するか、等保とPIPLの義務がどう履行されるか、といった真に異なる扱いが必要な少数の項目をカバーする。それ以外の、変える必要のないものは、すべて本社が構築した通りのままにしておく。これは、この立場にある大半の企業が実際に行き着く姿——本社の誰も知らない、文書化されていない、その週たまたま問題を解決した上海オフィスの誰かが個別に編み出した非公式な回避策の寄せ集め——とはまったく異なるものだ。

本格的な中国ITサポートが実際にカバーする範囲

欧州のグローバル標準と実際に機能する中国事業とのギャップを本当に埋めるサポート体制と、そのギャップを静かに開けたままにしておく体制とを分ける要素は、5つある。

中国の営業時間内に機能する、中国語・英語対応のサービスデスク。 上海と北京のスタッフは、自分が最も正確に表現できる言語で、実際に働いている時間帯にチケットを起票でき、欧州が目を覚ますのを待たずに応答を得られるべきだ。これだけで、これまで見えていなかった問題のかなりの部分が表面化する傾向がある。人々が静かに報告をやめてしまう2つの主な理由を、同時に取り除くからだ。

両都市に対応する現地オンサイト派遣体制。 上海と北京は十分に離れているため、「中国をカバーしている」ということは、たまたまどちらかの都市に拠点を置き、もう一方への訪問を特別出張扱いするエンジニア1人ではなく、両都市それぞれに実際のオンサイト対応能力があることを意味しなければならない。どちらの都市で発生したネットワーク、ハードウェア、オフィス移転の問題にも、本物の現地対応が必要であり、誰も2都市分の予算を組まなかったために静かにリモート対応だけがデフォルトになる、という事態は避けなければならない。

実際の回線に合わせて設計されたエンドポイント・パッチ管理。 同じグローバル配布アーキテクチャをそのまま中国に押し付けてうまくいくことを期待するのではなく、上海と北京から実際に何が起きているかを実測し、その観測結果に基づいてキャッシュ、配布ポイント、パッチスケジュールを調整する。これは、中国オフィスが視野に入る場合、マネージドITクラウドサービス全般に適用されるべき、実測を先に行うという原則そのものだ。

発票を正しく発行する現地調達。 ハードウェアと機器を、最初から中国法人に対して正しく調達・請求・計上し、欧州の財務チームが不慣れなプロセスを学ぶ必要も、上海のスタッフが個人的に費用を立て替える必要もなくす。

コンプライアンス義務を、付随プロジェクトとしてではなくサービスの一部として扱う。 システムやデータフローの変化に合わせて、等保の等級付けとPIPL義務を継続的に見直し維持する。一度の法務案件で対応してそれきりにし、事業の成長とともに静かに陳腐化させるのではない。

上海と北京という2つのオフィスを、それぞれ場当たり的に組み上げた2つの体制としてではなく、ひとつの体制のもとで管理することは、両拠点にわたるID管理、セキュリティポリシー、レポーティングをより一貫して管理する方法でもある——両都市をひとつのSLAでカバーするマネージドITクラウドサービスが、本来ばらばらだったはずの2つのローカルな応急対応を置き換える場面がまさにここにある。

本社に報告する現地採用者1人 vs 場当たり的な現地の修理業者 vs 文書化された「中国例外リスト」でグローバル標準を提供する単一のマネージドITパートナー（Brocentのモデル）

• 本社に報告する現地採用者1人 ——現地に実在の人材を配置できるという点で、言語と現地対応には確かに役立つが、1人の採用者は単一障害点であり、休暇・病気・離職への備えがなく、正式なエスカレーション経路もなく、ネットワークエンジニアリング、エンドポイント管理、セキュリティ、コンプライアンスをすべて同時にカバーできる幅広いスキルを持っていることはまれだ。しばしば、本社からの可視性が限られた非公式な「第2のIT部門」になってしまう傾向もある。
• 場当たり的な現地の修理業者 ——プリンター、配線、オフィス移転といった、まれに発生する物理的な修理には役立つが、構造的に受け身である。24時間365日の対応はなく、エンドポイント群やセキュリティ体制への責任もなく、コンプライアンス対応能力もなく、上海と北京のオフィスが会社の他拠点と本当に同じ水準を満たしているかどうかについての説明責任も存在しない。
• 文書化された「中国例外リスト」でグローバル標準を提供する単一のマネージドITパートナー（Brocentのモデル） ——変える必要のないものはすべて本社が設計した通りに保ちつつ、真に、そして意図的に異なる扱いが必要な少数の要素——中国の営業時間内で機能するバイリンガルのサービスデスク、両都市でのオンサイト対応、実際のネットワーク経路に合わせて調整されたエンドポイント配布、現地の調達と請求書発行、継続的に管理される等保／PIPL義務——を一つひとつ確実に処理する。トレードオフは、書面上は現地採用者1人よりコストがかかることだが、正直な答えを言えば、現地採用者1人は最初から同じ範囲をカバーしていたことなど一度もなかった、ということだ。

よくある質問

「中国ITサポート」には、グローバルヘルプデスクにはない、具体的に何が含まれるのか？

それは、言語やタイムゾーンを問わないグローバルヘルプデスクが構造的に単独では提供できないものを含む。欧州の時計に合わせた英語のサービスデスクではなく、中国の営業時間内に中国語で機能するサービスデスク。中国をひとつの拠点として扱うのではなく、上海と北京の両方に実際に到達できるオンサイト派遣。他の場所と同じだと想定するのではなく、その具体的な拠点から実測されたネットワークとエンドポイントのパフォーマンス。正しい発票発行を伴う現地でのハードウェア調達。そして純粋に欧州のセキュリティポリシーだけでは履行できない等保／PIPLのコンプライアンス義務だ。これらはグローバル標準を置き換えるものではなく、その標準がそのままでは通用しない特定のギャップを埋めるものである。

ローカルでITサポートを購入する前に、中国法人が必要か？

ほとんどの場合、必要だ。登録された現地法人があることで、通常、発票システムを通じて正しく請求される現地でのハードウェア調達や、ほとんどの形態の現地契約のITサービスが円滑になる。また、等保とPIPLの義務が実際に紐づくのも、この法人に対してである。すでに中国に社員がいるが正式な現地法人をまだ持っていない企業は、これを法務・財務アドバイザーとともに最初に解決すべき課題のひとつとして扱うべきだ。それによって、現地で調達・契約できるものと、当面は親会社を経由させる必要があるものとが決まってくるからだ。

グローバルなコラボレーションツールが各拠点で実際に十分なパフォーマンスを発揮しているかどうかを、どうテストすべきか？

上海と北京のスタッフが日々実際に頼っている具体的なアプリケーション——ビデオ通話、ファイル同期、IDおよびVPN経路、業務の中核をなすSaaSプラットフォームなど——を、その拠点から、人々が実際に利用する時間帯に、単発のチェックではなく数日間にわたってテストする。同じアプリケーションを欧州や米国のオフィスから見た場合と比較し、意味のあるギャップが見つかれば、それを一度限りの不便として我慢するのではなく、設計への入力として扱う。特定のサービスが影響を受けているかどうかを、その拠点から直接テストせずに想定するのは避けるべきだ。越境ネットワークの挙動は時間とともに、また経路によって変化するものであり、だからこそこの点では想定より実測が勝る。

等保とPIPLの責任は自社にあるのか、それとも提供事業者にあるのか？

法的責任は、上海と北京のオフィスを運営する中国法人、つまり実質的には自社にあり、外部委託先の事業者にはない——マネージドITパートナーが、あなたに代わってその法的責任を引き受けることはできない。有能なパートナーができるのは、あなたを弁明可能な立場に保つための運用面の作業だ。システムの等級付け、等保要件に沿った継続的なセキュリティ管理、PIPLコンプライアンスを支えるデータ取扱い実務を、一度限りのプロジェクトとしてではなく、サービスの継続的な一部として提供する。最終的な責任の所在、そして等級付けと届出の承認は、依然として自社の法務顧問が関与すべきものである。

ひとつの事業者が、ひとつのSLAで上海と北京の両方をカバーできるのか？

可能であり、この規模の企業であれば、通常はそのほうが一貫性のある選択肢となる。両拠点はID管理、セキュリティポリシー、エンドポイント基準、レポーティングを共有しており、単一の事業者を使うことで、互いに連携しない2つの現地ベンダーを管理する調整コストを避けられるからだ。とはいえ、そのSLAは、「中国」を地図上のひとつの点であるかのように扱うのではなく、上海と北京がそれぞれ独立した現地拠点であり、それぞれに固有の対応コミットメントを持つべきであることを、依然として反映すべきである。

後に3つ目の中国の都市に拠点を開設した場合、何が変わるのか？

最初の2拠点が場当たり的な対応ではなく文書化されたアプローチで構築されていれば、多くの企業が予想するよりも変化は少ない。サービスデスク、ID・セキュリティのベースライン、調達と請求書発行のプロセス、そしてコンプライアンスの枠組みは、大部分がゼロから作り直すのではなく拡張できるように設計されている。3つ目の都市が主に追加するのは、もうひとつのオンサイト派遣拠点と、拠点規模が十分に大きければ、その拠点固有のネットワーク実測だ。パフォーマンスが自動的に同じになると想定するのではなく、上海と北京ですでに用いてきた「先に実測し、それから設計する」という同じアプローチに従う。

事業の実際の運営に合った中国ITサポートを手に入れる

上海の本社オフィスと北京の営業オフィスは、欧州で構築されたグローバルIT標準に乗っかるだけの、もう2つの拠点ではない。それらは異なる言語で、異なる時計の上で、想定ではなく実測すべきネットワーク経路を介して稼働しており、本社ポリシーがどう書かれていようと現地法人にのしかかるコンプライアンス体制のもとに置かれている。だからといって、一からやり直す必要はない。必要なのは、中国が本当に異なる扱いを必要とする箇所を明記した、短く、意図的に選び抜かれ、文書化されたリストを、それに実際に責任を持つ人物が所有し、他のすべての場所ですでに十分に優れており、これからもその水準を保ち続けるグローバル標準の上に重ねることだ。

Brocentは2007年に北京で創業して以来、中国で事業を展開する外資系テクノロジー・ソフトウェア企業を支援し続けており、アジアでの唯一の拠点が中国であり、自社のために本当に作られたわけではない欧州標準の上で運営しようと奮闘している数十社の企業と、まさに同じ対話を重ねてきた。もしこれが、貴社が今日置かれている状況に思えるなら、テンプレートの見積もりではなく、貴社の上海・北京オフィスが実際に何を必要としているかから始まる対話をご希望の場合は、お問い合わせください。