Mac約380台をJamfからIruへ移行する計画の立て方——「順番」より先に決めるべき3つの合否ゲート
- ▶ MDM移行で本当に効くのは「What」より「How」だという話
- ▶ 数百台規模のMDM移行を「3フェーズ」で組む考え方
- ▶ Jamfで「死んでいるMac」を移行前に蘇生させる理由
- ▶ 本番GO前に必ず潰すべき3つの合否ゲート（ここを外すと詰む）
- ▶ スケジュールで一番崩れる「最後まで残る一部」のバッファ設計
ある約380台規模の会社で、Mac管理をJamf ProからIruへ移行する計画を組んだ。移行期間は約1ヶ月、台数は約380台。この規模のMDM移行を、実務で回せる粒度まで落とした計画の作り方を書く。
MDM移行の計画って、ネットだと「Jamfとは」「Iruとは」みたいな製品紹介か、ベンダーの提案資料くらいしか出てこない。実際に何百台を期限内に切り替える段取りの一次情報は、ほぼ転がっていない。だからここに残しておく。
▼背景：なぜMDMを乗り換えるのか
MDMの乗り換え理由は会社によって違うが、だいたい「コスト」「運用負荷」「機能の方向性（DDMやAuto Apps等の新しい管理モデルへの対応）」のどれかに集約される。今回もそのあたりが軸だった。
ただ、移行を決めた瞬間に最初に考えるべきは「どっちの製品が優れているか」ではない。380台をどうやって事故なく、期限内に、現場を止めずに切り替えるか——この一点だ。製品比較は終わっている前提で、ここから先は完全に「移行プロジェクトの設計」の話になる。
▼移行で本当に難しいのは「What」じゃなく「How」
構成プロファイルもスクリプトもアプリ配布も、Iruの移行ツールがJamfからAPIで一括で持ってくる。つまり「何を移すか（What）」はツールがほぼ解決する。検証5台で「ちゃんと運べたか」を確認すれば終わる話だ。
だから情シスが本当に設計すべきは、ツールが運べない領域——「どう移すか（How）」しかない。死んでいる端末をどう蘇生して移行の土俵に乗せるか、ユーザーをどう動かすか、最後まで残る端末をどう先回りで潰すか。この記事で挙げる合否ゲートも、すべてHowの話だ。
▼移行は「3フェーズ」で組む
数百台規模の移行は、一気にやると確実に事故る。フェーズを分けて、前のフェーズで合否を確認してから次へ進む。今回は3フェーズで組んだ。
| フェーズ | 期間 | やること | ゴール |
|---|---|---|---|
| 1. 現状確認・移行計画 | 約1週間 | API連携・管理者アカウント発行・Jamf側の不要設定整理・全社アナウンス文面・部署別展開順の決定 | 移行ツールが動く土台を作る |
| 2. 環境構築・検証・パイロット | 約10日（フェーズ1と一部並行） | 検証用5台で構成プロファイル／スクリプト／アプリ配布を移植検証→IT部＋各部門代表10〜15台でパイロット | 本番GOの可否を判断する |
| 3. 本番移行・契約終了 | 約3〜4週間 | Apple BusinessでMDMサーバ切替→部署別に段階展開→旧MDMのバックアップ・テナントクローズ | 全台移行完了＆旧契約終了 |
ポイントは、フェーズ1とフェーズ2を一部並行で走らせること。フェーズ1のアナウンス文面作成や展開順の決定は、検証（フェーズ2）の結果を待たなくても進められる。逆に検証は土台（API連携）が出来た瞬間に着手する。直列で組むとスケジュールが伸びすぎる。
本番の段階展開はバッチで切る
380台を一斉に切り替えるのは自殺行為だ。今回はこう刻んだ。
| 週 | 対象 | 台数イメージ |
|---|---|---|
| 第1週 | IT部・管理部門（自分たちで人柱になる） | 約80〜120台 |
| 第2週 | 事業部本体 | 約140〜180台 |
| 第3週 | リモートワーカー・出張中・休暇明け | 残り |
第1週に必ずIT部門を先頭に置く。自分たちが最初に移行プロセスを通れば、手順書の穴とヘルプデスクの負荷が現場展開の前に見える。ここを事業部から始めると、問題が全社に拡散してから気づくことになる。
▼ここが本題：本番GO前に潰すべき「3つの合否ゲート」
計画書の「順番」は、正直そこまで難しくない。本当に怖いのは、検証フェーズで絶対に確認しないと本番で詰む箇所を見落とすことだ。今回、ここを最優先の合否ゲートとして設計した。検証5台で全台クリアできなければ本番GOしない、という位置づけにしている。
これが移行の生命線。端末を再エンロールして再暗号化する流れで、復旧キー（Recovery Key）が新MDM側に確実に預け直されるか。ここが抜けると、ユーザーがロックアウトした時に復旧キーを出せず、端末が文鎮化する。「失敗時リカバリ手順」と同列の扱いではなく、最優先の合否ゲートとして、検証5台で全台エスクロー成功を確認できるまで本番に進まない。
今回の移行は、こういう仕組みで動く。
ところがJamfを使っていると、なぜか数ヶ月チェックインが来ていない＝インベントリが更新されていない「死んでいる」Macが、ほぼ必ず一定数生まれる。死んでいる端末には移行プロファイルがそもそも届かない。つまり、死んだままのMacはIruに移行できない。しかもこいつらは放置すると「連絡がつかない・最後まで残る端末」になり、スケジュールを崩す張本人になる。
対策は、フェーズ1でJamfのインベントリを最終チェックイン日でソートし、死んでいる端末を全部洗い出して、本番展開が始まる前にユーザーへ連絡して起動・チェックイン復帰させておくこと。蘇生は移行展開とは別タスクとして、早く着手するほど効く。
Apple BusinessでデフォルトのMDMサーバを新MDMに切り替えると、新規・ワイプした端末はすべて新MDM行きになる。一方で本番は段階展開＝既存端末はバッチで移していく。この切替タイミングで再起動・初期化した端末が中途半端な状態にならないよう、「デフォルトサーバ切替」と「個別デバイスのMDM割り当て」を分けて段取りする。ここを雑にやると、移行途中の端末が宙に浮く。
▼スケジュールで一番崩れるのは「最後まで残る一部」
移行計画のスケジュールで、ほぼ確実に崩れるのが最後まで残る一部の端末だ。連絡がつかない人、移行を渋る人、トラブった端末。この最後の一部が全体で一番時間を食う。
「全台完了 → 旧テナントのクローズ作業 → 旧MDM契約終了」を直列で組むと、最後の数台が押した瞬間に契約終了日に間に合わなくなる。今回も完了目標と契約終了の間が約1週間しかなく、ここが一番のリスクだった。
旧MDMの契約をズルズル延長する手は基本効かないと思っておいたほうがいい。だから自分側で先回りする。最後まで残るのは結局、ゲート②で挙げた「死んでいるMac」や連絡がつきにくいユーザーの端末だ。これをフェーズ1の段階で洗い出し、本番展開の通常フローとは別タスクとして早めに潰しておく。スケジュールの末尾に余白を作るより、頭で母数を減らすほうが効く。
▼ヘルプデスクは「リモート操作なし」で設計しておく
移行期間は問い合わせが跳ねる。そして移行中はリモート操作ツールが効かない（旧MDMからのリモート機能を切る／新MDM側がまだ入っていない、という端末が出る）前提で組んだほうが安全だ。
リモート操作なしでどう対応するか——手順書＋ビデオ通話で口頭誘導、というのが現実解になる。これを本番でいきなりやると炎上するので、パイロットの10〜15台で先にヘルプデスク運用そのものをテストしておく。何件問い合わせが来て、1件あたり何分かかるかを測れば、本番のヘルプデスク負荷が事前に読める。
▼代理店経由の移行で最初に握ること
Iruのように代理店が運用に入る形で導入する場合、最初に作業分担を明文化しておく。「どこまで代理店がやって、どこからが自社作業か」。ここが曖昧だと、移行のヤマ場で「それは御社作業です」で止まるパターンがある。Slack Connectでチャンネルを開設したら、まずこの線引きを文章で残しておくと事故らない。
▼まとめ
- ▶ WhatはツールがやるからHowが全て。プロファイルやスクリプトの移送はIruの移行ツールが解決する。情シスの工数と価値はHowに乗る
- ▶ 数百台のMDM移行は3フェーズ＋一部並行で組む。直列は伸びすぎる
- ▶ 段階展開はIT部門を第1週の人柱に置く。問題を全社拡散前に潰す
- ▶ Jamfで死んでいるMacは移行プロファイルが届かず移行できない。フェーズ1で洗い出して先に蘇生させる
- ▶ 検証は「動作確認」ではなくGO/NO-GO判断。FileVaultエスクロー・死んでいるMacの蘇生・Apple Business切替の3つを合否ゲートに昇格させる
- ▶ スケジュールは最後まで残る端末で崩れる。死んでいるMacや連絡がつきにくい端末を先に洗い出し、別タスクで潰す
- ▶ ヘルプデスクはリモート操作なし前提でパイロット時に運用テストする
- ▶ 代理店経由なら作業分担を最初に明文化する
📅 30分無料相談、受け付けています
「MDMを乗り換えたいけど、何百台をどう段取りすればいいかわからない」——そういった段階からお気軽にどうぞ。移行計画のレビューだけでも対応します。
📅 30分無料相談を予約する →