フロアは広東語、チケットは英語 — 言語要件がオンサイトITのコストとリードタイムに与えるもの

結論から: 作業範囲書（SOW）に書かれた言語要件の一行は、好みではなく人員配置上の制約です。候補者プールを狭め、プールが狭まれば料金も最短着任日も動きます。どれだけ動くかは職務と市場に完全に依存します——ただし「バイリンガル」と書いて終わらせるのではなく、*どの言語がどの仕事を担うのか*を明示すれば、コストは大きく下がります。

フロアの言語と、チケットシステムの言語は違う

地域IT責任者の多くが見覚えのある香港拠点を挙げます。倉庫チームと受付は広東語で仕事をしており、そのうち何人かは技術的な問題を英語で説明することに慣れていません。チケットシステム、資産台帳、ベンダーへのエスカレーションはすべて英語です。それが会社の業務言語であり、第三者保守契約もそう書かれているからです。そして四半期ごとに、本社が標準中国語でサービスをレビューします。

1つの拠点、3つの言語、そしてそれらの言語が担う3つのまったく異なる仕事。

オンサイトサポートの作業範囲書を書く地域IT責任者は、これをすべて理解したうえで一行だけ書きます。*エンジニアはバイリンガルであること*。書くこと自体はまったく妥当です。しかし人員配置の観点からは、この一行はほとんど値付け不能です。そして見積もりが想定より高く、着任日が想定より遅く返ってくる理由は、たいていこの一行にあります。

この記事は、その一行が書かれてからエンジニアがドアをくぐるまでに実際に何が起きるのか、そしてその一行をどう書けば良い値段で早く人が付くのかについてです。

なぜ「バイリンガル」は値付けするには粗すぎるのか

この語は、どの2言語かを言っていません。どちらが業務言語でどちらが例外かも言っていません。会話なのか記述なのかも言っていません。どの水準で合格とするのかも言っていません。

これが問題になるのは、言語が単一のスキルではないからです。バーコードスキャナーの不具合を流暢な広東語で倉庫主任に説明できる人が、書く英語のチケットはベンダーのサポートエンジニアにとって対処しづらいかもしれません。正確な技術英語を書ける人が、顧客来訪5分前に動揺している受付担当の前に立つ適任者とは限りません。どちらも本物のエンジニアであり、どちらも欠けてはいません。ひとつのものとして書かれた要件の、異なる半分ずつが得意なだけです。

要件がひとつのものとして書かれると、採用担当やリソースマネージャーは、そのすべてを同時に最も厳格に読むしかなくなります。流暢な広東語会話*かつ*流暢な書き言葉の英語*かつ*——しばしば——会話レベルの標準中国語を、1人の人間に、L1エンドユーザーサポートの単価で。その交差集合は存在します。ただし個々の集合よりはるかに小さく、小さい集合からの採用は時間がかかり、引き留めるコストも高くなります。

言語が実際に担っている3つの仕事

言語要件を書く前に、それが本当にカバーしている3つの仕事に分解してください。ほぼすべてのオンサイトSOWは、この3つを異なる比率で必要としています。

ユーザーと向き合う会話。 壊れた当人と話すこと。現地語が最も重要で、ミスマッチの痛みが最も強く出る場面です。ユーザーはすでに苛立っており、その状態で、自分でも理解していない問題を第二言語で説明させられるからです。香港の倉庫、受付、店頭フロアでは、この仕事は広東語であり、他の部分がどれだけ優れていても埋め合わせになりません。

書かれたチケットとドキュメントの品質。 チケット、資産記録、ランブック、引継書に入る内容。この仕事はたいてい英語です。組織の他の部分も、監査人も、第三者ベンダーもそれを読むからです。求められるのは流暢さではなく正確さ——雑談ができることではなく、障害を曖昧さなく記述できることです。

ベンダー・規制当局・本社へのエスカレーション。 ハードウェアベンダーに保証を履行させる、ビルオーナー側の設備担当に説明する、本社に四半期サービスレビューを提示する。これは第三の言語であることが多く、そして決定的に重要なことに、オンサイトエンジニアがやらなければならない仕事とは限りません。アカウントマネージャー、サービスデスクリード、地域コーディネーターが担うことができます。

3つに分解すると、要件はたいてい縮みます。上の香港の例では、*オンサイトエンジニア*が本当に必要としているのは仕事1のための広東語と、仕事2のために足りる書き言葉の英語です。仕事3の標準中国語は、デリバリー体制の別の場所に置いて何ら問題ありません。

ハード要件が1つ増えるごとに、プールと着任日に何が起きるか

メカニズムを、数字を捏造せずに率直に述べます。誠実な答えは「効果の大きさは職務・シニオリティ・市場に依存する」であり、SOWを見ずに固定の上乗せ率を提示する相手は推測で話しています。

ハードな言語要件は候補者プールにかけるフィルターであり、フィルターは足し算ではなく掛け算です。 香港で適切な技術レベルを持つエンジニアのプールは、すでに労働市場の部分集合です。流暢な広東語会話を求めてもほとんど縮みません。広東語はこの都市の多数派の業務言語だからです。自信のある技術英語の記述を求めると、もっと縮みます。その両方*に加えて*ビジネスレベルの標準中国語を求めると、さらに縮みます。個々の要件はどれも平凡です。重ねた結果として、十分だったプールがひと握りの人数になり、その人たちは定義上、同じ要件を掲げる他社全員からも追われています。

プールが小さくなると料金が動きます。 言語が割増として課金されるからではありません。通常そうではなく、Brocentが公開している派遣・オンサイト料金では、料金表下の注記が、数字はフルロードであり、そこに吸収されているものにはバイリンガルエンジニアが——生活費、研修、為替・税務処理、24×7コーディネーションと並んで——明記されています。料金が動くのは希少性が動かすからです。希少な人材は、あなたが採用しようとしている市場でより高い対価を得ますし、フルロード料金はその対象市場を反映せざるを得ません。要件が本当に特殊な場合は、職務自体がより上位のスキルティアに移ることもあり、そちらは明示的に値付けされています——公開されている専任エンジニア料金はティアで上がり、エントリー比でL2が約＋21%、L3が約＋44%です。

プールの縮小は、料金より着任日に強く効きます。 これがバイヤーの最も過小評価する効果です。お金はたいてい工面できますが、今月プールに存在しない人は工面できません。実務では、積み上がった言語要件が最初に現れるのはリードタイムです。ベンチから充当できたはずの職務が探索になり、探索はかかるだけかかります。稼働開始日が動かせないなら、契約書の段階ではなく会話の最初にこの制約を持ち出すべきです。

方向性を一行で: シニオリティを固定したまま、1人に対するハードな言語要件を増やすほど、プールは小さくなり、料金は上がり、着任は遅れます。SOWを読まず、現在の市場を確認せずにその効果の大きさを言う相手は、推測しています。

SOWに誰も書かないトレードオフ

ほとんどのSOWがうっかり排除してしまう選択肢があり、たいていそれが一番お買い得です。

ユーザーと向き合う言語が的確で、書き言葉の英語は「十分」程度のエンジニアに、英語をきちんと書けるサービスデスクを後ろに付ける——これが、すべてにおいて2番手の1人よりも通常は価値が高い。

それぞれで実際に何がうまくいかないかを考えてみてください。前者では、エンジニアはフロアを流暢にさばきます——倉庫主任は広東語で明快な説明を受け、受付担当は安心します——そして彼が起票したチケットは、それを一日中やっているデスクが正確な英語で整えてエスカレーションします。後者では、交差集合に対して採用し、希少性のプレミアムを払い、着任日を長く待ち、そして言語要件を満たすために技術的な深さを譲った人材を得ます。単価が固定なら、どこかが譲られるからです。

後者にはもう一つ、前者にはない失敗モードがあります。個人への単一依存です。言語要件全体を満たす唯一の人物が休暇に入れば、その週の要件は未充足です。言語カバーがレイヤーに分散していれば、不在を乗り越えられます。

同じ言語要件を満たす3つの方法

• すべてを1人でカバーするエンジニア——何のためか: 後ろにサービスデスクを持たない小規模拠点、または守秘のため環境に触れる人数を最小化したい環境。コスト: 希少性のプレミアムが、料金と着任日の両方に。どこで失敗するか: 休暇、病欠、退職。要件はちょうど1人によって満たされています。
• 現地語エンジニア＋バイリンガルサービスデスク——何のためか: 香港の拠点の大多数。コスト: 通常は低め。オンサイト職務についてはより広いプールから採用でき、記述とエスカレーションのレイヤーは既存のデスク能力を使えるからです。どこで失敗するか: デスクのカバー時間帯が拠点と合っていない場合、またはエンジニアとデスクの引き継ぎが定義されていない場合。
• サービスデスク内での言語ルーティング＋オンデマンド派遣——何のためか: 常駐を正当化できるほど物理需要が多くない拠点。コスト: 訪問ごと。その案件で派遣されるエンジニアに言語要件を適用します。どこで失敗するか: 緊急性。特定言語の派遣は、一般的な派遣より短時間で引ける母数が小さくなります。

レイヤー分割モデルと、それを機能させるもの

Brocentがこの状況で実際に運用している構成は3つの部分からなります。名前より分業の中身が重要なので、具体的に記しておきます。

デスクサイドは現地語。 ユーザーの目の前に物理的にいる人は、ユーザーの言語を話します。香港ならフロアは広東語、ユーザーが望む場面では英語です。ミスマッチの被害が最も大きいのがこのレイヤーなので、厳しくすべきなのもここです。

その後ろにバイリンガルのサービスデスク。 Brocentの24×7多言語ヘルプデスクは、標準中国語・広東語・英語でTier 1〜Tier 4のサポートを提供し、中国本土・香港・マレーシアの分散拠点から運用され、電話・メール・ウェブチャット・ポータル経由で年間およそ15,000件のITインシデントおよびサービスリクエストを処理しています。より広いAPACサービスでは、公開されている言語カバーはヘルプデスク層とオンサイト層の双方で日本語、インドネシア語、タイ語まで及びます。重要なのはこのリストではありません。言語カバーが、休暇を取るかもしれない1個人の属性ではなく、多数の人員で構成される*レイヤー*の属性である、という点です。

ドキュメントは方針として1言語に統一する。 資産記録、ランブック、変更記録、引継書をどの言語で書くかを決め、契約に書き込み、会話が何語で行われたかにかかわらず全員に守らせます。香港のオペレーションの多くではそれは英語です。監査人、保険会社、グループIT、第三者ベンダーが読むのがそれだからです。この一つの決定が、言語要件から驚くほど多くの曖昧さを取り除きます。「バイリンガルであること」を「当社のドキュメント標準で書けること」——検証可能なもの——に変換するからです。

このモデルを機能させるのは引き継ぎです。エンジニアが机の前に立っているときチケットを誰が書くのか、ユーザーの言語とベンダーの言語が違うときのエスカレーション経路は何か、ドキュメント言語はどれか。SOWのこの3文は、「バイリンガル」という語よりはるかに価値があります。

良い値段が付く書き方

実践的な書き換えです。*エンジニアはバイリンガルであること*の代わりに、次のように書いてください。

• 口頭・ユーザー対応: 母語または母語に近い広東語必須。会話レベルの英語必須。
• 記述: チケット、資産記録、引継書において、定められた標準に沿った明快な技術英語を書けること。顧客向け文書の起草は求めない。
• 標準中国語: オンサイトエンジニアには求めない。アカウント管理および四半期レビューのレイヤーで求める。
• ドキュメント言語: 英語。やり取りの言語にかかわらず、すべての記録について適用。
• カバー: 言語要件がオンサイトエンジニアの勤務時間外にも成立しなければならない場合は、明示してください。要件が「個人」から「シフト表」に変わるからです。

どの行も検証可能であり、*求めない*と書いた行は、プールから外れたフィルターです——料金とリードタイムが戻ってくるのは、まさにそこです。この版を読んだサプライヤーは、いくらでいつ始められるかを1日で答えられます。「バイリンガル必須」だけを読んだサプライヤーは最悪ケースを前提にするしかなく、それに従って値付けし、それに従ってスケジュールを引きます。

SOWに書く価値のあることがあと2つ。その要件が合否を分けるハード要件なのか、技術的深さと引き換えにできる希望なのかを明記してください。明記がなければサプライヤーはハードだと想定します。それが安全な読みだからです。そして、どう検証するつもりかも書いてください。「どう検証するのか」は、求めたものが実際に手に入るかどうかを決める問いです。着任前に、指名された当人と対象言語で短い技術的な会話を交わすことは、どんな証明書よりも価値があります。

言語レイヤーが属する場所

多言語カバーを提供するのが最も安く、最も頑健なのはサービスデスクです。個人ではなくチームで担っているからです。現地語・ユーザー対応の言語が譲れないのはオンサイトエンジニアのところです。そして両者が乖離するのを止めるのがドキュメント標準です。

構造はそれだけです。デスクサイドに厳しい要件を1つ、その後ろにレイヤーを1つ、両者を束ねる書かれた標準を1つ。Brocentは2007年に北京で創業し、2021年からシンガポールに本社を置き、2016年に開設した香港オフィスでこのパターンの人員配置を続けています。フルタイム・オンサイトエンジニアサービスと、その下に敷かれるユーザー単位のマネージドITプランも、同じ分業の上に成り立っています。

いまSOWを書いているなら、見積もりを依頼する前に最も価値が高い作業は、言語の一行を上記の3つの仕事に分解し、そのうちどれが本当に「その部屋にいる人」に属さなければならないのかを印を付けることです。SOWをお送りいただければ、どの要件がリードタイムを押し上げているかをお伝えします。

よくある質問

バイリンガルのエンジニアは割高ですか？

言語が割増として請求されるのが通常ではありません。公開されているオンサイト料金はフルロードと記載され、そこに吸収されるものにはバイリンガルエンジニアが明記されています。価格を動かすのは希少性です。同じシニオリティの1人にハードな言語要件を重ねるほどプールは小さくなり、小さいプールは採用先の市場でより高く値が付きます。本当に特殊な組み合わせであれば職務がより上位のスキルティアに移ることもあり、そちらは公開価格です——エントリーレベルの専任エンジニア料金に対してL2が約＋21%、L3が約＋44%。「どれだけ高いか」への誠実な答えは「職務と市場による」であり、SOWを見ずに数字を出せる人はいません。

採用にどれだけ時間がかかりますか？

長くなります。そして料金より先にリードタイムが動きます。既存のベンチから充当できたはずの職務が探索になり、探索は市場次第の時間がかかります。だからこそ言語要件は契約段階ではなく最初の会話で話すべきです。稼働開始日が固定なら、それを危うくするのは通常、商務条件ではなく言語要件です。黙って期日を落とすより、どの要件が何週間のコストになっているかをお伝えします。

香港では広東語と標準中国語のどちらが確保しにくいですか？

香港の技術労働市場ではどちらも広く話されており、単独ではどちらも深刻な制約にはなりません。制約を作るのは*重ね合わせ*です——1人のL1エンジニアに流暢な広東語とビジネスレベルの標準中国語と自信のある技術英語の記述を同時に求めること。個々の要件は平凡で、希少なのは交差集合のほうです。

オンサイトエンジニアは現地語だけでも構いませんか？

多くの場合それで構いませんし、むしろ良い買い方であることが多いです。成立する条件は、後ろに書かれたチケット・ベンダーエスカレーション・ドキュメントを担うバイリンガルのサービスデスクがあり、両者の引き継ぎが明示的に定義されていることです。成立しないのは、オンサイトエンジニアが事実上単独で動いている場合です。記述とエスカレーションのレイヤーを置く場所が他にないからです。

ドキュメントは何語にすべきですか？

1つ選び、契約に書き、やり取りが何語で行われたかにかかわらず適用してください。香港のオペレーションの多くでは英語です。グループIT、監査人、保険会社、第三者ベンダーがみな読むからです。利点は一貫性だけではありません。曖昧な言語要件を検証可能な文書標準に変換するので、採用もしやすく、サプライヤーに守らせるのも容易になります。

日本語や韓国語も必要な場合は？

それは「人」の問題ではなく「レイヤー」の問題です。より広いAPACサービスでは、ヘルプデスク層とオンサイト層の双方で公開されている言語カバーに英語、広東語、標準中国語、日本語、インドネシア語、タイ語が含まれます。正しい設計はほぼ常に、追加言語をデスクとコーディネーションのレイヤーに流すことです。オンサイトエンジニアの要件に足すのは、プール規模とリードタイムに最も大きな打撃を与えるやり方です。

たまにしか必要ない言語にも対応できますか？

できます。そして「たまに必要」こそ、その言語をオンサイト職務ではなくデスクのレイヤーに置くべき理由です。シフト表で満たされる散発的な要件は休暇や退職を乗り越えますが、同じ要件を1人の職務記述書に書き込めば乗り越えられません。しかも年に数回しか使わないもののために、希少性のプレミアムを毎月払うことになります。

多言語ヘルプデスクとは何が違うのですか？

同じ問題のもう半分です。香港の多言語ITヘルプデスクおよびシンガポールにある日系メーカーのASEANオフィスについてのガイドは、リモートデスクにおける言語カバー——どう規定し、どう検証し、契約に何と書くか——を扱っています。この記事が扱うのは、部屋に立っているオンサイトエンジニアです。そこでは制約の振る舞いが異なります。シフトの制約ではなく、採用の制約だからです。