優れたチームの共通点は「さまざまな職種が柔軟に協働していたこと」
Kenさん（以下、Ken）：キャリアの初期に、Macromedia、Adobe、Mediumでエンジニアリングチームを率い、さらにご自身の会社も立ち上げていますが、そうした経歴を経て、どのようにしてエンジニアリングからプロダクトへと軸足を移していったのでしょうか。
Shoさん（以下、Sho）：私はキャリアの最初はエンジニアとしてスタートしましたが、もともとずっと「プロダクト」が好きだったんです。
朝起きて歯を磨く前から「このアルゴリズムをもっと速くするにはどうすれば良いか」「より美しいコードを書くにはどうすればいいか」と頭を巡らす人っていますよね。ですが私はそうではなくて、「このプロダクトでこんなことができたらどうだろう」「ユーザーはこんな機能を求めているんじゃないか」「このボタンをここに移したらもっと使いやすいかも」といったことばかりを考えているタイプでした。
Macromedia（※1）では、エンジニアリングチームがプロダクトの方向性に強く関わる文化がありました。実際、次のバージョンでどんな機能を入れるか、そのロードマップを決めていたのはエンジニアリングです。通常こうした役割はプロダクトマネジメントの担当領域ですが、Macromediaではプロダクトマネジメントはどちらかというとビジネス寄りで、市場規模を分析したり、予測を立てたりする役割だったんです。
（※1）MacromediaはFlashなどのWeb技術で知られたソフトウェア企業。2005年にAdobeが買収。
エンジニアが「この機能を作ろう」と決めていたのは、当時としては珍しいスタイルでした。Adobeに転職してからも、エンジニアでありながら、ある種プロダクト的な視点で私は関わっていたと思います。
そしてFigmaに加わったときは、まだチームがとても小さく、プロダクトマネージャーがいない状態でした。アメリカでは一般的に、10人規模のスタートアップではCEOがプロダクトリーダーを兼ねることが多いのですが、会社が成長していくなかで、明確なプロダクトリーダーシップが必要になってきました。そのタイミングで、私はプロダクト開発を担う役割に移ることになったんです。
Ken：エンジニアでありながらプロダクトマネージャーのように考えていた経験が、実際のプロダクト開発でどのように生かされているのでしょうか。特にFigmaは、エンジニアリングとデザインの結びつきが非常に強いのではないかと想像しています。
Sho：まず、私が考える「理想的なチームのありかた」についてお話ししたあと、Figmaや自分が関わってきたプロダクトについても触れたいと思います。
もちろん前提として、会社ごとに文化は異なりますし、ソフトウェアの種類によって最適な進め方も違うと思いますが、それでも私がこれまで関わった優れたチームに共通していたのは、エンジニア、デザイナー、プロジェクトマネージャーがとても柔軟に協働していたという点です。
誰も「それは自分の仕事じゃない」とは言いません。エンジニアが「こんなアイデアを思いついたんだけど」と提案することもあれば、プロダクトマネージャーが「これ、そんなに遅くなくてもいいんじゃない？ この情報をどこかのデータベースにキャッシュしておいたらどうだろう？」と技術的な提案をすることもあります。そんなふうに、プロダクトマネージャーがエンジニアリングのアイデアを出すこともあれば、エンジニアがデザインの発想を提案することも、もちろんデザイナーがプロダクトの方向性を考えることもあります。
それらをふまえると、私が「最高のチームだった」と感じたのは、誰も自分の職域にとらわれず、思いついたアイデアを自由に出し合えるチームですね。そうやって互いの領域をまたいで協働する——。それが、私の理想の働き方なんです。
特にFigmaは、本当に開発が難しいプロダクトだと思います。なぜなら、プロダクト、デザイン、エンジニアリングのアイデアそれぞれが、すべて密接に結びついているからです。
知っている方も多いと思いますが、Figmaはドローイングツールとして始まりました。しかし今では、コンポーネント、変数（variables）、パラメータ、バリアントなど、非常に技術的な要素を多く備えています。そのため新しい機能を考えるときには、エンジニアのように発想する必要もあるのです。「この変数で新しいタイプの値を扱えるようにしたらどうか」と考えた瞬間、その変更がシステム全体にどう影響するかを想定しなければなりません。
そして、Figmaが現在のような大きな会社となった今では、その影響範囲はさらに広がっています。例えば「コンポーネントのこの機能を変えたら、Figma SlidesやFigma Makeをはじめとしたほかの製品全体にどう影響するのか？」というように、常に全体の構造を見渡すことが不可欠です。
目指すのは、「デザイン」「コード」「AI」を自由に行き来できる未来
Ken：FigmaはAIをどのように捉えているのか、教えていただけますか？
Sho：AIは本当にワクワクする分野です。AIによって、これほどまでに業界が急速に変化していることが信じられませんし、ここまで劇的な変化を目にしたのは、Webの誕生以来だと思います。
これまでも、モバイルやブロックチェーンなど、さまざまな技術的な波がありました。ですがそのどれもが、AIほどのインパクトを持ってはいなかった。AIは、すでにそれに匹敵する、あるいはそれ以上の変化を起こしていると感じています。
とはいえ、AIの領域は発展途上で、「これは本物だ」と言える部分もあれば、「まだ少し早いかもしれない」と感じる部分もある。それでも進化のスピードがあまりに速く、1年後にはまったく違う世界が見えているはずです。本当にエキサイティングな時代ですよね。
デザインの世界でも大きな変化が起きていると思いますが、いちばんのポイントは「自分のアイデアをどう表現するか」を人々が根本から見直し始めている点。そもそもデザインとは、アイデアを生み出し、それを考え抜き、他者と共有し、議論を重ねながら最良の形を見つけていくプロセス。それは、ユーザーインターフェースでも、ビジュアルデザインでも、変わりません。
ただ以前までは、そういったプロセスをもっとも早く進める方法は「描くこと」でした。SketchやFigma、Illustratorといったツールを使って画面上でモックを描き、それをもとに議論してきたわけですが、現在はAIを活用してコードを書くことも同じくらい速くなっています。
例えば「こんなアプリを作りたい」とAIにプロンプトを入力すれば、大規模言語モデル（LLM）がコードを生成し、それを通じて自分のアイデアを可視化できる。そのコードをもとに他の人と話したり、何度も試行錯誤しながらアイデアを磨いていったりできます。AIはこうして、デザインを探求するまったく新しい方法を切り開いているのです。
私たちは「Figma Make」というプロダクトでこの領域に取り組んでいますが、同じようにほかの企業も自社ツールでAI活用を模索しています。
なかでもとても興味深いのは、それによってあらゆるものの「作りかたそのもの」が変わり始めていることです。ではこの流れが、最終的にどこへ向かうのか──。私たちが考えているのは、人々がAIにプロンプトを与えるだけでなく、自分の手でコードを書いたり、デザインを直接操作したりといったプロセスを自在に行き来できるようになる未来です。
例えば、「こういう機能を持つアプリを作って」とAIに指示すると、AIが最初のバージョンを生成してくれる。それを見て自分でコードを少し修正し、「このデザインはいまいちだな」と思えば、マウスで要素を動かしたり、色を変えたりする。そしてまたAIに「今度はこう動くようにして」と指示を出す——。こうしたやりとりを何度も往復しながら、デザイン、コード、AIの間を自由に行き来できる。それこそが、私たちが理想と考える新しい制作ワークフローなんです。
AIだからこそ目を向けている「短期的」なマイルストーン
Ken：Figmaには、新しいテクノロジーを調査・研究して、それを製品に反映させるR&D（研究開発）チームのような組織はあるのでしょうか。また最新の技術トレンドをキャッチアップするための体制について教えてください。
Sho：Figmaでは、どちらにも対応できる組織を持っています。AIの研究体制で言うと、最初は多くの企業と同じように「AI専任の部門」を設けてスタートしました。そのチームは自社モデルの開発に取り組む一方、他社のモデルを研究し、業界最先端の動向を把握するなど、幅広くAIの可能性を探っていました。やがてその取り組みが発展し、現在では各チームにAIが組み込まれている形になっています。
例えば、エディターチームの中にはエディター専任のAI担当がいますし、FigJamのチームにもAIが組み込まれています。つまり、プロダクトごとにAIを活用するチームが存在している状態です。さらに、Figma全体を支えるAIリサーチチームとAIインフラストラクチャーチームもあり、全社的な基盤づくりや技術支援を担っています。
Ken：そのようなAIチームが新しい成果を発表して、それをロードマップに反映するのはどれくらいの頻度で行われているのですか？
Sho：厳密には、それほどフォーマルな進めかたはありません。Figmaはもともと、「おもしろそうなことを見つけたらまず試してみる」「一緒にコラボレーションして、繰り返し改善していく」という文化の会社。だからこそ、プロセスはいつも少し「混沌としている」んです。
AIに関しては特にそれが当てはまりますね。6か月先までのロードマップを立て「これを半年かけて進めよう」と決めても、1か月後には状況が変わっているかもしれない。そのため私たちは、もっと短期的なマイルストーンに目を向けています。「今、何を達成したいのか」「最大のボトルネックは何か」を常に見極め、できるだけ早くそれを解消する。ときには短期的な解決策と長期的なものの両方を並行して考えることもあります。
ただ、私たちが言う「短期」とは2週間くらいで、「長期」は1か月半くらいの期間。1年単位の計画ではなく、もっと短いサイクルで動いているのです。
