CGWireでは、「Shotgridを離れたい」と言う一番の理由として私たちが耳にするのは、コストと複雑さです。席数ごとのライセンス、エンタープライズ向けのサポート階層、コンサルタント費用やメンテナンス費用、そして誰か別の企業が管理しているプラットフォームに組み込まれた何年分もの組織的なノウハウ……。席数40のミッドサイズのアニメーションスタジオでも、予算が簡単に膨らんでしまいます。
Kitsuは、そうした状況の代替として、静かに成熟してきた堅実なプロダクション管理トラッカーです。オープンソースで、私たちのチームが積極的に保守しており、クリーンなREST APIを中心に構築されています。さらに、ホストして自社で所有できるのもポイントです。制作チームが「実際に使いたい」と思えるのは、ワークフローを毎日変えてもらう必要があることを考えると、簡単ではありません。
問題は、FlowからKitsuへの移行が「本当の意味でのエンジニアリング案件」だということです。移行を、ショーの納品と同じくらい慎重に計画するスタジオは、コストを抑えられ、より多くのコントロールを得て、しかも自分たちが全体を把握できるパイプライン設計になります。このガイドは、最初の一歩を踏み出すために役立ちます。
設定ファイルに触れる前に、最初のタスクは「Autodesk Flowに実際に何が入っているのか」を正確に理解することです。
第1段階：監査（Audit）とアセスメント（Assessment）
多くのスタジオでは、Flowインスタンスの内部に何年分もの技術的負債が積み重がっています。特定の1つの作品のために追加されたカスタムフィールドが削除されないままになっていたり、もはや誰も使っていないワークフローを反映したパイプラインステップが残っていたり、3人別々のTDがそれぞれ別のやり方で作った連携がそのまま残っていたりします。長編映画の制作では、ショット、アセット、タスクの各エンティティにまたがって、何百ものカスタムフィールドが散らばっていることもあります。
監査は、あらゆるエンティティタイプを対象にした全量分析から始まります。プロジェクト、ショット、アセット、タスク、プレイリスト、バージョン、ノートです。FlowのPython APIならこれをスクリプト化できますし、スクリプト化しておくのが正しい判断です。なぜなら、同じコードが第3段階の移行パイプラインの一部になるからです。
並行して、Flowから読み取ったりFlowに書き込んだりするすべてのパイプラインツールを文書化する必要があります。ローダー、パブリッシャー、ステータスフック、レビュー連携、そしてカスタムのWebhook受信側。5つ以上の下流依存を持つツールは、移行リスクが高いものとして優先度を上げます。たとえば、FlowのWebhookシステムを通じてFtrackのレビュー機能、Deadlineのステータスコールバック、さらにカスタムNukeパブリッシャーを統合しているスタジオは、大きな配線（リワイヤリング）の時間を見込む必要があります。
また監査には、部門の責任者（部門長）に話を聞くことも含まれます。多くのスタジオは、耳にする内容に驚かされます。責任者は「2つ前の制作以降、入札（bidding）のツールを使わなくなった。インターフェースが遅すぎたから」などと話すことがよくありますし、ライティング部門は、Flowのバージョン比較が十分ではなかったため、レンダー版の追跡用に自前のスプレッドシートの回避策を作っているかもしれません。どの機能が「本当に使われている」のか、どの機能が「回避されている」のかを把握することで、移行に必要な努力が最小限の機能同等性（minimum feature parity）へ向かうべき場所が決まります。具体的には、エンティティ数、日あたりのAPI呼び出し量、連携のマップ、そして本当に重要な機能の一覧です。
監査が完了したら、計画フェーズではFlowにあるものを、Kitsuで作るものへ翻訳していきます。
第2段階：計画（Planning）とアーキテクチャ（Architecture）
ShotgridとKitsuは同じデータベースのスキーマを共有していないため、2つのプラットフォームのアーキテクチャを対応づける必要があります。
Flowでは、Shotエンティティが制作メタデータの多くを直接保持しています。Kitsuでは同等のデータは、Shotエンティティに置かれることもあれば、リンクされたタスクに置かれることもあり、インスタンスの設定次第でカスタム属性に置かれることもあります。ショット800、ショットあたり12種類のタスクタイプで構成される作品を移行するスタジオは、その対応づけを事前に定義しておく必要があります。
セルフホストとKitsu Cloudの選択も、ここで決まります。
セルフホストなら完全なコントロールが得られ、スケール時のコストが下がりやすく、制作データを自社のファイアウォールの内側に維持できます。これは特定市場のクライアントで要求されることがあります。その代わり、DevOpsエンジニアがデプロイ、バックアップ、稼働率（アップタイム）を担当する必要があります。
Kitsu Cloudなら、その負担を月額費用の支払いとCGWireのインフラへの依存と引き換えに取り除けます。
オンプレミスの導入は、その2つの中間を取ります：データは物理的に施設の中にあり、セキュリティポリシーの管理下に置かれます。一方で、ゼロからKubernetesの専門性を構築することなく、マネージドなハードウェアやプライベートクラウドアプライアンス上で運用することができます。
第1段階で特定したすべての連携／自動化は、書面で意思決定します：移植する（port）／置き換える（replace）／廃止する（retire）。SGTKベースのローダーは、gazu（KitsuのPython SDK）に移植するか、カスタムのKitsu Pythonクライアントとして作り直せます。レビュー機能はKitsuのネイティブなレビューエンジンに置き換えます。たった1つの作品でしか使われてこなかったWebhook受信側は、廃止してよいかもしれません。
このリストは、移行のタイムラインを決めるための工数分解（WBS）になります。「そのリストにあるすべての項目が解決され、文書化されている」状態が“完了”です。最後のショットのインポートが成功したことではありません。
データ移行のフェーズは、計画が現実とぶつかる場所です。
第3段階：データ移行
最初のステップは、すべてのエンティティタイプについて、Autodesk Flowからスクリプト化されたエクスポート手順を構築することです。ショット、アセット、タスク、バージョン、ノート、プレイリストです。
Flow REST APIを使うPythonスクリプトはここでうまく機能します。単発のスクリプトではなく、ログ付きのETLジョブとして書くと、マッピングエラーを修正した後に再実行する必要が出たときに効果が出ます。500ショットの連続番組を移行するスタジオなら、各エンティティタイプごとに別のエクスポートスクリプトを書くことになり、さらにそれぞれにフィールド対応表とバリデーション工程が必要になるはずです。
エクスポート先はCSVではなくJSONが推奨です。CSVはノートスレッドやバージョンリンクのような、移行の中心にあるネスト構造をフラット化してしまい、データ損失が静かに起きます。エンティティタイプごとにJSONファイルを1つ用意し、行数とチェックサムを記録するマニフェストファイルも同時に作れば、インポート側が動く前に突き合わせて検証できます。
タスクステータスの対応づけには特別な注意が必要です。FlowとKitsuは異なるステータス語彙を使っており、対応が1対1になることは稀だからです。たとえば、Flowのステータス「rev」（レビュー待ち）は、Kitsuでは「wfa」（承認待ち）に対応するかもしれません。しかし、Flowの「hld」（保留）はKitsuに直接の同等物がない可能性があり、そのショットがどこに着地するかについて手動で判断する必要があります。すべてのステータス、パイプラインステップ、タスクタイプには、移行スクリプトを実行する前に、共有スプレッドシートで文書化された対応づけが必要です。
単一の完了済みプロジェクトで行うパイロット移行は交渉の余地がありません。すでに「包み込まれている（ラップ済み）」プロジェクトに対してフルのインポートパイプラインを走らせることで、スキーマの不一致、エンコーディングの問題、サムネイルの欠落、壊れたノートスレッドなどを、制作上のリスクなしに発見できます。進行中のプロジェクトは、すべてのバリデーションが終わった後に最後に回します。
推奨アプローチは、ローカルのKitsuテストインスタンスを立ち上げることです。公式の cgwire/kitsu Dockerイメージを使えば、10分以内で完全に動作する環境を用意できます。
インポートスクリプトをそのインスタンスに向けてフルパイプラインを実行し、その結果をgazuで照会して、エクスポートマニフェストと差分（diff）を取ります。
データがきれいに移行できるなら、次に最も大変なのがツール層です。
第4段階：ツールと連携のリワイヤリング
ここから制作パイプラインはさらに複雑になります。たとえば、レンダーの提出のたびに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を保守しています。Shotエンティティを探すためにsgtk.platform.current_bundle().shotgun.find_one()を使っていたパブリッシャーは、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日に8回もバージョンをアップロードするアーティストが15人いるコンポジット部門は、彼らが実際に行っていることと完全に一致する内容で、Kitsuの実際のインターフェース言語を使って作られたドキュメントが必要です。ライブKitsuインスタンスのスクリーンショットは、どんな量の文章による説明よりも価値があります。
当社のプロダクトドキュメントでは、アーティスト、監督者、プロデューサー、クライアント向けの一般的なワークフローを参照できます。
トレーニングセッションでは、実際に移行したプロジェクトのリアルなKitsuデータを使うべきです。アニメータに対して、Kitsu上で「自分の実際のタスク」「実際のアセット割り当て」「実際の締切情報」を見せることで、トレーニングが日々の業務と切り離された“抽象的なもの”に感じられるのを取り除けます。
各部門はまた、Kitsuのチャンピオン（推進役）を指定することもできます。たとえば1週間早くトレーニングを受け、いくつかの現実的な問題を解決し、パイプラインチームが介入する前に最初の質問の波を受け止められる人です。あるミッドサイズスタジオのリギング部門のチャンピオンは、チケット1件もエスカレーションせずに、最初の1週間の質問の80%を解決できた——他の誰よりも長くシステムを使っていたために、それだけで済んだというケースです。
移行の重なり（オーバーラップ）の期間中は、FlowとKitsuの両方が稼働します。運用上は気持ちの悪い状態ですが、私たちの経験上、しばしば必要になります。
第7段階：並行稼働（Parallel Production）と安定化（Stabilization）
Autodesk Flowは、担当エンジニアを割り当てることでアクセス可能な状態のままにします。必要なら問題の診断をしたりデータを引き出したりできます。最終納品の段階にあるショットは、基本的に最終的な期間中はFlowのままにされることが多いです。進行中のショットをストリーム途中で新パイプラインへ引っ張るのはリスクで、単に「やる意味」があるケースは多くありません。6週間でファイナルを納品する作品は、その6週間の間Flowに置いて進めます。
すべてのKitsu連携の問題は、専用のキューに記録され、週次でパターンをレビューします。たった1人のアーティストが「KitsuのPythonクライアントが、大きなバージョンアップロードでタイムアウトする」と報告したなら、それはサポートチケットです。3部門から5人のアーティストが同じ週に同じ内容を報告したなら、それはシステム的な問題で、おそらくサーバー設定の問題に起因しているため、すぐにキューの最上位へ回す必要があります。
移行の移行ウィンドウ中の機能凍結（feature freeze）は、Kitsuへ追加したいものが多くても徹底する価値があります。スタジオが並行稼働の状態で3週間経過しているなら、各部門にはKitsuのカスタマイズのリスト（欲しいもの）があるはずです。新しいタスクタイプ、カスタムステータス、追加のメタデータフィールドなど。パイプラインがまだ安定化している段階でそうしたカスタマイズを追加すると、ツールチーム側の“動くターゲット”が増えてデバッグが難しくなります。
Flowのサブスクリプションのキャンセルは、すべての進行中プロジェクトが移行済みであることを、移行担当のレビューア（審査者）によって確認され、アーカイブされ、サインオフされた後にのみ行います。
第8段階：廃止（Decommissioning）とドキュメンテーション
「ある作品が完全にKitsuへ移った」ことに監督者がサインオフするのは、TDが「アーカイブされたFlowデータが完全で、エクスポート可能で、復元できる」ことを検証するのとは別のことです。この2つの確認は両方必要です。誰かがサブスクリプション設定に触れる前に行われるべきです。
サブスクリプションが終了する前に、すべてのAutodesk Flowプロジェクトデータを完全にアーカイブとしてエクスポートしておくべきです。持ち運べる形式で行います：APIからのJSON、エンティティリストのCSVエクスポート、そしてFlowのファイルシステムに保存されているメディアのダウンロード済みバージョンです。アニメーションスタジオは、Flowインスタンスを廃止してから2年後に「ある納品（delivery）の紛争で、アーカイブされた作品のバージョン履歴がクライアントから求められている」ことを知るかもしれません。Flowのタスクとバージョンの全レコードをJSONエクスポートとして保持していれば、サブスクリプションを再アクティブ化せずに履歴を引き出すのは簡単です。エクスポートは週末で済み、費用はかかりません。
新しいKitsuパイプラインのためのドキュメントでは、エンティティモデル、タスクタイプの定義、統合ポイント、そして構成（設定）の場所を、コードからセットアップを逆算する必要なく新しいパイプラインTDが読める形式でまとめます。
移行に関するフォーマルなポストモーテム（振り返り）では、「うまくいったこと」「遅れの原因になったこと」「スタジオがどのように別の判断ができたか」を記録します。このドキュメントはスタジオ全体に配布する価値があります。制作パイプラインの移行から得られる教訓は、将来スタジオが行うすべての大きなシステム変更に当てはまるからです。
結論
ShotgridからKitsuへの移行を体系的に進めると、コストが下がり、ツールを自分たちで理解でき、自社で制作データを所有できるスタジオが生まれます。
私たちがうまくやり切った事例として見てきたスタジオには、共通する特徴が1つありました。急いで移行したいという切実な理由が生まれる前に監査を始めていたことです。ライセンス更新が3か月先に迫っていて、見積書がようやく届いたとなると、計画フェーズで手を抜きたくなるプレッシャーは非常に大きくなります。しかし、その手抜きこそが移行失敗の理由になります。
監査を始めるのにいちばん良いタイミングは、今です。連携を文書化し、カスタムデータスキーマを対応づけ、現状維持の実際のコストを理解してください。監査で見えてくることは、移行が正しい判断であると明確にするか、先に解決すべき具体的な問題を浮き彫りにします。
CGWireチームは、ShotGridからKitsuへの移行を直接サポートします。タイムラインを確定する前に、ぜひ気軽にご連絡ください。他の移行で起きた失敗を知ることは、その文脈なしに費やす計画時間の多くより価値があります。
