Microsoft 365 グループ の問題点

Entra

Microsoft 365 グループ ができてからかなりの年月が経ちましたが、複雑であるがゆえに混乱している方が多いのでいったんまとめてみたいと思います。(初学者向けに何個か書く予定です)

ひとつの考え方でありこうしなくてはいけないというものではありませんが、ある程度の会社の規模になるとかなりの割合で本対応を行っていますのし記載をしたいと思っています。

※Teams と同じタイミングではなく、Planner のリリースのタイミングでMicrosoft 365 グループができた認識なので2016年6月6日にGAされたのかなと思っていますがあってましたっけ?

Microsoft 365 グループのアーキテクト

Microsoft 365 グループのややこしいのは、作る場所によって動きが異なったり、設定できる項目が異なるという部分です。

リリースされてからもいろいろな機能が増えて既定値も変わったりしているので、検証した時期や関連する環境設定によって認識が異なっているケースもあるので、下記の公式文書で認識合わせをします。※英語ですが図だけでニュアンスはわかると思います。
https://download.microsoft.com/download/6/3/0/6309218f-a169-4f2d-af4c-2fe49e30ba17/msft-m365-groups.pdf

直接ファイルのダウンロードではなくサイトを見たい方は下記のサイトからIT アーキテクト向け Microsoft 365 のグループをご覧ください。
https://learn.microsoft.com/ja-jp/microsoft-365/solutions/productivity-illustrations?view=o365-worldwide

ここで注目してほしいのは2ページ目のMicrosoft 365 グループはいろんな場所から作成ができるというのと、この切り口ですらプロビジョニングパターンがTeams/Yammer/その他という3パターンがあるということです。(項目次第でさらに細かくパターン化が分かれる)

この表に書かれていない細かなパラメーターもあったりで、問い合わせ削減や標準化という観点だとPowerShellなどで個別対応の必要が出てくるために、管理者側としては運用コストが高くなるのですべてのパターンの対応を嫌がるという傾向があります。

一方でユーザー側も細かな内容を知りたいわけではなく「使いたいだけ」なので、出来上がったMicrosoft 365 グループが希望の形で作られないと不満です。

そのため、お互いの希望が合致するところですり合わせると「そのまま使う」ではないことが多いようです。

※Microsoft 365 グループがどう作られたかでパラメーターが違うのですが、どこでどう作って検証していますなんて条件がネット記事などに書かれるケースはほとんどありません。実際に記事のままやってみたものの SPO の言語が違うなどで画面が異なるのでパニックになったなんてこともあるので、作られたところによって違うという点は押さえたほうがよいポイントになります。

実際の運用パターン

それぞれマニュアル作ったり注意事項を作ってもいいのですが、新サービスであったり、画面が変わるたびに対応する工数がかかるということで、まずは Microsoft 365 Groups の作成できる人を絞ってしまうというのをよくやります。
※Outlook から作成禁止!Planner から作成禁止!のようなサービスレベルでの禁止は実装されていない。Outlook on the web からの作成禁止や Yammer で Microsoft 365 Groups を自動で作る機能を止めるなどの一部は可能だが全体的に止めることがほとんどである。

どういう止め方があるかというと大きく2つとなります。

① Microsoft 365 グループ のユーザー画面からの作成を全部止める
② グループメンバーだけ Microsoft 365 グループ を作れるようにする。(管理者とグループメンバーにAADP1ライセンス必須)
※管理者画面では作成ができるので、あくまでもユーザー画面での制御という位置付けです。

実例としては下記などをよく聞きます。
②のパターン:特定の役職以上であったり、いわゆるとりまとめ役だけをグループに入れて運用する。
②のパターン:社内資格取得者や特定書面にサインした人だけをグループに入れて運用する。

①も②もPowerShellで対応をするのですが、下記のサイトの通りにやればできるかと思います。https://jpmessaging.github.io/blog/Office%20365%20%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AE%E5%88%B6%E5%BE%A1%E6%96%B9%E6%B3%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/
※権限のある管理者の場合はMicrosoft 365 管理センターのサポート>ヘルプとサポートから問い合わせる(SRをあげる)という方法で質問に答えていただくという支援してもらうことも可能です。

まとめ

Microsoft 365 グループは便利であるがゆえに各サービスで使う場合に適したプロビジョニングをするのですが、この Microsoft 365 グループを別のサービスや別の観点で利用する可能性がある以上は標準化をしたほうがよいと考える企業やSIerが多いようです。

そのため、まずは自分たちが組織で使いやすいように作成するという「入り口に当たる部分」を制御するという対応をとる傾向にあります。

制御した後の話

「入り口を制御」する場合にパターンが①と②があったわけですが、いずれにせよある程度の作成する工数は管理者側に発生するので困るというのがよくある課題となります。

一番簡単なのは申請書を作るケースですが、DXという言葉もありますし、ある程度自動化して工数を削減していこうという発想で対応することが現場では求められると思います。

Power Platformで内製化したり、既存のサービスに組み込んだり(Service Nowなど)、Formsで申請だけ簡素化するなど担当者のレベル感や対応工数によっていろいろなパターンがありますが、この部分で3rdParty製品を使っている会社も結構あります。(自社製品にもありますが、個人ブログなのでこのレベルでとどめておきます。)

タイトルとURLをコピーしました