毎日、現場に一人：シンガポールの製造業者とITスタッフ拡充

端的な答え： シンガポールの製造業者がITユーザー数と端末数の合計で概ね100を超えたなら、「リモートのみの支援で足りる」という前提はすでに通用しなくなっている可能性が高い。そしてこの判断は、大部分が算術の問題である。Brocentが公開しているシンガポール料金では、専任オンサイトエンジニアとスポット派遣の損益分岐点は月あたり約50時間の支援量。残りを決めるのは、現場の複雑さだ。

なぜシンガポールの製造業者は、気づかないうちにその線を越えるのか

製造業にしか現れない種類のIT課題がある。しかもそれは、本質的に技術の問題ではない。何の予告もなくやってくる「規模の不一致」の問題である。

従業員六十名のシンガポールの製造業者なら、プロフェッショナルサービス企業と同じやり方でITを回せる。ノートパソコン、メール、ファイルサーバーかクラウドテナント、通信キャビネットのスイッチ一台、そして「誰かがリモートで電話を取り、リモートで直せるものは直す」という支援契約。このモデルは機能する。しかも、誰も見直そうと思わない程度に十分機能する。

そのうち会社は長期契約を獲得し、第二シフトを立ち上げ、設備を三台追加し、それを動かすために四十名を採用する。二、三年のうちに人員は六十名から百五十名へ。IT支援モデルを変更しようと会議で決めた人はいない。そもそもIT支援モデルについての会議自体が開かれていないからだ。オフィス中心の六十名に合わせて設計された取り決めが、いま百五十名を支えている。うち九十名は現場で働き、二交替制で、契約締結時には存在しなかった設備を扱っている。

これは「ダメなベンダーの話」ではない。リモート支援は、得意な領域では本当に有用だ。パスワードリセット、メールボックスの不具合、ソフトウェアのインストール、そして多くの企業でチケット量の大半を占めるエンドユーザー課題のロングテール。製造環境で変わるのは、物理的な問題が占める比率である。ペアリングしなくなったバーコードスキャナー。ライン端で画面が真っ暗になった堅牢型端末。フォークリフトに踏まれて断線したLANケーブル。白紙のラベルしか出さないラベルプリンター。生産設備と通信する装置脇の産業用PC——これは、誰かがその前に立つ必要がある。

どれも難しい問題ではない。だが、どれも建屋の中に人がいることを必要とする。

シンガポールの製造業の裾野が、この構図を例外ではなく常態にしている。カキブキット、ウッドランズ、ジュロン、トゥアス周辺の工業団地には、まさにこの規模帯の受託製造業者、サブアセンブリ工場、精密加工企業、軽組立工場が並んでいる。ITの停止が実際の金額として響くほど大きく、しかし社内IT部門を構えるほどには大きくない。そして現場にいる人々の本業は、生産であってITの一次切り分けではない。

シナリオ：百五十五名、二交替、そして六十名向けに作られた支援モデル

以下は例示のための複合シナリオである。特定の顧客名ではなく、繰り返し現れる「形」だ。

あるシンガポールの受託製造業者は、産業機械メーカー向けにサブアセンブリを生産している。工業団地の隣接する二区画を使い、一方は組立セル・試験台・小規模なクリーンエリアを備えた現場、もう一方の中二階オフィスに営業、生産計画、調達、品質、経理が入る。総勢百五十五名。うち約九十五名が現場で、日勤と、おおむね夜十時まで動く遅番の二交替で働いている。

IT支援はリモートで、会社が七十名未満、ほぼ全員がオフィス勤務だった時期に契約したものだ。ヘルプデスク、サーバー、パッチ適用、アンチウイルスをカバーしており、その範囲では十分に有能に機能している。手が必要なときは、エンジニアが派遣される。

IT関係を持っているのは、生産計画も回している運用マネージャーである。彼はIT出身ではなく、そう自称したこともない。彼が持っているのは、「ITが以前より自分の一週間を食っている」という漠然と強まる感覚だけで、それがどれほどなのかは数字にできていない。

週単位で見ると、実際にはこうなっている。

• 火曜の午前、試験台のPCが測定器との接続を失う。リモートエンジニアは、同時にシフトも回そうとしている生産主任と電話越しに切り分けを進める。九十分かかり、最後は「翌日訪問の予約」で終わる。
• 受入エリアの手持ちスキャナー二台が不安定。誰もチケットを立てていない。チケットを立てるには電話をかける必要があり、回避策（品番の手入力）は受入一件あたり二分増えるだけで、実際に回るからだ。
• 遅番には、夕方六時以降の支援がまったくない。それ以降に壊れたものは翌朝まで待つ。運の悪い夜には、シフトの後半を紙で回すことになる。
• 三か月前に新しい組立セルが立ち上がった。装置脇のPCは設備ベンダーの立上げエンジニアが設定した。そこに何が入っているのか、パッチが当たっているのか、バックアップされているのかを知っている人間は社内にいない。
• 運用マネージャーが事実上の一次窓口になっている。人々はITの問題を彼の席まで持ってくる。そのほうがプロセスより速いからだ。

どれ一つとして危機ではない。しかし合計すると、それはもはや実際の運用に合っていない支援モデルであり、本来それを検知するはずの仕組み——この取り決めがまだ適合しているかを見直すこと——が、誰の職務にも入っていない。

遅れが実際に生むコストと、それが見えないままである理由

この状況が続く理由は、そのコストがどの帳票の一行にも現れないことにある。

製造環境におけるリモートのみのモデルは、四種類の損失を生む。そしてその四つはいずれも拡散的だ。

物理故障の解決時間が延びる。 建屋に人がいれば十五分で解消する故障が、九十分のリモート診断＋翌日訪問になる。チケットは最終的にクローズし、指標もそれなりに見える。指標が捉えないのは、その生産主任が九十分をラインではなく電話に費やしたという事実だ。

需要が抑圧される。 これが最も高くつく。助けを求めるのが面倒になると、人は求めなくなる。受入エリアの不安定なスキャナー二台はチケットにならなかった。毎朝電源を入れ直す必要のあるラベルプリンターもならなかった。人が迂回する支援モデルは、きれいに見えるチケットキューと、回避策が積み上がった現場を同時に生む。しかも、それを示すレポートは存在しない。

カバーされない時間帯。 二交替の運用を単一シフト前提のモデルで支えると、構造的な穴が空く。遅番が多くのインシデントを生むという話ではない。生んだものが最悪のタイミングで着地し、エスカレーション先が誰もいないという話である。

持ち主のいない設備。 設備ベンダーが立ち上げた装置脇のPCは、製造業の古典的な死角だ。それはIT資産のように振る舞う生産資産であり、この規模の多くの企業では、誰が持ち主なのかを決めた人がいない。パッチの外、バックアップの外、資産台帳の外に置かれたまま——そのうち一台が故障し、セルを一つ止める日まで。

これらを足し合わせると、正直な結論はこうなる。運用マネージャーの直感は正しい。ITは請求書の額より多くの費用を会社にかけている。ただ彼にはそれを証明する手段がない。だからこそ、この会話は始まらないままなのだ。

Brocentの見方：これは算術の問題に、判断を一つ足したもの

当社は2007年以来、アジア各地のオフィスと工場にオンサイトエンジニアを配置してきた。この規模帯で企業が最もよく犯す誤りは、配置モデルを「好み」の問題として扱うことだ——「できれば構内に人がいてほしい」あるいは「できれば身軽に保ちたい」。それは好みではない。大部分は計算であり、その上に判断が一つ載る。

算術：専任エンジニアが派遣を上回る地点

Brocentはこの計算の両側を公開している。比較が実際に成り立つようにするためだ。当社の派遣・FTE料金ページでは、シンガポールの現場派遣は初回1時間85米ドル、以降1時間あたり78米ドルと記載している。これはレベル1のエンドユーザーコンピューティング支援について、翌営業日対応・標準9×5、初回1時間の最低量と都市圏内の移動を含むフルロードの参考料金である。シンガポールの専任フルタイムオンサイトエンジニアは、月額4,160米ドルと記載している。

後者を前者で割れば分岐点が出る。この参考料金では、専任エンジニアは単一拠点あたり月およそ五十時間の支援量で釣り合う——週あたり約十二時間だ。これを下回れば派遣がほぼ常に安く、上回れば通常は常駐配置が安く、しかも差は急速に開く。

この数字については、精度そのものより重要なことが二つある。

第一に、この位置にいる企業のほとんどは実際の支援時間を測ったことがなく、したがって線の誤った側で推測している。九十分のリモート診断＋翌日訪問＋主任の時間は「チケット一件」ではない。そして抑圧された需要まで数え入れると、実数は誰の想定よりも高くなるのが通例だ。

第二に、分岐点は答えの全部ではない。派遣と常駐エンジニアは同じ製品ではないからだ。五十時間の派遣を十回の個別訪問に分けた場合、あなたが得るのは十回の到着であり、そのたびに通信キャビネットの場所を説明する必要がある。常駐エンジニアが与えるのは連続性だ——どのセルの端末が気まぐれか、試験台の件はどのベンダーに連絡すべきかを知っている人間がいるということ。この差は、時間料金には現れない。

判断：規模の階段が言うこと、そしてそれが言い切れなくなる場所

Brocent自身の規模ガイダンスは、フルタイムオンサイトIT支援のページに、あえて率直な形で公開している。

• 50ユーザー未満 —— スポット派遣（ADHOC）またはリモートのマネージドIT支援。
• 50〜100ユーザー —— 概ね0.5 FTE、すなわちパートタイムのオンサイトエンジニア。
• 100〜500ユーザー —— 専任フルタイムのL1/L2エンジニア一名。
• 500〜2,000ユーザー —— 複数FTE＋チームリード。
• 2,000ユーザー以上 —— プロジェクトマネージャーを置いたFTEチーム。

その背後にある目安はこうだ。環境内のITユーザーおよび／または端末が概ね百を超えたら、フルタイムのエンジニアが通常必要になる。

この「および／または端末」という文言こそ、製造業が「階段をオフィス人数で読む」やり方から分岐する箇所であり、上の複合シナリオに当社が加える判断でもある。百五十五名は100〜500の帯に入るので、階段の答えは1 FTEだ。だが製造環境の端末数は人数を大きく先回りする。組立セルの端末、スキャナー、ラベルプリンター、試験台PC、装置脇のコントローラー——そのどれもが故障モードを持つ管理対象端末であり、どれも「誰かのノートパソコン」ではない。百五十五名の工場なら、管理対象エンドポイントは容易に二百五十台に達する。百五十五名のコンサルティング会社なら百七十台だ。

つまり階段は出発点であり、現場の複雑さがあなたを上へ押し上げる。二交替も同じ方向に働く。同じ人数でも、単一シフトでオフィス中心の企業なら、0.5 FTE＋派遣で本当に足りるかもしれない。同じ人数の二交替工場なら、それは完全な常駐配置であり、この会話の正直な版には「エンジニアの勤務時間帯をどこに置くか」が含まれる。夜十時まで動く工場で六時に終わる配置は、提起されたのとは別の問題を解いている。

専任オンサイトエンジニアに実際に含まれるもの

「専任オンサイトエンジニア」という言葉は、まったく異なる二つの製品を覆っている。そしてその差は、ほぼすべてが調達段階で誰も尋ねない部分にある。

うまくいかない版は、人材派遣型の送り込みだ。人を見つけ、あなたの拠点に送り、月次で請求する。その人が休暇に入れば支援は消える。その人が辞めれば振り出しに戻る。職務経歴書を超えて経歴を検証した者はいない。実際に何をしたかの記録はなく、その人の力量を超えた問題が出たときのエスカレーション経路もない。

当社が配置する版は、HRの仕組みを伴った運用プログラムである。具体的に述べるだけの価値がある。Brocentの配置プロセスは九つの定義された段階で進む——環境と要件を確認する事前ヒアリング、当社のソーシングネットワークに公開する採用計画、HRリクルートチームによる候補者のソーシング・技術評価・お客様基準に沿ったスクリーニング、お客様が実施する候補者面接（日程調整は当社が担当）、NDAとオファー（犯罪歴・学歴・本人確認を含む経歴確認を実施）、給与・福利厚生加入・現地労働法遵守・賠償責任保険を含む正式なHRオンボーディング、当社チームが引継パック・クライアントITマニュアル・シャドー計画を用意し、エンジニアが手探りではなくブリーフィング済みで着任する立上げ準備、パフォーマンスの緊密なモニタリングと知識移転を行う三か月のハイパーケア期間、そしてその後は当社のFTE管理システムによる継続的な勤怠管理（請求可能工数、欠勤率、勤怠レポートを出力）。

このうち三つは個別に取り出す価値がある。配置が数か月ではなく数年もつかどうかを決めるのは、この三つだからだ。

休暇時のカバー。 あなたのエンジニアは年次休暇を取り、ときには体調を崩す。その期間に訓練済みの代替要員が当社のプールから着任するかどうかは、前提ではなく契約条項である——当社が価格を積む十二の要素の一つであり、それは見積書に書かれるべきものであって、この件で最初に起きる気まずい会話の中で決めるものではない。

クライアントITマニュアル。 常駐エンジニアは知識を蓄積する。その知識が彼の頭の中にしか存在しないなら、あなたは「支援の穴」を「人への依存」に取り替えただけだ。マニュアルと引継パックは、環境の文書化が「いまそこに立っているのが誰か」から独立して保たれるために存在する。

勤怠とレポート。 レポートのない常駐エンジニアは不可視だ。請求可能工数、欠勤率、勤怠レポートは、一年後に「あの規模判断は正しかったか」を——あるいは階段が0.5 FTEへ、もしくは二名へあなたを動かしたのかを——見えるようにするための材料である。

配置価格は単一の数字ではなく、誤解を招く数字を出すよりは理由を説明したい。価格は次の要素で動く。契約期間（標準は6・12・24か月で、長期のコミットメントほど月額は下がる）、職位レベルと専門スキル（レベル2はエントリー比で概ね＋21%、レベル3は概ね＋44%）、実務年数、業務言語（バイリンガルのエンジニアはプレミアムがつく）、勤務時間帯（標準時間、延長時間、シフト勤務、オンコールは別の製品である）、拠点の立地と複数拠点対応の有無、リソース種別、代替要員の要否、お客様側休日の扱い、現地労働法上の有給休暇義務、リソース交代時の引継日数、そして早期終了時の標準補償条項の受諾。公開されている4,160米ドルは、シンガポールの専任エンジニアについてのフルロードのエントリー参考値であり、見積ではない。複数FTEおよび複数国のプログラムは、単一配置より低い価格になる。

もう一つ、資金繰りに関わる仕組みがある。派遣訪問は作業後に標準30日条件でチケット単位の明細請求となり、FTE配置は当月分を月次で前請求する。現地のGST請求書の発行方法は、どちらも同じだ。

この規模のシンガポールの製造業者がITを構える三つの方法

規模の適合点を過ぎたリモートのみの支援

• それは何か： 六十名のときに機能していた取り決めが、百五十五名でまだ動いている状態。
• 本当に強い点： エンドユーザーチケットのロングテール——アカウント、メールボックス、ソフトウェア。実際にリモートで解くのが最適な領域。
• どこで壊れるか： 現場の物理故障。そのすべてが「電話一本＋翌日訪問」になり、差分を生産主任が吸収する。
• 隠れた失敗モード： 需要の抑圧。人々は「面倒だがラインは止まらない」問題を報告しなくなり、チケットキューは現場の実態より健全に見える。
• 正直な結論： 50ユーザー未満では正しく、100を超えると次第に誤りになる——とくに端末数が人数を追い越したあとは。

リモート支援の上にスポット派遣を重ねる

• それは何か： リモート支援をベースラインとし、手が必要なときにエンジニアを送る。シンガポールの派遣は初回1時間85米ドル、以降1時間78米ドルで公開されている。
• 本当に強い点： 需要が本当に断続的な場合。月次のコミットメントも最低利用もなく、作業後に30日条件で請求される。単一シフトでオフィス中心、分岐点未満の拠点なら、これが正解だ。
• どこで壊れるか： 頻度。月十回の訪問は、十回の到着、十回の文脈の再説明、十回の翌営業日待ちである。回数が増えても連続性には変わらない。
• 経済性： 単一拠点で月およそ五十時間を超えたら、派遣のサービスに常駐配置の金額を払っていることになる。
• 正直な結論： 分岐点未満では正しいモデル。分岐点を超えた地点では、意思決定を回避するための高価な方法。

現場規模に合わせ、休暇カバーを備えた専任オンサイトエンジニア

• それは何か： 氏名の特定された、経歴確認済みのエンジニアがあなたの拠点に常駐する——これがBrocentのモデルである。九段階のプロセスで配置し、休暇カバー、文書化された引継パックとITマニュアル、勤怠レポートを備え、背後にBrocentの技術チームとエスカレーションネットワークがある。
• 本当に強い点： 物理故障、連続性、シフトのカバー、そして二年目を一年目より安くする拠点固有の蓄積知識。
• 費用： 月額4,160米ドル。シンガポールのフルロードのエントリー参考値として公開されており、レベル、勤務時間、言語、および上記のその他要素で変動する。
• 注意が必要な点： 規模の適合。0.5 FTEで足りる拠点に1 FTEを置くのは実際の無駄であり、二交替で動く工場に日勤時間帯のエンジニアを置くのは、問題の誤った半分を解いている。
• 正直な結論： ユーザー数が百を超え、端末数がそれをはるかに超える二交替工場に適合するモデル——ただし勤務時間をオフィスではなくシフト形態に合わせて設計する場合に限る。

商業面についてのBrocent自身の説明は、ペイ・アズ・ユー・ゴーの取り決めは、給与・ツール・管理時間まで数え入れたうえで、同等職を社内で雇用する場合のOPEXおよびCAPEXコストを最低37%削減するというものだ。当社としては、それを鵜呑みにするよりご自身の数字で検証していただきたい。派遣料金とFTE参考値の両方を、問い合わせベースではなく公開しているのはそのためである。

よくあるご質問

何名規模から専任オンサイトエンジニアが妥当になりますか？

当社の公開ガイダンスでは概ね百のITユーザーおよび／または端末で、100〜500の帯には1 FTEが示されています。製造業では、この文言の「端末」側を注意深く読んでください。端末機、スキャナー、ラベルプリンター、試験台PC、装置脇のコントローラーはすべて数に入り、工場の端末数は通常その人数を大きく先回りします。実務上の判定基準は分岐点です。シンガポールの公開料金では、単一拠点で月約五十時間の支援量を超えたら、常駐配置のほうが安いモデルになります。

シンガポールでは専任エンジニアはどのように価格が決まりますか？

公開されているエントリー参考値は、フルロードの専任オンサイトエンジニア一名につき月額4,160米ドル、月次前請求です。この数字は十二の明示された要素で動きます——契約期間、職位レベルと専門スキル（レベル2はエントリー比で概ね＋21%、レベル3は概ね＋44%）、実務年数、業務言語、対応時間帯、拠点立地、リソース種別、代替要員の要否、休日の扱い、有給休暇の法令遵守、引継日数、補償条項です。複数FTEおよび複数国のプログラムはより低い価格になります。比較として、現場派遣は初回1時間85米ドル、以降1時間78米ドルです。

エンジニアが休暇のときはどうなりますか？

訓練済みの代替要員がBrocentのプールから着任するかどうかは、価格に織り込まれた契約条項であり、前提ではありません——十二の価格要素の一つとして明示されており、シンガポール労働法上の有給休暇義務も同じ枠組みで扱います。これは、製造業のお客様に対して当社が最も強く書面化を勧める論点です。二交替の現場でカバーのない一週間は、まさにこのモデルが耐える必要のある局面だからです。

人員が減った場合、規模を戻せますか？

戻せます。そしてこの規模の階段は双方向です。標準契約期間は6・12・24か月なので、この問いを再検討する自然なタイミングは更新時であり、判断材料は配置自体が生成した勤怠データです。1 FTEから0.5 FTE＋派遣へ戻すのは正常な帰結であって失敗ではありません。既存サービスプランの変更である「Hire for Change」は、当社が影響を評価し、提供内容を再設計する定義済みのリソース種別です。

エンジニアはBrocentから来るのですか、それとも現在の担当者を残せますか？

どちらも標準です。フレッシュハイアは当社がソーシング・評価・配置を行います。リバッジは、すでにオンサイト要員がいて、その個人を維持したまま契約主体を変更したい場合に適用されます——職位レベル、法定福利、サービス継続計画を対象とするHRアセスメントを実施し、その方の雇用関係を移しつつ、あなたへのサービスが中断しないようにします。ハイア・トゥ・バジェットとハイア・フォー・チェンジが他の二つの典型ケースをカバーします。リソース種別が十二の価格要素の一つであるのは、まさにこれらの立上げ・移行コストが異なるためです。

自社でIT担当者を採用するのと何が違いますか？

仕組みの面では、採用サイクル、給与・福利厚生の管理事務、現地労働法の遵守、賠償責任保険、ツール、そして一人依存を負わずに済みます。運用面でより重要な違いはエスカレーションです。より広い技術チームを背後に持つ常駐のL1／L2エンジニアは、ネットワーク設計やサーバーの問題を有資格者に引き渡せますが、単独の社内採用者は自らその人になるか、ベンダーを待つしかありません。当社の公開見解はフルロードの社内同等職に対して最低37%の削減ですが、当社が強調したいのはエスカレーションの深さです。価格化しにくく、そして通常はより重要です。

どのような経歴確認が行われ、誰が実施しますか？

BrocentのHRリクルートチームが、オファー段階で犯罪歴・学歴・本人確認を対象とする経歴確認を実施します。確認が適法に行われ、本人にも適切に告知されるよう、事前に署名済みの同意書を取得します。NDAとプロジェクト文書はエンジニア着任前に締結し、オンボーディングでは給与、福利厚生、労働法遵守、賠償責任保険までを扱います。顧客監査を受けるプロセスをお持ちの、あるいは設備メーカーに対して守秘義務を負う製造業のお客様にとっては、この文書一式がサプライヤー監査で最も重要になる部分であることが多いです。

構内に担当者がいれば、マネージドITプランは不要ですか？

必要です。そしてこの点は最もよく逆に理解されます。常駐エンジニアは一組の手であり、拠点知識の源です。24時間365日の監視プラットフォームでも、パッチ適用のパイプラインでも、バックアップ体制でも、セキュリティガバナンス機能でもありません。配置が機能するのは、それらが背後に存在するからです。背後にプランのないエンジニアは、「席のついた単一障害点」です。

オンサイト配置の置き場所：プランの外ではなく、内側に

この規模の製造業のお客様に最も避けていただきたい誤りは、専任エンジニアをそれ単体で答えとして扱うことです。

上の複合シナリオの企業に問題があるのは、建屋に人が足りないからではありません。支援の取り決めが別の規模の会社に合わせて設計され、誰も再設計しなかったからです。見直されていない取り決めに常駐エンジニアを足せば、応答時間という症状は改善しますが、装置脇のPCは依然として持ち主不在、エンジニアが帰ったあとの遅番は依然として無カバー、端末台帳は依然として不完全なまま残ります。

実際にこれを解くのは、環境全体をカバーするプランです——24時間365日のNOC監視、ヘルプデスク、マネージドファイアウォール、パッチ管理、エンドポイント保護、バックアップと災害復旧、認証情報管理、そして技術ロードマップを保有し、更新時に規模の問いを自ら立てる指名vCIO（運用マネージャーが自分で問わなくて済むように）。そのうえで、オンサイト配置をそのプランの一構成要素として規模設定する。横に並べて後付けするのではなく。

それがBrocentのマネージドITプランです。監視、パッチ、セキュリティ、ガバナンスの層を担うユーザー単位の月額プランがあり、その上に、必要な拠点に対してオンサイト人員、現場派遣、インフラ系アドオンを規模に応じて重ねます。シンガポールのユーザー単位価格は、派遣およびFTEの参考値とあわせて価格ページで公開しています。本稿のような比較が、会話の最中ではなく会話の前に一度実行できるようにするためです。

シンガポールでユーザー数が百を超え、二交替で動く工場を運営していて、支援の取り決めがより小さかった時期の会社から引き継いだものであるなら、有用な最初の一歩は見積ではありません。実際の支援時間と実際の端末数を、一か月きちんと数えることです。時間が五十を超え、端末が二百を超えるなら、階段はすでにこの問いに答えています——規模の詰めは、ぜひ一緒に進めさせてください。お問い合わせいただければ、当社の数字ではなく、あなたの数字から始めます。

*本稿で述べた企業は、Brocentがシンガポールおよびアジア各地で支援している製造業の運用を例示のために合成したものであり、特定の顧客名ではありません。引用した料金はBrocentが公開しているシンガポールの参考値であり、最終的にはスコーピング時に確認します。Brocentは2007年に北京で創業し、2016年に香港オフィスを開設、2021年からシンガポールに本社を置いています。*