プロジェクトのフォルダ構成:Macユーザーのための実践ガイド

プロジェクトを送ろうとしたら、編集可能なファイルはデスクトップ、承認済みのPDFは「ダウンロード」、別の書き出しデータは「Final_New」という名前のフォルダの奥に埋もれている。何があったのか、自分ならたぶん思い出せます。でも、ほかの誰かがそのプロジェクトを開いても、わかりません。

使えるプロジェクトのフォルダ構成は、そうした判断を記憶に頼らずにすませてくれます。受け取った素材、編集中の作業ファイル、納品したファイルに、それぞれ予測しやすい置き場所を用意し、プロジェクトが終わるときも文脈を失わずに片づけられるようにします。Macでは、まず名前とフォルダから始めましょう。視覚的な目印を足すのは、土台の構成が筋の通ったものになってからです。

テンプレートをコピーして最上位の階層をつくる ​

下から、いちばん近いテンプレートを選んでください。これはあくまで出発点の構成であって、macOSが求める決まりではありません。

大事なのは、入力・編集中の作業・出力を分けることです。ダウンロードした参考画像は作業中のデザインではないし、書き出したPDFは編集可能な元ファイルの代わりにはなりません。この役割を分けておけば、あとから再生成できるものと、必ず守らなければならないものが見分けやすくなります。

Appleは、もっと根本的な区別をしています。File System Programming Guideによると、/SystemにはmacOSの動作に必要なリソースが入っていて変更してはいけません。/Usersにはユーザーのホームディレクトリが入っています。プロジェクトのルートは、システム用リソースの中ではなく、ユーザーが管理するストレージに置きましょう。

働き方に合わせてテンプレートを選ぶ ​

デザインプロジェクトでは、誰かがファイルを保存し始める前に、03_Sourceと04_Workingの違いを決めておきます。実用的なルールは、支給された素材や再利用するマスターデータをSourceに、コンポジションや進行中の修正版をWorkingに置くことです。この違いをはっきり説明できないなら、曖昧な置き場所を抱えるより、二つの役割を一つにまとめてしまいましょう。

リサーチでは、受け取ったデータは02_Data_Rawにそのまま残します。加工したデータセットは03_Data_Cleanに置き、どうやって作ったかを記録します。そうしておけば、分析をやり直すときに「元のスプレッドシートを誰かが編集したのでは?」と悩まずにすみます。

ソフトウェア開発は、連番パターンの意図的な例外です。リポジトリやフレームワーク、ビルドツールが期待するディレクトリ名をそのまま使いましょう。buildは生成物として扱い、バージョン管理の除外設定もそれに合わせます。ツールが別の場所にあると想定しているファイルを、手作業で動かしてはいけません。

クライアントワークでは、**Deliverablesは「実際に送ったもの」**を意味します。提出候補のプレゼン資料は、渡すまでWorkingに置いておきます。そうすれば、未承認のドラフトを納品記録として見せてしまう事態を避けられます。

Finderでプロジェクトをつくる ​

1. ずっと使うルートを決める。 「書類」フォルダかホームフォルダの中に「Projects」フォルダを作り、進行中のプロジェクトをそこに入れます。理由は実用的で、急いでいるときでも使う場所が必要だからです。よくある落とし穴は、デスクトップで作業を始めて「あとで整理する」と約束してしまうこと。デスクトップに置くのが間違いというわけではありませんが、一時保存と意図的なファイリングを混同しやすくなります。

2. プロジェクトにわかりやすい名前をつける。 クライアントコードや意味のある日付に、短い説明を組み合わせます。たとえばAcme_RebrandやYYYY-MM_Acme_Rebrandのように。会話や引き継ぎで実際に使う識別子を選んでください。New_Projectのような曖昧なルート名は避けます。同じクライアントの案件を複数抱えることが多いのでなければ、クライアントの階層は足さなくて大丈夫です。

3. 選んだ行のとおりにフォルダを作る。 連番のテンプレートなら、2桁の数字にアンダースコアを続けます。01は管理、ブリーフ、契約書、02は参考資料や受け取った素材、03は適切なら作業中のコンテンツ、それ以降は分析、出力、書き出し、請求書など、テンプレートに応じて割り当てます。99_Archiveは役目を終えた素材のために取っておきます。数字は順序を決めるためのもので、万能の分類体系ではありません。

4. ルートにREADMEを書く。 プロジェクトの目的、担当者、各フォルダに入れるものを書きます。新しく入った人が誤解しそうな違い、特にSourceとWorking、OutputsとDeliverablesの区別は必ず入れましょう。よくある落とし穴は、フォルダの一覧だけを書いてしまうこと。判断の中身まで説明してください。生データを編集していいか、承認の記録はどこにあるか、引き継ぎの記録はどのディレクトリにあるか、といったことです。

5. 空のコピーをテンプレートとして保存する。 再利用のために残す前に、プロジェクト固有の素材、非公開の契約書、クライアントの情報を削除します。フォルダの説明は残し、担当者と目的の欄は、わかりやすい書き込み用のプロンプトに差し替えておきましょう。使い終わったプロジェクトをきれいにせずそのままコピーすると、古いファイルや思い込みが次の仕事に持ち越されてしまいます。

考えられるサブフォルダを全部先に作る必要はありません。説明できる置き場所から始めて、実際の素材が必要としたときに細かく分ければ十分です。テンプレートは、繰り返しの判断を減らすためのもの。空のカテゴリを選り分ける手間を増やしてはいけません。

最後に、Finderでカラム表示のテストをします。名前順に並べ替え、プロジェクトのルートを開いて、最上位の階層を順番に読んでみてください。すべてのフォルダを開かなくても、受け取った素材から作業、納品までの流れを説明できるはずです。

フォルダの順序を保つ命名ルール ​

名前は、開かなくても近くにあるアイテムを区別できるものであるべきです。しかも、元のフォルダの外、つまり検索結果に表示されたときにも意味が通じる必要があります。

保存のたびにルールを考え直すのではなく、簡単なチェックリストを使いましょう。

• 接頭辞をそろえる。 パディングがばらばらだと、並んだリストの管理が難しくなります。悪い例:1_Admin、02_References、3_Working。良い例:01_Admin、02_References、03_Working。
• 区切り文字を決めておく。 意味のある単語どうしはアンダースコアで、日付やコードの中ではハイフンでつなぎます。悪い例:Acme / Brand & Web。良い例:Acme_Brand_Web。
• 日付は大きい単位から小さい単位へ書く。 時系列で並べたいときはYYYY-MM-DDを使います。悪いパターン:DD-MM-YYYY_Review。良いパターン:YYYY-MM-DD_Review。
• 区別に必要な言葉は見えるままにする。 文字数に恣意的な上限を設けるより、余計な言葉を削りましょう。悪い例:All_The_Working_Documents_For_The_Acme_Rebrand。良い例:Acme_Rebrand_Working。
• 不要な記号は避ける。 半角の英数字、アンダースコア、ハイフンだけなら、スクリプトでも扱いやすくなります。悪い例:Client's Draft (Approved?)。良い例:Acme_Proposal_v03。
• 一つの役割には一つの用語を使う。 同じ置き場所を指しているなら、Exports、Output、Renderedを使い分けないでください。悪い例:ExportsとExported_Filesという兄弟フォルダ。良い例:ドキュメント化された一つの05_Exports。
• バージョンと承認を分ける。 悪い例:logo FINAL new 2.ai。良い例:編集用マスターの置き場所と決めているなら、03_Sourceの中のAcme_Logo_v03.ai。承認は、Finalをまた付け足すのではなく、納品記録に残します。

意図をもって名前を変える ​

バージョン番号はリビジョンを識別するもので、承認の証明にはなりません。同じように、「Old」というフォルダ名だけでは、中身が置き換え済みなのか、却下されたのか、参考用に残してあるのかがわかりません。

役に立つ名前は、そのアイテムを説明します。役に立つ記録は、そのアイテムに何が起きたかを説明します。

名前は、ファイルがコピーされても、同期されても、アーカイブされても意味を保ちます。色やアイコンだけでは、その役目は担えません。

既存のコレクションなら、Macでファイル名を一括変更する方法で紹介しているような、先にプレビューを確認するやり方を使ってください。変更を適用する前に、行き先の重複やリンクされたファイルがないかを確認しましょう。

プロジェクトのフォルダには作成時に名前をつけ、範囲が変わらないかぎり、そのまま変えずに使います。名前を変えたときは、以前の名前と理由をREADMEに記録します。

フォルダ、タグ、スマートフォルダはそれぞれ役割が違う ​

フォルダは図書館の書架。タグは本に貼る付箋。スマートフォルダは保存した検索で、条件に合う本を、棚から外さずにまとめて見せてくれます。

この区別が大事なのは、答えようとしている問いがそれぞれ違うからです。これはどこに属するか? 何に注意が必要か? 何をまとめて見たいか? Appleが公開しているFinderの整理ガイドでは、入れ子のフォルダ、タグ、スマートフォルダは、互いを補い合う整理・検索の方法として説明されています。

空のフォルダを作っても、何も移動しません。表の違いを言い換えると、ファイリングはアイテムの物理的な場所を変えますが、タグ付けや保存した検索は変えない、ということです。

変わらない置き場所と、変わる見え方を分ける ​

たとえばクライアント向けのプレゼンを準備しているとします。編集可能なデッキは、プロジェクトのWorkingフォルダに置きます。フィードバック待ちのあいだは「レビュー」タグを付け、レビューが終わったら外します。

デッキを、別の「Needs_Review」ツリーに移す必要はありません。そうすると、一時的な状態に場所が左右されてしまい、共同作業者が以前の場所を探し回ることになりかねません。

スマートフォルダは、もっと広い問いに答えます。進行中の複数のプロジェクトにまたがって最近編集したPDFを集めたり、「仕事」タグの付いたファイルを表示したりできます。ファイルコレクション全体をそのまま再現するのではなく、特定の作業に役立つ結果になるまでルールを絞り込みましょう。

こうしたビューを支えるナビゲーションのコツは、Finderの使い方のヒントでさらに紹介しています。ビューは作業に合わせて選びます。場所をたどるならカラム表示、見た目でアセットを探すならビジュアルなプレビューです。

注意を引く目印は絞って使う ​

すべてに「至急」が付いていたら、もう役に立ちません。どんなものが各アクションタグに当てはまるのか、誰が外すのかを決めておかないと、昨日の優先事項が、いつまでも残る飾りになってしまいます。

注意力を保つこと自体が難しいという方には、Jan KutscheraのADDを抱える起業家のための整理のヒント(英語)が、個人の整理を考えるうえで補完的な参考になります。自分のタグの語彙は、ラベルに迷わず付けられる程度の小ささに保ちましょう。

判断のルールはこうです。 答えがプロジェクトの途中で変わるならタグ。プロジェクトが終わるまで変わらないならフォルダ。それらの場所をまたいで再利用できるビューが欲しいなら、スマートフォルダです。

どこまで深く入れ子にしていいか ​

深さは、習慣ではなく、探し出す必要に応じて決めるべきです。 フォルダを分ける価値があるのは、人が理解できるかたちで検索範囲を絞れるときです。「Project」「Files」「Assets」といった入れ物をもう一つ増やすだけなら、あまり意味がありません。

論文Evaluate, Reorganize, and Share(英語)は、正確なパスを暗記するのではなく、場所について考えられるようにする手段として、意味にもとづく整理を説明しています。新しい階層を足すかどうかも、そのテストが当てはまります。その名前によって、残りの選択肢がはっきりするでしょうか?

下の図は、ツリーが大きくなるにつれて積み重なるナビゲーションのコストを示しています。

各階層に役割を持たせる ​

以下は、測定された限界ではなく、あくまで提案するレイアウトです。プロジェクトのルートより下の階層を数え、役に立つ区別を表すときだけ、もう一段足してください。

共同作業者の名前を付けたフォルダは、それだけでは何も守ってくれません。保護が必要なら、アクセス権限を別途設定してください。

たとえば、Working、Concepts、Campaign、Digital、Social、Approved、Revised、Exportの奥に埋もれたパスを想像してみてください(仮の例です)。それを04_Working/Social/Acme_Campaign_v03.aiに平らにし、生成した納品用コピーは、指定した書き出し先に置きます。ファイル名がリビジョンを示してくれるので、判断のたびにフォルダを作る必要はありません。

クリック数ではなく、見つけられるかで確かめる ​

同僚に、参考アセット、編集可能なファイル、承認の記録、納品した出力、アーカイブされた過去の版を探してもらいましょう。どこで迷うかを見て、もっともらしいものではなく、正しいアイテムを見つけられたかどうかを記録します。

• 何度も引き返すなら、カテゴリ名が重なっているのかもしれません。
• 兄弟フォルダを片っ端から開くなら、グループ分けが探す作業に合っていないのかもしれません。
• 古い版を見つけてしまうなら、バージョンや納品の記録を見直す必要があるのかもしれません。

階層が余分にあると、共有する引き継ぎが複雑になり、バックアップの対象を確認するのも大変になります。サブフォルダは、完全に左右対称なツリーがきれいに見えるからではなく、中身にそれが必要なところに足しましょう。

何も壊さずに色とアイコンのレイヤーを足す ​

色付きのバインダーの背は、バインダーを見つけやすくしてくれます。でも、中身を教えてくれるのはラベルです。フォルダの装飾も同じ働きであるべきです。ひと目でわかる目印であって、信頼できる記録ではありません。

物理的なフォルダにたとえると、その違いがわかりやすくなります。

ライフサイクルの段階には色のファミリーを、コンテンツの役割にはアイコンを選びましょう。この二つの軸は共存できます。進行中のビデオ用フォルダなら、作業中を表す色にフィルムのアイコンを組み合わせられます。

小さく、繰り返し使える語彙で運用する ​

プロジェクトごとにまったく違う視覚言語をあてがうのはやめましょう。意味のある違いは、Finderでざっと見るときに実際に必要な区別のためにとっておきます。

Appleの拡張属性のドキュメントは、ファイルシステムのアイテムが関連するメタデータを持てることを示しています。フォルダの見た目も、そうした補助的な情報として扱いましょう。プロジェクトの中身やディレクトリの配置とは別ものです。

Tintdでは、フォルダウォッチャーが指定した場所に新しくできたフォルダを検出し、名前に応じた色とアイコンを自動で適用します。バッチエディタなら、選択した複数のフォルダにまとめてアイコンを適用できます。個別に変更したいときは、Finderの右クリックメニューから。カスタマイズしたフォルダは、ワンクリックで元のmacOSのアイコンに戻せます。

フォルダのアイコンや色を変えるのは、あくまで見た目だけの変更です。中のファイルやサブフォルダに影響せず、パスも変わりません。

下のデモは、ビジュアルレイヤーを適用する流れを紹介しています。

ほかのMacやほかのツールのことも考えておく ​

カスタムフォルダアイコンは、それぞれのMacのローカルに保存されます。チームで使うMacごとに、アイコンのカスタマイズを個別に設定してください。全員が同じ見た目で見えると思い込まず、対応表は文章の手順として配りましょう。

この考え方についてもっと詳しくは、ビジュアルなファイル管理のガイドをどうぞ。大切なのは、素早く見つけられることと、確実に読み取れることの違いです。見慣れたアイコンはディレクトリを見つける助けになりますが、新しく加わった人には、やはり名前と文書化された目的が必要です。

メタデータを落とすツールでコピー、同期、アーカイブすると、スタイルが失われることがあります。見た目に頼る前に、実際の引き継ぎ方法でテストしてください。そして、視覚的なルールの意味を残す記録として、READMEを維持しましょう。

四半期ごとのアーカイブ見直しで機能し続けるようにする ​

プロジェクトのフォルダ構成は、生きたシステムです。新しい共同作業者、改訂された納品物、予想外の素材などによって、最初はよく考えられていた構成も使いにくくなることがあります。

アリゾナ大学のデータ整理に関するガイダンス(英語)は、元データと作業用ファイルを分け、素材がどう整理されているかを文書化することを推奨しています。これを、一度やったら見返さない設定作業ではなく、継続的な責任にしましょう。

下のライフサイクルを、見直しのリズムとして使ってください。

責任の所在が変わったらプロジェクトを移す ​

• 受け取りから進行中の作業へ: 目的と担当者がわかったら、受け取った素材を適切なカテゴリに移します。
• 進行中の作業からレビューへ: フェーズが終わったとき、共同作業者が加わったとき、人が繰り返し置き間違えるときに、構成を見直します。
• レビューから納品へ: 承認された出力を確定し、実際に渡したコピーをそのまま残します。
• 納品からアーカイブへ: 担当者が、進行中の義務がすべて完了したことを確認したらアーカイブします。
• アーカイブから削除へ: 該当する保存要件が終わり、責任者が廃棄を承認してからにしてください。

アーカイブはバックアップではなく、どちらの行為も削除する許可にはなりません。この三つの判断は別々に扱いましょう。

READMEに整理の担当者を、「チーム」のような曖昧な言い方ではなく、実在する人の名前で書いておきます。その人が再編成を承認し、何を変えたかを記録することで、共同作業者がめいめい勝手に共有のパスを作り変えることを防げます。

四半期チェックを実施する ​

進行中の最上位の階層をテンプレートと比べて、例外を調べます。

• ずれを解消する: リンク、スクリプト、共同作業者が依存しているものを確認したうえで、わかりにくい追加分の名前を変えます。
• 空の構造を取り除く: 中身を確認してから、不要な空のフォルダを削除し、重なっているカテゴリを統合します。
• 終わった作業を引退させる: 完成したプロジェクトを丸ごと、親階層の99_Archiveかアーカイブ用のボリュームに移します。
• 文脈を残す: プロジェクトの状況、担当者、納品先、保存の指示を書いた、日付入りのREADMEを残します。

プロジェクトを、そのプロジェクト自身のアーカイブのサブフォルダの中に移してはいけません。内部のアーカイブは制作中に置き換えられた素材用、親階層のアーカイブは完了したプロジェクト用として使い分けましょう。

計画をビジュアルで立てるなら、Wallingのビジュアルなノートの取り方のヒント(英語)が、決定事項を記録する補完的な方法として参考になります。そこで出た決定は、プロジェクトの記録に戻して残しておきましょう。

一貫性とは、どこでも同じ深さにすることではありません。 役に立つ例外は残し、もう役に立たないカテゴリは取り除きます。今日のうちに、四半期ごとの見直しを定期の予定に入れ、いま取り組んでいるプロジェクトの完了後チェックを予約して、今週中に次のプロジェクトのためのきれいなテンプレートを保存しましょう。

Tintdは、あなたが決めた構成に、カスタムのフォルダカラーとアイコンを足します。既存のフォルダにはバッチ操作で、新しいフォルダには自動のスタイル適用で対応。進行中の作業、納品物、アーカイブに一貫した視覚的な目印をつけたいなら、Tintdをどうぞ。中のファイルには一切手を加えません。