Figmaは次に何をするのか？

 (robin-cannon.com)
3 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • デザインをマルチプレイヤー協業にしたという課題を解決し、この10年で最も重要なプロダクトツールの1つとなったが、重心がキャンバスからコードへ移る局面で、キャンバスに縛られた戦略的想像力という問題を抱えている
  • Figmaはデザインファイルをブラウザベースの共有空間へと変え、協業・レビュー・探索・ハンドオフを1つの画面で可能にし、Sketchを急速に時代遅れにした
  • キャンバスは視覚的な意図と動作するソフトウェアの間にある翻訳問題を扱う抽象化だが、AIがそのギャップを埋めることで、デザインシステム・API・パターンを直接コードとして解釈する実行システムへと移行しつつある
  • AIによって実行コストが安くなるにつれ、制約要因は「インターフェースを作れるか」ではなく、**「正しいインターフェースを、組織が信頼できる形で作れるか」**という調整（coordination）の問題へ移っている
  • いま再び重心が移るなかで、Figmaがキャンバスを拡張して次の時代を取り込もうとする試みはイノベーターのジレンマにあたり、真実へ向かう協業インターフェースへ転換できるかが核心となる（incumbent trap）

Figmaが最初に勝った方法

  • Figmaの最初の成果は技術的なもので、ブラウザをデザインにおいて誰も実現可能だと思っていなかったほど重要なものにした
    • クロスプラットフォームのアクセシビリティ、性能、マルチプレイヤーのすべてが重要に作用した
  • より深い変化は文化的な次元にある
    • Figma以前、協業はローカルファイル、レッドライン、PDF、そして「これが正しいバージョンか？」と確認する会議へと断片化していた
    • Figmaはその距離を崩壊させ、単により良いキャンバスではなく、**より良い調整モデル（coordination model）**を提供した
  • ただし抽象化はあくまで抽象化であり、キャンバスはプロダクトではなく**表現（representation）**にすぎず、実際のプロダクトはコードの中に存在する
    • キャンバスは、実装コストが高くなる前に思考を助ける道具だったが、視覚的な意図と動作するソフトウェアのあいだに大きな隔たりがある世界に依存していた
    • AIがその距離を崩壊させつつある

キャンバスは翻訳問題への答え

  • キャンバスモデルは明確な役割分担の上に成り立っている
    • デザイナーは意図を表現し、エンジニアは意図をコードへ翻訳し、プロダクトマネージャーは優先順位と範囲を調整する
    • 想像したものを使って、実際にリリースするものを作る
  • このモデルはすぐには消えず、多くの組織が今後も数年にわたりこのやり方で働く可能性がある
  • しかし進む方向は変わっている
    • Design-to-codeは速くなったが、それは既存の作業方式（ハンドオフ・翻訳）をただより速く圧縮したにすぎない
    • 本当に異なるのは、構造化されたデザイン・プロダクト文脈、コンポーネントコード、ルールが直接コード化された動作インターフェースとして解釈されることだ
    • プロンプトがデザインシステム・API・パターン・エンジニアリング制約にアクセスできるなら、もはや白紙から始める必要はない
  • ここでデザインは**AI実行システムが使うコンテキスト（context）**になる
    • チームには依然として視覚的比較・レビュー、ビジネス上の意思決定のための共有空間が必要だ
    • ターミナルウィンドウやIDEは、多数の利害関係者が参加する場ではない
    • それでも、だからといってこれがキャンバス中心になるわけではない

再びキャンバスへ

  • Figmaの最近の動きは、現在の強みに基づいていると考えれば理解できる
    • より多くの作業がFigmaで行われ、より多くの成果物がFigmaから生まれ、ワークフローがFigmaへ戻り、プロダクト開発がFigmaエコシステム内で行われるべきだという方向性だ
  • 極端に単純化すれば、その戦略は**「すべてをキャンバスへ、私たちのキャンバスへ戻す」**ように見える
    • しかし次の時代は、その軸では組織されない
  • **"code-to-canvas"**がそれを示している — 実際の成果物を作ったあと、それを編集可能なフレームとしてFigmaへ持ち戻すやり方だ
    • 短期的な協業の問題は解決できるかもしれないが、方向性としては不自然で、未来に対しては誤っている
    • Figmaは、協業がどう機能するかを知っている自分の部屋へユーザーを戻すことにより関心を払い、それが未来にとって正しい協業モデルかどうかにはあまり関心を払っていない

キャンバスは真実の源泉ではない

  • Figmaが現実を反映する協業インターフェース、つまり**レンズ（lens）**として、より説得力のある未来へ向かう可能性もある
    • 動作するシステムを点検し、派生形を比較し、実物に注釈を付け、デザインシステムのドリフトを確認し、方向づけと制御を行う場所になり得る
  • ただしそれは、キャンバスがもはや中心ではないと受け入れることを意味する
    • キャンバスが重要であり続けるには、ただ真実へ向かうインターフェースとしてのみ可能だ
    • ここでいう真実とは、コード、ランタイム、実際に存在し、実際にリリースされるものだ
  • Figmaのリスクは、すべてを古いモデルを通過させて中心を維持しようとすることにあり、これは**incumbent trap（既存強者の罠）**にあたる
    • 最初に支配力を生み出したものを見つめ、それだけを改善する行為であり、競争の基準が変わる瞬間までしか正しくない
    • Figmaは重心が変わり得ることを理解してSketchに勝ったが、いまその中心は再び移動しており、イノベーターのジレンマの反対側に立っている

実行は安く、調整はそうではない

  • AIは実行をより安くする — 無料ではないが、実務者の視点ではそう感じられるかもしれない
    • AIは画面をスキャフォールドし、コンポーネントを使い、接続し、リファクタリングし、派生案を提示し、従来のボトルネックを書き換える速度で生成する
  • したがって制約要因は「インターフェースを作れるか」ではなく、**「正しい基準・ユーザー・組織的信頼のもとで、正しいインターフェースを作れるか」**である
    • AI支援による調整は、キャンバス抽象化の中での協業と同じではなく、構造化され、優先順位づけされたコンテキストを必要とする
  • 判断が必要な問いがある
    • どのコンポーネントが承認されているのか、どのパターンが廃止されたのか
    • 文書・コード・Figmaが互いに食い違うとき、どの実装が権威を持つのか
    • どのアクセシビリティルールが適用されるのか、どの規制上の制約が重要なのか、どのエンジニアリング標準が妥協不能なのか
    • これはキャンバスの問題ではなく、インフラの問題だ
  • この世界ではデザインシステムがさらに重要になる
    • コンポーネントライブラリやアセット保管庫、人が手動で参照する文書ではなく、組織がどう作るかをAIシステムに伝える**実行可能な知能（executable intelligence）**である
    • キャンバスは配置し、レビューを促すことはできるが、プロダクト提供の制御レイヤーと深く結びついていなければ、実態は別の場所にあり、キャンバスはきれいな絵にとどまる危険がある（戦略的問題）

Figmaが信じているように見えること

  • 外から見ると、Figmaはキャンバスを拡張して次の時代を取り込めると信じているように見える
    • これは外部からの解釈にすぎないかもしれず、Figmaには変化を理解するインセンティブを持つ賢い人が多く、商業的に巧みな判断なのかもしれない
    • ただしそれは、それが次の時代の仕事にとって正しいプロダクトモデルであることを意味しない
  • プロダクト戦略は態度を表し、Figmaの態度はキャンバスへの回帰に集中しているように見える
    • 生成された作業を持ち戻し、コードの成果物を持ち戻し、開発者をFigmaへ連れてきて、AIをキャンバスへ連れてくる
    • 組織のより多くの部分を、Figmaが所有する場所の中へ入れる
  • これは必ずしも愚かではない
    • 企業は歴史的に**統合（consolidation）**を好み、人々はFigmaに慣れており、市場支配から生まれる重力が存在する
    • Figmaは有用な機能を追加し続けられるが、重要なのは、それらの機能が、動作する成果物と組織的コンテキストがデザインファイルより重要になる世界への適応を助けるかどうかだ
    • Figmaの賭けは「そうだ。なぜならそのすべては結局Figmaに戻ってくるからだ」であり、これはキャンバスが中核だという賭けである

私たちが働く空間が変わるなら

  • 次に支配的になるプロダクトワークスペースは、AI機能がさらに付いたFigmaのようなものにはならず、従来のデザインツールのようにもならない
    • より可能性が高い形は、空間的協業を備えたIDE、あるいはライブソフトウェアを直接編集・点検・デプロイできるブラウザベースのプロダクト環境だ
    • デザインシステム・リポジトリ・文書・分析・プロダクト管理ツールを横断するAIオーケストレーション層が必要になる
    • キャンバス、コードエディタ、ステージング環境、ガバナンスおよびルールシステムの統合形態だ
  • このような形は、最初は悪く見えるだろう
    • 正しいものの初期バージョンは、過去の成熟したバージョンより悪く見えるもので、不格好で不完全で、無視しやすい
    • Figmaはこれを誰より理解しているべきだ — 前のラウンドで勝てた理由が、より良いデザインツールではなく、仕事のための別の環境だったからだ
  • キャンバスは不可欠なままでいられるかもしれないが、抽象化としてのキャンバスはそうではない
    • キャンバスは現実を平坦化する場所ではなく、現実を議論する場所であるべきだ（難しく、興味深い問題）

Figmaは次に何をするのか

  • 3つの経路がある

  • 防御的経路

    • キャンバスを引き続き拡張し、ますます多くの作業がFigma内で行われるように構築する
    • 有用な機能と強い売上を生み、支配的地位からさらに粘着性を高め、深く定着できる

  • 移行的経路

    • キャンバスをより**コード認識的（code-aware）**かつインタラクティブにし、より良い生成・ワークフロー・インポート・エクスポートを提供する
    • 現在のFigmaの動きはここにあり、非常に有用ではあるが、なおキャンバスをプロダクト環境の軸として組織している

  • ピボット経路

    • キャンバスとFigmaが真実の中心ではないと受け入れ、その真実へ向かう最良の協業インターフェースの1つになるよう構築する
    • コード・プロダクト文脈・デザインシステム・ライブな動作を実際の仕事として扱い、キャンバスはすでに生きているシステムを視覚的に推論するための1つのビュー（view）とする
    • Figmaがこのピボットを望んでいるかは不明だ
  • 戦略的変化とは、未来を見通すことというより、現在の事業を成立させている前提を捨てることに関する問題だ
    • マルチプレイヤーデザインは消えず、依然として重要だ
    • 重要なのは、コードにはるかに近い場所で生成・修正・レビュー・リリースできるようになったとき、その仕事がどこに存在するのかということだ
    • Figmaは前回の重心の変化を理解していた。そしていま、その重心は再び移動している

関連記事

1件のコメント

 
shakespeares 4 시간 전

選択肢があまりにも多くなり、方向性を見失っているようで悲しいですね。
未来を見通すことが、これほど重要だとは。