エンティティのProjectフィールドを変えたらどうなる？

エンティティにはProjectフィールドがあります。Assetエンティティなど作成するときに、Projectを指定するように促されます。Assetエンティティを作るときは、既にどこかのプロジェクトのページ内にいるので、現在のプロジェクトがデフォルトで設定されます。次の例では、「Signal」というプロジェクト内でAssetエンティティを作ろうとしているので、Projectには「Signal」と表示されています。

実はProjectフィールドはあとから変更できます。
別のプロジェクトを指定すると、今のプロジェクトからAssetエンティティが消えます。でも安心してください。データは消えていません。平たく存在しているAssetエンティティのProjectの値が変われば、別のプロジェクトで表示されるようになるわけです。

試しに次の様に「Signal」プロジェクトにいるAssetエンティティで、「Demo:Game」プロジェクトを指定してみます。

Projectフィールドを変更してすぐは、まだAssetエンティティが今のリストに表示されます。
ページをリロードすると新しくAssetエンティティを見つけなおすので、先ほどのAssetエンティティが消えます。

「Signal」プロジェクトからは消えましたが、「Demo: Game」プロジェクトのページに行くと、Assetsページに無事表示されました。

このようにエンティティは別のプロジェクトに移すことが出来ます。ただし、サイト間を越えて移動できないので注意が必要です。

もし会社で一つのサイトを用意し、各プロジェクトをぶら下げる形にしていれば、AssetやTaskエンティティを別のプロジェクトに移すことが簡単にできます。（まあ、タスクを別のプロジェクトに移すということはあまりないと思いますが。）

エンティティ自体にも種類がある

AssetエンティティにあるProjectフィールド、これを空欄にするとプロジェクトに紐づかないAssetエンティティになりそうですよね？やってみましょう。

次の図のように、Projectフィールドを表示してプロジェクト名を削除します。
すると、赤く表示されてしまいます。ページを更新すると、変更前のプロジェクト名に戻ります。

これはなぜか？というところに、エンティティを深く知るカギがあります。

実はエンティティには、それ自体いくつか種類があります。
Site Preferencesを開くと、Entitiesという項目があり、既存のエンティティの設定を変更できます。カスタムエンティティといって、独自のエンティティを用意することもできます。

Custom Entityをよく見ると、次のように「Custom Entity」「Custom Non Project Entity」「Custom Threaded Entity」という種類があることに気づきます。

「Custom Entity」が通常のエンティティです。これは「一つのプロジェクトに属する」必要があります。AssetエンティティやTaskエンティティは、プロジェクト内にいるためこの種類に当たります。

「Custom Non Project Entity」は「プロジェクトに属さない」エンティティです。
例えばユーザのアカウントの情報は「Person」エンティティとして管理されます。（そう、アカウント情報もエンティティなのです！）
アカウント情報はサイトに属しますが、プロジェクトには属さないので、この種類になっています。（Personは、SHOTGUN上部のPeopleから開けます…複数形に注目！）

「Custom Threaded Entity」は「スレッド化できる」エンティティです。「一つのプロジェクトに属する」必要があります。
ちょっとわかりにくいですが、次のような見た目で、コメントをスレッドとしてつらつらと追加できます。添付ファイルをつけることも出来ます。

これらの使い分けはなんとなく想像してもらえると思います。

例えば海外のアウトソースに仕事を発注することを考えてみてください。通貨のレートの情報が必要だとします。次の図のように、Assetエンティティに「通貨レート」というフィールドを追加して、直接レートを書いてもいいですが、管理が大変になります。あとで変更しにくいですし。

代わりに通貨レートのエンティティを用意するとします。プロジェクトとは関係なく複数プロジェクトから参照できるとよいので「Custom Non Project Entity」として作成します。

こんな感じで、プロジェクトに紐づけるかどうかでどのエンティティ種類を使うか考えてもらえればOKです。スレッドは特殊なのでそれほど出番はないです。

改めてまとめると、エンティティ自体の種類と、実際のエンティティの関係は次のようになります。

「すべてはエンティティ」の意味

AssetやTaskがエンティティなら、Projectもエンティティです。この様子なら、何でもかんでもエンティティにできそうですよね。要はフィールドのまとまりとして表せるものはなんでもエンティティになりうるわけですから。Mayaのシーンだってどんなに複雑でも大抵はノードとして扱われます。同じノリで、SHOTGUNで管理するデータは、なんでもエンティティにすることが可能なわけです。

実際SHOTGUNはそのように管理されています。
先ほどチラっと触れたように、ユーザのアカウント情報はPersonエンティティとして扱われます。

また、データベースでは何かしら変更を行うとログが記録されます。例えばエンティティのフィールドを編集します。すると編集したという情報をログにします。このログはEvent Logというエンティティが作られて、記録されます。

他にも沢山のエンティティがあります。これらを見るには、グローバルナビゲーションと呼ばれる右上のユーザアイコンのメニューを辿り「Default Layouts」にアクセスします。
エンティティがずらっと表示されますので、そのメニューから「（エンティティ名）List」を選びます。
（上図のイベントログは、Default Layouts > Event Log Entry > Event Log Entry Listで表示できます。）

とまあ「すべてがエンティティ」というのはこういうことを意味していたのですね。

一つのサイトで複数プロジェクトを管理する大きな利点として、プロジェクトをまたいで使用できる情報を一元管理できるところにあります。Personに登録されているユーザ情報に対して、その人が属するプロジェクトやタスクを簡単に変更できます。

SHOTGUNなら仕事を引き継ぐのも簡単！

今時は仕事が流動的になっています。次のようなストーリーをイメージしてもらうと、サイト内に複数プロジェクトがある利点がわかりやすいです。

「デザイナのボブは、プロジェクトAで大忙し。担当していた3Dモデル作成のスケジュールが遅れ始めてきた。そこで上司と相談して、プロジェクトBのデザイナを確保してもらうことに。」

…よくある問題として、ボブは忙しいあまり、引継ぎにも時間を割けなくて自分でやると言い出す始末。でも、SHOTGUNであれば心配ご無用！

「上司は早速プロジェクトBのキャサリンのPersonエンティティにアクセス。Projectフィールドに”プロジェクトB”と”プロジェクトA”を記入。すると、キャサリンにプロジェクトAが見えるようになった。次にボブがアサインされているTaskエンティティを見つけて、Assigned Toをキャサリンに変更。」

関係性はこんな風になります。

「引継ぎ？引継ぎに必要なすべての情報は、キャサリンがアサインされたTaskやAssetエンティティに記録されているので問題なし！これまでの経緯も残っているし、やらないといけないことも一目瞭然。キャサリンはボブの手を借りずとも、今から作業が始められる。さあ、引継ぎ開始だ！まずはモデル作成のニュアンスをつかむために、これまでのレビュー画像の履歴をチェックしよう！」

…というように、このスピード感でプロジェクトを進めていけるようになるのがSHOTGUNです。
まあ、個人的にはスピード感が上がって仕事に追い立てられるのは嫌ですが、何よりもボブやキャサリンに余分な負担がかからず、デザイン作業に集中できることが重要かなと思います。

謎なVersionエンティティ

エンティティについて深く知るうえで、最後に触れておきたいのがVersionエンティティです。

名が体を表していない、混乱の元となっているこのVersionエンティティ…。
この名前からして「SHOTGUNはバージョン管理できるんですね！」と思われてしまうという。
このエンティティについて改めて情報をまとめると、次のような感じです。

・　バージョン管理ではない。
・　実際にはメディアであり、ファイルなどアップロードして記録するエンティティ。スレッドになる。
・　Versionという名前は気にしない！

ちなみに本当にバージョン管理を使いたい場合、SHOTGUNでは行えないため、Perforceなど別のバージョン管理システムが必要です。SHOTGUNのToolkitを使うと、PerforceとSHOTGUNで連携を取るためのツールが提供されます。が、既にPerforceを使っている場合や他のバージョン管理を使われいる場合は、Toolkitを無理に使う必要はないです。このあたりの話も追々…。

まとめ

というわけで二回にわたりエンティティについてみてきました。これでおおよそエンティティについて理解して頂けています。

今回知った、エンティティの重要なポイントは次の通りです。
「プロジェクトに必ず属するエンティティ、プロジェクトに属さないエンティティ、スレッドになるエンティティがある。」
「SHOTGUNのかなりの情報がエンティティとして管理されている（PersonやEvent Logなど）」
「Versionエンティティの名前は気にしない」

フィールドのふるまいなど、さらに細かいところや気になる部分についても引き続きご紹介していきますので、乞うご期待！