Microsoft 365 (Office 365) の導入によって、SharePoint Online でポータルを作り、コミュニケーションの活性化を図りたいと思っている企業も多いのではないでしょうか。
そんな中、オンプレミスの SharePoint 2007 時代から導入をしてきた観点から、３大やってはいけない事を紹介します。
1. 権限を中央管理してはいけない
権限をユーザーに管理させるべきなのか、IT 部門がすべて管理するのか、最初に迷うところかと思います。
これまでの導入経験と運用してきた経験から言えば、大きい会社ほど中央管理をしてはいけません。
ユーザーに管理させない会社と管理を委譲する会社のそれぞれの言い分は、主に以下の通りです。
[権限委譲しない会社の主張]
・ガバナンスが効かない (ノーツから移行した会社に多い)
・ユーザーには操作が難しいだろう
・ユーザーに操作させると事故を起こすかもしれない
・システム側が利活用を促進してあげなければいけない
・勝手なアプリが将来バージョンアップを妨げる
[権限移譲する会社の主張]
・システム側だけでやるとサポート工数が莫大にかかる
・システム側だけでやるとユーザーからの不満が爆発する
・ユーザーが使えないと利活用が進まない
・システム側が規制すると SharePoint の本来の機能を生かしきれない
しかし、これは過去 10 年、SharePoint の世界ではほぼ決着のついた話です。
過去の経験では、システム側で中央管理する体制で利用者が数千人を超えるようになると 、IT部門の負荷が急増する一方で、SharePoint 自体が使われない事態に陥ります。逆にユーザー自身が自由に使える状況でもサポートコストというのは意外と跳ね上がりません。
上記の [権限委譲しない会社の主張] の中に見え隠れする「ユーザーはまともに操作できない」「システム側がユーザーに教える必要がある」という考え方はシステム側の傲りにすぎません。
現に、リアルコムが 2011 年に取ったアンケートでは、約 84% の企業が権限管理をユーザーに委譲しています。
私は利用者 １万 6000 人規模の SharePoint の管理者をしたことがありますが、ユーザーはおろかヘルプデスクにさえ権限を委譲していなかったために、4 人の管理部門のメンバーが 1 年に 1 人のペースで過労で倒れる地獄絵図になりました。
権限の集中管理は、せいぜい 100 人、200 人の数ポータル規模だけで可能だと思ってください。
2.ファイルサーバーにしてはいけない
SharePoint のライブラリ機能がエクスプローラーで表示できることを知ると、ファイルサーバーのファイルをまとめて登録したくなると思います。
ただ、これも昔から SharePoint をファイルサーバーにしてはいけないことが知られています。
オンプレミスの SharePoint の話では、ディスクコストとサーバー性能の観点でデメリットになります。
SharePoint 上にファイルを配置すると、最終的にはデータベース内にファイルが格納されます。たとえ１００MBのファイルを格納するにしても、DB内では２００MBくらいになります。ディスクコストの観点ではDB用のディスクのほうが圧倒的に高いので、非常に高コストになります。
また、データベース構造も複雑な複数のテーブルで構成されるため、1 つのファイルの読み書きにサーバーに負荷がかかり、ファイル操作の速度も共有フォルダに比べて遅くなります。
一方、SharePoint Online の場合、少し事情が変わってきます。
無制限に近い容量を考えると、ディスクコストのメリットが出てきます。ただし、その代償としては大きすぎる遅延問題に出くわします。
SharePoint Online はクラウドアプリケーションであるため、会社が複雑なネットワーク経路を持っていたり、高負荷のプロキシサーバーを中継していたりすると、ファイルを開く動作がとても遅くなります。
私が管理者をしていた会社では、1 つの Excel ファイルを開くのに 15 秒～ 20 秒かかっていました。
コンテンツ管理をせずにファイルの置き場所にするだけであれば、ファイルサーバーやファイル ストレージ サービスを併用するのが正しい使い方でしょう。
なお、ファイルサーバーと SharePoint を併用することでアクセス権を整合させる問題が出ますが、利便性の損失に比べるとはるかに些末な問題です。
3. 過度にカスタマイズをしてはいけない
SharePoint が出た当時は、ASP.NET の知識レベルに応じて、
・ブラウザレベルでできるカスタマイズ
・SharePoint デザイナーレベルでできるカスタマイズ
・Visual Studio でできるカスタマイズ
と、3 段階のカスタマイズが可能でした。
SharePoint を業務に合わせて使うためにはカスタマイズは必須ですが、カスタマイズにはバージョンアップの問題がつきまといます。
SharePoint が爆発的に普及し始めた 2007 年から数年たったころ、この問題は大きくクローズアップされました。
SharePoint はフレームワークがしっかりしていて、過去の製品からの互換性が非常に高く作られています。
SharePoint 2007 で使っていたことが ShrePoint 2016 どころか、SharePoint Online でも使用できます。
オンプレミスの SharePoint の場合、デザイナーレベルのカスタマイズまではやっても困りません。実際に私が見た中でも、バージョンアップに困ったことはありませんでした。ただ、Visual Studio で DLL を開発したものは、そのまま動作しなくなったものもあり、しっかりと長期にわたる開発会社の保守契約がないと困ってしまうことが多いです。
SharePoint Online の場合、DLL 開発はできませんが、SharePoint デザイナーの開発は可能です。しかし、SharePoint Online は毎日プチバージョンアップが行われる SaaS 型アプリです。UI 層レベルのカスタマイズ (JavaScript を使用した場合など) は高い確率で数年で使用できなくなります。
また、テナント全体で横展開してしまったカスタマイズのせいで、モダン UI など新機能展開に踏み切れず、連携の悪いコミュニケーションツールとして使用せざるを得なくなるケースもあります。利用をしてナンボのコミュニケーションツールがカスタマイズのせいで利用制限がかかるなんて本末転倒です。
以上が、SharePoint を 2007 時代から見てきた私の、３大やってはいけない事でした。
これから SharePoint を導入する企業はご注意ください。
参考
リアルコム、SharePoint利用企業におけるユーザーへの管理権限委譲の実態調査を実施
https://japan.zdnet.com/release/30000146/
SharePoint成功の道標
https://ci.nii.ac.jp/ncid/BB11479668
コメント