Mac 約380台の管理を Jamf から Iru へ移す計画。本番前に確かめる3つ

会社の Mac を遠隔でまとめて管理するサービス（MDM と呼ばれる）を、別の製品に乗り換える。ある約380台規模の会社で、その計画を組んだ。乗り換え元は Jamf Pro、乗り換え先は Iru（旧 Kandji）。どちらも会社の Mac に設定やアプリを配り、状態を見張るためのサービスだ。移行期間は約1ヶ月。

乗り換えで難しいのは、設定の引っ越しではない。それは乗り換え先の移行ツールがほぼやってくれる。困るのは別のところだ。何ヶ月も管理サービスと連絡が途絶えている Mac は、そもそも乗り換えられない。社員がパスワードを忘れて Mac に入れなくなったとき、会社側で開けるための鍵がある。この鍵が新しいサービスに預け直されていないと、そういうときにその Mac を誰も開けられなくなる。そして最後まで残る数台の作業が遅れると、古いサービスの契約が切れる日に間に合わない。

この記事では、約380台を事故なく、期限内に、仕事を止めずに切り替えるために、計画をどう組んだかを書く。中心は、本番に進む前に必ず確かめる3つのことだ。設定の名前や手順の細かい話は、後半の「担当者向け」にまとめた。

Mac の管理サービスの乗り換えを調べても、ネットに出てくるのは製品の紹介か、ベンダーの提案資料くらいだ。何百台を期限内に切り替える段取りの一次情報は、ほぼ見当たらない。だからここに残しておく。

▼背景：製品選びは終わっている。考えるのは切り替え方

乗り換えを決めたら、最初に考えるのは「どちらの製品が優れているか」ではなく、「380台をどう事故なく、期限内に、現場を止めずに切り替えるか」だ。

乗り換えの理由は会社によって違うが、だいたい「費用」「運用の手間」「製品の進む方向」のどれかに集約される。製品の進む方向とは、Apple が進めている新しい管理の仕組み（DDM）や、よく使うアプリを自動で入れて最新に保つ Iru の機能（Auto Apps）のような、新しい管理のやり方にどれだけ対応しているか、だ。今回もそのあたりが軸だった。

ただ、製品の比較は終わっている前提だ。ここから先は「移行プロジェクトの設計」の話になる。

▼難しいのは「何を移すか」ではなく「どう移すか」

設定やアプリの引っ越しはツールがやる。情シスが考えるべきは、ツールが運べない「どう移すか」だけだ。

Mac に配っている設定のまとまりも、自動で動かしている小さなプログラム（スクリプト）も、アプリの配り方も、Iru の移行ツールが Jamf から一括で持ってくる。検証用の5台で「ちゃんと運べたか」を確かめれば終わる話だ。

ツールが運べないのは、連絡が途絶えている Mac をどう乗り換えの土俵に乗せるか、社員にどう動いてもらうか、最後まで残る Mac をどう先回りで片付けるか、の3つだ。この記事で挙げる「本番前に確かめる3つ」も、すべてここの話だ。

▼乗り換えは3つの段階に分けて組む

一気にやると確実に事故る。段階を分け、前の段階の結果を見てから次へ進む。今回は3段階で組んだ。

ポイントは、1と2を一部並行で走らせることだ。案内文づくりや部署の順番決めは、検証の結果を待たなくても進められる。逆に検証は、新旧のサービスがつながった瞬間に始める。順番に一つずつ組むと、スケジュールが伸びすぎる。

本番は部署ごとに週を分けて切り替える

380台を一斉に切り替えるのは自殺行為だ。今回はこう刻んだ。

第1週には必ずIT 部門を先頭に置く。自分たちが最初に乗り換えを通れば、手順書の穴と問い合わせ窓口の負荷が、現場に広げる前に見える。事業部から始めると、問題が全社に広がってから気づくことになる。

▼ここが本題：本番に進む前に確かめる3つ

計画の「順番」は、正直そこまで難しくない。怖いのは、確かめないと本番で詰む箇所を見落とすことだ。

今回は次の3つを、ほかの確認項目と同じ並びには置かず、「ここが駄目なら本番に進まない」関門（合否ゲート）として扱った。合格の条件は次のとおりで、どれか1つでも欠けたら本番に進まない。

① Mac に入れなくなったときの「鍵」が、新しいサービスに預け直されるか

② 何ヶ月も連絡のない Mac を、本番の前に起こしておく

③ 新しい Mac の行き先は、「標準」と「1台ずつ」を分けて切り替える

▼スケジュールで一番崩れるのは「最後まで残る一部」

移行のスケジュールで、ほぼ確実に崩れるのが最後まで残る一部の Mac だ。連絡がつかない人、乗り換えを渋る人、トラブルが起きた Mac。この最後の一部が、全体で一番時間を食う。

▼問い合わせ窓口は「画面を遠隔で操作できない」前提で用意する

移行期間は問い合わせが跳ねる。しかも移行中は、担当者が社員の画面を遠隔で操作して助けられない Mac が出る。旧サービスの遠隔機能はもう止めた、新しいサービスはまだ入っていない、という Mac だ。その前提で組んだほうが安全だ。

遠隔操作なしでどう助けるか——手順書とビデオ通話で口頭で案内する、というのが現実的な答えになる。これを本番でいきなりやると炎上するので、先に乗り換える10〜15台で、問い合わせ対応のやり方そのものを試しておく。何件問い合わせが来て、1件に何分かかるかを測れば、本番の負荷が前もって読める。

▼販売代理店が入るなら、最初に作業の分担を文章にする

Iru のように販売代理店が運用に入る形で入れる場合、最初に作業の分担を文章にしておく。「どこまで代理店がやって、どこからが自社の作業か」。ここが曖昧だと、移行のヤマ場で「それは御社の作業です」で止まることがある。代理店との連絡用のチャットを開いたら、まずこの線引きを文章で残しておくと事故らない。

▼まとめ：自分の会社で確かめる4つ

Mac の管理サービスの乗り換えで、設定の引っ越しはツールがやる。手間がかかるのは、連絡の途絶えた Mac、入れなくなったときの鍵、最後まで残る数台だ。だから計画の順番より先に、本番前の関門を決めておく。

乗り換える予定があるなら、計画を組む前に、担当者（または委託先・代理店）に次の4つを聞いておけばいい。

• ▶ 何ヶ月も管理サービスに連絡が来ていない Mac が、何台あるか：その Mac はそのままでは乗り換えられず、最後まで残る候補になる。誰の Mac かまで分かれば、本番の前に起こしておける
• ▶ 社員が Mac に入れなくなったときの鍵を、乗り換え後も新しいサービスから出せるか。それを本番前に確かめる計画になっているか：「たぶん大丈夫」ではなく、検証用の Mac で全台確かめてから本番に進むか
• ▶ 移行完了の目標日と、旧サービスの契約が切れる日の間に、何日あるか：今回は約1週間しかなかった。短いなら、最後まで残りそうな Mac を最初に洗い出す
• ▶ 販売代理店との作業分担が、文章になっているか：「どこからが自社の作業か」が曖昧なまま本番に入らない

▼担当者向け：設定と手順の詳細

ここからは、実際に移行を組む人向け。前半の言い方と、実際の名前の対応から。

前半の言い方と、実際の名前

3フェーズの中身

移行の仕組み（ゲート②の前提）

端末側はターミナルにワンコマンド叩くだけなので、ユーザー手順に乗せられる。前提は Jamf 経由で移行プロファイルが届くこと。チェックインが止まっている端末には届かない。

3つの合否ゲートの中身

• ▶ ゲート①：FileVault Recovery Key のエスクロー：再エンロールの流れで、Recovery Key が新 MDM 側に確実にエスクローされるか。Iru は FileVault がすでにオンの Mac が登録されると、Recovery Key のローテーションをユーザーに促し、新しいキーをエスクローする（ディスクの再暗号化ではない。ローテーションにはユーザーのパスワード入力が要る。出典：Configuring FileVault（Iru／旧 Kandji））。ロックアウト時に Recovery Key を出せないと端末が文鎮化する。検証5台で全台エスクロー成功を確認できるまで本番 GO しない
• ▶ ゲート②：Jamf で死んでいる Mac の蘇生：フェーズ1で Jamf のインベントリを最終チェックイン日でソートし、数ヶ月チェックインがない端末を全部洗い出す。本番展開が始まる前にユーザーへ連絡し、起動・チェックイン復帰させておく。蘇生は移行展開とは別タスクにする
• ▶ ゲート③：Apple Business のデフォルト MDM サーバ切替と段階展開の整合：デフォルトの MDM サーバを新 MDM に切り替えると、新規・ワイプした端末はすべて新 MDM 行きになる。既存端末はバッチで移すので、切替タイミングで再起動・初期化した端末が中途半端な状態にならないよう、「デフォルトサーバ切替」と「個別デバイスの MDM 割り当て」を分けて段取りする

ヘルプデスクと代理店

• ▶ リモート操作ツールが効かない端末が出る：旧 MDM からのリモート機能を切る／新 MDM 側がまだ入っていない、という端末が出る。手順書＋ビデオ通話の口頭誘導を、パイロットの10〜15台で先にテストし、問い合わせ件数と1件あたりの所要時間を測る
• ▶ 代理店との作業分担：Slack Connect でチャンネルを開設したら、まず「どこまで代理店、どこから自社作業か」を文章で残す