製品名が変更されました。前回はエンティティがどういうものかご紹介しました。大まかに振り返ると、ポイントとしては次のあたりでした。「SHOTGUNのページは、表示したいエンティティを選ぶためにフィルタリングしている」では、この情報を踏まえて、もっとエンティティをいじくりましわして、より深く知っていきましょう!エンティティのProjectフィールドを変えたらどうなる?エンティティにはProjectフィールドがあります。Assetエンティティなど作成するときに、Projectを指定するように促されます。Assetエンティティを作るときは、既にどこかのプロジェクトのページ内にいるので、現在のプロジェクトがデフォルトで設定されます。次の例では、「Signal」というプロジェクト内でAssetエンティティを作ろうとしているので、Projectには「Signal」と表示されています。実はProjectフィールドはあとから変更できます。別のプロジェクトを指定すると、今のプロジェクトからAssetエンティティが消えます。データは消えていません。平たく存在しているAssetエンティティのProjectの値が変われば、別のプロジェクトで表示されるようになるわけです。試しに次の様に「Signal」プロジェクトにいるAssetエンティティで、「Demo:Game」プロジェクトを指定してみます。Projectフィールドを変更してすぐは、まだAssetエンティティが今のリストに表示されます。ページをリロードすると新しくAssetエンティティを見つけなおすので、先ほどのAssetエンティティが消えます。Game」プロジェクトのページに行くと、Assetsページに無事表示されました。このようにエンティティは別のプロジェクトに移すことが出来ます。サイト間を越えて移動できないので注意が必要です。会社で一つのサイトを用意し、各プロジェクトをぶら下げる形にしていれば、AssetやTaskエンティティを別のプロジェクトに移すことが簡単にできます。(まあ、タスクを別のプロジェクトに移すということはあまりないと思いますが。)エンティティ自体にも種類があるAssetエンティティにあるProjectフィールド、これを空欄にするとプロジェクトに紐づかないAssetエンティティになりそうですよね?やってみましょう。次の図のように、Projectフィールドを表示してプロジェクト名を削除します。すると、赤く表示されてしまいます。ページを更新すると、変更前のプロジェクト名に戻ります。これはなぜか?というところに、エンティティを深く知るカギがあります。実はエンティティには、それ自体いくつか種類があります。Preferencesを開くと、Entitiesという項目があり、既存のエンティティの設定を変更できます。カスタムエンティティといって、独自のエンティティを用意することもできます。Entity」という種類があることに気づきます。Entity」が通常のエンティティです。これは「一つのプロジェクトに属する」必要があります。AssetエンティティやTaskエンティティは、プロジェクト内にいるためこの種類に当たります。Entity」は「プロジェクトに属さない」エンティティです。ユーザのアカウントの情報は「Person」エンティティとして管理されます。(そう、アカウント情報もエンティティなのです!)アカウント情報はサイトに属しますが、プロジェクトには属さないので、この種類になっています。Entity」は「スレッド化できる」エンティティです。「一つのプロジェクトに属する」必要があります。わかりにくいですが、次のような見た目で、コメントをスレッドとしてつらつらと追加できます。添付ファイルをつけることも出来ます。これらの使い分けはなんとなく想像してもらえると思います。海外のアウトソースに仕事を発注することを考えてみてください。通貨のレートの情報が必要だとします。次の図のように、Assetエンティティに「通貨レート」というフィールドを追加して、直接レートを書いてもいいですが、管理が大変になります。あとで変更しにくいですし。代わりに通貨レートのエンティティを用意するとします。Entity」として作成します。こんな感じで、プロジェクトに紐づけるかどうかでどのエンティティ種類を使うか考えてもらえればOKです。スレッドは特殊なのでそれほど出番はないです。まとめると、エンティティ自体の種類と、実際のエンティティの関係は次のようになります。「すべてはエンティティ」の意味AssetやTaskがエンティティなら、Projectもエンティティです。この様子なら、何でもかんでもエンティティにできそうですよね。要はフィールドのまとまりとして表せるものはなんでもエンティティになりうるわけですから。Mayaのシーンだってどんなに複雑でも大抵はノードとして扱われます。同じノリで、SHOTGUNで管理するデータは、なんでもエンティティにすることが可能なわけです。実際SHOTGUNはそのように管理されています。先ほどチラっと触れたように、ユーザのアカウント情報はPersonエンティティとして扱われます。データベースでは何かしら変更を行うとログが記録されます。エンティティのフィールドを編集します。すると編集したという情報をログにします。Logというエンティティが作られて、記録されます。他にも沢山のエンティティがあります。Layouts」にアクセスします。エンティティがずらっと表示されますので、そのメニューから「(エンティティ名)List」を選びます。Listで表示できます。)とまあ「すべてがエンティティ」というのはこういうことを意味していたのですね。一つのサイトで複数プロジェクトを管理する大きな利点として、プロジェクトをまたいで使用できる情報を一元管理できるところにあります。Personに登録されているユーザ情報に対して、その人が属するプロジェクトやタスクを簡単に変更できます。SHOTGUNなら仕事を引き継ぐのも簡単!今時は仕事が流動的になっています。次のようなストーリーをイメージしてもらうと、サイト内に複数プロジェクトがある利点がわかりやすいです。「デザイナのボブは、プロジェクトAで大忙し。担当していた3Dモデル作成のスケジュールが遅れ始めてきた。そこで上司と相談して、プロジェクトBのデザイナを確保してもらうことに。」...よくある問題として、ボブは忙しいあまり、引継ぎにも時間を割けなくて自分でやると言い出す始末。SHOTGUNであれば心配ご無用!「上司は早速プロジェクトBのキャサリンのPersonエンティティにアクセス。Projectフィールドに”プロジェクトB”と”プロジェクトA”を記入。すると、キャサリンにプロジェクトAが見えるようになった。Toをキャサリンに変更。関係性はこんな風になります。「引継ぎ?引継ぎに必要なすべての情報は、キャサリンがアサインされたTaskやAssetエンティティに記録されているので問題なし!これまでの経緯も残っているし、やらないといけないことも一目瞭然。キャサリンはボブの手を借りずとも、今から作業が始められる。さあ、引継ぎ開始だ!まずはモデル作成のニュアンスをつかむために、これまでのレビュー画像の履歴をチェックしよう!」...というように、このスピード感でプロジェクトを進めていけるようになるのがSHOTGUNです。個人的にはスピード感が上がって仕事に追い立てられるのは嫌ですが、何よりもボブやキャサリンに余分な負担がかからず、デザイン作業に集中できることが重要かなと思います。謎なVersionエンティティエンティティについて深く知るうえで、最後に触れておきたいのがVersionエンティティです。名が体を表していない、混乱の元となっているこのVersionエンティティ...。この名前からして「SHOTGUNはバージョン管理できるんですね!」と思われてしまうという。このエンティティについて改めて情報をまとめると、次のような感じです。バージョン管理ではない。実際にはメディアであり、ファイルなどアップロードして記録するエンティティ。Versionという名前は気にしない!ちなみに本当にバージョン管理を使いたい場合、SHOTGUNでは行えないため、Perforceなど別のバージョン管理システムが必要です。SHOTGUNのToolkitを使うと、PerforceとSHOTGUNで連携を取るためのツールが提供されます。Perforceを使っている場合や他のバージョン管理を使われいる場合は、Toolkitを無理に使う必要はないです。このあたりの話も追々...。まとめというわけで二回にわたりエンティティについてみてきました。これでおおよそエンティティについて理解して頂けています。今回知った、エンティティの重要なポイントは次の通りです。「プロジェクトに必ず属するエンティティ、プロジェクトに属さないエンティティ、スレッドになるエンティティがある。何か変更したときの影響範囲を知ろう!2020.10.09前々回、前回とShotgunのエンティティがどういうものか、色々いじりながら挙動を見てきました。30日間無償で体験できます。30日間無償で体験できます。製品のご購入に関してご連絡を希望される場合は、こちらからお問い合わせください。