Figmaでデザインを作って、そこに仕様もわかるように作ることは可能か。
答えはYESだけど少し曖昧な返事をするだろう。私はここ数年、仕様と共存しようと考えてきました。そんなデザイナーのエッセイです。
ー
デザイナーとエンジニアって、いつも同じ道を歩いてるようで、実は違う方向を見てることがある。お互いに「これが正しいはずだ」と信じてるのに、何かがズレてる。そんな瞬間、あるよね？でも、実はその微妙なズレが、大きな問題を引き起こすこともある。
「これ、開発できるの？」とデザイナーが不安になる一方で、エンジニアは「デザイン、ちょっと複雑すぎない？」と頭を抱える。お互いが同じゴールに向かっているはずなのに、話が噛み合わない。まるで、見えない壁があるみたい。
その壁を壊すためのツールがある。それがFigma。
しかし、Figmaが全てではなく、解決しきれないことが多いのも事実だ。冒頭の「曖昧なYES」について、ちょっと語ってみようと思う。
もったいぶらないで言うけど、解決できない部分を補ってくれるのが、ドキュメントツールたち。要件定義を文章として残すため、具体的にはNotionやConfluenceとかね。これらをうまく使い分けることで、デザイナーとエンジニアが一緒に歩ける道が、少しずつ見えてくる。デザイナーは何をFigmaで作り、どうエンジニアにバトンを渡すべきなのか。そして、本当のリスペクトとは何なのか。
この記事では、Figmaを使ってデザインとエンジニアがどのように連携できるか、そして最終的にどうやってドキュメント化するのがいいのか、そのヒントを探していこうと思う。
最初に保険をかけさせてもらうけど、これが全てじゃない。いろんな方法があるし、もしかしたらすでに答えが出ているものを誰かが書いているかもしれないし、実践しているけどまだインターネットには出ていない方法があるかもしれない。
だから、先に言わせてください。もしこれより良いものがあったら、私の屍を糧にして、記事に残してクリエイティブを前進させてください。それがきっと、ユートピアなクリエイティブカルチャーの本来の姿だと私は切に願っているから。それでは本題へ。
ー Figmaの強みと有効なシチュエーション
Figmaはデザインの「言葉」だ。
見た目の美しさだけじゃなくて、その裏側にある意図や思い、さらにはチームのフィードバックまでも、一枚のキャンバスで全部表現できる。しかも、チーム全員がリアルタイムで参加できる。まるでみんなで一緒に絵を描いているような感覚。それがFigmaの最大の強みだ。
まず、視覚的なコミュニケーション。何がいいって、言葉にしなくても、絵として伝わるところだ。デザイナーは、ワイヤーフレームやユースケースシナリオをサクッと描いて「こんな感じ？」ってチームに見せられるし、エンジニアはそれを見て「こうやって動かせばいいのか」とイメージがつきやすい。言葉よりも先に「絵」で伝えることで、理解が早くなるんだ。
そして、ラフの早期作成も大きな利点。デザインって、完成形じゃなくても「これが大体の方向性です」って見せることで、フィードバックを早くもらえる。その結果、方向修正もスピーディーになるし、手戻りも減る。Figmaは、特にラフ段階での強力なツールなんだよね。まさにプロトタイプ神ツール。
最後に、Figmaはチームでのフィードバックがしやすい。エンジニアやプロダクトマネージャー、デザイナーが同時に画面上でコメントを付け合えるから、時間差のズレが少なくなる。普通ならデザインが完成した後に「ちょっとここ直してもらえますか？」なんて言われるけど、Figmaなら作業中にリアルタイムで指摘できるから、調整が早いんだ。
でもね、Figmaには一つ気をつけなきゃいけないことがある。
それは、デザインの楽しさに夢中になりすぎて、「デザインとしては最高だけど、実装できない」なんてことも起こり得るってこと。だからこそ、エンジニアと早い段階で相談するのが大事だし、Figmaはその相談をしやすくしてくれるツールなんだ。
ー デザイナーがデザインデータに残す仕様として考慮しておくと良いポイント
デザインって、ただ「見た目」を作るだけじゃないよね。もうこうれは当たり前になってきたから割愛するね。
実はその裏には、UIの動き方とか、エラーが出たときにどう見えるかとか、目に見えない細かな要素もたくさんある。Figmaのキャンバスには、そんな「見えない部分」までしっかり詰め込んでおくべきなんだ。何を入れておくとエンジニアへの配慮になるのか、見てみよう。
まず考えておきたいのは、UI Stackだ。これは、デザインを作るときに考慮すべき5つの状態のこと。たとえば、ユーザーが何かの操作をした後の理想の画面（Ideal State）とか、何もデータがない場合の表示（Empty State）とか。どんな状況でも対応できるように、全ての画面でこれを意識しておくといい。たとえば、エラーメッセージが出た時の見え方（Error State）なんかも、ユーザーに優しく伝えられるかが大事だよね。
次に、ゼロ・ワン・インフィニティという考え方も押さえておきたい。これは、画面に表示されるコンテンツの数が「ゼロのとき」「1つだけのとき」「無限に近いとき」の全てに対応できるか、というもの。たとえば、投稿がまだない状態だったら、ユーザーにどう行動を促すかを考える必要があるよね。逆に、コンテンツが無限に続く場合、スクロールの方法とか、ページを跨ぐかどうかの設計も重要になってくる。
さらに、Figmaのコンポーネントやバリアント機能を活用することも大切だ。ボタンやフォーム、メニューのような頻繁に使う要素は、再利用できるようにコンポーネント化しておこう。プロトタイプでインタラクションも見られるように設定しておくと、エンジニアにも意図が伝わりやすい。デザイナーとしては「オリジナルのカスタマイズ」を追求したいところだけど、優しさを忘れずに、エンジニアの負担にならない形でバトンを渡そう。
あと、少し前に書いたヒューリスティック評価についても良い。
ー Figmaの限界
Figmaは素晴らしいツールだけど、何でもできる魔法の杖じゃない。デザイナーが考える「ここまでできる」という範囲と、エンジニアが求める「本当に必要な情報」の間には、まだ大きなギャップがあるんだ。Figmaがカバーできるのは主にフロントエンド。画面のレイアウトやインタラクションはバッチリ表現できるけど、バックエンドの要件に関しては苦手な領域だ。
一応、コメントやメモ、Dev Modeでカバーはできるけど、正直ドキュメントツールで書いた方がわかりやすい。もしも、FigmaにドキュメントツールやKANBANボードなど搭載されたらいいのにと夢見ている。
たとえば、APIの仕様やデータベースの構造、さらには非機能要件と呼ばれる、パフォーマンスやセキュリティの部分。「表示速度n秒で！」みたいなメモがあるけどこれは仕様ではなく、要求。エンジニアはこれの解決方法や実装についてはFigmaではないところに書いてるはず。
これらは絵にするのが難しいし、Figmaのキャンバス上で表現するのはほぼ不可能。エンジニアが「このシステムはどう動くんだ？」という質問に対して、Figmaだけでは答えきれないことが多いんだ。
だからこそ、ここで登場するのがドキュメントだ。要件定義や目的、背景、課題、そしてそれに対する解決策は、文章でしっかりとまとめる必要がある。特に、非機能要件、たとえばセキュリティ対策やパフォーマンスの調整、運用や拡張性に関する部分は、ドキュメントで詳細に記述することが不可欠なんだ。
それに、履歴管理も重要なポイント。Figmaでは編集履歴を確認するのが難しかったり、過去に何がどう決定されたのかが後々追いにくくなることがある（頑張れば可能だけど酷）。だから、開発が進む過程での仕様変更やディスカッションの経緯を、きちんとドキュメントに残しておくことが大切。何年後かに誰かがそのプロジェクトに関わるとき、ドキュメントがあるかないかで作業のしやすさが大きく変わるんだよね。
ー 仕様をドキュメントに残す重要性
Figmaでデザインを作るのは楽しいし、視覚的にわかりやすいけど、それだけではカバーしきれない部分がある。特に、開発が始まると「え、これどうするんだっけ？」という疑問が次々に出てくることがあるんだよね。そんな時に役立つのがドキュメントだ。Figmaが完成した絵だとしたら、ドキュメントはその背後にある「設計図」であり、「すべて」と言っても良い。これがないと、チーム全員が同じゴールに向かって進むのが難しくなるんだ。
先ほども言ったけど、Figmaでは表現できないものを補完するために、ドキュメントが必要だ。たとえば、非機能要件（セキュリティ、パフォーマンス、運用、拡張性）や、バックエンドの細かな仕様。これらは絵にしにくいし、言葉で説明しないと伝わらないことが多い。だからこそ、きちんと文章で残しておくことが重要なんだ。
それに、ドキュメントは共有スペースの役割も果たしてくれる。Figmaはリアルタイムでコラボできる素晴らしいツールだけど、プロジェクトが進む中で全ての情報を一つの場所に集約するのは難しい。そこで、NotionやConfluenceなどのドキュメントツールを使って、チーム全員が参照できる「共通の地図」を作っておくことが大事だ。
さらに、ドキュメントには履歴管理の意味もある。開発が進むにつれて、仕様が変更されることはよくあること。v0.1とかv1.09とかね。そんな時、過去のディスカッションや決定事項がドキュメントに残っていれば、チーム全員が「何がどうしてこうなったのか」を理解しやすい。何年後かに新しいメンバーがプロジェクトに参加しても、そのドキュメントがあるだけでスムーズに作業に入れるようになるんだ。
ー Figmaに仕様を書く効力を最大限に発揮するためにエンジニアを序盤から巻き込む
デザインとエンジニアの連携って、どれだけ早く始めるかで結果が大きく変わるんだよね。デザインが完成してから見せて「えー、これ作るの？」「めっちゃボリュームあるじゃん」「さて、これどうやって作ろうか」など出てくるケースがほとんど。口に出さないだけで脳内では緊急会議が開かれている。
そして、時間も労力も無駄になることが多い。だから、企画段階でできるだけ早く開発チームを巻き込むことが肝心なんだ。
なんでもMaterial Designで！じゃなくて、開発がどんなフレームワーク使っているか知るのも大切。Shadcnとじゃ相性がそこまで良くないよねという学びを最近得たので。
まず、実現可能なラインを意識することが重要。デザイナーはクリエイティブな表現を追求したいけれど、技術的な制約も考慮に入れないと、エンジニアに負担をかけてしまうことがある。だから、デザインの初期段階から「これって技術的にいけるかな？」とエンジニアに相談することで、現実的な解決策が見えてくる。早めに技術的な壁を把握しておくと、後から手戻りが発生するのを防げるんだ。
次に、開発の大変さを理解することも大事。エンジニアって、デザインをただそのまま実装しているわけじゃない。内部でどう動かすか、どう最適化するか、常に頭をフル回転させている。デザイナーがその大変さを理解して、敬意を持って「ここはどう実装すれば良いですか？」と誠実に相談することで、よりスムーズな連携ができるようになる。これは、ただデザインを「渡す」だけじゃなくて、「一緒に作り上げていく」という意識が必要なんだよね。
最後に、早期のコラボレーションが進むと、余計な機能の省略も容易になる。「これ、あったら良いよね」というNice-to-Haveな要素があっても、エンジニアとの話し合いで「今は必要ないね」と判断できることがある。その結果、プロジェクト全体がシンプルに、効率よく進められるようになるんだ。
ー ツールを超えたコラボレーションの本質
FigmaやNotion、そしてConfluence。どれも優れたツールだけれど、ツールそのものがすべてを解決するわけじゃない。たとえFigmaで美しいワイヤーフレームを描いて、Notionに完璧なドキュメントを残したとしても、そのデータがプロダクトを完成させるわけじゃないんだ。本当に必要なのは、デザイナーとエンジニアのコラボレーション、つまり人間同士の対話と信頼。それがなければ、どんなツールもただの箱にすぎない。
考えてみれば、FigmaもNotionも、道具としてはとても便利だ。デザインの意図や構造を視覚化し、仕様や要件を整理してくれる。でも、それを使いこなすのは私たち。人間のクリエイティブな力が、これらのツールを「プロジェクトを前進させるためのエンジン」に変えるんだよね。
コラボレーションの本質は、早い段階での意識的な連携にある。デザインが完璧に仕上がってからではなく、まだラフな段階、荒削りなアイデアの状態で開発チームを巻き込むことで、プロジェクトの進行がスムーズになるんだ。「デザイナーがリードして開発にバトンを渡す」ではなく、「一緒に走り始める」感覚。それができれば、仕様変更や手戻りも少なくなるし、エンジニアも早い段階でフィードバックを出せるから、結果的にお互いがストレスを感じることも少なくなる。
じゃあ、具体的にどう始めるか？まずは、今作っているワイヤーフレームをFigmaで共有して、開発チームとレビューするところから始めてみてほしい。レビュー会をただ開くんじゃなくて、もっとカジュアルに、「この部分どう思う？」って聞くところからでいい。エンジニアに相談することで「ここの動きは実装が難しそう」とか「この機能は今の技術スタックで問題ないね」という貴重な意見をもらえる。早い段階でこうした意見を取り入れておけば、後々の手戻りや修正を減らすことができるんだ。
そして、もう一つ大事なのは、ドキュメントを残すことの重要性を開発チームとも共有すること。デザインの意図や仕様が、Figmaだけでなく、NotionやConfluenceにしっかりと残っていることで、エンジニアが仕様を確認するたびにFigmaを開く手間が省ける。ドキュメントは「道しるべ」だ。仕様変更が起こったときにも過去の記録を辿れるし、新しいメンバーが入った時も、そのドキュメントを見れば迷うことなく作業に取り掛かれる。
そして、チームの全員が意識すべきこと。それは「ツールを使いこなすだけではなく、互いを理解する姿勢を持つ」ということ。デザイナーは、エンジニアがどれだけ複雑な処理をこなしているのかを知り、エンジニアは、デザインがいかに緻密な計算のもとに成り立っているのかを理解する。それができて初めて、本当のコラボレーションが成り立つんだよね。Figmaやドキュメントツールは、そのための橋渡しをしてくれるものに過ぎない。
ー 後日談
「Figmaでデザインを作って、そこに仕様もわかるように作ることは可能か。」これは条件付きでのYES。全ての仕様を収めることは不可能で、非効率だ。それでもスピードとクオリティを保つため、コラボレーションを生み出すには必要だ。
よくデザイナーから「エンジニアとのコミュニケーションが苦手」という人が多い。これは私も新人の頃同じ気持ちでいた。
せっかく作ったデザインをボロカスに言われるし、淡々とフィードバックをして修正量が膨れ上がってくる。とても悔しい思いをした。
でも観てる景色違っていた。というか、私が何もわかっていなかった。
私が作ったデザインは開発を始めるにはチグハグで、足りないものが多く、何がしたいのか伝わるものではなかった。それが開発フェーズに入ると問題が多く発見され、その皺寄せは開発に行く。私が粗末なデザインをしたばかりに。
その後、私は1年ほどアプリエンジニアの経験をした。正直にいうと開発はエグい、デザイナーのが楽。なんでこんなデザインを実装しないといけないのか、こうしたらもっと楽に達成したいことが実現できるのに。そう思ってしまった時が多々あった。以前に私がエンジニアに対してやっていたことが、同じように私に降り注いできた。
開発チームはプロジェクトの要であり、守護神だ。法則と秩序の元、プロダクトを守る番人の邪魔をしてはいけない。むしろ、隣で一緒に戦わないといけない。
そうそう、今Figmaデータと開発環境の変数・関数を連動させる自動化プラグインツール一式を開発中なの。頑張れば今年、来年には絶対できているはず。ものすごいもの作るから待ってて。
あと、hicardでも開発チームを作る予定。今こっそり募集してるけど、興味あればぜひ声かけてほしい。この記事の考えに共感してくれる人、クリエイティブの最前線で戦うぜ！って人も。
今日も明日も、最高なもの作っていきましょい。