こんにちは、taka4roです。
僕は2024年に、社員約300名の会社でグループウェアをMicrosoft 365（M365）へ移行する主担当でした。期間は8ヶ月で、社内の担当は僕を入れて3名でした。
この記事では、M365移行のきっかけからベンダー選定、苦労したこと、次にやるなら変えたいことまで、実際にあったことだけを書きます。
最後に、この経験を職務経歴書や面接でどう伝えるかもまとめました。これからM365移行を担当する社内SEの方、転職で移行経験をアピールしたい方の参考になればうれしいです。
社内SEがM365移行を担当したきっかけ
きっかけは、それまで使っていたExchange（メールのサービス）が老朽化でサービス終了になることでした。
このExchangeは、グループ共通のものとして既存のベンダーが提供していました。会社として選んだというより、「移行せざるをえない」状況からのスタートです。
移行先はM365です。社員約300名のメールやグループウェアを、業務を止めずに切り替える必要がありました。
ベンダー選定：3社を比較
導入するベンダーは、会社の決まりで3社を比較しました。
| ベンダー | どんな会社か | プレゼン |
|---|---|---|
| A社 | 旧環境（Exchange・グループネットワーク）を提供していた既存ベンダー | 1回 |
| B社 | グループ会社ですでにM365の導入実績があった | 1回 |
| C社 | 以前、IT資産管理ツールの導入でお世話になった | 3〜4回 |
C社だけプレゼンが多かったのには理由があります。うちのグループは特殊なグループネットワークを使っていて、接続に制限がありました。その確認に時間がかかったためです。B社はグループ会社での実績があったので、その点は問題ありませんでした。
導入費用は一番高い会社と安い会社で2倍以上の差がありました。
僕はC社で導入を決めたかったのですが、最終的にはグループで実績のあるB社に決まりました。
ベンダー選定のポイント
グループ会社がある場合、「グループ内の実績」は大きな判断材料になります。担当者としての希望と、会社としての判断が違うこともあります。そのときは、決まった方針の中でどう進めるかに切り替えることも大切です。
体制と進め方
社内の担当は僕を入れて3名です。ベンダーとの打ち合わせは基本この3名で、場面によってチーム長や部長も参加しました。
ただ、旧環境のADやExchangeは、最初の数年を1人で運用していた僕が社内で一番詳しい状態でした。そのため、打ち合わせでの質問への回答や移行データの準備は、ほぼ僕が担当しました。
期間は全体で8ヶ月でした。そのうちベンダー選定に約2ヶ月かかっています。
M365移行の手順（5つのフェーズ）
ここからは、移行の手順を5つのフェーズに分けて紹介します。うちの環境に合わせて決めたことも、あわせて書いています。
フェーズ1：事前準備・設計
1. 要件定義とライセンス選定
うちのPCは2種類ありました。グループ共通の「標準PC」（A社からのリース）と、自社で調達した「個別PC」です。
ライセンスは「スタンダード」と「プレミアム」の2種類にしました。標準PCはスタンダード、個別PCはプレミアムです。個別PCに入っているOfficeのバージョンが、M365に対応していなかったためです。
2. ネットワーク要件の確認
プロキシ・ファイアウォールの通信許可設定を確認しました。M365の特定のURL・IPアドレスを、プロキシを通さずに通信させる（バイパスする）かの検討です。
3. ID管理の方針決定
Entra Connectを使ったハイブリッド構成にしました。既存のオンプレミスのActive Directory（AD）と、アカウント・パスワードを同期する構成です。
ただし、グループネットワークに接続しないPCもあります。そのPCはEntra ID（クラウド側のID管理）のみで管理することにしました。
フェーズ2：テナント開設・基本設定
- テナント（M365の会社用の契約環境）の初期作成
- 独自ドメインの登録・検証
- DNSレコードの設定
DNSには、メールの送受信や自動設定に必要な次のレコードを登録します。
- MXレコード：メールの受信先。旧サーバーから切り替えるタイミングで変更
- TXTレコード（SPF・DKIM・DMARC）：なりすまし防止のためのメール認証
- CNAMEレコード：autodiscover（Outlookの設定の自動化）など
うちの場合、MXレコードとTXTレコードはA社の管理下にありました。
フェーズ3：ID管理とセキュリティ設定
1. 緊急用アクセスアカウント（Break-glass）の作成
通常の管理者アカウントが使えなくなったときのための、予備の管理者アカウントです。
2. アカウント作成・ライセンス割り当て
Entra Connectを構築し、オンプレミスのADとの同期を設定しました。
3. セキュリティの基本設定
- 多要素認証（MFA）の義務化
- 条件付きアクセス：社外からのアクセス制限や、会社支給の端末だけ接続を許可するなどのポリシーを定義
会社支給の端末だけを許可するには、端末をM365に登録（デバイス登録）する必要があります。このデバイス登録で、ユーザーの1割がつまずくことになります（後ほど「苦労したこと」で書きます）。
フェーズ4：主要サービスの構成・データ移行
1. Exchange Online（メール）
- 旧Exchangeからのメールボックス移行
- 共有メールボックス、配布グループ（複数人あてのメールアドレス）、スパム対策ポリシーの作成
- 移行日の1週間前から、旧Exchangeに届いたメールをM365にも転送
2. ポータルサイトの構築（SharePoint）
旧Exchangeの環境で構築済みだったポータルサイトを手動で移行しました。
3. Microsoft Teams
- チームを作成できる人を制限するポリシー
- 社外とのチャット（フェデレーション）の許可・拒否の設定
4. Microsoft Intune（MFA用の端末登録）
PCの管理はSKYSEA、スマホの管理はCLOMO MDMですでに行っていました。そのため、IntuneはMFA（多要素認証）のためだけに使いました。
- コンプライアンスポリシー（OSのバージョン、BitLockerの有効化など）の作成
- 端末の登録（Windows Autopilot、職場アカウントの接続）
フェーズ5：クライアント展開・運用開始
1. M365 Apps（Office）の展開
個別PCのみが対象です。
2. 旧Officeからの切り替え
Outlookのプロファイルを作り直しました。
3. 展開準備と切り替え
- 社員向けマニュアルの手直し
- 多要素認証用iPhoneの調達・展開
- 切り替え当日のプロキシ変更
4. 運用設計・監視
監査ログ（Purview）の保持期間を確認しました。
M365移行で苦労したこと
1. デバイス登録ができないユーザーが1割
グループのセキュリティポリシーで、多要素認証・デバイス登録・ハイブリッド参加が必要でした。
ところが、PCにはグループネットワークの中にあるものと、外にあるものがありました。その影響もあり、デバイス登録に手間がかかりました。最終的にユーザーの1割がうまく登録できない状態になりました。
導入ベンダーのSEも、原因をすぐには解消できませんでした。相談した結果、B社が制限を外したグループを作り、登録できないユーザーをそこに入れて対応しました。
2. 切り替え時のプロキシ変更
切り替えのときはプロキシの設定変更が必要でした。ただ、グループネットワークを提供しているのはA社なので、変更はA社にお願いするしかありません。
そこで、変更内容をB社に作ってもらい、A社が変更する流れにしました。変更がうまくいったかの確認や調整は、間に立つ僕の仕事です。ここはかなり苦労しました。
さらに切り替えの直前になって、プロキシ変更のテストに日数がかかることがわかりました。A社は慎重に進める考え方で、テストの方法にも時間をかける必要があったためです。その結果、切り替え本番は2週間先に延期になりました（8ヶ月はこの延期を含んだ期間です）。
3. マニュアルの手直し
社内展開用のマニュアルは、ベンダーが作成したものをほぼ僕が社員目線で手直ししました。
このとき見かねた他の社員が、手直ししたマニュアルをチェックしてくれました。これはとても助かりました。
4. 多要素認証用のiPhoneの調達
多要素認証は社用のiPhoneで行うことになりました。ところが事務職にはiPhoneを貸与していなかったので、新たに調達して展開する必要があり、これにも苦労しました。
5. 移行後は問い合わせが増えた
移行が終わってからは社内の問い合わせが増えました。切り替えて終わりではなく、その後の対応までが社内SEの仕事です。
やって良かったこと
既存ベンダーのSEと関係ができていた
旧環境のADやExchangeを担当していたA社のSEとは、過去のリプレイスも一緒にやっていてかなり仲良くなっていました。そのおかげで、今回も色々助けてもらえました。
導入ベンダーとは別に、旧環境を知っている人に相談できたのは大きかったです。ひとり情シスの方ほど、普段のつきあいを大切にしてほしいと思います。
旧環境を社内で一番知っていた
1人で運用していた時期があったからこそ、ベンダーの質問に答えられ、移行データも用意できました。地味な運用の経験が、移行プロジェクトで生きました。
ITに詳しくない社員にマニュアルを見てもらえた
社員目線で書き直したつもりでも、ITに詳しい人の目線は抜けきりません。実際に使う側の人にチェックしてもらえたのは、本当にありがたかったです。
業務を止めずに移行できた
1割のデバイス登録トラブルなど、問題はいくつもありました。それでも業務を止めずに約300名の移行を終えることができました。
次にやるなら変えたいこと：多要素認証の方法
一番変えたいのは、多要素認証の方法です。
今回は社用iPhoneにしました。先に切り替えたグループ会社がそうしていたので、それにならった形です。
でも事務職に持たせたiPhoneは、ほぼ多要素認証のときにしか使われていません。ほとんど使われないまま、費用がかかり続けています。個人のスマホで認証している組織もあるので、わざわざ調達する必要はなかったと思っています。
次にやるなら
決裁者には、「何台必要で、どのくらい使われ、毎月いくらかかるか」を数字で見せて提案します。ほかの会社にならう前に、自社の使い方に合っているかを確かめることが大切です。
M365移行の経験を職務経歴書・面接でどう伝えるか
M365移行は多くの会社が経験しているテーマです。だからこそ「何をしたか」を具体的に書くと差がつきます。
職務経歴書の書き方の例
NG例
グループウェアのM365移行を担当。
OK例
社員約300名のグループウェアをM365へ移行（2024年、8ヶ月、社内3名体制の主担当）。ベンダー3社の比較、旧環境（AD・Exchange）の情報整理と移行データの作成、ネットワーク提供ベンダーと導入ベンダーの間の調整、社員向けマニュアルの改訂を担当し、業務を止めずに移行を完了。
面接では、苦労したことをどう乗り越えたかを話せるようにしておくと安心です。僕の場合なら、デバイス登録のトラブルや3社の間に立ったプロキシ変更の調整がそれにあたります。
職務経歴書全体の書き方は40代社内SEの職務経歴書の書き方で、社内SEの経験を伝わる言葉に言い直す方法は社内SE経験の価値化ガイドで詳しく書いています。
まとめ
M365移行は、技術の作業以上にベンダーや社内との調整が多いプロジェクトでした。
- きっかけは既存Exchangeのサービス終了
- ベンダーは3社を比較し、グループで実績のある会社に決定
- デバイス登録・プロキシ変更・iPhoneの調達で苦労した
- 既存ベンダーのSEとの関係と、旧環境の知識が助けになった
- 次にやるなら、多要素認証の方法を数字で見直す
これから移行を担当する方は、旧環境を知っている人とのつながりをぜひ大切にしてください。
僕の経歴についてはプロフィールにまとめています。