#5　スケジューラもメールもMicrosoft 365へ移行。ユーザを第一に考えたIIJの移行方法とは

青木

そうですね。元々IIJが自社で開発したWebベースのスケジューラを利用していましたが、2年ぐらい前に外部サービスへリプレースすることにしました。リプレースに当たって様々なサービスを検討した結果、Microsoft 365の採用を決定しました。

青木

苦労しました（笑）
一例をあげると、一度設定したスケジュールの編集があります。旧スケジューラでは誰でも編集できる仕様でしたが、Microsoft 365では基本的に予定登録した本人だけが編集できる仕様なんですね。その点、大きく考え方が異なるので。

青木

はい。なのでIIJでは全員に予定の編集権限を与える設定をすることで、その予定の所有者のスケジュールからにはなりますが、全員が編集できる環境を再現することにしました。やはり、それがIIJの使い方にマッチしていると思いました。

青木

あとはデータのコンバートにも苦労しました。移行元が自社開発の製品なので、サードパーティの移行ツールが使えず、移行ツールの開発から行いました。

青木

いえ、旧スケジューラのデータベースからデータをエクスポートし、Microsoft 365にメール送信して登録する仕様で、移行ツールを開発しました。Microsoft 365のUI上で登録した時と同じ動作になりますね。
そんな感じで考え方が全然違うスケジューラですし、社員のみなさんの操作トレーニングもありますので、念のため旧スケジューラとMicrosoft 365スケジューラの並行稼働期間を設けました。

青木

連携ツールを自社開発しました。双方向でデータ連携する必要があるので、これもなかなか大変でしたね。

青木

意識はしていたので、並行期間を設け、段階的に移行していく形をとっていたのですが、想像以上にプロキシサーバに負荷がかかり、一時的にアクセスが遅延する事態が起きてしまいました。
その時は対応に追われましたが、すぐにプロキシオフロードする環境が整えられたので幸いにも大きな問題とならずに済みました。

関

IIJの場合、スケジューラのリプレースを先に完了させて、少し後にMicrosoft 365のメール機能もリリースしました。メール機能は、一部オンプレミスのメールサーバやセキュリティ系の機能と連携する必要があったので。

森

今は全体の約3割がMicrosoft 365のメールを利用していますね。やはり過去のメールの蓄積がありますので、簡単には移行できない方が多いみたいですね。

森

そうですね。情シスとしてはユーザの利便性を第一に考えて、2種類から選択できるようにしている、という意味もあります。
ユーザ自身が自分のタイミングで移行できるように、WebのGUIから変更できるツールを開発しました。

森

実は双方の環境を運用維持するのは大変なんですけどね（笑）
オンプレミス環境のサーバ台数も数十台レベルの規模ですし。

関

IIJでは、自社のサービス運用でもメールを利用します。例えば、お客様へのアナウンスにもメールを利用しているので、IIJ自身のコントロールで運用できるオンプレミスの環境も維持する必要があるんですよね。

森

あとは、グループ企業のメール環境も運用しているのですが、会社ごとにポリシー、運用、配送経路が違うところがありますので、個々にコントロールする必要があります。それを実現するのにオンプレミスの環境が必要ですね。統一できるところはなるべく統一するように調整はしていますが、すべては統合できないので。

森

そうですね。例えば、新入社員がメールを設定するときのデフォルトをオンプレミスからMicrosoft 365に変更するなど、徐々に移行を進めてもいいかもしれません。
Microsoft 365の良い点として、メールとスケジューラのUIがOutlookで統合されたり、Exchange Onlineでブラウザやスマホアプリで見られたりする点がありますしね。

関

今後は、メールに大きく依存している業務や運用を、何か別の方法へ移行することも検討できると思います。コミュニケーションツールとしてTeamsの活用も進んできましたので、より良い運用を模索したいですね。