[SG Tips] リソースプランニングの入力をできるだけサボって利用する
ShotGridアドカレ2021 12月23日の記事です。
< 16日目 | 18日目 >
リソースプランニングとは？
10月の「Shotgun -> ShotGridリブランド」期限を目前に控えた9月末に、リソースプランニング（以下、RP）というツールが追加されました。
簡単に言うと「超すごいタスク集計機能を使って「作業負荷」と「作業許容量（リソース）」を見積もってみようぜ」というビューです。
関連するエンティティタイプ
作業のリソースを計算するからには タスク が絡むことは明らかですが、
他にもいくつかのエンティティタイプと連携して集計を行います。
関与するのは下記です。
- タスク
- 部門
- パイプラインステップ
- 予約/契約
- プロジェクト
- ユーザー
多い！
RPをきちんと稼働させようと思ったら、これらのエンティティの所定のフィールドが十分入力されていることを期待されます。
{紙版ではこのあたりにRPで登場するエンティティの関係図を入れます}
公式ドキュメントのRPを設定する記事をみてみると「部門」は「一回限りの設定」に分類されています。部門自体はそう増減するものではないものの、ユーザー追加時、パイプラインステップ追加時にはそれぞれ関連づける必要があります。「一回限りの設定」という文言の印象よりずっと、面倒を見る必要があります。
入力コストが高い！
関わるエンティティタイプが多いということは、ちゃんと動かすコストが高いということです。
SGを利用する中でトラッキングしたい情報があったとして、
それ以外の入力はなぁなぁに済ませる、という運用も可能です。
たとえば「部門」は「グループ」と印象が近いこともありそのあたりが微妙に適当だったりするケースもありますが、基本的にはユーザー側で問題なければそれもよしでした。
「予約」「契約」もそうで、追いかける必要がある、という運用でなければ無視して構いませんでした。
「ユーザ」のキャパシティ欄もそうですね。
タスクのステータスだけ追えればいい場合、開始終了日を入れなくてもなんとかなるとか、最悪担当者が曖昧でも運用可能でした。
RPを使う場合、これらが曖昧ではきちんと動作しません。
また、動作しない時に「どれの入力が足りないんだ？」と考慮する原因も多岐に渡ることになります。
RPで得られる恩恵と入力コストの高さとを天秤にかけてどうかというのは、結局は制作に携わる人々の習慣にやプロダクションの文化に因ってしまうので簡単には結論は出ないのですが、
それくらいの入力時間は捻出できて当然でしょ、というほどカンタンでもありません。
そこで、
入力内容の中から 妥協できるポイント を探って、
「全開ではないもののとりあえずRPを動作させる」状態を考えてみたいと思います。
「部門」を妥協する
RPでの情報分類の最上位階層は「部門」と「プロジェクト」です。
先に挙げたドキュメントでは、SGの「部門」は、現実のプロダクションの部門分けと一致しているべき、と言うことになっています。
実際そうだと思います。
そうだと思いますが、現実には無理な場合もあります。
RPは、「部門」は「パイプラインステップ」を経由して「タスク」と関連づけることで、キャパシティと作業負荷を計算します。
パイプラインステップといえば、「アート」「モデリング」「テクスチャ」……といった内容が並びます。
一方、現実のスタジオでの部門として考えられるものとして、たとえば「キャラ班」「背景班」「エフェクト班」あたりが一般的でしょう。
そのどれも「アート」「モデリング」「テクスチャ」工程をもつ可能性があり、
RPの要求を満たそうとすると「キャラ班」に「アート」「モデリング」「テクスチャ」パイプラインステップ、「背景班」に「アート」「モデリング」「テクスチャ」パイプラインステップ、「エフェクト班」に「アート」「モデリング」「テクスチャ」パイプラインステップ、といった処理をする必要があります。
▼下記は、そういうことを考えながらためしに入力し冗長になってしまったパイプラインステップの一例です。
パイプラインステップに追加があった場合は、それを部門分足したり足さなかったりします。
プロジェクトごとのパイプラインステップ表示・非表示コストも変わってきます。
妥協点
そこで、RPで集計してもらうのはとりあえずプロジェクト側だけと割り切り、
「「部門」を実際と一致させる」ことを妥協します。
「Production」とか「work_resource」とかそれっぽい部門を作成して、全ユーザをそこに所属させ、パイプラインも全てその部門に関連づけます。
これで、パイプラインステップを追加する段になっても部門への関連付けは最小限、部門ごとに追加する必要もなく、またユーザが増えても部門への関連付けは流れ作業化できます。
この場合、リソースとして計上しない人（タスクにアサインされないけどバージョン閲覧などでログインする人）をまとめる部門も作成しておきます。「Office」「Manage」「_」など、RP仕分け都合の命名で大丈夫かと思います。
「予約」を妥協する
プロジェクトに参加する期間、稼働可能な期間をトラッキングするためのエンティティです。
プロジェクトへのアサインはプロジェクトオーバービューにある通り「参加している・していない」という値ですが、
RPで計算するにあたり「期間」が必要となり、そのための時間軸を持っているのが「予約」（または「契約」）です。
プロジェクトへのアサインだけでことたりていた運用の場合、予約の入力はシンプルにコスト増です。
妥協点
そこで、部門ほどドラスティックではありませんが、
「アサインされたら、同時にその日から年末まで予約を作成する」
あたりを運用ルールとします。
プロジェクトがいつ終了するか、そのユーザがいつプロジェクトのリソースから外れるかを考慮しないことで、予約はとりあえず入力できます。
言うほど入力負担は下がっていないので、だったらきちんと入力できるならした方がいいですが、
全員を きちんと入力するのはそれなりのシゴトになると思うので、
あらかじめ雑になることを織り込んだ方が現実的な運用になるのでは？
くらいの施策です。
「契約」のことは忘れます。
タスクを妥協する
これは基本的には「やってはいけない」運用な気がするのですが、
1パイプラインステップに1タスク だけ作成し、関連しそうな人 全員を担当者 にします。
プロジェクト開始前でタスクが具体化できない状況などで、無理やり 抽象的なタスク を設けてRPを稼働させます。
「プロジェクト中の、負荷の高そうな期間を把握・分散する」というプランニングに利用するには十分かと思います。
これはほぼ「フェーズ」が担う役割なのですが、フェーズにはユーザーアサインがなく、またRPはフェーズを加味しません。
この抽象的なタスクはあくまでもRPを稼働させて 見積もり作業 を行うためのものです。プロジェクトがある程度具体的に見えてきたタイミングで、具体的なタスクに分解した上で削除するのを忘れずに。
タスクの妥協できないところ
開始・終了・担当者・パイプラインステップは確実に入力しておく必要があります。
ついでにパイプラインステップも妥協する
これも、やらずに済むならやらない方がいい感じがしますが……
特に小さいプロジェクトのタスクがそうだと思いますが、タスクによってはパイプラインステップが明確に分けられない場合があります。
また、上記の抽象的なタスクはそもそもパイプラインステップを跨いでしまう可能性が高いです。
そこで、「工程」という意識を一旦忘れて、とりあえず「AssetWork」「ShotWork」「Implementation」など抽象度の高いパイプラインステップを設けておいて利用します。
許容されるなら「etc」「_」でもいいでしょう。
とにかくRPが稼働できる状況を優先します。
部門との関連付けに関しては、本稿では部門はひとつにまとめているのでむしろ相性がいいです。
まとめ - これだけ妥協を重ねた計算に意味があるのか
ここまでやってきた内容は、
- 部門をひとつにまとめてしまう
- 予約をプロジェクト期間に関わらず長めに入力する
- +αとして…
- タスクもひとまずまとめる
- パイプラインステップもひとまずまとめる
です。
予約については、予約期間に含まれていない場合は作業リソース（キャパシティ）として計算されません。（下図の最下行、水色の期間はキャパ扱い、それ以降はプロジェクトにアサインされていてもキャパ外となっている例です）
計算精度はザルみたいに落ちているので、役に立つか立たないかというと微妙なところです。
動かすことが目的化しているため当然といえば当然ですね。
ですが完全に役に立たないかというと、そうでもないかと思います。
後半で述べているように、RPを無理やり計算できる程度に入力するというのは、
きちんとした入力項目が得られないときでも計算できる、ということでもあります。
プロジェクトの情報自体が曖昧な状況でも、とりあえずRPを稼働させて俯瞰する、というのは特にプロジェクト黎明期ではこれはこれで旨味があるかと思います。
（「きちんと入力してくれ！」というツール側の要求と、ツールが受け持つ「プランニング」とが微妙に乖離している気がしますが、ご愛嬌）
あるいはある程度ツール化してサポートすれば、入力負担を下げつつ精度も上げられると思います。
余談
Autodeskがかつて買収したConsiliumによる「機械学習駆動の生成的スケジューリング」は、そのうちRPと関連づいてくるんじゃないかなと期待しています。
こちらの記事▼では、どういうカスタムエンティティやフィールドを追加したかなどが語られていて、興味深いです。
40ページほどの講演資料もダウンロードできます。
余談2 - ユーザーをdisableした場合
リソースプランニングは、アクティブなユーザーのみリソースとして扱います。
その瞬間瞬間ではほぼ問題になりませんが、過去の集計結果を参照するときには、当時在籍してたけどいまいないみたいなユーザーの計算結果が変わってきます。
プランニングなので未来方向の集計ができていればいいのですが、
振り返りに使う際にはご注意ください。
宣伝
ShotGrid のTipsをまとめた技術同人誌を制作中です。
2022年のイベントやBOOTHでの頒布を目指しています。
Discussion