前回、7人のAIネイティブなデザイナーがいても、AIネイティブなチームにはならないと論じました。一人ひとりは速くなっても、その周りの調整はまったく動かず、チームはむしろ最初より断片化していきます。
私自身のチームを含め、多くのチームが、デザイナーにツールを渡して自由に触らせ、学びを共有させるだけで満足してしまっている——それが、この話を書き続けている理由です。それは個人のスキル形成でしかありません。チーム全体をどう連れていくか。それが、私自身に問い続けている問いであり、次に率いるチームで持ち込みたいことです。
自然な反応は、標準化です。すでに走っているプロセスの、あらゆる段階にAIを入れる。リサーチ統合にはLLM、コンセプトにはFigma Make、プロトタイプにはClaude CodeやCursor、ハンドオフにはコードベースにつないだFigma。
そのどれもが、実際に改善です。しかし、それらを合わせても、以前と同じプロセスが、少し速く回っているだけです。
私たちの多くが走らせているデザインプロセスは、「ものを作ることが高くつく」世界のために作られています。リサーチ、統合、要件定義、Figma、プロトタイプ、レビュー、ハンドオフ、実装、QA。各機能が成果物を生み出し、次の機能へ渡す。プロダクトが要件を書き、デザインがそれを解釈し、エンジニアリングがデザインを解釈し、QAが実装を解釈する。すべてのハンドオフは翻訳であり、すべての翻訳は何かを失います。
いま私たちがやっているのは、箱を自動化して、箱と箱をつなぐ矢印はそのままにしておくことです。
AIは、組織がすでに持っているものを増幅します
AI支援ソフトウェア開発に関するDORAのリサーチは、デザインリーダーが向き合うべきある事実にたどり着いています。AIは増幅装置として働きます。組織の強い能力を拡大し、まったく同じ効率で機能不全も拡大します。個人レベルの成果は、下流のテスト、セキュリティレビュー、デプロイ、手戻りの中に飲み込まれていきます。
デザインには、まさにこの問題があり、ほとんどの場合、それを直視していません。2時間で作られたコード付きプロトタイプは、エンジニアリングがそれを検証するのに2日かかり、コンポーネントが間違っていて、状態の半分が抜けていて、実際のアーキテクチャに耐えられないと分かるなら、成果とは呼べません。最初の成果物は速く届きました。プロダクトは、速く届いていません。
さらに言えば、AI以前からハンドオフが不明瞭だったなら、いまはその不明瞭さが、より大きな量で起きているだけです。デザインとエンジニアリングがプロトタイプの意味について食い違っていたなら、その食い違いは、スプリントに一度ではなく、週に四回起きるようになっています。断片化は、速く動いたことの副作用ではありません。もともとあった機能不全が、増幅されているだけです。
実際のワークフローをマッピングする
デザインワークフロー再設計は、ツールから始まりません。顧客の課題からプロダクションに至るまで、一つの実際の仕事がどう流れているかをマッピングすることから始まります。スライドに描かれたプロセスではありません。実際に人々が従っている、誰も文書化していない部分も含めたプロセスです。
仕事はどこで滞留しているか。情報は、どこで見つからずに再作成されているか。エンジニアリングは、どこでファイルからデザインの意図を逆算しているか。どの意思決定が、誰も所有していないために5人がかりになっているか。どんな知見が、Slackのスレッドや、誰も記録していない会議、あるいは一人のデザイナー個人のプロンプト集の中に閉じ込められているか。
そのうえで、一つひとつの活動について、何を廃止すべきか、何が十分に構造化されていて自動化できるか、AIは何を所有せずに改善できるか、何をまったく別の役割に移すべきかを問うていきます。狙いは、すべてのステップにツールを取り付けることではありません。消えるべきステップ、統合されるべきステップ、前倒しされるべきステップ、あるいは今とはまったく違う成果物を生むべきステップを見つけることです。
多くのチームがこれを飛ばすのは、地味で、誰も口にしたくないことを露わにしてしまうからです。だからこそ、これが効くのです。
実物を使って、共に学ぶ
Atlassianは2026年に「AI Builders Week」を実施しました。1,400人のデザイナーとプロダクトマネージャーが、理論を語るのをやめて、実際に作りました。31のセッション、100人を超える登壇者・メンター、参加者の96%が肯定的に評価しました。後半のラウンドは、基礎的なスキルを超えて、実際のワークフロー変化と測定可能な成果に踏み込んでいます。
そこで重要な数字は、1,400という参加人数ではありません。人々が、守られた時間の中で、実際の問題に取り組み、助けてくれる人たちと共に、失敗する許可を持って働いたということです。4日間で組織は変革されません。しかし、どの新しい働き方が残す価値があるかは、はっきりと浮かび上がってきます。
これが、私が縮小して採用したいモデルです。号令ではありません。実際のプロジェクト一つに絞った、本物の顧客価値と、管理可能なリスクと、ある程度成熟したデザインシステムの一部と、実際に違うやり方で働きたいと思っているプロダクト・エンジニアリングのパートナーを備えた、一つの横断的なパイロットです。
そして、始める前に仮説を書き留めておきます。たとえば——共有され、システムに整合したコードプロトタイプから始めることで、レビュー負荷や不具合を増やすことなく、より早く顧客の学びに到達し、実装の手戻りを減らせる、といった具合です。
それが実験です。「今四半期は全員Cursorを使うべきだ」は、プレスリリースにすぎません。
コードで書かれた成果物はすべて同じ、と思い込むのをやめよう
デザインとエンジニアリングのあいだで繰り返し起きる衝突は、ほとんどの場合、語彙の問題です。デザイナーがCursorで作った何かを渡す。エンジニアリングは、それがスケッチなのか、提案なのか、出荷を期待されているものなのか分かりません。だから、それを軽視するか、プロダクションコードとして評価するのに2日を費やすか、どちらかになります。どちらも高くつきます。
私のチームのあるデザイナーは、2日でプロトタイプを作り、「私が言いたいのはこういうことです」という意味でエンジニアリングに送りました。エンジニアリングはそれを実装提案として受け取り、アーキテクチャ、コンポーネント、状態管理のレビューに一週間を費やしました。彼女はスケッチのつもりでした。彼らは仕様書として受け取りました。問題はコードではありませんでした。そのコードが何であるべきかについて、共有された言葉を持っていなかったことです。
デザイナーは、いまコードを生み出しています。それが何のためのものか、ほとんど誰も合意していません。私は5つのレベルに名前をつけ、チームにそれを声に出して使わせています。
1. 思考の成果物。 使い捨て。アイデアを探るために作られ、使ったら捨てる。
2. 体験プロトタイプ。 顧客やチームが、そのインタラクションから何かを学べるだけのリアリティがある。
3. システム整合プロトタイプ。 実際のコンポーネント、トークン、パターン、アクセシビリティ要件を使って作られている。
4. エンジニアリング対応の成果物。 実環境で動作し、重要な状態を扱い、エンジニアリングに信頼できる出発点を与える。
5. プロダクションへの貢献。 他のあらゆるコードと同じアーキテクチャ、テスト、セキュリティ、アクセシビリティ、パフォーマンス、レビューの基準を満たしている。
全員がレベル5で作業する必要はありません。チームに必要なのは、いまどのレベルを見ているかを推測しなくて済むことです。何かを渡すときに、その番号を口にするだけで、摩擦のほとんどは消えます。
レベル3と4が本当に難しいところであり、それはデザインシステムがどれだけ成熟しているかに完全に依存します。整合の取れていないデザインシステムをエージェントにつなぐことは、そのシステムを直すことにはなりません。不整合を、より速く、より大きな規模で、プロダクションの中で再生産するだけです。この問題は大きすぎるので、次回、それだけで一本書きます。
人ではなく、ワークフローを測る
AIの影響を測っているチームのほとんどは、間違った単位を測っています。個々のデザイナーが速くなったと感じるかどうかを追っていますが、これはほぼ確実に人を誤らせる数字です。2025年のランダム化研究で、METRは、2025年初期のAIツールを使った経験豊富なオープンソース開発者が、実際には19%長い時間をかけていたにもかかわらず、自分は速くなったと信じていたことを発見しました。新しいツールは改善されており、結果はタスクや人によって異なりますが、残しておくべき発見は、体感速度と実際の速度のあいだのギャップです。
これを、前回引用したハーバードのリサーチと並べてみましょう。GPT-4を使ったコンサルタントは、モデルの得意領域の中では25%速く終わり、その外では悪化していました。どちらも真実です。個人レベルの高速化は本物であり、一貫性がなく、タスク依存で、それを体感している本人にはほとんど見えません。だからこそ、デザイナーではなくワークフローを測るべきだ、という議論全体が成り立つのです。
だから、現実との接触に耐えて残るものを測ってください。顧客の証拠に、より早くたどり着けたか。レビュー時間は減ったか。エンジニアリングの手戻りは減ったか。品質は向上したか。ツールのコストはいくらだったか。チームは、来四半期にも使える何を学んだか。
一つの箱の中のスピードは、これまで一度も本当の指標ではありませんでした。
パイロットのアウトプットは、あなたの手元に残るシステムです
コンサルティング会社も、100枚のスライドの変革プランも必要ありません。一つのプロジェクトから始めてください。先進的な採用者と、まだ足場を固めている段階の人たちをペアにする。プロトタイプが固まる前にエンジニアリングを巻き込む。ツールのデモではなく、ワークフローレビューを行う。失敗したプロンプト、足りなかったコンテキスト、繰り返し行った修正、そして依然として人間を必要とした意思決定を書き留める。
そして、うまくいったものを残してください。
Vercelは、承認されたプロダクトの意思決定を、コードと同じように扱い始めています。彼らのエージェントは、プロダクトに紐づいたプロダクト判断、インターフェース品質のガイダンス、インタラクションパターン、実例、リントルール、評価にアクセスできます。どの学びを標準にするかは、依然として人が決めています。
これこそが、本当の成果物です。機能ではありません。あとに残るシステムです。共有されたプロセス、より広いデザインシステムのカバレッジ、明確な意思決定権限、エージェントのための再利用可能なコンテキスト、既知の失敗パターン、明示的な品質ゲート、そして、デザインがエンジニアリングに対して何を負っているかについての、実際の合意。
プロセスを再設計することは、デザイナーをそこから排除することではありません。引き継がれてきた作業を取り除き、いまも人間を必要とする部分に集中できるようにすることです。顧客を理解すること。正しい問いを立てること。重要な判断を下すこと。良いとは何かを決めること。
AIがデザインプロセスのどこに当てはまるかを問うのは、もうやめましょう。
いまAIが存在する中で、どんなデザインプロセスが可能かを問いましょう。
