デザインとエンジニアリングの引き継ぎ – Figmaコメントを超えて
Figmaコメントだけではデザインとエンジニアリングの引き継ぎギャップを埋められない理由と、小規模チームで実際に機能する方法。
By Ellis Keane · 2026-04-06
最高のデザインとエンジニアリングの引き継ぎツールは、エンジニアが開く必要のないもの
デザイナーがFigmaの引き継ぎを完璧にすることに投資すればするほど – オートレイアウト、デザイントークン、デベロッパーモードのアノテーション、コンポーネントドキュメント – 実際のデザインとエンジニアリングの引き継ぎはむしろ悪化することが多いのです。デザイン作業が悪いからではありません – それは大抵素晴らしいものです – しかし、その努力のすべてが、エンジニアが渋々訪れ、素早く流し読みし、見たと思ったものを作るために閉じてしまうツールの中に存在しているからです。
私はこの両側を経験してきました。最初はデザイナーとして始めました（まあ、「デザイナー」 – ニューハンプシャーで質屋のウェブサイトを作っていたので、その肩書きには寛大であってください）、そして今はSugarbugのエンジニアリングコードの大部分を書いています。デザインとエンジニアリングの引き継ぎ問題はツールの問題ではなく、ワークフローの問題です。情報は存在しています。ただ間違った場所に間違ったタイミングであるだけです。
典型的なデザインとエンジニアリングの引き継ぎはこんな感じです。デザイナーがFigmaフレームを3日間磨き上げ、スペーシングの決定やエッジケースを説明する12のコメントを追加し、エンジニアをタグ付けして待ちます。エンジニアはFigmaを開き、フレームを約90秒見て、「了解」と思い、タブを閉じ、80%正しく20%間違ったものを構築します – その20%を解決するのにさらに1週間のやり取りが必要になります。12のコメント？読んだのはせいぜい4つです。
デザインとエンジニアリングの引き継ぎは壁の向こうに投げるファイルではありません。エンジニアが作業する場所 – イシュー、PR、コードの中 – に存在する必要があるコンテキストであり、一度だけ訪れるデザインツールの中ではありません。
Figmaコメントが引き継ぎに適さない理由
私は毎日Figmaを使い、心から楽しんでいます（これはおそらくもはや性格的欠陥です）。しかしFigmaコメントはデザイナー同士のコラボレーションに最適化されており、デザインとエンジニアリングの引き継ぎには最適化されていません。その違いはほとんどのチームが認識している以上に重要です。
根本的なミスマッチはこうです。Figmaコメントはフレームやコンポーネントに空間的にアンカーされています。デザインファイルの中に存在しています。しかしエンジニアはデザインファイルの中で作業しません – LinearイシューやGitHub PR、IDEで作業します。デザイナーがフレームに「このドロップダウンは640px以下のモバイルビューポートで折りたたむべき」とコメントを残すと、その情報はFigmaに閉じ込められます。タスクにはなりません。エンジニアのワークフローに表示されません。エンジニアが訪れることを覚えていなければならない並行世界に存在し、（ここが本当に重要なところですが）Figmaを訪れることは、LinearのチェックやPRのレビューのようにエンジニアの自然な作業ループの一部ではありません。
結果は予測可能です。重要なデザインの意思決定が失われます。誰も不注意だからではなく、情報が間違ったツールにあるからです。在宅勤務の人のデスクに付箋を貼るようなものです。
デザイナーがコンテキストを残す場所
- Figmaコメント – 空間的、フレームにアンカー
- Figmaデベロッパーモードアノテーション – 詳細だがFigmaを開く必要がある
- Slackスレッド – 会話的、1週間後には検索不能
- デザインシステムドキュメント – 包括的だがスプリント中にはほとんど参照されない
エンジニアが実際に見る場所
- Linearイシューの説明 – 着手前に最初に読むもの
- GitHub PRの説明 – 実装中の参照
- コードコメント – レビュー中に発見
- IDE – 時間の90%を過ごす場所
実際に機能すること（両方をやっている人間より）
Sugarbugを構築してきたこの1年間、私はデザイナーであり（主に）エンジニアでもありました。つまり、自分自身に引き継ぎをして、それでもコンテキストを失うという珍しい経験をしてきました。先週火曜日の自分のデザイン決定すら覚えていられないなら、別のエンジニアがFigmaコメントスレッドからすべてをキャッチできるはずがありません。
私たちのチームのデザインとエンジニアリングの引き継ぎプロセスで実際に機能したことをお伝えします。どれもより良いFigmaコメントを書くことは含まれていません。
1. デザインの意思決定はデザインファイルではなくイシューに書く
エンジニアが構築を始める前に、デザインのコンテキストはLinearイシュー（またはチームが使っているもの）に存在する必要があります。「デザインを見て」というFigmaファイルへのリンクではありません – それは手抜きであり、全員がそれを知っています。イシューには以下を含めるべきです：
- 何を： スクリーンショットまたはエクスポートされたフレーム（Figmaリンクではなく – エンジニアが別のツールを開かずに見られるPNG）
- なぜ： 主要な決定の背後にある理由。「ユーザーが編集中にリストを参照する必要があるため、モーダルではなくスライドオーバーパネルを採用しました」 – 「なぜモーダルじゃないの？」の3往復を節約する1文
- エッジケース： モバイルではどうなる？長いテキストではどうなる？データがないときはどうなる？考えたなら書き留めてください。考えていないなら、正直に言いましょう（「空の状態はまだ考えていません」は沈黙よりも有用です）
2. デザインレビューはFigmaではなくイシューで行う
実装中にデザインフィードバックを受けるとき、2日間見ないかもしれないFigmaコメントではなく、Linearイシューのスレッドで欲しいのです。イシューは作業の唯一の情報源です – フィードバックがそこにあれば、次にイシューを確認するときに見えます。それは1日に何回もあります。Figmaにあれば、そのファイルをたまたま開いたときに見ることになり、それは永遠にないかもしれません。
これはFigmaコメントを決して使うなという意味ではありません。デザイナー同士のコラボレーション、特定の視覚的詳細のアノテーション、デザインそのものについての会話には最適です。しかしフィードバックが「エンジニアが何かを変更する必要がある」となった瞬間、それはエンジニアリングのワークフローに移動する必要があります。
stat: "ほとんどの" headline: "引き継ぎにFigmaコメントを頼った場合、Figmaコメントは48時間以上見られなかった" source: "3ヶ月間の非公式トラッキングによる私たちのチームの経験"
3. 仮定ではなくスクリーンショットでループを閉じる
デザインとエンジニアリングの引き継ぎの検証で最も手軽な形式はスクリーンショットです。エンジニアがコンポーネントの実装を終えたら、PRまたはイシューにスクリーンショットを貼り付けてデザイナーをタグ付けします。「これは合っていますか？」は10秒で済み、出荷前に20%の乖離をキャッチします。ミーティングもFigma比較の儀式も不要 – PNGと質問だけです。
すべてのUI PRでこれを始めたところ、「これはデザインと一致しません」という会話はほぼゼロに減りました。残る会話はデザインがカバーしていない本当のエッジケースであり、それは問題ありません – それは議論すべき類のものであり、基本的な「12pxではなく16pxのパディングを使っている」というような話ではありません。
4. ツール間でコンテキストを自動的に流す
ここでSugarbugに触れます。まさにこの特定の問題を解決するために作ったからです。デザイナーがFigmaでスペーシングの変更についてコメントを残します。Sugarbugはそのコメントを拾い、関連するLinearイシューとGitHub PRに接続し、エンジニアはFigmaを開かずにワークフロー内でそれを見ます。デザインとエンジニアリングの引き継ぎは手動のコピペの儀式ではなくなり、自然に起こるものになります。
しかしSugarbugを使っていない場合（ほとんどの方はそうでしょう、まだプレローンチです）、手動バージョンはこうです。Figmaコメントを毎日チェックし、関連するフィードバックをLinearイシューにコピーする「引き継ぎブリッジ」担当を割り当てましょう。面倒ですが機能しますし、エンジニアがFigmaをチェックすることを覚えていることを期待するよりも無限に良いです。
先週火曜日の自分のデザイン決定すら覚えていられないなら、別のエンジニアがFigmaコメントスレッドからすべてをキャッチできるはずがありません。 attribution: Chris Calo
デザインとエンジニアリングの引き継ぎチェックリスト
この記事から一つだけ持ち帰るなら、これにしてください。解決策はより良いツールではありません（まあ、主にではありません – ただし私は一つ作っているので、話半分に聞いてください）。解決策はデザインの意思決定がどこに存在するかについての規範を確立し、その「どこ」がエンジニアの自然なワークフローの中であることを確認することです。
- [ ] 主要フレームをPNGとしてLinearイシューにエクスポートする（Figmaリンクだけではなく）
- [ ] 各主要デザイン決定の「なぜ」をイシューの説明に書く
- [ ] 既知のエッジケース（モバイル、空の状態、長いテキスト）を列挙する – または未解決のものを明示的にフラグする
- [ ] 実装フィードバックをFigmaコメントからイシュースレッドに移動する
- [ ] デザイン承認前にすべてのUI PRでスクリーンショットを必須にする
- [ ] FigmaとLinearを自動的に接続するツールがない場合、「引き継ぎブリッジ」担当者を割り当てる
よくある質問
Q: Figmaコメントがデザインとエンジニアリングの引き継ぎツールとして失敗する理由は？ A: Figmaコメントはデザインファイルの中に存在し、エンジニアリングのワークフローから切り離されています。エンジニアはLinear、GitHub、IDEで作業しており、Figmaの中ではありません。フレームへのコメントは、誰かが手動でコピーしない限りタスクにはなりません。その手動のステップこそがデザインとエンジニアリングの引き継ぎが崩壊する場所です。人の問題ではなく、ツールの境界の問題です。
Q: SugarbugはFigmaコメントをLinearイシューに自動的に接続しますか？ A: はい – それはまさに私たちが解決するために作った特定の問題の一つです。SugarbugはFigmaコメントをスクレイピングし、関連するLinearイシューやGitHub PRに接続するため、デザインフィードバックがツール間のコピペなしにエンジニアのワークフローに表示されます。私たちは毎日自分たちで使っており、その違いは（正直なところ）アイデアのシンプルさを考えると少し恥ずかしいほどです。
Q: 小規模チームにとって最適なデザインとエンジニアリングの引き継ぎプロセスは？ A: エンジニアが構築を始める前に、デザインの意思決定をLinearイシューに書き込みましょう。見た目だけでなく理由を含めてください。実装中にエッジケースが出てきたら、エンジニアが探し回らなければならないFigmaコメントではなく、イシュースレッドで議論しましょう。最もシンプルなプロセスが最も長持ちすることが多いです。
Q: エンジニアリングが始まった後のデザイン変更にどう対応しますか？ A: スコープ変更と同じように扱いましょう。明確なビフォー・アフターをイシューに記録し、理由を説明し、コミットする前にエンジニアに実装コストを評価させましょう。最悪の引き継ぎ失敗は、すでに構築された作業に対してカジュアルなFigmaコメントとしてデザイン変更が届くときに起こります – それが不満を持つエンジニアとフラストレーションを感じるデザイナーを生む原因です。
シグナルインテリジェンスをあなたの受信箱にお届けします。