「使い方が悪い」と叱る前に、なぜ誰でもシステムを壊せるのか考えてみないか。

SharePointの容量不足から考える、リテラシー・権限・上限・例外処理の設計

月曜日の朝、共有ファイルが保存できなくなる。管理者が調べると、あるチームのサイトで大量の容量を使っていた。動画を挿入したPowerPoint、更新を繰り返した資料、使い終わったはずのファイル。そんなものが積み重なっている。

ここで誰かが言う。「使い方を分かっていない社員がいるからだ」「リテラシー教育が必要だ」。

たしかに、ファイルの扱い方を知らないことが原因の一つになる場合はある。しかし、僕はそこで話を終わらせたくない。

そもそも一人や一つのチームが、他の仕事まで止めかねない量を使い続けられる設計になっているのはなぜだろう。

以下は特定の会社の出来事を記録したものではない。多くの組織で起こり得る容量不足を題材に、管理の仕組みを考えるための仮想事例だ。

善意の仕事が、誰かの仕事を止めることがある

共有サイトに大きな資料を保存した人にも、理由があるだろう。営業資料に製品動画を入れたかったのかもしれない。

共同編集のためにオンラインに置く必要があったのかもしれない。過去版を残したのも、後から差し戻しが発生する仕事なら合理的だ。

一つひとつの判断には業務上の理由があっても、それらが同じ容量の財布から支払われていることを利用者が意識しているとは限らない。

SharePoint Onlineでは、サイトのストレージが組織全体の共通プールから提供される自動管理が標準的な仕組みだ。サイトごとの細かな上限を設ける手動管理も用意されている。

つまり、あるサイトが大きく容量を使えることには、製品側の運用上の理由がある。共同作業をいちいち容量申請で止めないためには、柔軟な配分は便利だからだ。

だが、便利さには裏面がある。ある利用者から見れば「自分の資料を保存した」だけでも、管理者から見れば共有資源の消費であり、別のチームから見れば残り容量の減少になる。

これは単純な善悪の話ではない。個々の行動が合理的でも、全体では困った結果になる設計なのだ。

「リテラシーが低い」という言葉は、誰にでも理解しやすい。しかし、それだけでは誰が容量を見守るのか、いつ異常を検知するのか、どこまで利用してよいのか、上限が近づいたら何をするのかが決まらない。

理解のない人を叱る前に、理解がなくても被害が広がり過ぎない構造を考えるべきではないか。

SharePointには上限がある。ただし、望む粒度で何でも制限できるわけではない

ここは事実関係を丁寧に分けたい。

Microsoftの公式資料によれば、SharePoint管理者は容量管理を「自動」から「手動」に切り替え、個別のサイトに最大ストレージ容量を割り当てられる。制限に近づいたサイトの所有者へ通知する設定もある。

一方、これはあくまでサイト単位の上限だ。同じ管理画面から「Aさんは全部のチームサイトを通算して10GBまで」「営業部の全サイトをまとめて100GBまで」といった上限を、同じ感覚で簡単に設定できるわけではない。

部門別・利用者別の総量を制御したいなら、サイトの区分、所有者、監視、権限、追加の運用や実装を組み合わせる必要がある。

さらに厄介なのが、容量の内訳である。SharePointにはバージョン履歴があり、設定や利用状況によって過去版がストレージを消費する。

Microsoftは組織・サイト・ライブラリ単位のバージョン制限や使用状況レポートを提供しているが、古い版を減らすことには復元能力とのトレードオフがある。

保持ポリシーの対象なら、見た目のファイルを削除しただけで期待どおり容量が減るとも限らない。

つまり「動画の大きなPowerPointを使うな」「古いものを全部消せ」「全員に同じ上限を付けろ」のいずれも、単独では解決策として不十分なのである。

守りたいのはGBではなく、仕事を続けられる状態だ

容量制限の目的を「たくさん使った人を罰すること」にしてしまうと、設計を間違える。

まず守るべきなのは、業務に必要な保存・共同編集・復元が止まらないことだ。次に、容量の増加を早めに把握できること。

さらに、利用量が多いチームには事情を確認し、正当な理由があれば増枠できること。使い終わったデータは、消してよいかを確かめた上で整理できること。

ここまで考えて初めて、教育・権限・容量制限の役割が分かれてくる。

教育は、利用者が適切な置き場所や形式を選ぶ助けになる。権限は、誰がどの操作をできるかを決める。

容量制限は、一つの場所の使い過ぎが無制限に広がることを防ぐ。警告と例外処理は、必要な仕事が突然止まらないようにする。そして、定期的な見直しがなければ、どの仕組みも次第に現実とずれていく。

僕がほしいのは、規則を増やしただけの組織ではない。問題が起きる前に気づけて、必要なら正規の経路で変更できる組織だ。

以前、「33万人の個人情報をAIに投入した社員。本当に問うべきは、その社員のリテラシーなのか？」という記事を書いた。あちらでは、リスクに名前を付けることと、実際に事故の条件を変えることの違いを考えた。

今回はその先へ進みたい。抽象的な「組織の責任」で終わらず、明日から何を調べ、どの制限を試し、誰が例外を判断し、30日後に何をもって成功とするか。そこまで設計してみる。

以下は、そのための実務ノートである。