CGWireでは、人々がShotgridから離れたいと考える最も大きな理由として、コストと複雑さが挙げられています。シート単位のライセンス、エンタープライズ向けサポート階層、コンサルタント費やメンテナンス費、そして、誰か別の会社が管理しているプラットフォームに組み込まれた何年分もの組織的なナレッジ。シート数40の中規模アニメーションスタジオなら、予算が簡単に膨らんでしまいます。
Kitsuは、その代替として静かに成熟し、堅実な制作トラッカーになりました。オープンソースで、私たちのチームによって積極的に保守されています。クリーンなREST APIを中心に構築され、自分たちでホストして所有できる仕組みです。制作スタッフが実際に使いたいと思えるのは、それが日常のワークフローを変えてもらう必要がある場合には、なおさら重要で、簡単な話ではありません。
問題は、FlowからKitsuへの移行が“本当のエンジニアリング案件”だということです。 移行をショット納品と同じくらい慎重に計画するスタジオは、コストを抑えられ、より多くのコントロールを得て、エンドツーエンドで理解できるパイプラインアーキテクチャを手に入れます。このガイドは、その第一歩を踏み出すための手助けになります。
設定ファイルに触れる前に、最初にやるべきタスクは、Autodesk Flowの中身を「何がどれだけ入っているのか」を正確に理解することです。
フェーズ1：監査（Audit）と評価（Assessment）
ほとんどのスタジオは、Flowインスタンスの中に長年分の技術的負債を溜め込んでいます：単一の作品のために追加したカスタムフィールドがいつまでも削除されず残っている、もう誰も使っていないワークフローを反映してしまっているパイプラインステップ、そして3人の異なるTDがそれぞれ別のやり方で作った連携。長編映画の制作では、ショット、アセット、タスクの各エンティティにまたがって、何百ものカスタムフィールドが散らばっていることもあります。
監査は、あらゆるエンティティタイプを完全に分析することから始まります。プロジェクト、ショット、アセット、タスク、プレイリスト、バージョン、ノートです。FlowのPython APIはスクリプト化できますし、Phase 3の移行パイプラインの一部になる同じコードを使うことを考えると、スクリプト化するのが正しい判断です。
並行して、Flowから読み取ったり書き込んだりするすべてのパイプラインツールを文書化する必要があります：ローダー、パブリッシャー、ステータスフック、レビュー連携、そしてカスタムのWebhook受信側などです。下流の依存関係が5つ以上あるツールは、移行リスクが高いので優先度を上げます。たとえば、Ftrackのレビュー機能、Deadlineのステータスコールバック、さらにカスタムのNukeパブリッシャーをすべてFlowのWebhookシステム経由で統合しているスタジオは、組み替えのための工数を大きく見積もる必要があります。
監査には、部門の責任者に話を聞くことも含まれます。多くのスタジオは、その内容に驚きます。監督（スーパーバイザー）は「2本前の制作からFlowのビッド（見積・入札）ツールを使うのをやめた。インターフェースが遅すぎたからだ」と報告することがあります。また、ライティング責任者がレンダーバージョン管理のために自分でスプレッドシートの代替策を作っていたりするかもしれません。Flowのバージョン比較が十分ではなかったためです。本当に使われている機能と、人々が回避してきた機能の区別が、移行工数をどこに投入すべきかを決めます。最低限の機能対等性（feature parity）に到達するために必要な範囲、つまりエンティティ数、1日あたりのAPI呼び出し量、統合マップ、そして実際に重要な機能の一覧です。
監査が終わると、計画フェーズでは、Flow上の内容をKitsuで何を構築するのかに翻訳します。
フェーズ2：計画（Planning）とアーキテクチャ
ShotgridとKitsuは同じデータベースのスキーマを共有していません。だからこそ、2つのプラットフォームのアーキテクチャを対応づけ（マッピング）する必要があります。
Flowでは、Shot（ショット）エンティティが制作メタデータの多くを直接保持します。Kitsuでは相当するデータがどこにあるかは、Shotエンティティか、リンクされたタスクか、あるいはカスタム属性かで変わります。インスタンスの設定方法によります。ショット800、ショットあたり12種類のタスクタイプで作品を移行するには、そのマッピングを事前に定義しておく必要があります。
セルフホストとKitsu Cloudのどちらを選ぶかも、ここで決めます。
セルフホスティングは完全なコントロールを与えます。スケール時のコストを抑えられる可能性もあり、制作データを自社のファイアウォールの内側に保てます。これは特定の市場の顧客が求めることがあります。一方で、デプロイ、バックアップ、稼働率（uptime）を所有するDevOpsエンジニアが必要です。
Kitsu Cloudは、その負担を月額費用とCGWireのインフラへの依存という形で取り除きます。
オンプレミスは両者のちょうど間を狙えます：データは物理的に施設内に置かれ、セキュリティポリシーの管理下にあります。しかし、Kubernetesの専門知識をゼロから構築せずに、マネージドなハードウェアやプライベートクラウドアプライアンス上で動かすことも可能です。
フェーズ1で特定したすべての連携・自動化について、文書化された意思決定を行います：port（移植する）、replace（置き換える）、retire（廃止する）。SGTKベースのローダーは、gazu（KitsuのPython SDK）へ移植する、またはカスタムのKitsu Pythonクライアントを作ることで対応できます。レビュー機能はKitsuのネイティブなレビューエンジンに置き換えます。ある作品でしか使われていなかったWebhook受信側は廃止できます。
その一覧は、移行のタイムラインを駆動するエンジニアリングの作業分解リストになります。移行が「完了」するのは、最後のショットのインポートが成功したときではありません。その一覧にあるすべての項目が解決され、文書化されたときです。
データ移行フェーズでは、計画が現実にぶつかります。
フェーズ3：データ移行
最初のステップは、Autodesk Flowからあらゆるエンティティタイプごとにスクリプト化されたエクスポート経路を構築することです。ショット、アセット、タスク、バージョン、ノート、プレイリストを対象にします。
ここではFlow REST APIを使うPythonスクリプトがうまく機能します。単発のスクリプトではなく、ログ付きのETLジョブとして書くのがおすすめです。マッピングエラーを直したあとに再実行する必要が出たときに、価値が出ます。ショット500の連続配信（エピソード）シリーズを移行するなら、エンティティタイプごとに別々のエクスポートスクリプトを書き、それぞれに独自のフィールドマッピングテーブルとバリデーションステップが必要になるはずです。
エクスポートの出力先はCSVではなくJSONにすべきです。CSVはノートスレッドやバージョンリンクのような、移行の中心にあるネスト構造をフラット化してしまい、データを失っていることに気づかずに進む可能性があります。エンティティタイプごとにJSONファイルを1つ用意し、行数とチェックサムを記録するマニフェストファイルを付ければ、インポート側を走らせる前に照合できます。
タスクステータスのマッピングには特に注意が必要です。FlowとKitsuは異なるステータス用語を使うため、対応は一対一になりにくいのです。Flowの「rev」（レビュー待ち）はKitsuの「wfa」（承認待ち）にマッピングされるかもしれません。しかしFlowの「hld」（保留）は、Kitsuに直接の同等項目がない場合があり、そのショットがどこに着地するのかについて手動の意思決定が必要になります。すべてのステータス、パイプラインステップ、タスクタイプは、移行スクリプトを実行する前に、共有スプレッドシート上で文書化されたマッピングとして用意しておく必要があります。
パイロット移行として、単一の完了したプロジェクトを対象にするのは譲れません。すでに包み終わっているプロジェクトに対してフルのインポートパイプラインを実行すれば、スキーマの不一致、エンコードの問題、サムネイルの欠落、壊れたノートスレッドなどを、本番リスクなしでチームが安全に洗い出せます。アクティブなプロジェクトは、すべてのバリデーションが終わってから最後に進めます。
推奨されるアプローチは、ローカルのKitsuテストインスタンスを立ち上げることです。公式の cgwire/kitsu Dockerイメージを使えば、10分未満で完全に機能する環境を用意できます。
インポートスクリプトをそのインスタンスに向けてフルのパイプラインを実行し、その後 gazuで結果を問い合わせて、エクスポート用マニフェストと差分を取ります。
データがきれいに移行できるなら、ツール層がこのプロジェクトでもっとも難しい部分になります。
フェーズ4：ツールと連携の作り直し（Re-wiring）
ここから制作パイプラインはさらに複雑になります。たとえば、レンダ提出のたびにFlowへバージョンをスタンプするNukeパブリッシャー、最新の承認済みアセットをチェックアウトするMayaローダー、ファームジョブ完了時にタスクステータスを切り替えるDeadlineのコールバック… これらのツールはすべて、統合ロジックの中にFlowがハードコードされています。SGTKセッション呼び出し経由でも、直接のAPIリクエスト経由でも構いません。
Kitsuは、ここで重要になる中核のトラッキング操作をカバーしますが、ShotGridとはいくつか違いがあります。連携の作り直しを始める前に、把握しておく価値のある点です：
- キャスティングとブレイクダウンはKitsuではネイティブで、専用ビューがあります。一方ShotGridでは、より多くのセットアップを要するエンティティの関係性で扱います。
- クォータと勤怠のトラッキングはKitsuではスケジュールとタスクタイプに直接紐づくため、同じ結果を得るのにShotGridで通常必要になるカスタム設定なしで、アーティストごとの課金計画を簡潔にできます。
- レビューでは、Kitsuがチームメンバーが開いて注釈できる共有可能なプレイリストURLを生成します。ShotGridはアプリ内でレビューを維持し、外部共有は通常、付随する別ツールで対応します。
- APIも異なります。Kitsuは文書化されたPythonクライアントとしてgazuを使い、REST APIを公開しています。ShotGridの独自Python APIはVFX領域で確立されていますが、Autodeskのエコシステムの中に閉じています。
- Kitsuが再現できない唯一の機能は、ファイルシステムのテンプレートマネージャーです。ロジックはSGTKにあり、明示的に作り直す必要があります。
SGTKベースのツールは置き換えるか、作り直して再ラップする必要があります。繰り返しになりますが、CGWireのチームは、SGTKのtk-coreが担っている多くの操作をカバーするために gazuを保守しています。たとえば、sgtk.platform.current_bundle().shotgun.find_one()を使ってShotエンティティを検索していたパブリッシャーは、gazu.shot.get_shot_by_name()で置き換えます。ロジックは同様のものです。SGTKのコンテキストとテンプレートシステムにパイプライン全体を依存させて構築していたスタジオは、そのパス解決ロジックを自社コード内で再現する必要があります。いくつかのスタジオは、このタイミングを利用して、より明示的なパスの取り決めへ切り替え、何年も積み上がったSGTKテンプレートの複雑さを単純化します。
テストこそが、移行を本番へ進める権利を得るフェーズです。
フェーズ5：テストと検証
代表的なショットをKitsuの一連の流れ（チェーン）全体に通します：タスク作成、ステータス更新、ファイルパブリッシュ、バージョンアップロード、プレイリストレビュー、そして納品。 「代表的」とは、うまくいくケース（ハッピーパス）だけではなく、エッジケースをカバーするショットのことです。1,200ショット、共有アセットを含む複数シーケンスのプロジェクトなら、50ショットだけのテストプロジェクトでは決して表面化しないデータモデルの問題が見つかります。たとえば、ネストされたアセット階層を持つシーケンス、40以上のタスクを持つショット、クライアント向け注釈付きのバージョンなどは、ストレステストに投入すべき良い例です。
データの検証とは、移行されたレコードのサンプルを、各エンティティタイプごとにレビュアーが選んだ形で、元のFlowデータと突き合わせることです。コーディネーターはショットのメタデータが一致していることを確認します。TDはバージョンのファイルパスが正しく解決されることを確認します。スーパーバイザーは、ノートや注釈が正しい著者情報とタイムスタンプ付きで引き継がれたことを確認します。このステップを省くと、移行から3か月後にデータ整合性の問題が見つかることがあります。
権限とアクセスのモデルのテストは、プロセスの後半まで先送りされがちですが、KitsuのロールシステムはFlowとは異なります。Kitsuはよりシンプルなアクセスモデルを採用しています。組み込みの権限階層も少ないため、複雑なFlowの権限設定を持つスタジオは、タスクタイプの可視性ルールやプロジェクトメンバーシップを通じて、その一部を再実装する必要があります。たとえば、Flowでクライアントがバージョンを「閲覧はできるがダウンロードできない」ように設定していた場合、その挙動をKitsuのクライアントアクセスモデルへマッピングしなければなりません。実際のクライアント向けアカウントを使ってライブ前にテストしておくことで、最初のクライアントレビューで恥ずかしい過剰共有の事故を避けられます。
技術的な移行は完璧でも、アーティストとのコミュニケーションが雑だと、ロールアウトは失敗し得ます。
フェーズ6：アーティスト向けトレーニングとロールアウト
うまくいくロールアウトの順序は：まずスーパーバイザー、その次にパイロットチーム、その後に1つの部門、最後にスタジオ全体です。監督（スーパーバイザー）が説明を受ける前に、初日からスタジオ全体へ移行を告知してしまうと、答えられない混乱した不満のメールが山ほど届くことになります。
書面のドキュメントは、アーティストが毎日実行する10個のワークフローをカバーすべきです。タスク指向の手順として書きます。「Kitsuのタスクボードの紹介」よりも、「自分の現在のタスクステータスを確認する方法」のほうが役に立ちます。タスクステータス確認を1日に15人のアーティストが行い、さらにバージョンを1日に8回アップロードするコンポジット部門には、Kitsuの実際のインターフェース言語で、彼らがやっていることと完全に一致するドキュメントが必要です。ライブKitsuインスタンスのスクリーンショットは、どんな量の文章説明よりも価値があります。
アーティスト、スーパーバイザー、プロデューサー、クライアントのための一般的なワークフローについては、私たちのプロダクトドキュメントを参照できます。
トレーニングは実データを使うべきです。実際に移行したプロジェクトから持ってきたKitsuのデータを使います。アニメーターに対して、Kitsu上で「自分の本当のタスク」「自分の本当のアセット割り当て」「自分の本当の締切情報」を見せることで、抽象的で“日々の仕事と切り離されている”感覚を取り除けます。
各部門はKitsuのチャンピオン（推進役）を指名することもできます。チャンピオンは、1週間早くトレーニングを受け、いくつかの実際の問題を解決していて、パイプラインチームが介入する必要が出る前に質問の最初の波を受けられる人です。ある中規模スタジオのリギング部門のチャンピオンは、他の誰よりもシステムを長く使っていたというだけで、最初の1週間に出た質問の80%を、チケットをエスカレーションせずに解決できることがあります。
並行期間ではFlowとKitsuの両方が稼働します。運用的には気持ち悪い（不快な）状態ですが、私たちの経験上、しばしば必要になります。
フェーズ7：並行制作と安定化
Autodesk Flowは、割り当てたエンジニアが担当する限りアクセス可能なままにしておきます。問題を診断し、必要に応じてデータを引き出せる人を用意するのです。最終納品フェーズのショットは、基本的に制作途中のショットを途中から新しいパイプラインへ引き込むのはリスクが高いため、期間中ずっとFlowのままにすることが多いです。6週間でファイナル納品する作品なら、その6週間はFlowのまま進めます。
Kitsuの連携・統合の問題はすべて専用キューにログされ、週次でパターンを確認します。大きなバージョンアップロードでKitsuのPythonクライアントがタイムアウトする、と1人のアーティストが報告したら、それはサポートチケットです。3部門から5人のアーティストが同じ週に同じことを報告した場合、それはシステム的な問題であり、おそらくサーバ設定の問題に起因するため、すぐにキューの最上位へ上げる必要があります。
移行期間中は機能凍結（feature freeze）を設ける価値があります。Kitsuに追加したくなるプレッシャーが高いとしてもです。スタジオが並行制作を開始して3週間経つと、各部門にKitsuのカスタマイズ要望が溜まってきます。新しいタスクタイプ、カスタムステータス、追加メタデータフィールドなどです。パイプラインがまだ安定化の途上にある段階でそれらを追加すると、ツールチームに“移動するターゲット”が発生し、デバッグが難しくなります。
Flowのサブスクリプションキャンセルは、すべてのアクティブなプロジェクトが移行済みであることを確認し、アーカイブされ、レビュアーがサインオフしてから行われます。
フェーズ8：非稼働化（Decommissioning）とドキュメント
「その作品はKitsuに完全に移行できた」とスーパーバイザーがサインオフすることは、TDが「アーカイブ済みのFlowデータが完全で、エクスポート可能で、復元できる」と検証することとは同じではありません。両方の確認が必要です。誰もサブスクリプション設定に触れる前に行う必要があります。
サブスクリプションが終了する前に、すべてのAutodesk Flowプロジェクトデータをポータブルな形式で完全にアーカイブしてエクスポートしてください。APIからのJSON、エンティティリストのCSVエクスポート、そしてFlowのファイルシステムに保存されている媒体のダウンロード済みバージョンです。アニメーションスタジオは、Flowインスタンスを廃止してから2年後に、「クライアントがアーカイブ済みの作品に関してバージョン履歴を要求している」ということに気づく場合があります。もし、Flowのタスクとバージョンの全記録をJSONエクスポートとして保持していれば、サブスクリプションを再アクティブ化せずにその履歴を取り出すのは簡単です。エクスポートは週末で終わり、費用はかかりません。
新しいKitsuパイプラインのドキュメントでは、エンティティモデル、タスクタイプの定義、連携ポイント、設定の場所を、新しいパイプラインTDがコードからセットアップを逆算せずに読める形式でまとめます。
移行に関する正式な ポストモーテム（振り返り）では、うまくいったこと、遅延を生んだ原因、そしてスタジオが別のやり方をできたことを記録します。そのドキュメントはスタジオ全体に配布する価値があります。制作パイプラインの移行から得られる教訓は、将来スタジオが行うすべての大きなシステム変更に当てはまるからです。
結論
ShotgridからKitsuへの移行を体系的に行うと、スタジオは支払いを抑え、自分たちのツールを理解し、制作データを自分たちで所有できるようになります。
私たちがうまくやり遂げた事例として見てきたスタジオには、共通する特徴が1つありました。それは、急を要する「移行しなければならない理由」が出る前に監査を始めていたことです。ライセンス更新が3か月先で見積書も届いたばかりだと、計画フェーズを手抜きせざるを得ないプレッシャーは非常に大きくなります。しかし、手抜きこそが移行失敗の原因になりがちです。
監査を始める最適なタイミングは今です。連携を文書化し、カスタムデータのスキーマを対応づけ、現状維持（status quo）の本当のコストを理解してください。監査で明らかになる内容によって、移行が正しい判断だと明確になるか、最初に解決すべき具体的な問題が見えてくるかのどちらかになります。
CGWireチームは、ShotGridからKitsuへ移行するスタジオに対して直接の移行支援を提供します。タイムラインを約束する前に、ぜひご相談ください。他の移行で起きた失敗から学べることは、文脈なしで計画に費やす時間のほとんどよりも価値があるはずです。
