- デザインとデリバリーの間にある壁
- AIが動かしたのは仕事と、信頼できる情報源
- デザインの力では抜け出せなかった、Figmaの二つの問題
- いまのやり方:デザインはGitの中にある
- AIが取り除いたのは雑務であって、理解する必要ではない
- このシリーズについて
Figmaのページに 240711 と名前を付けたことがあるなら、念のためにフレームを複製してから手を入れたことがあるなら、あるいは誰かの変更で自分の画面が壊れないように、ファイルの中にコンポーネントライブラリの自分用コピーを置いていたことがあるなら、あなたはバージョン管理システムを手作業で作っていたことになります。
私は三つともやってきました。この4年ほどの大半、何が、いつ、なぜ変わったのかを追うための方法は、そうした決まりごとでした。だいたいはうまくいっていました。ずっと後になるまで気づけなかったのは、どれもデザインの問題を解決していたわけではなかった、ということです。
この記事では、その気づきについて、AIによってそれがむしろ切実になった理由、そしていま代わりに何をしているかを書きます。これは短いシリーズ「Design in Git」の始まりでもあります。Claude CodeとGitHubを使って私が落ち着いたワークフローを、エンジニアではなくデザイナーに向けて紹介していくシリーズです。
デザインとデリバリーの間にある壁
ほとんどのデザイナーは、Figma、Adobeのツール、あるいはそれに似たものを使って仕事をしています。そして多くの人が、コンポーネント、バリアント、オートレイアウト、変数、ライブラリと、何年もかけてその扱いに習熟してきました。体系的に考えるとき、私たちはたいてい、デザインツールの中にあるデザインシステムのレベルで考えます。このコンポーネントの名前はどうするか。どんなバリアントが必要か。どのトークンを使うべきか。
引き渡しの後に何が起きるかは、私たちの関心事になることはほとんどありませんでした。フレームを実際に動く画面にする方法、変更を安全にリリースする方法、何かを壊したときにロールバックする方法、移行が終わるまでコンポーネントの二つのバージョンを共存させる方法は、開発者が考えてきました。ソフトウェアのライフサイクル(バージョン、リリース、レビュー、ロールバック)は壁の向こう側にあり、デザインシステムの考え方はたいていその壁で止まっていました。
それは長い間、理にかなっていました。説得力のある画面を一つ作るのに何日もかかっていたころは、デザイナーが時間を使うべきなのは画面でした。
AIが動かしたのは仕事と、信頼できる情報源
AIによって、アイデアを画面の形にすることはほとんど取るに足らない作業になりました。このことは「画面ではなく、仕組みをデザインする」で書きました。アセットを作ることが安くなると、価値のある仕事はデザインアセットを作ることから、デザインの意図を管理することへ、そしてその意図を途中で失わずにデザインからコードまで運ぶ基盤を作ることへと移ります。言い換えれば、プロダクトをデザインすることから、その下にある仕組みをデザインすることへの移行です。そのとき私はこう書きました。
デザインとエンジニアリングは、逆の方向から同じ気づきに向かって収束しています。生成が安く速くなったとき、守り、持ち運べるようにする価値があるのは、その出力のどれかではなく、仕様そのものだという気づきです。
同時に、UX Collectiveのこの記事が論じているように、デザインの信頼できる情報源はコードの側へと移りつつあります。デザインと開発の境界はますます曖昧になり、引き渡しの重要性はどんどん小さくなっています。出荷されるコンポーネントこそがデザインそのものになりつつあり、Figmaのフレームはその絵にすぎなくなっているからです。そうなると、デザイナーはかつてエンジニアのものだった問いに答えなければなりません。このコンポーネントのどのバージョンが本番で動いているのか。ほかに何がそれを使っているのか。誰がこの変更を承認したのか、そしてなぜなのか。
デザインの力では抜け出せなかった、Figmaの二つの問題
プロダクトデザイナーとフロントエンドエンジニアを兼ねて働くうちに、私の関心は少しずつ、デザインアセットを作ることから、作ったものを管理し、その流れを整えることへと移っていきました。そこで何度も戻ってくる問題が二つありました。
命名規則によるバージョン管理
一つ目はバージョン管理でした。私はいつでも、ある単純な問いに答えられる必要がありました。この画面は先週どんな見た目で、なぜ変わったのか。Figmaのバージョン履歴はファイルのスナップショットを保存してくれますが、二つの作業の流れを並べて持つことはできず、レビューのために変更前と変更後をきれいに見せることもできません。
そこで私は、その場しのぎの仕組みを作りました。日付付きのページ。バージョン付きのフレーム。一度日付を付けたら二度と触らないフレーム。以前の職場で身につけた、dev、stage、masterに分けたページ。この仕組みは十分に機能し、その時期のフレームはどれも、いまでも日付とタスクまでたどれます。ただし、すべては規律だけで成り立っていました。忙しい日の私自身も含めて、誰かが「凍結した」フレームを編集するのを止めるものは何もなく、それぞれの変更の理由は、どこか別の場所にある議事録の中にありました(この決まりごと自体については、チームがFigmaから離れられない場合にはいまでも役に立つので、別の記事にまとめるつもりです)。
Figmaにはブランチ機能もあり、それがあれば助けになったかもしれません。しかしこれはOrganizationプランとEnterpriseプランでしか使えず、私は試せていません。その価格は、たとえデザインチームが重要だと考える機能であっても、たった一つの機能のためにほとんどのスタートアップが払える額を超えています。
範囲を絞れないコンポーネントの更新
二つ目の問題は、更新の伝播でした。コンポーネントを変えると、ファイル内でそれを使っているすべての画面も変わり、その範囲を限定することはできません。たいていはそれで構いません。しかし次のリリースに向けてコンポーネントをデザインし直しているとき、現在のリリースの画面は動いてはいけないのです。
私の回避策は、デザインを別々のファイルに分け、それぞれにコンポーネントライブラリを複製することでした。これで範囲の問題は解決しましたが、新しい問題が生まれました。コピー同士が少しずつずれていき、ほどなくして、誰もが基準として指せる正式なライブラリがなくなってしまったのです。共有ライブラリを公開し、ファイルごとに更新を受け入れるようにすれば多少はましになりますが、それでも更新は画面単位ではなくファイル単位で受け入れるもので、「この画面は当面古いバージョンのままにする」と言うための、きれいで公式な方法はありません。
これはエンジニアリングの問題だ
振り返ってみると、どちらもデザインの問題ではなく、エンジニアリングの問題です。ツールのデザインの問題だと言うこともでき、それはもっともですが、根っこにあるものは変わりません。Figmaはデザインファイルをドキュメントとして扱います。ソフトウェアチームは自分たちの成果物をパッケージとして扱います。履歴、バージョン、リリース、そしてそれに依存するものを持つものとしてです。私の日付付きのページはコミットでした。dev/stage/masterのページはブランチでした。複製したライブラリは、各ファイルが固定できるバージョン付きのパッケージを、手作業で、下手に作ったものでした。ソフトウェアチームは、これらすべてを何十年も前に、ほとんどのデザイナーが開くことのないツールで解決していたのです。
いまのやり方:デザインはGitの中にある
そこで私は、そうした道具をFigmaの中で作り直すのをやめ、本物を使い始めました。あるスタートアップのプロダクトのための、AIを組み込んだワークフローで、Gitのリポジトリがデザインをバージョン管理する場所になりました。
- Storybook は、開発チームのためのコンポーネント一覧です。
- 同じリポジトリからビルドするデザインシステム専用のサイトは、組織のそれ以外のすべての人のためのものです。トークンのライブラリ、基本原則、コンポーネントの仕様、そしてデザイン判断の一覧と履歴があります。
- デザイン判断は、実装しながら書き残します。 一つひとつが短い記録(D-001、D-002など)で、ルール、理由、そして何を置き換えるのかが書かれています。判断は決して編集せず、新しい判断で置き換えるだけなので、なぜの履歴が残ります。Claudeが変更を実装しながら最初の下書きを書いてくれるので、記録にかかる私の手間は午後いっぱいではなく、レビュー一回分です。
- Figmaは、Figma MCPサーバーを通じてコードから同期します。 いまでも両方の世界で変更を加え、行き来していますが、どの変更でも最後のステップは、Figmaを実際に実装された内容に合わせることです。
一つ、正直に補足しておきます。建前のうえでは、いまもFigmaが仕様です。リポジトリにあるClaudeへの指示には、文字どおり「Figma is the source of truth」「Figma wins, but say so out loud」と書いてあります。Gitが与えてくれるのは、その周りにある、Figmaにはできないすべてのものです。すべてのトークンの値がある一つのファイル、すべての変更の履歴、すべての判断の記録、そして出荷前にそのすべてをレビューする手段です。
チームの他のメンバーも、実際にこれを使いました。フロントエンドチームは、ある画面のコンポーネントの一部をStorybookを使って更新しました。コンポーネントパッケージへの全面的な切り替えも計画されていましたが、本番障害や大規模な品質低下のリスクといった運用上の懸念から保留になりました。そしてドキュメントサイトは、マーケティング、開発、デザインのそれぞれが利用していました。この仕組みがどうやってできあがったのか、うまくいかなかったことも含めた全体の話は、別のケーススタディとして後日公開する予定です。
AIが取り除いたのは雑務であって、理解する必要ではない
デザインとコードが隣り合ういま、デザイナーにはコードがどう動くのか、そしてエンジニアとどう働くのかを理解することが、以前にも増して求められています。逆のことを言っているように聞こえるかもしれません。AIのおかげで、デザイナーがエンジニアリングに触れる必要はそもそも減った、と考える人はたくさんいます。私の経験はその逆でした。
そのデザインシステムをClaudeと一緒に作っていたときの二つの出来事が、それを具体的に実感させてくれました。
一つ目は、余白のトークンについてでした。私たちのトークン spacing.4 は4ピクセルを意味していました。ところが、コンポーネントが使っているCSSフレームワークのTailwindでは、p-4 はすでに16ピクセルを意味していて、すべてのコンポーネントがそれを使っていました。私たちのトークンをそのまま登録していたら、コードベース中のすべての p-4 が黙って再定義されていたでしょう。何もエラーにはならず、ただあらゆる場所の余白が間違っていたはずです。Claudeはこの衝突に気づき、手を止めて質問してきました。トークンの仕組みに関わることは、決めるのではなく指摘するように、と私が伝えていたからです。しかし判断したのは私で、それができたのは p-4 が何を意味するかを理解していたからです。私たちはトークンのキーをTailwindのスケールに合わせて名前を変え、結果として九つの余白の値がすべて、ぴったり一致しました。
二つ目は、ビルドが通ったことを信じてよいかについてでした。あるとき、プレイグラウンドのアプリで、すべてのボタンがまったく背景なしで表示され、コンポーネントのスタイルのほとんどがそっくり抜け落ちていました。ビルドは通り、lintも通り、型チェックも通っていました。原因は、モノレポの中でTailwindがパッケージをまたいでクラス名を見つける方法に関する、設定の細かな点でした。これに気づけたのは、コンポーネントはFigmaのフレームと比較するまで完了ではない、というルールを私がリポジトリに書いておいたからで、Claudeはビルドが通ったことを信じる代わりにスクリーンショットを撮りました。デザイナーにとって、「ビルドできた」と「見た目が正しい」は明らかに別の事実です。エージェントにとってはそうではありません。誰かがそう教えない限りは。
どちらの場合も、雑務をこなしたのはAIでした。コードを書き、問題を見つけ、修正を提案しました。AIが提供できなかったのは、ルールと判断を可能にした理解のほうです。AIは、かつて人間がしていた多くの仕事を取り除きました。しかし人間が理解する必要までは取り除いていませんし、取り除けるとも私は思いません。
だからこそ、いま採用する価値のあるプロダクトデザイナーは、デザイン思考、デザインの手法、技術的な素養、そしてAIを使いこなす力という、ハイブリッドなスキルセットを持っている人だと私は考えています。これは脅威ではなく、良い知らせです。AIがあれば、わからない行のすべてについて質問できるので、ずっと短い時間で、ずっと多くのことを理解できます。AIが私たちを悪いデザイナーや不要なデザイナーにするのではなく、より良いデザイナーにしてくれる、私の知る限り最もはっきりした例の一つです。
このシリーズについて
GitとGitHubを使えばこの働き方はずっとスムーズになり、Claude Codeを使えば、エンジニアリング出身でない人にとってもずっと取り組みやすくなります。シリーズの残りは、その実践編です。
- パート1: 探索はひとりで、レビューはみんなの前で。すべての変更の背後にある二つのループと、Claudeが働く場所。
- パート2: Claudeでも壊せないデザインシステムのリポジトリ。トークンとコンポーネントを守るルールを含む、一度きりのセットアップ。
- パート3: 記録が残るデザインレビュー。どのClaudeのレビューを使うべきか、そしてコードレビューでは見えないもの。
- パート4: 行間ひとつの変更を、Issueからマージまで。実際のデザイン判断を最初から最後まで追います。
最後に一つ、注意点があります。私はまだこれを実際のチームで試してはいません。いくつかの学業やサイドプロジェクト、そしてそのスタートアップのデザインシステムで、チームで働いているつもりでこのパイプラインを組んできました。デザイナーとエンジニアが一緒に、似たような仕組みを運用したことがある方がいたら、何がうまくいかなかったのかぜひ聞かせてください。