※この記事は全文機械翻訳されています。

フォルダーとドキュメントを構成および命名する方法はいくつかあります。

プロジェクトのタイプによって、異なる構造と命名規則が他の方法よりも適切に機能する場合があります。

このアーティクルには、データ環境をセットアップする方法を決定する際に役立つヒントが含まれています。

この記事では次のトピックについて説明します：

要素の名前 - サブフォルダー - フォルダー構造 - モデルフォルダー

構造内のアイテムに名前が付けられる方法に影響を与える可能性のあるいくつかの要因があります。

検出可能性とパス長は、多くの場合、重要な要因です。

このセクションでは次のトピックについて説明します：

名前を設定する人は、多くの場合、命名されるアイテムの内容に精通しています。

個人用ドキュメント

個人用アイテムに名前を付ける場合、アイテムに名前を付ける個人的な方法が最善であることが多いです。

ドキュメントに名前を付ける人は、後で検索することで簡単にアイテムを見つけることができるためです。

ドキュメントに名前を付ける人でさえ、後で自分の情報を再度見つけるのに苦労することがあります。

コラボレーションドキュメント

コラボレーション用のアイテムに名前を付ける場合、複数の人が異なるアイテムで作業します。

フォルダーの名前は、プロジェクト内で事前に定義されることが多いため、特定のタイプに属する異なるプロジェクト全体で簡単に認識できます。

最小要件

ドキュメント命名の最小要件は、多くの場合、合意されます。

異なる単語は異なる人に対して異なる意味を持つことができるため、アイテムに与えられた命名についてチームと議論することが重要であり、すべてのメンバーがアイテムに名前を付ける方法と検索対象を認識します。

ドキュメントの命名に関する良い慣例に従うことは常に役立ちますが、誰もが独自の好みを持っています。

あなたにとって意味のある命名戦略は、他の人にとって常に意味があるわけではありません。

チーム全体の命名スキーム

チーム内では、ファイル構造への貢献者はしばしば命名スキームに同意します。

これは、日付を名前に入れるように人々に伝えるなどの言葉による提案である場合もあれば、人々がアップロードできるように命名規則を作成することで強制される場合もあります。

プロジェクト全体の命名スキーム

共通データ環境では、一堂に集まる複数のチームがいることが多いです。

チームはまだ命名ルールを設定していないか、変更する意思がない場合がありますが、すでに非常に長い間ドキュメントに名前を付けている場合、彼らに別の方法をするよう説得するのは難しい場合があります。

この場合、良い解決策は、プロジェクトで合意された規則にドキュメント名を変更する限り、人々が希望の名前でファイルをアップロードできるようにすることです。

このように、チームメンバーはファイルの元の名前でドキュメントを見つけることができ、プロジェクトメンバーはそのドキュメント名で見つけることができます。

記述的であり、完全な単語を書き出すことは、単語を読むことができ、一目でドキュメントの内容を理解できるため、これに役立ちます。

これは、ドキュメント名が完全な文である必要があることを意味しません。

読むには長すぎるドキュメント名は、テキストの壁のように見え、すぐに一目で見過ごされます。

したがって、名前を1〜5語に保つことが推奨されます。

外部制限

Catendaでは、任意のパス長のフォルダー構造をインポートおよびエクスポートできます。

この情報が交換される他のソフトウェアには、構造内のドキュメントへのパスを形成する親フォルダーとドキュメント名の合計文字数に制限がある場合があります。

フォルダー構造を交換するために、Zipファイルがよく使用されます。

Windowsでは、Zipファイルのパス制限は260文字です。

OneDriveおよびSharePointでは、この制限は増加していますが、依然として400ユニコード単位に制限されています。

人々が直面する典型的な状況は、ドキュメントを次のように呼ぶことです：

Presentation_Final

その後、変更が必要になると、Presentation_Final_Final、Final_Final_For real、Final_LastOneIPromise_になります。

この時点で、あなたは諦めて、次のもの_Presentation_Submitted_と呼びます。

この状況は、最初からバージョン管理規則を決定することで回避できます。

_Presentation_v1、_Presentation_v2_などでファイルを開始することができます。

これにより、同じファイルの異なるバージョンが論理的な順序で確保されます。

Catendaに優れたリビジョンシステムがありますが、バージョン番号を追加することはまだ意味があります。

アップロードされたローカルリビジョン数が異なる場合があります。

プレゼンテーションのv3をアップロードしたが、次にアップロードしたものがv5だったとします。

Catendaのリビジョンは1つ増加しますが、ローカルリビジョンは2つ増加しています。

このようにして、どのバージョンが正しいかを追跡できます。

歴史的に、システムはドキュメント名のスペースに苦労してきました。

多くのシステムは現在ドキュメント名にスペースを処理できますが、ドキュメント名からスペースを削除する理由がまだあるかもしれません。

2つの単語が別の2つの単語ではなく一緒に検索できるようにしたいかもしれません。

名前のスペースを削除することで文字数を圧縮することを望むこともできます。

通常のファイル名を見ると：

this is a normal file name that is very long with many words.png

とスペースを削除すると、単語の境界がどこにあるかの視覚的な手がかりが必要なため、読みにくいごちゃごちゃしたメスになります：

thisisanormalfilenamethatisverylongwithmanywords.png

圧縮があなたの目標である場合、各単語を分離するために別の文字を導入したくないでしょう。

別の方法は、各単語を大文字にすることです。

ThisIsANormalFileNameThatIsVeryLongWithManyWords.png

これはすでにわずかに良くなっていますが、より長い名前では読むのはまだかなり難しいです。

スペースを最小化することが目標である場合、一緒に属する単語をグループ化しようとすることができます：

ThisIs_ANormalFileName_ThatIs_VeryLong_WithManyWords.png

これで、読める良い短いファイル名の領域に入り始めています。

ファイル長が意味をなさない場合でも、このように単語を圧縮することについて考えることは意味があります。

グループ化された単語を一目で理解する方が簡単だからです。

ファイル名の長さについて気にしない場合、それをさらに良くするために何ができるかは、セカンダリセパレーターを導入することです。

グループ化された単語が1つの方法で分離される方法を確認し、各グループ内の単語が別の方法で分離される方法を確認してください。

This-is_A-normal-File-name_That-is_Very-long_With-many-words.png

各単語を分離することで、各最初の単語を大文字にして、次の単語を小文字にすることが可能でした。

多くの異なるドキュメントがすべてわずかに異なる場合、5番目の単語に変動を追加するだけのために同じ4つの単語を何度も繰り返すことは意味がありません。

この場合、各単語に省略形を使用することをお勧めします。

例：Architecture_は_ARC_に、First floorは1stに変わる可能性があります。

ファイル名の情報により多くの情報を少ないスペースで取得できるという事実は、強みと弱みの両方です。

ファイル名情報で100%正確に取得することは簡単ですが、ファイルに名前を付けるのに最適な方法ではありません。

省略形を追加すると、ファイル名がごちゃごちゃした読みにくいメスに変わることにすぐに気付き始めます。

例を見てください：_20110101_ARC_BLDG1_BLCK2_FLR4_Q4_Wa3_Win4_S_C_v4 建築家による建物1のブロック2のフロア4のウォール3のウィンドウ4のコンクリート桶の4番目のバージョンについて2011年1月1日のファイルであることは、ファイル作成者にとって意味があるかもしれません。

プロジェクト内の他の人がそれを読むのに時間をかけるという確信がありません。

特に検索者が本当に探していたものではない場合は：

20110101_ARC_BLDG1_BLCK1_FLR4_Q4_Wa2_Win3_S_C_V4

これは完全に異なるウィンドウシルです。

このレベルに達すると、ファイルをフォルダーに分割する方が良いです。

ドキュメントセクションは自動的に名前でソートされます。

したがって、最も関連性の高いドキュメントが最初に表示されるようにドキュメントの先頭にいくつかの文字を追加することをお勧めします。

時系列順

Catenda Hubで履歴の概要を取得するために、公開または作成でソートできます。

デフォルトでは、ドキュメントは名前でソートされます。

メンバーが初めてフォルダーを開くと、最新のドキュメントがトップにない可能性があります。

これに対抗するために、ドキュメントの日付をドキュメントの前に追加できます：_20110101_は2011年1月1日になります。

これは、長い間前に作成されたドキュメントがCatenda Hubにインポートされた場合にも役立ちます。

この名前は変更できますが、ドキュメントを探すときに役立つ情報です。

このようにして、名前列を日付でソートすることもできます。

英数字順序

他の文字より前に来る文字を確認するには、Catendaのリストのソート順序を参照してください。

ドキュメントを重要度の順に並べるために、ラベルまたはリビジョンの数でソートできます。

デフォルトでは、ドキュメントは名前でソートされます。

メンバーが初めてフォルダーを開くと、最も重要なドキュメントがトップにない可能性があります。

これに対抗するために、最初に来るようにする名前の先頭に文字を追加できます。

例えば、_1.0 Most important. 1.1 Less important、1.2など_でファイルを呼ぶことができます。

その後、誰かが誤ってアップロードすることで前に来た0でドキュメントをアップロードしてルールを破ることに気付くかもしれません。

その後、名前の前に_を追加して、どのアイテムの前に来ることを確認できます。

誰が最初かについてのこの戦いは無限に思えるかもしれません。

したがって、リストのソート順序を確認して、他の文字より前に来る文字を確認し、あなたのケースで何が使用するのに意味があるかを確認することが役立つ場合があります。

リストに大量の情報がある場合、探している情報を見つけるために遠くまでスクロールする必要がある場合、情報を見つけるのが難しい場合があります。

このセクションでは次のトピックについて説明します：

フォルダー内に多数のドキュメントまたはフォルダーがある場合、リストを遠くまでスクロールして探しているドキュメントを見つける必要があるため、見つけるのが難しくなる可能性があります。

この時点で、このリストにサブフォルダーを追加し、ドキュメントをそれらの最も重要なプロパティで分割することが多いです。

これは、以下のようなプロパティの範囲である可能性があります：

ドキュメントタイプ(図面、画像、スプレッドシート)

関連トピック(壁と窓)

研究分野(ARC、MEP、STR)

アップロードした当事者(グループ1、グループ2、グループ3)

アップロード日(20110101、20231225)

成熟度(ドラフト、提出、承認、拒否)

ドキュメントを分割する方法の決定に影響を与える理由は、以下の通りです：

検出可能性

アクセス権設定

ドキュメント構造を使用してしばらく作業した後、多くのサブフォルダーを作成し始めることに気付くでしょう。

サブフォルダーに到達するのに多くのクリックがかかる場合、最初の場所でサブフォルダーを作成することで解決しようとしていた問題を解決していません。

情報はまだ見つけにくいからです。

サブフォルダーを作成する場合、3レイヤーより深くは進まないことをお勧めします。

これは、ほとんどの人が彼らがいた最後の2つのフォルダーを覚えているかもしれませんが、より深く行くほど、あなたが来た場所を忘れ始めるからです。

これを防ぐために、サブフォルダーをレベルアップできます。

ここに4レベル深いフォルダーの例があります:

01_Models-and-drawings 0101_Models 010101_ARC 01010101_Window 01010102_Wall 010102_MEP 01010201_Ducts 01010202_Vents 010103_STR 0102_Drawings

このフォルダーは次のように簡略化できます:

0101_Models_ARC 010101_Window 010102_Wall 0102_Models_MEP 010201_Ducts 010202_Vents 0103_Models__STR 0201_Drawings

またはさらにシンプルにすることもできます:

010101_Models_ARC_Window 010102_Models_ARC_Wall 010201_Models_MEP_Ducts 010202_Models_MEP_Vents 010301_Models__STR 020101_Drawings

ご覧のとおり、同じレベルで類似したフォルダーを複数追加すると、探しているドキュメントを含むフォルダーに到達するのにかかるクリック数を削減できます。

気づくかもしれない別のことは、フォルダー構造をより単純にするほど、ファイル名が長くなるということです。

ファイル名が長すぎると、読むのが難しくなります。

したがって、ファイル名の長さとフォルダーの深さのバランスを保つことが重要です。

このセクションでは次のトピックについて説明します：

このドキュメント構造では、ドキュメントのタイプに基づいてファイルを構造化します。

すべてのフロアプランはフロアプランフォルダーに入り、すべてのミーティングサマリーはサマリーフォルダーなどに入ります。

このファイル構造は、コンサルタントから提供されるファイルが1つの場所に集められるため、クライアントが使用しやすくなります。

このファイル構造は、コンサルタントがファイルを配信する場所が多いため、コンサルタントが使用しにくくなります。

ファイル構造の例

このタイプのドキュメント構造の例は以下の通りです：

0101_Information 010101_Admin 010102_Contracts 0201_Images_Presentations YYMMDD_Presentation-title.ppt 0202_Images_Site-visits YYMMDD_Site-visit-title.jpg 0301_2D 03010101_Plan_Floor 030101010101_DWG_ARC YYMMDD_Drawing-title.dwg 030101010102_DWG_STR 030101010103_DWG_MEP 030101010103_DWG_LAN 030101010201_PDF_ARK YYMMDD_Drawing-title.pdf 030101010202_PDF_STR 030101010203_PDF_MEP 030101010203_PDF_LAN 03010102_Plan_Ceiling 03010103_Plan_Fire-escape 03010201_Section 03010301_Elevation 0302_3D 03020101_Models_Archicad 030201010101_PLN_ARC 030201010102_PLN_STR YYMMDD_Drawing-title.ifc 030201010103_PLN_MEP 030201010104_PLN_LAN 030201010201_IFC_ARC 030201010202_IFC_STR 030201010203_IFC_MEP 030201010204_IFC_LAN 03020102_Models_Navisworks 03020103_Models_Revit 030201030101_RVT_ARC 030201030201_IFC_ARC 03020104_Models_Rhinoceros 03020105_Models_Solibri 03020106_Models_Point-clouds 03020201_Visualization_Renderings 03020202_Visualization_Images-high-resolution

このドキュメント構造では、まずプロジェクトに参加する研究分野を分離します。

このタイプのフォルダー構造は、ユーザーに独自の領域への完全なアクセスを提供したい場合に適しており、ユーザーはファイルを希望に応じて自由に移動できます。

このファイル構造は、コンサルタントが自分の領域を持ち、アップロードするすべてのファイルを制御できるため、コンサルタントが使用しやすくなります。

このファイル構造は、異なるコンサルタントからのファイルが独自のフォルダーに分散されているため、クライアントが使用しにくくなります。

ファイル構造の例

0101_Information 010101_Admin 010102_Contracts 0201_ARC 02010101_2D 02010201_3D_Archicad 0201020101_PLN 0201020102_IFC YYMMDD_Drawing-title.ifc 02010202_3D_Navisworks 02010203_3D_Revit 0201020301_RVT 0201020301_IFC 02010204_3D_Rhinoceros 02010205_3D_Solibri 02010206_3D_Point-clouds 02010307_Contracts 0202_MEP 020201_2D 020202_3D 020203_Contracts 0203_STR 0204_LAN

ドキュメントとしてモデルを有効にしたら、モデルセクションのモデルをドキュメントセクションのドキュメントに接続することができます。

モデルセクションで新しいモデルが作成されると、モデルフォルダーと呼ばれるフォルダーに表示されます。

モデルは、モデルフォルダーから移動して、ドキュメント構造内にあるようにしたい場所に移動できます。

上記の例と同様に、タイプ別にモデルを構造化できます: 01_Models -> 0101_ARC -> YYMMDD_Model-title.ifc

または、研究分野別にモデルを構造化できます: 01_ARC -> 0101_Models -> YYMMDD_Model-title.ifc

ここで選択する最良のオプションは、ユーザーがモデルフィルターを使用するかどうかによって異なります。

研究分野ごとにモデルを分離する場合、ユーザーは各研究分野の他のドキュメントと混ざっている3Dモデルを見つけるのが難しい場合があります。

ユーザーがモデルフィルターを見つけることに自信がある場合、このオプションを使用できます。

ユーザーがこのフィルターを使用しないと思われる場合、すべてのモデルを独自のモデルフォルダーに配置する方が良いので、ユーザーはこのフォルダーに3Dで開くことができるモデルが含まれていることに気付きます。