ドキュメント置き場、今までのファイルサーバーの代わりとして期待されている企業は多いですし、その通りだと思います。SharePoint上の検索機能はもちろん、Delveでふいに見つけるドキュメントも増えるでしょう。既存のファイルサーバーをそのままコピーするだけではSharePoint上ではうまくファイルサーバーの置き換えにとしては利用できないでしょう。いった失敗をいくつか見聞きしたので、こちらにまとめます。利用する際のアンチパターンひとつのドキュメントライブラリに全部ぶち込んじゃう→ドキュメントライブラリは複数作れるので、それぞれ意味のあるドキュメントライブラリを作成したほうがよいです。「ファイル置き場」みたいな大きな役割じゃなくて、「申請書類フォーマット」ぐらいの粒度にしましょう。自分が見るかもしれないドキュメントライブラリを「全部」エクスプローラ同期しちゃう→たまにしかアクセスしないライブラリは同期せずに、ブラウザのお気に入りにしておきましょう。1項目目でもあるようにドキュメントライブラリの管理粒度を小分けにできていれば同期する必要がないライブラリが出てくるはずですね。→常に同期チェックされることで、逆に同期エラーが起きやすくなります。同期するドキュメントライブラリは3つぐらいまでではないでしょうか。ドキュメントライブラリに深い階層を作っちゃう→基本的にWebのUIでフォルダを下がるのにページの読み込みが発生して非常にストレスになります。可能な限りフォルダは作らないようにしましょう。ドキュメントライブラリのフォルダ単位に個別のアクセス権限付与しちゃう→プロジェクトが変わって、担当者のアクセス権限を削除する必要があるときに、とっても大変です。ファイルアイテム単位に個別のアクセス権限付与しちゃう→上記と同じ理由です、特殊な理由がない限りすべきではありませんし、アイテム単位のアクセス権限付与の必要があるときは、人力やPowerShellなどで管理するのではなく、別途有償のソリューションで管理すべきでしょう。ユーザーを削除するとコンテンツはどうなる?サイトのトップページに全部のドキュメントライブラリのWebパーツを貼り付けちゃう→ページの表示がすっごく遅くなるよ。ファイル名を変更して参照をできなくしちゃうドキュメントライブラリに限ったことではなく、ファイル管理の基礎ですが、ファイル名に日付を付けたり、更新者の名前を付けたり、バージョン番号を付けたり。20190707_見積もり.docx見積もり_mokudai.docx見積もりv2.docx最終_見積もり.docxこうした行為は他人の業務効率の足を引っ張る悪人なので見つけ次第指導してください。ファイル命名規則(笑)は、クラウドストレージは関係なくオンプレのファイルサーバーでも現状では不要です。ファイルサーバーの機能としてバージョン管理があるので、システムが準備する機能を使ってください。