ファイルサーバの共有フォルダを再設計するときには、せっかくだから整理された状態になるよう、ルールを定めて共有フォルダが混沌としないようにしたいと考えるシステム管理者の方は多いはずです。
昔、一人ブレスト（孤独だったんです…。）したときに記述した内容は我ながら後から役立つ内容になっておりますので、ここにその遺産を遺しておきたいと思います。
ファイルサーバ共有フォルダ設計
データの分類は
1) 共同で参照し作業するデータ
2) ためておく（蓄積）/保管データ
3) 受け渡し（PC⇔PC）データ（USBメモリの代わりです。）
4) 読み取り専用（写真・動画）データ
5) 個々人のバックアップデータ
6) 皆に見せる公開（回覧や書類フォーマットのような）データ
の6種類くらいあるでしょうか。。。
このデータに対して、使う人、の分類をすると
1) 機密（2・3人の関係者のみ）の共有
2) 部署や作業チーム（たとえばシステム部開発チーム、のような）内での共有
3) チームを横断するワーキンググループ（業務システム開発プロジェクトのような）
4) スタッフ・間接社員全体
5) スタッフ・間接部門外（研修生や社の業務に関わらない役割の社員）全体
6) 会社全体
と、こんなところでしょうか？
このデータと使う人の組み合わせをうまく作って共有フォルダ化していくのが定石です。
共有フォルダを作る場所（ストレージ）には安物の場所と高価な場所の2通りあります。
今回でいえば、
安物・・・外付けHDDなどの単一メディア（ディスク）のストレージ
高価・・・RAID構成で用意し、バックアップ等で保護しているストレージ
です。ここで考える分けはデータをどちらの場所に置くように共有フォルダを作るかです。
■安物でいいデータ
4) 読み取り専用（写真・動画）データ（ただしバックアップは欲しい）
5) 個々人のバックアップデータ
2) ためておく（蓄積）/保管データ ※ただし多少手間をかけたほうがよい
■高価なほうがいいデータ（パフォーマンスを要するという点で）
1) 共同で参照し作業するデータ
6) 皆に見せる公開（回覧のような）データ
■どちらでもよい
3) 受け渡し（PC⇔PC）データ ※ただし自動削除ルールを設けたほうがよい
いくつか考えたほうがよいルールがあります。
1) 共同で参照し作業するデータ
プロジェクトや同じ作業を進める作業者同士で共有が可能なよう、仕事の単位をフォルダの単位にする。（業務名称＝フォルダ名）
人間別のフォルダ（個人名フォルダ）を作らないようにする。（禁止事項、削除ルール化が望ましい）
2) ためておく（蓄積）/保管データ
保管する期限ごと（≒書類保管期限のように）に共有フォルダとして蓄積する期間を定めておく。
期限を迎えたデータはDVDやCD-Rなどに焼いてキャビネットで保管する（※ここ重要※）
期（年）毎で共有フォルダから別のストレージに（機械的に）移してしまい、オンライン（イントラ上の）共有フォルダには残さない、というルールにするのです。
3) 受け渡し（PC⇔PC）データ
誰でもアクセスできるフォルダにして、PCからPCへデータを渡す場合にはここを使うよう指導。
自動削除ルールを決めておき毎週削除（掃除）してかならず一時的な領域として公開する。
USBメモリを使ってデータの受け渡しする、という行為をこのフォルダに置き換えるように指導する。
4) 読み取り専用（写真・動画）データ
共同編集するデータとは別の共有場所/別記憶装置で保管するようにしたほうがよい。
たとえば共有フォルダに置く期間を必要なだけ定め期間終了後DVD化、
あるいは最初から写真や動画といったデータは置かないようにルール化してしまう。
（ファイルスクリーニング、samba拡張子制御などで制限）
5) 個々人のバックアップデータ
この共有では(1)と逆にフォルダを個人名とし、個人をあらわさない名前を付けないようにする。
個人が会社の関係者であれば存在を認めるが、関係者から外れた時には削除（やアーカイブ）するようにする。
また業務引き継ぎの際に、引き継ぎ関係者間でこの個人フォルダを空にする＝引き継ぎと利用すると目安になる。
6) 皆に見せる公開（回覧のような）データ
極力みんな閲覧だけができる。公開する内容（データ）によって編集者（読み書き変更権限ユーザ、sambaのadmin users）を定めて、公開するデータはかならず編集者が削除までデータに責任を持つようにする。
各フォルダにこんなルールがあればさしあたって、なんだかよく分からないデータがたくさんある…ということはない（はず）
このあたりまでを踏まえるとフォルダの分類は以下のようになる。
WorkGroup…共同作業（業務単位チーム横断）
Team…共同作業（チーム別）
Delivery…受け渡し
Publish…公開
Private…個人フォルダ
このフォルダ分類を命名規則に当てはめそれぞれ以下のような名前の共有フォルダができる予定。
WG-%業務名%＝業務名が名づけられたフォルダの先頭にWGを付け並べる。
G-%部署名%＝部署名が名づけられたフォルダの先頭にGを付け並べる
TM-%チーム名%＝チーム名が名づけられたフォルダの先頭にTMを付け並べる
Delivery＝原則は空っぽの状態のフォルダ
Publish＝公開しているデータの名前が名づけられたフォルダがこの下にならぶ
※Pub%公開名%としてWGやTMのように運用してもよい。
Private＝人名が名づけられたフォルダがこの下にならぶ
※samba機能でHomeディレクトリ共有機能を使い、"\\%HOSTNAME%\%USERNAME%"でログインユーザのみの共有提供でもよい。
業務別とチーム別（部署別）を分割している理由は共有フォルダ内のデータが
「古くて共有される必要がない＝DVDなどに焼いて保管でも問題ない。」
状態かどうかを判断しやすくするためです。
業務が会社内に既にない→古い＝DVD化
チーム（部署）が会社内に既にない→古い＝DVD化
上記にはありませんが、「顧客名別」に共有フォルダが作成される、というのもいいかもしれません。
共有フォルダは1つのフォルダ配下に大量のデータが集中しないようにする必要があります。
管理上解決できない利用上の問題が発生するためです。
問題1：特定のフォルダを開くのに時間が掛かるようになる→ほかの処理にも影響する、ためです
問題2：いざデータの管轄する対象（人、部署、チーム、など）が変わった場合に仕分けができなくなるためです。
問題3：業務の引き継ぎ上、以下のようなことがあります。
例）わかりやすい例はアクセスできる人ができない人へ引き継ぐ場合におきます。
業務を引き継ぐアクセスできない人が、引き継ぎ上必要になり（あまり見られたくない）関係ないデータまでもまとめて見れるようになってしまう。
同じような管理上の理由で、フォルダの階層を深くしないという必要性もあります。
あるPCからアクセスできなくなる、ファイルをコピーできなくなる、といった弊害がでます。
目安は「\\%HOSTNAME%\%共有フォルダ%\～\～…」の文字列が256文字を超えないようにする、というものです。
これはバックアップにも影響します。（バックアップが取れない＝エラーになる、ということが起きます。）
一番大事なこと<PRICELESS>
1) 使う人がみんなで、整理されている状態っていいよね、と思って共有フォルダを使う
2) 整理されている必然性がある。（あるいは番人が居る）
3) 整理された状態が強制される。
結局共有フォルダルールが破たんするのは、共有フォルダが整理されていることに誰も価値を感じないから、ということが多いです。
