120ライセンス、9カ国、オフィスなし：分散型チームのMicrosoft 365ライセンス管理

オフィスが存在しないとき、テナントこそが会社そのものになる。 完全リモートのMicrosoft 365環境で本当に怖いのは、多くの場合セキュリティ事故ではなく「じわじわとした劣化」だ——誰が割り当てたか誰も覚えていないライセンス、退職後もアクセスできてしまうアカウント、実際の業務にもう合っていないライセンス階層、そして誰も見直さない更新。これを直すのはセキュリティプログラムではなく、周期的に回すライセンス衛生管理である。

オフィスのない完全リモート組織と、たった一つのMicrosoft 365テナント

従業員約120名のソフトウェア企業を思い浮かべてほしい。いわゆる本社は存在しない——エンジニアリングはアジアの数都市に分散し、カスタマーサクセスの多くは湾岸諸国、小さなプロダクト・デザインチームは欧州で働き、営業はオーストラリアとアジア太平洋の他地域を、それぞれが暮らす場所からカバーしている。全員が最初からリモート採用で、誰一人としてオフィスに足を踏み入れ、目の前のIT担当者からノートパソコンを手渡されたことがない。これは特定の顧客を指すものではない複合的な例示シナリオだが、今日のリモート優先のソフトウェア・サービス企業にとって、その形はごく一般的なものだ。

このような会社にとって、Microsoft 365はオフィスネットワークに付随するものではなく、それ自体がオフィスである。メール、チャット、ファイル、カレンダー、ビデオ会議、そしてほぼすべての他のSaaSツールがログインの拠り所とするID——そのほぼすべてが一つのMicrosoft 365テナントの中に収まっている。守るべきサーバールームもなければ、監査すべき入退室システムもなく、物理的な境界線自体が存在しない。テナントそのものが境界であり、同時にファイルキャビネットであり、電話システムであり、玄関でもある。

最終的にこの問題を抱え込むのは、たいてい運営責任者やチーフ・オブ・スタッフのような役職の人で、彼らが自ら望んでIT運用を担いたいと思ったわけではない。誰かが管理者アカウントを持たなければならなかったから引き継いだだけで、実際の日々のテナント運用は、採用や給与処理の合間に見つけたわずかな時間でこなされてきた。本稿はまさにその立場の人に向けて書かれている。

「本格的なセキュリティプログラムは求めていない」という立場が合理的である理由

はっきり言っておく価値がある。従業員120名のリモート企業が、大がかりなセキュリティ体制を求めていないと言うのは、決して不注意なのではない。この規模の事業で、規制対象データもなく、特定の管理フレームワークを強制するコンプライアンス義務もない場合、セキュリティオペレーションセンターの構築、専任アナリストチーム、特定規格に基づく正式な監査といったフルスペックのセキュリティ運用体制は、目の前の実際のリスクに対して過剰な投資になることがほとんどだ。事業に必要以上のセキュリティを買うこと自体もコストであり、しかもそのコストは、日々実際に問題を引き起こしている原因を解決しない。

このようなテナントで実際に問題を引き起こしているのは、たいてい高度な攻撃ではなく、管理面での劣化だ。半年前に無効化されているべきだったアカウント、すでに存在しない役割のために購入されたライセンス階層、誰も見直さないまま静かに更新されたサブスクリプション。これらを直すのにセキュリティプログラムは要らない。必要なのは、ビル管理人が建物を管理するようにテナントを管理する人——派手ではなく、セキュリティとして語られることもないが、決められた周期で実行される仕事だ。

この区別は本稿の以降の内容にとって重要である。ここから先の内容は、従業員120名のリモート企業に不要なセキュリティ機能の構築を求めるものではない。求めるのは、規模にかかわらず本当に譲れない、ごくわずかな項目と、日常のライセンスおよびアクセス権の衛生管理を、誰かが手隙のときにやる作業ではなく、通常の業務として扱うことだけだ。

分散型のMicrosoft 365テナントでは、実際に何が起きるのか

明確な責任者を持たないまま成長してきたテナントでは、四つのパターンが繰り返し現れる。一つひとつは単独では大したことがないように見えるが、一、二年積み重なると、テナントは必要以上にコストがかかり、誰もが思っているほどには制御が効いていない状態になる。

誰が割り当てたか誰も覚えていないライセンス

契約社員のプロジェクトが終わってもアカウントは無効化されない。役割が再編されても、古いライセンスは誰も使わないアカウントに割り当てられたままになる。あるチームツールの試用のために10席契約したのに、実際に触られたのは3席だけ。これらは意図的な浪費ではなく、ライセンス割り当てが一方通行の操作であり、誰も見直さないまま放置される場合に自然と起きることだ。分散型のチームには、空いた席に気づくオフィスマネージャーに相当する存在がいないため、こうした宙に浮いたライセンスは、互いの席が見える環境よりもはるかに長く生き延びる傾向がある。

想定より長く残ってしまう退職者のアクセス権

オフィスのある会社では、オフボーディングには物理的なきっかけがある。ノートパソコンが返却され、入館証が無効化され、誰かが空いた椅子に気づく。完全リモートの会社では、唯一のきっかけは誰かがITに伝えることを思い出すかどうかだ。退職する人がテナントを管理する人と8時間の時差がある場所にいれば、「今日ITに伝えようと思っていた」は簡単に「3日後にようやく伝えられた」に変わってしまう——そしてその3日間、退職済みの従業員のメールボックス、ファイル、接続済みのあらゆるSaaSツールは、退職前日とまったく同じようにアクセス可能なままだ。

実際の業務にもう合っていないライセンス階層

ライセンス階層は積み重なった歴史を帯びていく。2年前に、今はもう終わったプロジェクトのために誰かに上位階層を割り当てた。新しく入った人には、その役割の前任者が使っていた階層をそのまま引き継がせる、実際の業務に合っているかどうかにかかわらず。120名規模で数年経つと、テナントには基本階層で十分な人に高額なライセンスが割り当てられている例が一定数生じ、逆に、本当は上位階層が必要な業務をしている人が、誰にも気づかれないまま入門階層のまま制約を回避して働いている、というケースも稀に起きる。

誰も所有していない更新

Microsoft 365のサブスクリプションは、誰かが事前に見直すかどうかにかかわらず更新される。カレンダー上に「この構成は今の会社と業務にまだ合っているか」を誰かが問う固定の時点がなければ、更新は単に前年の割り当てを繰り返すだけになる。安定した年であればそれでも問題はない。だが採用、組織変更、退職を繰り返すうちに、更新日はもはや会社の現状を反映せず、前回誰かがきちんと見た時から積み重なったものをそのまま反映するようになる。

入社・異動・退職がチェックリストではなくプロセスであるべき理由

チェックリストは、誰かがそれを実行することを覚えていることを前提にしている。この前提こそが、分散型のチームで最も崩れやすい部分だ。なぜなら、ある時区の退職者に対してチェックリストを実行すべき人は、しばしば眠っていたり、何時間も離れた時区にいたり、そもそも最初にそれを知った人ではなかったりするからだ。チェックリストと区別されるプロセスには、少なくとも三つの要素がある。誰が最初に気づいたかにかかわらず起動する単一のトリガー、退職者のいる時区で誰も起きていなくても実行を完了させる責任を負う明確な担当者、そして実際に実行されたかどうかを示す記録である。

入社は比較的簡単な半分だ。新入社員には初日からアカウント、その役割に合ったライセンス階層、そのチームが実際に使うツールへのアクセス権が必要であり、最も権限の大きい人のアクセス権をそのままコピーするべきではない——それこそが過剰付与されたアカウントが最初に生まれる原因だ。異動はほとんどの会社が完全に見落としている半分である。社内で役割を変えた人のアクセス権が見直されることはめったになく、2年間で三つの役割を経験した人は、その三つ分のアクセス権を積み重ねたまま持ち続けることになりかねない。

退職は時差の問題が最も強く影響する場面だ。オフボーディングのトリガーは、退職する人の上司がたまたまどの時区にいるかに左右されるべきではない。人事が退職日を確定した瞬間に起動し、その担当者がどこにいて何時であっても実行する責任を負い、標準的な手順に沿って完了させるべきである——サインインを即座に無効化し、メールボックスとファイルの扱いを決め、それが決まった時点でライセンスを削除し、そのアカウントがどのアクティブな一覧にも表示されないことを確認する。退職する従業員のメールボックスを共有メールボックスに変換することは、まさにこの状況に対してMicrosoft自身が公式に示している方法だ。アカウント自体は「アンカー」として残り、上司や後任者がメールやファイルにアクセスし続けられるようにしながら、そのアカウントのサインインは無効化され、その後、そのアカウントに付いていた有償ライセンスを削除できる——これこそが、誰も使っていない席の料金を実際に止める部分である。これをチェックリストではなくプロセスとして扱う分散型チームと、そうでないチームの違いは、退職者のアクセス権が数時間で終わるか、誰かがたまたま気づくまでひっそりと残り続けるかの違いになる。

ライセンスの適正化のために何を測定し、どのくらいの頻度で見るべきか

ライセンスの適正化にセキュリティ監査は必要ない。必要なのは二つの習慣だ。実際に誰が何を使っているかを測定すること、そしてそれを誰かが手が空いたときではなく決まった周期で行うことである。

毎月実行する価値のある二つのレポート

一つ目はライセンス利用状況のビューだ。Microsoft 365管理センターの使用状況レポートは、アプリケーションごとに、ライセンスを保持しているユーザーが実際にアクティブかどうかを示す。これにより、何か月も使われていないライセンスが、もはやその役割にすらいない人の名前に紐づいている、という状況が一目でわかる。二つ目はサインインアクティビティのビューだ。Microsoft Entra管理センターのユーザー一覧に「最終インタラクティブサインイン」と「最終非インタラクティブサインイン」の列を追加し、日付でソートすることで、静かになっているアカウントを洗い出せる。これはしばしば、オフボーディングが完全には終わっていない退職者や、期限を区切ることを誰も覚えていなかった契約社員アカウントの最初の兆候である。

この二つを月に一度実行し、レビューの担当者を一人決め、フラグの立った各アカウントを自動的な削除対象としてではなく確認すべき問いとして扱う——静かになっているアカウントの中には、退職した人ではなく育児休業中の人のものもあるからだ。この習慣を毎月続けるだけで、上記の劣化の大部分を、更新のタイミングで驚かされる前に食い止められる。

この種の顧客であっても省略できない最小限のセキュリティとは何か

以下の内容は、従業員120名のリモート企業を、本格的なセキュリティプログラムを運用する企業に変えるものではない。会社の日常業務すべてを預かるテナントであれば、より大きな体制への意欲の有無にかかわらず本当に譲れない、ごく一部の項目である。

一つ目は、すべてのアカウントでの多要素認証（MFA）の有効化で、例外はない——登録の手間を理由に静かに除外されがちな契約社員アカウントや共有サービスアカウントも含めてである。二つ目は基本的な条件付きアクセスだ。最低限、最も機密性の高いシステムへのアクセスには管理対象または準拠デバイスを要求し、見慣れない場所や見慣れないデバイスからのサインインは、そのまま通すのではなく再確認に値するものとして扱う。どちらもセキュリティチームの運用を必要とせず、一度設定すれば動き続ける類のものだ。

Microsoft自体の保持機能がバックアップではない理由

三つ目は、テナント内にある実際のデータの復元可能なバックアップであり、これが最も誤解されやすい点である。Microsoftに組み込まれている保持ポリシー、バージョン履歴、ごみ箱の仕組みは、製品を通常使う中での短期的な誤削除に対応するために存在する——誰かがファイルを削除して同じ週のうちに戻したい、あるいはメールボックスの項目が削除されて間もなく復元が必要になる、といった場面だ。これらは、事業継続計画が想定するような意味での「バックアップ」——独自の復旧ポイントを持ち、Microsoftの保持設定がたまたま許す期間ではなく自分たちで決めたスケジュールで復元できる、独立して監視されたデータのコピー——として設計・テスト・運用されているわけではない。Brocentのクラウド管理バックアップサービスは、まさにこのギャップを埋めるために存在する。定義された目標復旧時間と目標復旧時点に基づいてバックアップと復旧のポリシーを設定し、バックアップジョブを無人のまま動かすのではなく継続的な監視のもとで実行し、実際に復元できるかどうかを想定に頼らず検証する定期的な復旧演習を含む。現場にIT担当者がおらずバックアップの失敗にサイレントに気づけない完全リモート企業にとって、監視され検証されたバックアップは、任意のオプションというよりほぼ譲れない項目に近い——それはテナントが特別な脅威にさらされているからではなく、何か起きたときにそれ以外の安全網が存在しないからだ。

オフィスがないとき、デバイスはどう管理すべきか

リモート企業も、オフィスが暗黙のうちに答えていた問いに答えなければならない。このデバイスは登録され把握されているか、最低限のセキュリティ基準を満たしているか、そして人が退職したときにどう扱うのか、という問いだ。デバイスの登録は、業務で使われ始める前に済ませておくべきであり、後から取ってつけるべきものではない——会社支給か個人所有かにかかわらず、新入社員のノートパソコンは、Microsoft 365アカウントを発行するのと同じプロセスの中でデバイス管理に登録されるべきで、誰かが後で思い出して行う別のステップにしてはならない。

適切な基準は短くても十分に実行可能だ。ディスク暗号化を有効にし、OSを最新に保ち、デバイスが紛失した場合や雇用関係が終了した場合に企業データをリモートで消去できる手段を持つ——これらはどれも、すべてのノートパソコンを今にも起きるセキュリティインシデントであるかのように扱うことを求めるものではない。個人所有のデバイスを業務に使う場合は、会社支給のデバイスとは違う対応が必要になる。個人の携帯電話を完全にワイプすることは、ほとんどの会社が望むことでも、ほとんどの従業員が望むことでもないからだ。現実的な落としどころは、企業データをデバイス上の管理された領域に分離し、個人の写真やメッセージに触れることなくその部分だけを消去できるようにすることである。この分離の具体的な仕組みについては、同じように分散したチームを対象にシンガポールのSaaS企業向けMDMおよびBYODデバイス管理ガイドで詳しく取り上げており、そこではMDMおよびBYOD管理そのものがどのように登録とコンテナ化を行うかも解説している。本稿ではその内容を繰り返さない——デバイスが最も気になる部分であれば、次に読むべきはそちらの記事だ。

複数国にまたがるチームが見落としがちな落とし穴

ライセンスとデバイス以外にも、チームが一つの建物に集まっているのではなく複数の国に分散しているからこそ現れる問題がいくつかあり、それらは具体的な問題が起きるまで気づかれにくい。

一つ目はデータレジデンシーに関する期待だ。国や顧客によってデータが物理的にどこに存在すべきかについての期待は異なり、十数か国からログインするスタッフを抱える完全リモートチームは、少なくとも自社のMicrosoft 365データがどこに存在するのか、そしてそれが顧客や規制当局にすでに行った約束を満たしているのかを把握しておく必要がある——これは顧客に聞かれる前に答えを用意しておくべき問いだ。

二つ目はサポート体制における現地の祝日で、見た目以上に業務を混乱させる。ある一つの地域のカレンダーに基づいて組んだ当番表は、他のすべての地域の祝日に静かに穴を作る。アジア、湾岸諸国、欧州、オーストラリアにまたがるチームでは、全員をカバーできる単一のカレンダーは存在しない。解決策は増員ではなく、最初から関連するすべての国のカレンダーに照らして当番計画を組むことであり、実際に問題が起きた日に穴を発見することではない。

三つ目、そして前述の入社・異動・退職の問題の最も一般的な現実の原因は、給与計算に連動した入退社日である。人事・給与システムは、特に複数の国にまたがり労働法や給与サイクルが異なる場合、入社日や退職日が確定した瞬間にITへ通知するとは限らない——システム同士が連携していないこともあれば、そもそも誰がその橋渡しをする役割なのかが明確に定義されていないこともある。入社日がITに遅く伝わると、新入社員の最初の数日が生産的に使えない。退職日が遅く伝わると、それが本稿前半で述べた退職問題の最も典型的な現実の姿になる——悪意でもチェックリストの見落としでもなく、二つのシステムが互いに知らせ合うように設計されてこなかっただけのことだ。

なぜ四つの別々のツールではなく、一つの統合されたプランにまとめるべきなのか

これまで挙げた四つの問題——宙に浮いたライセンス、退職者に残るアクセス権、実態に合わない階層、誰も所有しない更新——に加え、入社・異動・退職プロセスの穴、そして複数国運用ならではの落とし穴は、すべて同じ場所で起きている。つまりMicrosoft 365テナントと、それに紐づく人とデバイスの記録だ。これが、四つの異なるベンダーから四つを別々に購入するのではなく、一つのものとして管理することの実務的な根拠である。

分散型チームがMicrosoft 365を管理する三つのやり方

• 正式には誰も所有していない。 テナントを最初に構築した人がそのまま管理者権限を持ち続け、ライセンスの割り当ては誰かに頼まれたときだけ場当たり的に行われ、オフボーディングは誰かが伝えることを覚えているかどうかに依存する。これは急成長するリモート企業が誰も意図せずに陥るデフォルトの状態であり、これまで述べたすべての問題の発生源でもある。
• 四半期ごとの表計算による棚卸し。 誰かが四半期に一度ユーザー一覧をエクスポートし、人員名簿と手作業で突き合わせ、見つかった問題を片付ける。これは最悪の状態はいずれ食い止められるが、退職者のアクセス権は次のレビューまで最長で三か月開いたままになり得るし、その作業はその四半期に担当者が時間を取れるかどうかにすべて依存する。
• 一つの統合されたプランを、継続的に運用する。 ライセンス利用状況とサインインアクティビティは、たまに行うプロジェクトではなく毎月のルーティンとしてレビューされ、入社・異動・退職の依頼は時区にかかわらず一つの明確なプロセスを通り、テナントを管理するのと同じチームがデバイス登録とそれを守るバックアップも管理する——これらは本来四つの別々の問題ではなく、同じテナントの四つの側面にすぎないからだ。

ここで、具体的に言い切っておく価値のある主張がある。Brocent自身のマネージドITプラットフォームは、寄せ集めの外部ツール群ではなく、単一のエンジンとして構築されている。プラットフォーム自身の各モジュールがデータを共有しているからこそ、私たちのマネージドITサービスは、未使用の前払い済みソフトウェア席をフラグ立てし、ハードウェアのライフサイクルを追跡することを、誰かが別途スケジュールを覚えていなければならない監査プロジェクトとしてではなく、プラットフォームの通常機能として組み込んでいる。これはプラットフォームが現在実際に備えている機能であり、仮定の上のメリットではない——表計算による棚卸しが手作業で近似しようとしていることと同じ仕組みを、四半期に一度ではなく継続的に動かしているだけのことだ。同じプラットフォームは、Microsoft 365テナントが依存するクラウドサービスと、前述のデバイス管理層も併せて調整する——これが「四つのツールではなく一つのエンジン」の実際の姿であり、単なるスローガンではない。

よくある質問

従業員120名のリモートチームに専任のITチームは必要ですか

必ずしも完全な社内チームは必要ありません。必要なのは、社内・外部を問わず、このテナントを継続的かつ明確に所有する人——ライセンス割り当て、毎月の利用状況・サインインレビュー、入社・異動・退職プロセス——です。120名規模の会社であれば、運用面をマネージドITプロバイダーに任せ、より上位のライセンス階層が本当に必要かどうかといった、プロバイダー単独では判断すべきでない部分を社内の担当者が判断する、という形でうまく運用できます。

未使用のライセンスはどうやって見つければよいですか

Microsoft 365管理センターの使用状況レポートを実行し、各アプリケーションでライセンスを持つユーザーが実際にアクティブかどうかを確認し、テナントを最初に構築した時点の一覧ではなく、現在の人員名簿と突き合わせてください。長期間ライセンスが割り当てられたまま非アクティブになっているものは、削除する前にその人の上司に直接確認する価値があります。休暇中や役割変更、日常的にそのツールを必要としない人など、正当な非アクティブ理由もあるためです。

退職者のメールボックスとファイルはどうなりますか

標準的な対応は、退職する従業員のメールボックスを削除するのではなく共有メールボックスに変換することです。これにより、上司や後任者はメールとファイルにアクセスできる状態を保ちながら、その人がサインインできないようにできます。この変換が完了すれば、そのアカウントに付いていた有償ライセンスを削除でき、これが実際にコストを止める部分です。中身をどう扱うか決める前にアカウントをいきなり削除してしまうのは、たいてい誤った最初の一歩です。

Intuneは必要ですか

会社がデバイスを支給している場合や、個人所有のデバイスに企業データへのアクセスを許可している場合は、何らかのモバイルデバイス管理プラットフォームが必要です。Microsoft 365を中心とする会社にとって、Microsoft Intuneは同じエコシステムの一部であるため自然な選択肢になります。必要かどうかは会社の規模よりも、現時点でデバイスに何らかの登録や基準がまったく存在するかどうかに左右されます。デバイス管理が現在ゼロの会社は、プラットフォームの選択よりも埋めるべきギャップの方が大きいということです。

Microsoft自体のバックアップだけで十分ですか

Microsoftに組み込まれた保持機能とごみ箱機能は、短期的な誤削除への対応を目的として設計されており、独自の目標復旧時点と復旧演習のスケジュールを持つ、テスト済みで継続的に監視されたバックアップではありません。バックアップの失敗にサイレントに気づく現場のIT担当者がいない完全リモート企業にとって、Brocentのクラウド管理バックアップのような独立したマネージドバックアップサービスは、本格的なセキュリティプログラムを一切必要とせずにこのギャップを埋めることができます。

どのライセンス階層を選べばよいですか

これはその役割が実際に何をしているかによって決まるものであり、前任者がたまたま使っていた階層によって決まるものではありません。Microsoft自身が公表している階層と現在の価格は、意思決定の時点で必ず直接確認してください。変更されることがあるためです。上記の毎月の利用状況レポートは、更新のタイミングでこの問いに答えるための正しい出発点です。各階層が当初何のために購入されたかではなく、今日実際に何のために使われているかを示してくれるからです。

料金体系はどうなっていますか

Brocentのユーザー単位のマネージドITプランは、従業員一人当たり月額で課金されます。これは、ライセンス・アクセス権・デバイスがすべて拠点やサーバー台数ではなく個人に紐づくという、この問題の性質そのものに自然に合った課金方法です。現在の各階層の価格と内容は料金ページでご確認いただけます。

自分たちが構築していないテナントでも管理を引き継げますか

はい、これは例外ではなくよくある出発点です。明確な所有者がいないまま二、三年自然に成長してきたテナントは、まさにマネージドITプロバイダーが引き継ぐのに適した状況です。最初のステップは、上記で説明した利用状況とサインインのレビューを、毎月の習慣としてではなく一度限りのベースライン評価として実行することで、多くの場合その最初の一回で、宙に浮いたライセンスや静かになったアカウントの大部分が見つかります。

ライセンス衛生管理から、予測可能なユーザー単位の請求へ

本稿で述べてきたことはどれもセキュリティプログラムではなく、そのように売り込まれるべきものでもありません。これは、たまたまオフィスが建物ではなくMicrosoft 365テナントである会社にとっての、ごく普通の運用上の衛生管理です。ライセンスがそれを持つ人に合っていること、退職者のアクセス権が数週間ではなく数時間で終わること、本当に譲れないごく少数のセキュリティ基準、想定ではなく把握されているデバイス、そして更新日が驚きに変わる前に劣化を食い止める毎月の習慣。これらはどれも特定の移行イベントに固有のものではありません。もし直面しているのが実際に移行——プロバイダーの切り替えや、Microsoft 365への初めての移行——であれば、それは異なる手順を持つ別のプロジェクトであり、本稿の対象ではありません。詳しくはMicrosoft 365移行チェックリストをご覧ください。買収後にテナントを統合する場合も同様に、別のプロジェクトとして扱うべきですので、直接ご相談ください。

これが、四つの別々に購入したツールの寄せ集めではなく、一つの月額プランに自然に収まる理由は、この問題自体の形が一人ひとりに紐づいているからであり、BrocentのマネージドITプランも同じ方法で価格設定されています——ユーザー単位、月単位。だからこそ120名の分散型チームは、それぞれ一部分だけを解決する別々にライセンスされたツールの積み重ねではなく、120名分の料金を支払うことになります。何かを決める前に、現在のテナントについて第三者の意見を聞きたい場合は、私たちのチームにご相談ください。私たちなら最初にどこを見るか、そして今の状況にとって本格的なマネージドプランが実際に適した規模かどうかをお伝えします。