SharePoint Online の集中管理で大失敗!権限はユーザーに委譲せよ!

IT Wizard

以前、SharePoint で 3 大やってはいけないことについて書きました。

その最もひどかった実例として、1万人規模の会社で権限を中央管理した結果、地獄絵図のようになってしまったお話を紹介します。

1. 権限の集中管理で始まった

その会社では、情報共有ツールとして使っていた Notes を廃止し SharePoint Online に乗り換えを行っていました。
しかし不幸なことに、3大やってはいけない事の 1 つとして挙げた、SharePoint の IT 部門による集中管理を選択し、導入に踏み切ってしまっていました。

ユーザーができる操作は、既存のリストとライブラリへのアイテム投稿・編集だけで、その他すべての設定変更は IT 部門への申請にて実施されます。
ちなみにその申請のフローは以下の通りで、ものすごい人手をかけないといけません。

この会社の SharePoint 利用者は 1 万 6 千人である一方、SharePoint の設定、操作を行うシステム側担当者は 2 人でした。セルフサービス型アプリである SharePoint を一般の業務アプリのように扱っているとしか思えず、導入計画に携わった者がこの手のアプリを少し舐めていたことは間違いないでしょう。
現に集中管理を選択したことに加え、その他の点でも運用設計におかしなところがありました。

2. 権限に関する運用設計がおかしかった

SharePoint の権限設定は、以下のような不思議な運用ルールがありました。

・既存の権限設定をユーザーに確認させない
・権限の付与は、セキュリティグループに対してのみ行う (ユーザー個別、SharePoint グループに権限付与は不可)
・ユーザーがセキュリティグループを作成し、権限付与をするには前述のワークフローが必須

世の中に知られる権限設計の手法なんて4種類くらいしかありません。しかし、この会社では独自の権限設定理論を作り出し、独自の運用を開始していました。
このルールでは、たとえば自分の部門+派遣のAさんにアクセスさせたい場合、わざわざ新しくセキュリティグループを作って自部門ユーザーと派遣 A さんをメンバーに含め、それを付与 (しかも都度上記のワークフローを実施) しなくてはなりません。

それどころか、ユーザーは設定された権限を確認する術がシステム部門に依頼する (上記のワークフロー) 以外にありません。
次に説明しますが、コンテンツの構成上大量に権限設定が必要なつくりであったため、非常に煩雑なものになります。
この時点で、SharePoint の権限運用は複雑なものに仕上がっていました。

3. コンテンツ設計もおかしかった

まるで上記の爆弾を抱えた権限運用の弱点をあぶりだすように、この会社ではコンテンツ配置の設計もうまくされていませんでした。
通常 SharePoint では、なるべく利用者のグループとサイトの単位を揃えるように展開します。利用者の単位が異なる場合、サブサイトを作成してコンテンツをまとめることもあります。
しかし、この会社では部門用に展開されたサイトの配下に、部門以外のメンバーがアクセスするコンテンツを一緒くたに配置し、リストやフォルダの単位でアクセス権の警鐘を破壊し再定義して使用していました。
ライブラリに至っては 1 つしか作成されず、サブフォルダを作って権限を再定義して使用する始末です。

複雑に権限定義されるにもかかわらず、前述の通りユーザーは自分で申請した権限は自分で覚えていなければなりません。
しかしながら、そんな情報は担当が変わった際に引き継がれることはないため、権限情報は次第にブラックボックス化していきます。

4. ユーザーへの対応が爆発的に増えた

ユーザーは自分の業務に合わせて機能を求めます。しかし、ユーザーの権限をきわめて絞っているため、ユーザーは自分で確認することができません。そのため、「こんなことはできるのか?」「こんな機能を搭載してほしい」「ネットで調べたらこう書いてたので使えるはずだ」など、要望と質問は非常に増えていきました。提供できている機能も絞っていたため、明らかにユーザーの求めるレベルからかけ離れていました。
また、権限の確認もできないので、部署異動を機に「突然ファイルが見れなくなった」「見るためにはどうしたらいいか?」「申請が複雑だから申請方法を教えてほしい」などの問い合わせも常時発生します。
 1万人規模の会社で新しいサービスレベルを開放することは容易ではありません。SharePoint の対応を行っていた外注作業員やヘルプデスクは、「〇〇部の〇〇さんがこんな要求をしていますがどう答えましょうか?」というような指示を仰ぐ内容が増えていきます。そうなると、対応作業員を増やしても判断する者の手が追い付かず、増員の効果がなくなります。こうなると、「すまん、適当に対応してくれ」と指示 (?) せざるを得なくなってきますが、そのせいで食いついてくるユーザーへの対応も増えてゆき、支援工数はさらに増大します。

5. 上司も提案を聞いてくれなかった

このようなカオスな設計の運用に管理者として私が放り込まれ、間もなく私は上司に権限設定の改善を提案しました。

しかしながら、この上司は「セキュリティ上の懸念」という、ありがちな魔法の言葉を理由に OK しませんでした。
なお、ここでの「セキュリティ上の懸念」とは、ユーザーがよくわからないまま権限操作をすることで、意図しない人に見えてしまい情報漏洩するのではないかという事でした。しかしながらむしろシステム側のほうが依頼された内容をそのまま設定するので、私はユーザーに権限設定をすることがこのリスクを増大させるものになるものではないと主張しています (現に間違った依頼をそのまま設定していることが後になって発覚しました)。

ただ、この上司からOKは出なかったものの、「セキュリティ上の懸念」を払拭すれば聞き入れてもらえる芽が出たとも言えます。

6. 人が倒れ、地獄が始まった

私はあきらめずに、上司向けの再度の提案を考えました。しかし、ここで事件が起きます。SharePoint 運用担当者である社員の一人が、SharePoin 作業依頼に忙殺され、過労で倒れてしまいました。SharePoint の運用は外注メンバーを入れて4人 (工数的には2~3人) でしたので、残りのメンバーは今にも増して作業に忙殺されます。メンバーの残業も月に60時間にも及び、会社の労働基準にひっかかる状況なので、上司への再提案にはどうしても手が回りませんでした。
こうしているうちにも SharePoint の利用者が増え、そのサポートも爆発的に増えます。毎日、ヘルプデスクからのエスカレーションがたまってきて、ユーザーへの回答を催促される日々でした。
倒れた会社員の復帰には半年を要しましたが、フルタイムで復帰する頃には別の外注の運用作業員が過労で倒れていなくなりました。このような状況では、はできる人から順に倒れてゆきます。補充で新しい人を入れたところで素人から開始なので、相当な教育コストがかかります。補充した外注作業員も半年でまた入れ替わりました。私のほうも SharePoint の運用以外に3案件を兼務することになり、SharePoint の運用作業員への指示が滞る状況です。SharePoint への移行が後半になったころには利用者も増加し、収集が付かないほどの残業地獄になっていました。 この地獄は2年間続きました。

7. Teams の登場を利用し、地獄を回避した

そんな中 Microsoft 365 に Teams という機能がリリースされました。Teams はユーザーがセルフで作成して管理することができる、いわゆるSharePoint のワークスペース機能に当たります。
Teams が出たころ、Teams の機能は停止するべきかという話が作業員から出ましたが、私はあえて誰にも報告せずに放置することにしました。つまり、ユーザーに自由に使わせようということです。
これが地獄の出口となりました。
利用者は、ほとんど使えない SharePoint を捨てて Teams に移り始めたのです。上司やオーナー部門が Teams を知ったのは社内でずいぶん広まってからです。Teams の利用を規制するには遅すぎる状況になりました。

結果、SharePoint の利用者が減ったことで時間ができ、これまでの課題の対応に当たることができるようになりました。

振り返り
この地獄絵図は、SharePoint の世界ではよく知られた権限の集中管理から始まったと言えます。
もちろん、上に挙げた以外にも上司に相談していますが、だいたいの対策は以下のようなものでした。

ユーザー対応工数増加の問題に対して
・「ユーザーの問い合わせが多いのであれば FAQ で対応すればよい」
・「人を増やせばいい」

ユーザーが権限を確認できない問題について
・「こちらが変更をすべて記録しておいて、その記録から回答すればよい」

ユーザーが欲しがる機能について
・「ユーザーに必要な機能があれば、申請を受けてシステム側で作ればよい」

これらの対応は浅はかと言わざるを得ません。
FAQ はすでに作ったうえでの状況であり、増員が効果的でない状況は上に示したとおりであり、機能の開発もあの申請ワークフローです。また、上に示したとおりユーザーは何ができるかわからないので、相談から入るわけです。それが1万6千人。

はっきり言えば、もともとセルフサービス型のアプリを1万人規模で集中管理するのは戦略として間違っています。
そして、戦略の間違いを戦術で取り返すことはできません。

「SharePoint の権限はユーザーに移譲するべし」
それを確認できる不幸な例であったことは間違いありません。

コメント

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