要約

  • 接続済みフォルダーでは双方が自社の有料シートを使うが、接続を切ると原本はホストに残り、外部チームは中のファイルへのアクセスを失う。
  • コピーの送付では、コメント、バージョン履歴、ブランチは原本側に残る。画面を受け取っても、設計の経緯まで届くとは限らない。
  • ライブラリを移転対象に含めなければ、移転したファイルは更新を受け取れない。ライブラリを移せば、送り手側に残るファイルへの更新が止まる。

Figmaが接続済みフォルダーの説明に用意している別れ方は、驚くほどそっけない。接続を切った後、ホストは何もしなくてもよい。フォルダーは手元に残り、外部チームは中のファイルに入れなくなる。コピーを送るか、後から移転するかは、そこから先の操作になる。

これは揉めた案件の顛末ではなく、Figmaが公開している製品仕様だ。仕事を始めるための接続承認は両社に求める一方、終わった後の原本の置き場所は最初に決まっている。両社が自分のシート代を払っていても、最後に資料棚の前に立つのは片方だけである。

発注担当が買うのは完成した画面か、それとも次の担当者が直せる設計か。この差を曖昧にすると、「ファイルは全部送りました」と「これでは保守を引き継げません」は両立してしまう。コピーは届いている。だが、変更を配る元の部品庫は別の管理下にある。Figmaの公開手順を接続解除、コピー、ライブラリの順に読むと、その食い違いがどこで生まれるかを追える。

独立した保守を買うなら、納品の終点はファイル受信ではなく、受け手が次の変更を実行できる状態に置くべきだ。ホストを誰にするかは、その終点から逆算する。最初に招待メールを送った会社へ、成り行きで将来の保守まで預ける必要はない。

どちらも切断できる。その後は同じではない

Figmaの接続済みフォルダーの説明では、双方の有料プランと管理者の承認が必要になる。編集には適切なシートに加え、そのファイルの編集権限も要る。料金を払うことと、どのファイルを扱えるかは別に設定される。

ホストはセキュリティーやプライバシー、利用可能な機能、外部に提供するライブラリを管理する。両者ともファイルを作成したり、中へ移したりできるが、外へ取り出せるのはホスト側の人だけだ。

接続の切断はどちらの管理者でもできる。しかし切断後、フォルダーはホスト側に残り、外部チームは中の全ファイルへアクセスできなくなる。ホストはそのままにすることも、コピーを送ることも、後から移転することもできる。

退出する権利は両方にある。退出後に原本の前に立っているのは片方である。会議室から出るボタンと、資料を持ち帰る権限は同じではない。

だからホストは、先に設定画面を開いた人に任せるだけの役割ではない。発注側が長期にわたり自力で保守するのか、制作会社が運用を続けるのか。最後に必要な形を、最初の配置に反映させたい。最終請求と最後の修正が重なってから鍵の話を始めると、単純な設定が交渉材料になる。

コピーには、設計の会話がついてこない

Figmaのフォルダーとチームの移転手順は、原本の移転とコピーの送付を区別している。コピーではコメント、バージョン履歴、ブランチが原本側に残る。

新しい担当者が知りたいのは現在の見た目だけではない。なぜこの配置になったのか、どの例外を残したのか、なぜ前の案を捨てたのか。答えが過去の議論や版にあるなら、それを持たない側は再び調べることになる。納品ファイル数は正しくても、理解する費用は違ってくる。

フォルダーの受け入れはProfessional、Organization、Enterpriseで可能だが、チーム全体の移転先はOrganizationまたはEnterpriseとなる。ファイルとプロトタイプの元のリンクは引き続き使え、フォルダーとチームには新しいリンクが付く。こうした結果の差を「一式納品」という一言に押し込むのは雑だ。

顧客との共同作業ガイドには、ローカルコピーを保存して別アカウントへ取り込む方法もある。ただし、元のチームライブラリの更新は引き継がれない。ダウンロード完了は、将来の修正経路まで届いたという通知ではない。

共通の部品庫を一社に丸ごと渡せるか

Figmaのライブラリは、コンポーネント、スタイル、変数を一つのソースファイルにまとめ、別のファイルで再利用する仕組みだ。制作会社にとっては、案件ごとに同じボタンや色設定を作り直さずに済む、実用的な蓄積である。

この蓄積が複数の案件を支えていると、移転の範囲が難しくなる。ライブラリを含めずにファイルを移せば、部品は最後の状態のまま残り、更新を受け取らなくなる。公開済みライブラリそのものを移せば、元のチームや組織に残ったファイルが更新を受け取れなくなる。

一社への納品を完成させるために、他の案件にも料理を出す厨房を丸ごと運ぶわけにはいかない。反対に、出来上がった皿だけを渡し、発注側が明日から調理もできると思わせるのも困る。

顧客専用の資産、制作会社の共通資産、今後提供する保守を分ける必要がある。接続済みフォルダーでホストがライブラリを利用可能にした場合、そのソースファイルについて与えられるのは閲覧権限だ。部品をページに使えることと、部品の元を直せることには差がある。

判断の分かれ目は、発注側が今後の変更を誰に任せるかだ。制作会社へ継続して頼むなら、共通ライブラリを残して保守サービスとして買えばよい。必要な更新を誰が公開し、いつまで提供するかを合意する。ファイルの受信だけで契約を閉じれば、その義務が抜け落ちる。

社内チームや別の制作会社が独立して保守するなら、顧客専用のソースと管理権限を受け取るか、独立したコピーを今後自分で育てるかを選ぶ。共通ライブラリが他案件にも使われているなら、丸ごとの移転は他の使用先への更新を止めるため、専用部分を分ける設計が必要になる。独立コピーを選ぶ場合は、元のライブラリの改善が自動で届かないことを保守予算に織り込む。ここまで決めれば、「一式」の中身はようやく値付けできる。

次の変更が届いて初めて分かる

ライブラリの置き換えでは、別の公開済みライブラリの資産へファイルをつなぎ直せる。Figmaは名前で対応を探す。一致するものがない資産は置き換わらず、元のライブラリへの接続が残る。見た目が似ていることや、名前を変えて作り直したことでは自動的に対応しない。

移行報告には、置き換わったものと残ったものの両方が必要だ。同じ名前でも意図した部品かを確認する。画面が一様に見えても、保守の経路は二つに割れているかもしれない。スクリーンショットはこの種の不均一さを上手に隠す。

更新の確認と受け入れは編集権限のある人が行う。合意したソースから代表的な変更を公開し、受け手の実際の権限で使用先ファイルに反映させる。この一往復は、古い画面が開くことより強い引き継ぎの証拠になる。

個別の引き継ぎ費用を算出するには、実際のホスト、依存関係、合意した納品範囲が必要だ。その三つがそろえば、継続保守への支払いなのか、独立した原本の受け渡しなのか、コピーを育て直す費用なのかを分けられる。

独立を買ったのに、次の修正を公開するたびに前の制作会社の承認が要るなら、引き継ぎは終わっていない。継続サービスを買ったのなら、その依存には担当者と約束した仕事が必要だ。席は両社が用意できる。納品で決着させるべきなのは、明日の仕事に使う鍵の行き先である。