四つの言語、一つのチケット、五つの記録

要点： ある日本の製造業のシンガポール地域統括オフィスは、さらに 4 つの ASEAN 諸国のチームを支えている。チケットは英語・日本語・タイ語・インドネシア語で上がり、東京への月次報告は日本語でなければならない。この状況を支えてきたのは善意と、いまや単一障害点になっているバイリンガルの管理担当者 1 名である。解決策は多言語人材をもっと採ることではない。ひとつの記録、ひとつのシステム、そして定義された記録言語である。

問題を生む構造：ASEAN 地域統括拠点としてのシンガポール

日本に本社を置く製造業の多くが、東南アジア事業をシンガポールの地域統括オフィス経由で運営している。理由はいずれも筋が通っており、大半は商業上のものだ。地域財務機能がここにあり、資金管理と法人構成が最も整理され、地域営業責任者を置きやすく、日本人駐在管理者にとっては域内の他の赴任地に比べて言語や子女教育の摩擦が小さい。地域統括オフィスは、マレーシア、タイ、ベトナム、インドネシア、しばしばフィリピンにまたがる工場・営業チーム・代理店を調整する。

IT の観点でこの構造が興味深いのは、それが本社ではなく調整機能を担う拠点だという点である。地域に対する権限はあるが本社に対する権限はない。地域に対する責任はあるが、各国の予算権限を必ずしも持たない。上へは東京に報告し、横へは各工場長と、下へは各国チームとやり取りする。そしてその三方向を、それぞれ異なる言語で行っている。

本社はこの層をほとんど見ていない。東京から見れば話は単純だ。シンガポールに地域統括オフィスがあり、IT の取り決めがあり、月次報告が届く。報告が伝えないのは、その報告を作るのにどれだけの人手がかかっているかであり、その「IT の取り決め」が実際には 5 つの取り決め、5 社のベンダー、5 種類のチケット形式、そして 5 通りの前提であるという事実である。

これは人の問題ではなく構造の問題であり、その点は正確に述べておく価値がある。このシナリオで仕事ができていない人は 1 人もいない。地域 IT マネージャーは有能である。各国ベンダーも個別には十分だ。シンガポールのバイリンガル管理担当者は全体を支えており、しかもよく支えている。破綻の型は、この構造に単一の記録がなく、その記録が存在する言語も定義されていない、という点にある。以下に挙げる問題はすべて、この二つの欠落から派生している。

シナリオ：シンガポールの 75 名と、その背後の 4 か国

説明のための複合シナリオを考えたい。特定の顧客ではなく、この領域で繰り返し現れる案件の形から組み立てたパターンである。東京上場の日本の精密製造企業が、約 75 名のシンガポール地域統括オフィスから ASEAN 事業を運営している。地域営業、アプリケーションエンジニアリング、小規模な財務・人事機能、そして常に移動している地域品質チームである。

シンガポールの背後には、より小さな 4 つの国別チームがある。クアラルンプールは約 20 名、大半が営業とサービスエンジニア。バンコクは 15 名で、代理店との関係と小さなサービス拠点に紐づいている。ホーチミンは 12 名、急成長中で、最も新しい法人だ。ジャカルタは 18 名で、倉庫機能を含む。いずれの拠点にも専任 IT はいない。それぞれに現地ベンダーがおり、契約時期も条件もばらばらで、その時点でその国を見ていた人物がそれぞれ手配したものである。

言語の問題を厄介にしているのは人員構成だ。日本人駐在管理者は地域統括オフィスの上層と、1〜2 の国別拠点にいる。シンガポールのスタッフは英語で働き、非公式な場では中国語もよく使う。マレーシアのスタッフは英語とマレー語。タイのスタッフは圧倒的にタイ語で働く——「英語で通じる」という前提が最も鋭く崩れるのがこの国だ。ベトナムのスタッフはベトナム語で、英語力は職種と世代で大きく異なる。インドネシアのスタッフはインドネシア語と英語である。

そして報告ラインがある。東京は月次の IT 報告を日本語で求める。英語資料に添えた翻訳要約ではない。日本語で書かれ、本社が使う語彙を用い、本社が慣れた粒度で書かれた報告である。シンガポールのオフィスで、これを職務記述書に持っている人は 1 人もいない。毎月末、あのバイリンガル管理担当者が、5 つのソースから手作業で組み上げた表計算をもとに作成している。

この構造が実際に生む問題

• チケット品質が受付の時点で崩れる。 時間に追われながら第二言語で書くと、問題の記述は劣化する。「ログインできない」は、パスワード失念、アカウント期限切れ、ライセンス未更新、条件付きアクセスによるブロック、MFA デバイスの交換、ネットワーク経路の断——そのいずれでもありうる。母語であれば、その違いはたいてい最初の一文で述べられる。第二言語ではそうならない。結果として、障害対応の最初の 1 時間は修理ではなく「実際に何が起きたのか」の特定に費やされる。これを 4 か国分掛け合わせれば、あらゆるチケットにかかる恒常的な税になる。
• 東京へのエスカレーションには、誰の担当でもない翻訳作業が必要になる。 予算承認、セキュリティインシデント、グローバル標準に影響する変更など本社の関与が必要な事柄が起きるたび、誰かが日本語の要約を書かなければならない。この作業に名前は付いていない。手が空いていてできる人に落ちる。実務上それは、毎回同じ人物を意味する。
• SLA の時計が 3 つのタイムゾーンと 5 つの祝日カレンダーをまたぐ。 日本標準時、シンガポール時間、インドシナ時間は 1〜2 時間しか違わない。だからタイムゾーンの問題は些細に見え、そのせいで本当の問題が隠れる。祝日カレンダーがまったく異なるのだ。タイの祝日、マレーシアの州単位の祝日、インドネシアの国民の祝日、ベトナムのテト、日本のゴールデンウィークとお盆、そしてシンガポール独自の暦。「どの時間が数えられるか」で当事者の認識が食い違えば、4 時間の応答コミットメントには意味がない。
• 5 社のベンダーは 5 つの記録を意味し、地域の全体像は存在しない。 各国ベンダーはそれぞれのチケットシステム、それぞれの重大度定義、それぞれの「解決済み」の解釈、それぞれの報告形式を持つ。「前四半期に地域全体でパスワードリセットが何件あったか」に答えるには、誰かが手作業をするしかない。同じ再発障害が 3 か国で起きていることに気づく手段もない。3 つの記録を同時に見ている人がいないからだ。
• 月次報告は手作業で組み立てられる。 5 つのエクスポート、1 つの表計算、1 人、月に 2 日。この報告の正確さは、整合しない 5 つのソースが許す範囲に留まる。しかもその人が不在なら、他の誰にも再現できない。
• 単一障害点が人であり、しかも全員がそれが誰か知っている。 そのバイリンガル管理担当者は IT の専門職ではない。できてしまうから、そして誰かがやらねばならないから引き受けたのである。この人が退職すれば、地域 IT 機能は緩やかに劣化するのではなく、東京が実際に読んでいる成果物の産出が止まる。

Brocent の視点：翻訳は症状であり、5 つの記録が病である

この状況への直感的な対応は、言語で採用することだ。日本語とタイ語ができる人を探す。インドネシア語話者を加える。バイリンガルのコーディネーターを採用して報告作業を管理担当者から引き取る。理解できる反応だが、これは機能しない。理由は率直に述べる価値がある。言語の問題は、記録の問題の下流にある。

5 社のベンダーが 5 つの独立したチケットシステムを維持しているなら、どれだけ語学力を足しても地域の全体像は生まれない。採用した多言語人材は、互換性のない 5 つのデータセットのあいだに座る非常に高価な翻訳者になり、その人が休暇を取れば問題はそのまま戻ってくる。単一障害点をより有能にしただけで、単一であることは変わっていない。

結果を実際に変えるのは、次の二つの構造的な事柄である。

5 か国すべてを貫く単一のチケット記録システム。そこでは、どの言語で起票されたかに関わらず記録が完全である。 母語での受付はきわめて重要だ——先述のチケット品質の崩壊を避ける手段そのものである——が、その目的は良い記録を作ることであって、それ自体が目的ではない。タイ語で起票されたチケットは、シンガポールで英語で起票されたものと同じシステムに、同じ重大度分類、同じカテゴリ体系、同じ解決フィールドを伴って収まるべきである。そうなって初めて、地域の全体像はプロジェクトではなく一つのクエリになる。

定義された記録言語と、定義された報告言語。それぞれに担当者名を付ける。 この二つは通常同じ言語ではない。記録は英語で、東京への報告は日本語——これは正常で運用可能な取り決めである。運用できないのは、どちらも定義しないまま放置することだ。すると記録はチケットが偶然到着した言語に流され、報告は「自分の責任だと感じた人」が作ることになる。報告義務を担当者名と頻度とともにサービス契約に書き込めば、全体が善意に依存しなくなる。

自社のカバー範囲については、誇張するより明確に述べたい。Brocent の 24×7 グローバルサービスデスクは中国・香港・マレーシアの分散拠点から運営され、年間およそ 15,000 件のインシデントとサービスリクエストを扱い、着信の 90% を 40 秒以内に応答し、70 以上の分野の認定を持つ 150 名超のヘルプデスク要員が、標準中国語・広東語・英語で支援している。日本語対応は Brocent の日本地域オフィスを通じて提供しており、これが日本本社の精密製造企業に対して東京・大阪で日英バイリンガルのマネージド IT を提供している体制である。ASEAN 各市場の現地語対応は各国内で提供しており、これがシンガポール・クアラルンプール・ジャカルタを横断する統一サービスデスクの運営形態——3 社の現地ベンダーを一つの説明責任ある SLA に置き換えた案件——の背景でもある。これが正直な姿である。明確な中核言語セットを持つ中央デスクを、各国拠点と日本オフィスの能力が拡張し、そのすべてが一つの記録に書き込まれる。

実務上、何が変わるか

• 一つの記録システムと、各国に適した受付。 ユーザーは自分が使いやすい言語で、電話・メール・ウェブチャット・ポータルからチケットを起票でき、一貫した分類体系を持つ単一のシステムに収まる。Brocent のデスクは ServiceNow、SDP、Jira ほか主要な ITSM プラットフォームと連携するため、本社がすでにプラットフォームを指定しているなら、地域デスクはその横に別建てするのではなく、そこに書き込む。
• 合意され明文化された記録言語。 通常はチケット記録を英語にする。域内の最大公約数であり、本社も読めるからだ。要点は英語を選ぶことではなく、それが偶然ではなく決定であることにある。
• 定義された報告言語・頻度・担当者。 月次 SLA 指標レポートは標準的な ITIL ベースのサービス範囲に含まれる。東京が読む報告が日本語でなければならないなら、それは担当者と期日を持つ成果物であって、管理担当者が月末金曜に行う厚意ではない。
• 祝日とタイムゾーンのカレンダーを、障害時に発見するのではなくカバレッジモデルに織り込む。 どの国がどの日を休むのか、その日にどの水準の対応があるのか、そしてタイでは祝日でシンガポールでは通常営業日という日に応答コミットメントが実際に何を意味するのか。当社の地域金融サービス案件が統一の 8×5×4H コミットメントで運営されているのは、まさにその代替案——5 通りの現地解釈——が管理不能だからである。
• 国ごとの指名されたエスカレーション担当と、物理作業が必要な場所の登録済みオンサイトエンジニア。 地域デスクは大半をリモートで解決するが、ジャカルタ倉庫で故障したスイッチには人手が要る。Brocent はシンガポール、マレーシア、タイ、ベトナム、インドネシア、フィリピン、日本を含む 19 か国のフットプリントで登録済みの現場派遣エンジニアを維持しており、派遣は別ベンダーへの電話ではなく同じ取り決めの一部になる。
• サービス範囲内でのベンダー折衝。 障害の原因が通信事業者、ビル側のネットワーク、ソフトウェアベンダーにある場合、その追跡は ITIL ベースの範囲に明示的に含まれ、地域統括オフィスに差し戻されない。これは 5 か国構造ではとりわけ重要である。地域 IT マネージャーの週の時間を最も食っているのが、まさにこの種の作業だからだ。

地域 IT サポートの三つの運営形態を、正直に比較する

• 国ごとに 1 社のベンダー。 受付は現地語、現地の関係があり、素早く現場に行ける人がいる。その代償は、5 種類のチケット形式、5 通りの重大度定義、5 通りの報告様式、地域の全体像の欠如、市場をまたいだ障害パターンを見つける手段のなさ、そして手作業で組み立てるしかない月次報告である。これが既定の形になるのは、一国ずつ積み上がるからだ。誰も設計として選んだわけではない。
• 英語のみの地域デスク。 一つのシステム、一つの分類体系、一つの報告、即座の地域可視性、そして 5 社体制よりかなり安い運営コスト。その代償は受付時の品質低下であり、英語が最も一般的でない市場に集中する。このフットプリントで言えば、タイとベトナムで最も顕著だ。使いにくいと感じたデスクをユーザーは迂回し、1 年以内に国レベルのシャドー IT が再び現れる。
• 多言語の地域デスク（Brocent モデル）。 件数を担う言語での母語または母語に近い受付、5 か国を貫く一貫した分類体系の単一チケット記録システム、定義された記録言語、担当者名の付いた契約成果物としての本社言語レポート、カバレッジ・コミットメントに織り込まれた祝日とタイムゾーンのカレンダー、そして同一契約下での各国派遣。その代償は、地域統括オフィスがこれまで避けてきた決定を下す必要があること——記録言語は何か、東京向け報告の担当は誰か、各国の祝日に応答コミットメントはどう計測されるか——そして、5 つの小さな契約ではなく一つの商業関係になることであり、これは本社によっては説得が要る。

ここからどう進めるか

診断の問いは「何言語に対応する必要があるか」ではない。東京向け報告を書いている人が明日辞めたとして、他の誰かがシステムだけから翌月の報告を作れるか。 答えが「作れない」なら、問題は言語ではなく記録にある。バイリンガルのコーディネーターをもう 1 人採っても、解決ではなく先送りにしかならない。

Brocent は 2007 年からアジアでマネージド IT を手がけ、2021 年からはシンガポールに本社を置き、このパターンの両側を現在も運用している。日本本社の精密製造企業に対する日英バイリンガルのマネージド IT と、シンガポール・マレーシア・インドネシアにまたがる地域グループ向けの、各国派遣を伴う統一マルチカントリー・サービスデスクである。プラン構成と各ティアの内容はマネージド IT サポートで確認でき、24×7 多言語ヘルプデスクとマネージドサービスの詳細もご覧いただけます。5 か国の現状についてお話しされたい場合はお問い合わせください。

よくある質問

御社のエンジニアは実際に日本語・タイ語・インドネシア語を話せますか。

正直かつ具体的にお答えします。Brocent の中央 24×7 グローバルサービスデスクは、中国・香港・マレーシアの拠点から標準中国語・広東語・英語で運営されています。日本語対応は日本地域オフィスを通じて提供しており、これによって現在、日本本社の製造企業に対し東京・大阪で日英バイリンガルのマネージド IT を提供しています。ASEAN 各市場の現地語対応は各国内で提供しており、シンガポール・クアラルンプール・ジャカルタを横断する統一サービスデスクもその形で運営しています。言語ごとの母語話者の人数を主張するよりこの構造をお示しするほうが誠実だと考えています。ユーザーが自分の使いやすい言語で応答を得られるかどうかを決めるのは、まさにこの構造だからです。

チケットをある言語で起票し、別の言語で報告することはできますか。

できますし、5 か国を抱える地域統括オフィスにとっては、それが妥協ではなく正しい設計であることがほとんどです。受付はユーザーが業務で使う言語で行います。それが障害の正確な記述を生むからです。チケット記録は単一の定義された言語で維持します。そうすることで地域の全体像が手作業ではなくクエリになります。本社への報告は本社の言語で、契約上の成果物として作成します。三つの言語、三つの目的、そのそれぞれが意図的に選ばれています。

5 か国の祝日はどう扱いますか。

契約開始前にカレンダーをカバレッジ・コミットメントへ織り込みます。障害の最中に発見するのではありません。実務的には、どの国がどの日を休むか、その日にどの水準の対応があるか、そしてある日が一方の市場では祝日、他方では通常営業日である場合に応答コミットメントをどう計測するかを合意することを意味します。単一の地域契約が 5 つの現地契約より運用しやすい理由の一つがこれです。祝日の問題が、暗黙のうちに 5 回ではなく、明文で 1 回だけ答えられるからです。

各国にベンダーが必要ですか。

各国に「能力」が必要なのであって、各国に別々の商業関係が必要なわけではありません。この区別は重要です。現地の関係そのものはたいてい問題ではなく、断片化が問題だからです。Brocent はこのシナリオの 5 市場すべてを含む 19 か国のフットプリントで登録済みの現場派遣エンジニアを維持しており、現場作業は同じ契約の下で、同じチケットシステムに、同じ SLA に対して行われます。これはまさに、シンガポール・マレーシア・インドネシアの 3 社の現地ベンダーを一つの説明責任ある SLA に置き換えた地域金融グループの案件で実現した変化です。

本社が読む報告は誰が書くのですか。

適切にスコープされた取り決めであれば、サービス提供者が、本社の言語で、合意された頻度で、名前の付いた成果物として作成します。月次 SLA 指標レポートは当社ヘルプデスクサービスの標準的な ITIL ベース範囲に含まれます。重要な変化は「報告が存在すること」ではありません——それは御社にすでに存在します——そうではなく、報告の作成が、厚意ある管理担当者が担う無主の作業であることをやめ、担当者と期日と一貫した基礎データを持つものになる、ということです。

日本にある既存の社内 IT とはどう連携しますか。

横に並ぶのではなく、その下に位置づきます。この形の案件では通常、本社 IT 機能がグローバルアーキテクチャ、セキュリティポリシー、アプリケーションのオーナーシップ、ベンダー戦略を保持し、地域側の取り決めがエンドユーザー支援、インシデントおよび問題管理、現場派遣、地域レポーティングを担当します。実務上の統合点は二つです。ITSM プラットフォーム——東京が ServiceNow、Jira、SDP を指定しているなら、地域デスクはそのインスタンスに書き込みます——と、エスカレーション経路で、これは双方に指名された担当者が必要です。この二点を正しく設計することが、立ち上げ作業の大半を占めます。

5 社の現地ベンダーと比べて、地域カバレッジのコストはどうですか。

項目単位で比べると、たいてい既存の体制のほうが有利に見えます。小額の現地契約 5 本はそれぞれ単独では安く見え、隠れたコストは IT の外——報告の組み立てに費やす月あたりの日数、言語の曖昧さで各チケットの冒頭に失われる時間、地域 IT マネージャーが第三者ベンダーを追いかける時間——にあるからです。現実を反映した比較にはそれらが含まれます。それを別にすれば、価格は人数、対応時間帯、各市場で必要な現場派遣の量によって決まります。プラン構成と各ティアの内容はマネージド IT サポートのページに記載していますが、スコープを定めた金額の提示には、実際の国別構成についての対話が必要です。