IT リバッジング：常駐エンジニアはどうなるか

結論から: IT アウトソーシングのベンダーを切り替えるとき、現行ベンダーの常駐エンジニアが職を失う必要も、御社が彼らの持つ環境知識を失う必要もありません。リバッジング（rebadging、要員の移籍）とは、その同じエンジニアを新しいサービス提供者の雇用に移すことです。同じ人、同じ席、新しい雇用主。全体が「空白ゼロ」の切替日を軸に設計されます。

IT ベンダーの切り替えでは、ほぼ必ずどこかの時点で、誰かがプロジェクト計画に一行も書かれていない問いを口にします。あのエンジニアたちはどうなるのか、と。

契約の話ではありません。チケットシステム、資産台帳、ライセンスの移管、ナレッジベースのエクスポート——そういう話でもありません。人の話です。四年間ずっと三階に座っていて、経理部の共有プリンターはファームウェア更新のたびにドライバーを戻さないといけないことを知っていて、どの会議室のディスプレイが Mac のドックと一度もまともに動いたことがないかを知っていて、すれ違う社員全員の名前を知っている、あの二人のことです。

その問いが出てくる頃には、移行プロジェクトはたいてい数週間走っています。調達の意思決定は終わり、新しいベンダーは決まり、スライド上の計画はシステムと切替日が並んだ、整然として自信に満ちた一覧になっています。エンジニアはそこに一度も出てきません。多くの組織で彼らは現行ベンダーの従業員であり、現行ベンダーの従業員は、書類の上では現行ベンダーの問題だからです。

この記事は、その問いを口にする人のために書いています。登場する会社は特定の顧客ではなく複合的な想定ですが、記述している仕組みは実際のものです。フェーズ構成、ガバナンス、失敗の型は、Brocent が実際に運用している移行フレームワークに基づいています。

実際に直面するのはどういう会社か

これは中小企業の問題でも大企業の問題でもありません。契約の形の問題です。常駐 IT 要員を第三者から供給されている会社が、その供給元を変えようと決めたとき、必ず現れます。

具体的には次の四つの場面です。

主契約先の変更。 最も多いケースです。デスクのレベルではそれなりに機能していて、アカウントのレベルでは機能していない——応答時間がずれ、エスカレーションが遅く、レポートが約束どおりに届かない——だから契約が動きます。常駐しているエンジニア自身は、そもそも問題ではありませんでした。
ベンダーの統合。 四都市に三つの要員契約があり、それぞれに請求書があり、それぞれに担当者がいて、SLA の解釈もそれぞれ違う。責任の所在がひとつのパートナーに集約されるということは、そのエンジニア一人ひとりに行き先が要るということです。
ベンダーの市場撤退や提供体制の再編。 グローバルの提供者が市場から退く、あるいは提供モデルを変える。御社の拠点を支えているエンジニアには、サービスを止めずに、法令に適合した新しい雇用主が必要になります。
コストとコンプライアンスの最適化。 同じ人を、より適切に統制され完全に法令に適合した雇用コストで。給与支払い、法定福利、現地労働法上の義務を一者が明確に負う形で。

この四つに共通しているのは、失おうとしている組織知識がどの文書にも存在していないということです。それは、これから支払いを止めようとしている人たちの中にあります。

想定シナリオ: 人ではなく契約を軸に組まれた移行計画

二か国三拠点、総勢およそ 300 名の会社を考えてください。IT サポートはリモートのサービスデスクと、四名の常駐フルタイムエンジニアで構成されています。四名全員が、六年来つきあってきたアウトソーシング会社の従業員です。関係は商務レベルで冷え込んでおり——デスクのレベルではありません——正式な入札を経て、会社は新しいサービス提供者を選定しました。

この移行計画は、一点を除いてあらゆることに周到です。RMM ツールの移行、認証情報の引き継ぎ、資産台帳の突合、ライセンスの再割り当て、ドキュメントのエクスポート、四週間の並行稼働期間。すべてに担当者と期日と依存関係があります。

四名のエンジニアについては一言もありません。計画を書いた誰にも、彼らについて何かを決める立場がなかったからです。調達にはできません。雇用主ではないからです。現行ベンダーはやりません。契約を失う側だからです。新しいベンダーは四名分の見積もりを出していますが、その四名が誰になるかは知りません。そして会社自身の人事は、この部屋に呼ばれていません。組織図の上では、この四人はサービス契約の中の一行の予算であって、人員枠ではないからです。

切替の六週間前、オペレーション責任者が尋ねます。そしてすべての当事者から返ってくる正直な答えは、同じ一文の言い換えです。*それはうちが答える話ではない。*

人の問いが遅れると、必ず起きる四つのこと

「ベンダーを替える＝ゼロからやり直す」が既定路線になります。 誰も別の段取りを組まなかったので、現行ベンダーのエンジニアは現行ベンダーの契約とともに去り、新しいベンダーが四人を新規採用する、という流れに自然と収まります。この前提が検証されることはほとんどなく、そして高くつきます。四名が環境について知っていることのすべて——文書化されなかった回避策、拠点固有の癖、二分の立ち寄りで片づく用件が本来なら四十分のチケットになるのを防いでいた人間関係——が、契約最終日に一緒に出ていきます。

知識移転が、期限に追われた文書作成作業になります。 標準的な緩和策は引き継ぎ期間です。去る側が書き、受ける側が読む。もともと書ける性質のものには有効ですが、それ以外には効きません。しかもその時点で去る側は、自分の任務が終わると告げられたばかりの人たちです。最後の二週間で網羅的なナレッジベースを書き上げる動機は、計画が暗黙に想定しているほど強くありません。

退職金や予告期間のエクスポージャーが場当たり的に処理されます。 常駐エンジニアの任務が終わるとき、誰が誰に何を負うのかは、国により、契約により、そしてその雇用関係が実務上どう成立していたかにより変わります。ある市場では責任は現行ベンダーにきれいに残ります。別の市場では、その体制が日々どう運用されてきたかが、「実際の雇用主は誰だったのか」という問いを招きます。これは切替六週間前に始める話ではなく、自社の人事と法務を同席させずに進める話でもありません。

新しい提供者が、すでに存在していた知識についてゼロから始めます。 引き継ぐチームは有能です——だから選ばれたのです——しかし有能さは文脈ではありません。新しい常駐チームの最初の九十日は、すでに描かれていた地図を描き直すことに費やされ、この決定に一切関与していない利用者たちは、それをサービスの劣化として体験します。

どれも珍しいリスクではありません。要員の問題を契約の問題として扱った結果として、ごく普通に予測できる帰結です。

私たちの考え方: リバッジングは定義されたモデルであって、その場しのぎの人事交渉ではない

中核にある観察は単純です。エンジニアと契約は別のものであり、切り替えの理由になっているのは片方だけです。

この二つを切り離すと、ほとんどの移行計画が検討しない第三の選択肢が現れます。エンジニアを新しい提供者の雇用に移すことです。それがリバッジングです。同じ人、同じ拠点、同じ利用者、新しい雇用主。離れたかった契約は終わり、失いたくなかった知識は残ります。

Brocent ではこれは案件ごとに交渉する即席の取り決めではありません。フルタイム常駐要員に関する四つの定義済み契約モデルのひとつであり、背後に構造化された移行フレームワークがあります。

Type 1 — Fresh Hire（新規採用）。 IT 環境のニーズを体系的に評価したうえで、エンジニアのレベルとサービス提供スケジュールを提案し、自社のエンジニアプールから調達します。既存の常駐チームがない場合、あるいは既存チームが残したい相手ではない場合に適します。
Type 2 — Rebadge（リバッジ）。 すでに常駐要員がいて、エンジニアを維持したまま主契約先を替えたい場合。職位レベル、社会保険・福利、サービス継続計画を対象とした人事アセスメントを実施します。
Type 3 — Hire to Budget（予算内配置）。 IT サービス予算が決まっている場合。ニーズをその予算に照らして評価し、予算内で最適なエンジニアレベルとスケジュールを提案します。
Type 4 — Hire for Change（体制変更）。 既存の常駐サービス計画を変更したい場合。変更がサービスレベル、品質、事業に与える影響を評価し、更新後のサービス内容を提案します。

この整理が効くのは、持ち主のいない問いを、答えの定まった問いに変えるからです。「エンジニアはどうなるのか」は、誰にも決める立場がない事柄ではなくなり、コストも期間も帰結も異なる四つのモデルからの選択になります。会社が実際に下せる決定です。

限界についても率直に書いておきます。リバッジングが自動的に正解になるわけではありません。常駐チームの働きが実際に不十分なら、リバッジングは知識と一緒に問題も保存します。人が理由でベンダーを替えるのなら、新規採用のほうが誠実です。要点はリバッジングが常に勝つということではなく、これが既定値ではなく決定であるべきだ、ということです。

現行ベンダーの常駐チームを扱う三つの道

契約と一緒に去ってもらう（既定路線）

何の計画も要らず、だからこそこれが起きます。
書き留められなかった環境知識はすべて最終日に出ていきます。
退職金、予告期間、共同雇用に関する疑義は、期限に追われながら受動的に、たいていは一番近くにいた人によって処理されます。
新チームの最初の四半期は、旧チームが知っていたことの再発見に費やされます。
ひとつの場合には本当に正しい選択です。常駐エンジニア自身が切り替えの理由であるときです。

完全に新規採用で始める

きれいな断絶。引き継がれる前提も、受け継ぐ癖もありません。
ベンダーではなくサービスモデル自体が変わるときには、これが正解です。技能構成が違う、対応時間帯が違う、職位レベルが違う。
既定路線と同じ知識を失いますが、少なくとも意図的に失います。偶発的な空白ではなく、計画されたオンボーディングを伴います。
引き継ぎと文書化の期間を、想定ではなく実際に工程へ積む必要があります。

目的に合わせた構造化リバッジング移行（Brocent のモデル）

同じエンジニアが同じ拠点で継続し、利用者側には何の変化も見えません。
エンドツーエンドの目安は三〜四週間。五つのフェーズと、並行して走る補充トラックで構成されます。
各エンジニアの給与、福利、勤務地、職務、予告期間は、いかなるオファーよりも前に検証されます。報酬は透明に確定され、一方的に決められるものではありません。
現雇用主での最終勤務日の翌日が、新雇用主での入社日になります。この「空白ゼロ」の切替は設計目標であって、期待される結果ではありません。
移籍しないエンジニアは検証の段階で特定され、並行トラックで補充されます。一人の判断が計画全体を止めることはありません。
給与支払い、法定福利、賠償責任保険、税務、現地労働法への適合は、事業を展開するすべての国で新しい提供者の責任になります。

リバッジング移行の実際の中身

フレームワークは五つのフェーズと、並行する一本のトラックで構成されます。エンドツーエンドの目安は三〜四週間です。

フェーズ 1 — 移行の開始（1〜2 日）。 着手の正式承認。対象要員を列挙した変更依頼のドラフトを発行します。要員リストは、どのエンジニアがどの都市のどの拠点に割り当てられているかを含めて凍結され、暫定の開始目標日が合意されます。初日から日次のガバナンスコールを設定し、ずれ始めた予告期間や欠けている書類が、期限当日ではなく発生したその日に表面化するようにします。

フェーズ 2 — 要員の特定（2〜3 日）。 エンジニアの氏名と連絡先を共有します。現行ベンダーが個人データを共有できない、あるいはしない場合——これは通常のことであり、多くの場合まったく正当な立場です——フレームワークは別経路を使います。対象を絞った採用活動を行い、特定されたエンジニアに応募リンクを伝え、本人が直接応募します。結果は同じで、現行ベンダーが誰の個人情報も引き渡す必要はありません。

フェーズ 3 — 要員との接触と商務検証（7〜10 日）。 最も長く、商務条件が成立するかどうかを決めるフェーズです。各エンジニアについて、現在の給与、福利、勤務地、職務、予告期間を構造化して検証します。人事が一人あたりの完全負担雇用コストを算出し、集計値を合意済みの商務ベースラインと突き合わせます。差異が出た場合は、双方が該当要員を共同でレビューし、次の手——補充か、商務条件の再提出か——を合意します。コストの想定外が稼働開始後に現れることを防ぐのが、この仕組みです。

フェーズ 3.1 — 補充対応、並行実施（10〜14 日）。 移籍しないエンジニアは出ます。現行ベンダーからの引き止め、報酬の不一致、個人的な事情。起こることであり、失敗として扱うのではなく、あらかじめ織り込みます。移籍しない要員は検証の段階で識別され、顧客が補充要件を承認し、調達は主線の移行と並行して進みます。全体の工程を延ばさないためです。

フェーズ 4 — 人事調整とオファー準備（3〜5 日）。 候補者ごとに報酬を確定し、合意済みの商務条件に沿って、移籍して当該案件を新しい雇用のもとで続ける意思を本人に明示的に確認します。本人の同意なしに動かされる人はいません。

フェーズ 5 — オファーの発出と入社（5〜7 日）。 いかなるオファーの発出よりも*前*に、変更依頼が双方の署名を受けます。オファーは書類検証——現雇用主の給与明細と雇用契約書——の後に出されます。エンジニアがオファーを受諾し、入社日を確定し、現雇用主に退職を申し出ます。予告期間、退職日、入社日は一人ずつ組み立てられ、各切替が合意日に着地するようにします。この組み立てが「空白ゼロ」を支える仕組みです。現雇用主での最終勤務日の翌日が、当社での入社日になります。

これと並行して、人事コンプライアンスは標準手順として進みます。初日より前の秘密保持契約と案件書類への署名。身元、学歴、職歴のバックグラウンド検証。給与支払いの設定、法定福利の加入手続き、現地労働法への適合——賠償責任保険と税務を含む——を、事業展開するすべての国で当社が担います。

ガバナンス上、二点だけ挙げておきます。フレームワークと計画を分けるのはこの二点だからです。ひとつは日次コールで、マイルストーン時ではなく初日から走ること。もうひとつは商務差異の管理で、各エンジニアの完全負担雇用コストがオファー発出*前*にベースラインと照合されること。コストのギャップは移行中の判断点になり、移行後の発見にはなりません。

より大きなマネージド IT の意思決定の中での位置づけ

比率を正しく置いておきます。リバッジングは移行の仕組みであって、サービスモデルではありません。答えるのは*現行の体制から次の体制へ、何も壊さずにどう移るか*という問いです。次の体制がどうあるべきかという、より重要な問いには、それ自体では答えません。

多くの会社にとって実質的な決定は、マネージド IT プランの形です。何が含まれ、どう価格が決まり、何が測られ、アカウントのレベルで誰が責任を負うのか。常駐要員はその一構成要素にすぎません。ベンダー変更が検討されているのなら、有用な順序はサービスモデルを先に、移行の段取りを後に決めることです。最初の会話が属するのは当社のマネージド IT サポートと、その背後にある料金です。フルタイム常駐 IT サポートは専任エンジニアがその中でどう位置づくかを、マネージドサービスは全体の提供モデルを説明しています。

コストについて実務的な注意をひとつ。常駐エンジニアの価格は単一の数字ではなく、何も尋ねずに一つの数字を出す相手は推測しています。実際の変数は、契約期間、職位レベルと専門技能、関連実務年数、業務言語、対応時間帯、拠点の場所、休暇中の代替要員の要否、顧客側の休日の扱い、そして本稿に関係するところでは要員タイプそのものです。Fresh Hire、Rebadge、Hire to Budget、Hire for Change は、それぞれ立ち上げコストと移行コストが異なります。リバッジングは新規採用より自動的に安くも高くもありません。コストの形が違うのであり、その形として見積もられるべきものです。

よくある質問

IT リバッジングとは何ですか。

IT リバッジングとは、既存の常駐 IT エンジニアを、ある雇用主から別の雇用主へ——通常は退出するアウトソーシングベンダーから引き継ぐベンダーへ——移すことです。エンジニアは同じ拠点で、同じ利用者と同じシステムを支え続けます。変わるのは契約と雇用主であり、人と任務は変わりません。

リバッジングなら同じ人が必ず職を維持できるということですか。

機会が提供されるということであり、結果が保証されるということではありません。各エンジニアの報酬は検証のうえ確定され、オファー発出の前に移籍の意思が確認されます。エンジニアは辞退できます——現行ベンダーからの引き止め、報酬の不一致、個人的な事情など——そしてその可能性は例外としてではなく、並行する補充トラックであらかじめ計画されています。

退出するベンダー側の退職金の義務はどうなりますか。

法域により、会社と現行ベンダーの契約により、そしてその雇用関係が実務上どう成立していたかによります。だからこそ、切替の六週間前に片づける話ではないのです。リバッジング移行はこれを計画項目にするよう設計されています。予告期間、退職日、入社日はフレームワークの一部として一人ずつ組み立てられます。各国での法的な立場は御社自身の法務・人事顧問に確認してください。移行フレームワークが提供するのは手順であって、法的見解ではありません。

Rebadge、Fresh Hire、Hire to Budget、Hire for Change の違いは何ですか。

Rebadge は新しい契約先のもとで既存エンジニアを維持します。Fresh Hire は要件の評価に基づいて新しいエンジニアを調達します。Hire to Budget は決まった予算から逆算して最適なエンジニアレベルとスケジュールを導きます。Hire for Change は要件自体が変わったときに既存の常駐計画を作り替えます。四つの異なる状況への四つの答えであり、立ち上げコストと移行コストもそれぞれ異なります。

どの国でも同じやり方になりますか。

フレームワークと手順はどこでも同じで、これは意図的です。複数国にまたがる移行を統一されたひとつの計画として運用するほうが、四つのローカル案件がそれぞれの調子で走るより、はるかに制御しやすいからです。異なるのはその下の現地雇用の層です。予告期間、法定福利、退職金の算定、社会保険の加入手続きは国ごとに固有であり、新しい雇用主が国ごとの責任として担います。その場の擦り合わせでは処理しません。

リバッジング移行にはどれくらいかかりますか。

エンドツーエンドの目安は三〜四週間です。単一フェーズで最も長いのは要員との接触と商務検証で、七〜十日です。補充対応は十〜十四日かかりますが、意図的に並行で走るため、全体の工程は延びません。

現行ベンダーがエンジニアの情報の提供を拒んだ場合は。

よくあることで、多くの場合まったく正当です。現在の雇用主として、その個人データは現行ベンダーが保持しているからです。フレームワークにはこの場合のための別経路が用意されています。対象を絞った採用活動を行い、特定されたエンジニアに応募リンクを伝え、本人が直接応募します。現行ベンダーが誰の個人データも引き渡すことなく、移行は進みます。

リバッジングが常に正しい選択ですか。

いいえ。常駐エンジニア自身がベンダーを替える理由であるなら、リバッジングは問題も一緒に保存します。サービスモデル自体が変わるのなら——技能レベルが違う、対応時間帯が違う、職務構成が違う——新規採用や体制変更のモデルのほうが誠実です。リバッジングが正解なのは、離れたいのが契約で、残したいのが人であるときです。