プロジェクトファイル管理:チーム向けベストプラクティス

優れたプロジェクトファイル管理は5つの習慣の上に成り立つ。3階層以内の浅く予測可能なフォルダ構造、オンボーディング時から徹底する書面化した命名規則、ファイル種別ごとの唯一の正本（Figmaファイル一つ・マスター.docx一つ・正規の.xlsx一つ）、少なくとも180日間のバージョン保存、そしてプロジェクト完了時の計画的なアーカイブだ。ほとんどのプロジェクトの混乱はツールの問題ではなく意思決定の問題だ。ファイルをどこに置くかを事前に30分話し合わない組織は、3つのツールに7つの重複した「Budget_Final.xlsx」を抱える羽目になる。

3階層ルール

3階層を超えたフォルダは見つからなくなる。テストしてみよう。チームメンバーは2026年Q2のデザインレビューデッキを30秒以内に見つけられるか。パスが/Clients/Acme/2026/Q2/Design/Reviews/June/Deck_v3.pptxなら答えはノーだ。

機能する構造の例を示す。

/Projects
  /2026-Q2-Acme-Rebrand
    /01-brief
    /02-working
    /03-final
    /04-archive

数字のプレフィックスが並び順を強制し、プロジェクトフォルダ名に四半期とクライアント名が入るので検索で即座にヒットし、4つのサブフォルダが実際のワークフローの状態に対応している。この構造を導入したチームは最初の1か月で「ファイルはどこ？」というSlackメッセージを60〜80%削減する。

現実に耐える命名規則

命名規則が機能するのは、全メンバーが考えずに適用できる場合だけだ。ほとんどの業界で有効な形式を示す。

YYYY-MM-DD_ProjectCode_DocType_Descriptor_vNN.ext

例：2026-06-12_ACME-RB_brief_scope-of-work_v03.pdf

持続可能にする5つのルールがある。ISO 8601形式の日付（YYYY-MM-DD）はどのロケールでも正しくソートされる。プロジェクトコードはフルネームより短い。スペースは使わず、ハイフンかアンダースコアを使うが一つのフィールド内で両方を混用しない。2桁のバージョン番号（v03）はv09を超えても正しくソートされる。可能な限り小文字を使い、ファイルシステムの大文字小文字区別の罠を避ける。

正本と作業中コピーの管理

プロジェクト上のすべてのファイルは正本か作業中コピーかのいずれかに分類される。正本は納品物・請求対象・ステークホルダーがレビューするもの。作業中コピーは下書き・ブランチ・実験だ。

どのコピーが正本かを見失うことが最大のプロジェクト管理の失敗だ。対策は3点ある。正本ファイルをロックすること（DAMやDropboxはロック機能を持ち、SharePointのチェックイン/チェックアウトは堅牢だが過少活用されている）。作業中コピーにはオーナーのプレフィックスを付ける（jbloggs_WIP_2026-06-12_ACME-RB_hero.psd）。スプリント終了時に最終資産を03-finalに移し、作業中バージョンを削除すること。アーカイブはしない。アーカイブは「出発点」として掘り出され、問題が再発する。

ツールをまたいだファイルの追跡

実際のプロジェクトはJira・Linear・Notion・Slack・Google Drive・クライアントポータルにまたがる。Jiraのチケットで言及されたファイルがDriveにあり、同じファイルがSlackで共有され、NotionページにEmbedされ、Dropboxリンクとしてクライアントに届く。手動での追跡は不可能だ。

2つのアプローチが効果的だ。ファイルを添付せずリンクする（正本がDriveにあるなら、Slackにもリンクを貼る。添付はすぐ古くなる別のコピーを作るだけ）。AirtableまたはNotionのデータベースにオーナー・ステータス・最終レビュー日・保存ポリシー・外部リンクを列として持つファイルメタデータのカタログを作る（500資産を超えると維持コストが高くなるが、規制対象プロジェクトでは価値がある）。

バージョン保存とロールバック

ほとんどの同期ツールはデフォルトの保存期間が短い。Google Driveは無料プランで100バージョンまたは30日間、Dropbox Businessは180日間、Box BusinessはバージョンをBusiness Enterpriseで無制限に保持する。デフォルトを確認すること。おそらく思っているより保存期間が短い。

GDPR第5条1項（e）の保存期間制限やHIPAAの6年保存などの規制プロジェクトでは、ツールのデフォルトではなく規制に合致した保存ポリシーが必要だ。AWS S3 Glacier Deep Archiveへの自動エクスポートを設定する（0.00099ドル/GB/月）。ロールバック訓練は四半期に一度、誰かがランダムなファイルを選んで前日に破損したと仮定し、以前のバージョンを復元するまでの時間を計測する。

大容量納品物と外部送信

最終的なプロジェクト納品物はメールに収まらないことが多い。4K映像のカットは40GB超、レイヤー付きのフルPSDソースパックは2〜10GB、建築BIMファイルは常に5GBに達する。

機能するパターンは、正本ファイルをDAMや同期ツールに保管しつつ、最終的なクライアント納品は追跡機能付きの専用転送サービスを通じて行うことだ。HexaTransferのようなE2EEサービスは最大10GBをクライアントサイドのAES-256-GCM暗号化とともに転送でき、プロバイダーはコンテンツにアクセスできない。すべてのクライアント納品はデフォルトでパスワード保護すること。機密性の低いファイルであっても、受信者に正しいリンクを受け取ったことを確認させる効果がある。

アーカイブ：誰もがスキップするステップ

プロジェクトは終わる。ファイルは終わらない。プロジェクト終了から1年後に「Acmeに納品した最終ロゴは何だったか？」に答える必要があるが、/Projects/2026-Q2-Acme-Rebrand/02-working/には14GBのノイズが残っているだけだ。

プロジェクト終了時のアーカイブの規律として、03-finalを読み取り専用で/Archive/YYYY/ClientCode/にコピーする。各最終資産・その目的・承認したステークホルダーを列挙したプロジェクトマニフェスト（.mdファイル）をエクスポートする。規制で保存が求められない限り02-workingを削除する。12か月後にアーカイブの保存要否を再検討するカレンダーリマインダーを設定する。

HexaTransferは無料・アカウント不要・最大10GB。詳しくは https://hexatransfer.com をご覧ください。