2026年10月8日
コメント
組み込みUI/UXデザイナーにとって最大の課題の一つが、自分のデザインビジョンを最終製品まで実現することです。だからこそ、私たちは今年初めに「Figma to Qt」をリリースしました。これは、デザイナーがFigmaから離れることなく、Qtアプリケーションの作成、プレビュー、検証、承認を行えるようにするプラグインです。
これまで私たちはこの点をセールスポイントとしてきましたが、デザインからコードへの変換ツールが、実際のプロジェクトのスケジュールにどのような影響を与えるのかについても検証したいと考えました。そこで、実際に調べてもらうことにしました。
UXDiversは、UX/UIデザインとフロントエンド実装を通じて、エンジニアリングチームによるより良い製品づくりを支援するプロダクトデザインスタジオです。同社はデスクトップ、モバイル、組み込みアプリケーションを幅広く手がけ、デザインとエンジニアリングを結びつけることで、複雑な製品体験をシンプルにしています。
今回の調査では、実際のクライアント案件を使用しました。農業分野向けに微気候による霜害リスク評価ソフトウェアを提供しているThe Climate Boxの、組み込み向け霜害リスク・ダッシュボードです。フロントエンドを2回構築しました。1回目はQMLで完全に手作業で、2回目はFigma to Qtプラグインを使用しました。デザインもターゲットハードウェアも同じです。使用したのは、Dahliaキャリアボード(Dahlia carrier board)上のToradex Verdin iMX8M Plusモジュールで、10.1インチの静電容量式タッチディスプレイを駆動し、Torizon OSを実行します。
そして、かかった時間を集計しました。
この記事では、UXDiversの共同創業者兼デザイン責任者であるPablo Germano氏に、今回のプロジェクトでFigma to Qtを使用してどのような経験をしたのか、デザインチームにとって何が意外だったのか、そして同じことを試そうと考えている別のスタジオに何を伝えたいかを伺います。
まず、最も分かりやすい質問から。Figma to Qtの調査とは、どのようなものだったのでしょうか？
私たちは、クライアントからよく受ける質問、そして正直なところ、私たち自身も疑問に思っていたことに答えたかったのです。自動化されたデザインからコードへの変換ツールは、実際の組み込みプロジェクトで本当に時間を節約できるのか。それとも、単に作業を別の場所へ移しているだけなのか。
これに答える唯一の正直な方法は、実際に2回作業してみることです。そこで、デモではなく実際に進行中のクライアント案件を使い、2つの方法でフロントエンドを実装しました。
1つ目は完全な手作業です。すべてのデザイントークン、すべてのコンポーネント、すべての画面を、QMLでゼロから手作業で作りました。2つ目では、Figma to Qtプラグインが適用できるところではできる限り使用し、プラグインで対応できない部分だけを手作業で実装しました。
このプロジェクトは、私たちのクライアントであるThe Climate Box向けのものでした。3つの画面を選びました。これは、さまざまなUI上の課題を幅広くカバーしているためです。1つ目は、リスクの概要を一目で確認できるメインダッシュボード。2つ目は、チャート、ゲージ、地図による可視化が多数含まれるゾーン詳細画面。そして3つ目は設定画面です。データの可視化、ナビゲーション、設定、ステータス表示を含んでいるため、組み込みUIに求められる機能の妥当な一断面になっていると考えました。
では、自動化されたデザインからコードへのワークフローは、実際に時間を節約できるのでしょうか？
2つのワークフローについて作業時間を集計し、フロントエンド画面、複雑なカスタムコンポーネント、バックエンドのシミュレーションなど、さまざまな作業領域を調べました。
その結果、フロントエンド画面と標準コンポーネントの実装にかかった時間は、手作業のワークフローでは118時間だったのに対し、Figma to Qtを使ったワークフローでは36時間になりました。これは、その部分の作業量が約70%削減されたことを意味し、約3.3倍高速化されたことになります。
一方、カスタムコンポーネント、バックエンドのシミュレーション、その他のプラグインの影響を受けない作業を含めたプロジェクト全体への影響は、約20%でした。
70%と20%の違いについて説明してもらえますか？
その違いは、この特定のアプリケーションがカスタムコンポーネントを非常に多く含んでいたことによるものです。ゾーンマップ、時間ごとのリスクを示すチャート、そしてゲージ。この3つだけでプロジェクト全体の作業量の48%を占めており、どちらの方法でも手作業で構築する必要がありました。プラグインはこれらを生成しませんし、そもそも生成することを目的としていません。
この点は重要な注意事項なので、明確にしておきたいと思います。プラグインの効果が集中するのは、標準的な画面と標準コンポーネントという1つのカテゴリーです。そして、このカテゴリーが今回のプロジェクトで占めていた割合は、わずか28%でした。
より一般的なレイアウト、フォーム、コントロールを使用するアプリケーション――正直なところ、ほとんどのアプリケーションがそうです――では、この70%というフロントエンドの削減効果が、プロジェクト全体のより大きな割合に適用されます。その場合、プロジェクト全体で見た削減率は20%を大きく上回るでしょう。
プラグインを使ってみて、主にどのような点に気づきましたか？
私にとって興味深かったのは、プラグインによってFigmaファイルの作り方そのものが変わるということです。デザインがどう見えるかではありません。その内部構造をどう作るか、ということです。
私たちの場合、4つの点がありました。
-
命名: 全体を通してkebab-caseからsnake_caseに変更しました。レイヤー名がQMLの識別子になり、QMLではハイフンを使用できないためです。
-
テキストの配置: すべてのテキストレイヤーに、垂直方向の配置を明示的に設定する必要がありました。Auto Layoutコンテナ内のテキストは、コンテナ自体の設定に関係なく、上部にずれてしまったためです。
-
ストローク: 元のデザインでは、辺ごとに異なる太さや異なる不透明度のボーダーを使用していました。しかしQMLのborderプロパティでは、太さを統一し、色も単色にする必要があります。そのため、これらを統一しました。
-
シャドウ: コンテナからドロップシャドウを削除しました。プラグインは、シャドウを持つレイヤーをラスタライズするためです。ラスタライズされた画像は、解像度に依存せず、編集可能であり続ける必要のあるUIには適していません。
どれも苦痛な作業ではありませんでした。しかし、こうしたことはデザインした後ではなく、デザインする前に知っておきたいことです。プラグインを使用することを前提に作られていないファイルは、見た目としては完全に優れたデザインであっても、きれいに変換するためには実際に作り直す必要が出てくる可能性があります。
もう一つ、ほぼすぐに気づいた小さな点があります。Figma to Qtのライブプレビューは、Figmaをブラウザで使用した場合にのみ動作します。私たちのデザインチームはデスクトップアプリを使っているので、そのことに気づくまで少し時間がかかりました。一度それが分かると、プレビューが最も頻繁に使う機能になりました。選択した要素を別のタブに高い忠実度で描画し、その横に生成されたQMLを表示してくれます。1つのコンポーネントを確認し、デザインの意図と生成結果を比較し、何かをエクスポートする前に調整できることによって、デザイナーと開発者の共同作業の方法が変わりました。
フィードバックのサイクルは、「ビルドが終わるまで待つ」から「今これを見て」に短縮されました。
何をプラグインに任せ、何を手作業で残すかは、どのように判断しましたか？
インタラクティブなコントロールについて、プラグインには2つの方法があります。組み込みのコンポーネントライブラリを使用する方法と、独自のFigmaコンポーネントをQt Quick Controlsにマッピングする方法です。まず組み込みコンポーネントを試しました。しかし、それらは固定フレームと手動配置を前提に構成されており、私たちのデザインシステムは完全にAuto Layoutをベースにしています。編集しようとすると、内部構造と格闘することになりました。たとえばチェックボックスのチェックマークを中央に戻したり、スイッチのつまみを再配置したり、といった作業です。
独自のコンポーネントをマッピングすることで、編集を完全にコントロールでき、デザインシステムの一貫性も維持できました。ただし、1つ制限にぶつかりました。私たちの「すべて選択」チェックボックスには、チェック済み、未チェック、部分的にチェック済みという3つの状態があります。しかし、マッピングで扱えるのは2状態だけです。その部分は手作業で仕上げました。
マップ、チャート、ゲージなどの複雑なビジュアルコンポーネントについては、プラグインに静的な画像のプレースホルダーとしてエクスポートさせ、その後で完全にコード化したコンポーネントに置き換えました。
まだ試していない、より良い方法もあります。Advanced Settingsを使ってFigmaのレイヤーに注釈を付け、任意のQML型にマッピングする方法です。次はこれを試す予定です。今回の調査では意図的に評価対象から外したため、実際にどの程度うまく動作するかについてはお伝えできません。ただ、理論上はプレースホルダーを置き換える工程を完全になくせる方法です。
作業時間以外では、どのような影響がありましたか？
私自身、これほど重要だとは思っていなかったことが2つあります。
1つ目は、誰が実装するかに左右されない忠実度です。手作業による実装でも、もちろんデザインを完全に再現できます。しかし、それには開発者が視覚的な細部を見極める優れた感覚を持っていることが大きく影響します。これは人やチームによって大きく異なります。小さな位置ずれ、わずかに異なる間隔、間違ったフォントウェイト。こうしたものは、気づかないうちに組み込みUIの品質感を大きく損ないます。生成された出力は決定論的です。誰がエクスポートを実行しても、同じ結果になります。デザイナーとして、これは信頼できるものがあるという意味で非常に重要です。
2つ目は、統一性です。生成されたQMLは、予測可能で規則的な構造になります。一方、手書きのQMLは時間とともにスタイルのばらつきが蓄積します。開発者が違えば違いが生まれ、月が変われば違いが生まれ、習慣が違えば違いが生まれます。長期にわたるプロジェクトでは、その違いが積み重なっていきます。
Figma to Qtは、他のプロジェクトでどのように役立つと思いますか？
一般的なUIの割合が高いアプリケーションでは、Figma to Qtが非常に効果的に機能すると考えています。設定画面、フォーム、カード、ナビゲーション、リストなどです。70%という数字が当てはまるのはまさにこの領域であり、ほとんどの製品では、これらがインターフェースの大部分を占めています。
また、より大規模で、分散したチームでは非常に大きな効果があると思います。今回の調査は、とても小規模で緊密なチームによって行われました。デザイナー1人と開発者1人が常に会話し、お互いの仕事のスタイルを理解しています。これは手作業による引き継ぎとしては、かなり理想的なケースに近いものです。それでも、プラグインによって20%の削減効果が得られました。デザインと開発が別々のサイロに分かれていたり、完全に別の組織に分かれていたりする場合、生成されたコードによって、スペーシング、サイズ、色の忠実度について何度もやり取りする必要がなくなります。こうしたやり取りは、通常なら複数回のレビューサイクルを消費します。そのため、こうした環境では、Figma to Qtの価値は低くなるどころか、むしろさらに高くなると考えています。
生成されたコードは、実際のハードウェアでも問題なく動作しましたか？
はい。私たちは、できる限り長い時間をデスクトップ上で開発することを意図的に選びました。そうすることで、より高速な反復、より短いビルド時間、そして開発サイクルの中にデプロイ工程を挟まないというメリットが得られるからです。デバイスへのデプロイは、日常的な作業ではなく、最終的な検証ステップとして扱いました。
Torizon VS Code拡張機能とデフォルトのQt 6テンプレートを使ってデプロイした際、唯一問題になったのはバージョンの違いでした。テンプレートはQt 6.8.2を使用していた一方、私たちはQt 6.10.2を対象として開発していました。必要だった調整は、APIの小さな違いへの対応だけでした。そして面白いことに、その対応が必要だったのは完全に手書きしたコンポーネントだけでした。Figma to Qtによって生成されたQMLコードには影響がありませんでした。
デバイス上でのパフォーマンスも非常に優れていました。ナビゲーション、アニメーション、チャートの描画はいずれも滑らかで、デスクトップ上との違いは体感できませんでした。
最後の質問です。Figma to Qtの導入を検討しているデザイン責任者に、何を伝えたいですか？
まず、それが何であるかを明確に理解することです。このツールは実装を高速化できます。しかし、ユーザー体験の品質は、ユーザーを理解し、適切なワークフローを設計し、適切なUI上の判断を行えるかどうかに依然として左右されます。デザイナーもまた、コンポーネントをどのように構成するか、そして何を生成し、何をカスタム実装する必要があるのかを開発者と一緒に決めるうえで、重要な役割を担います。この協力関係は、UXDiversにおける私たちの仕事の中心にあるものです。
課題が出てくるのは、その後です。デザインが変更され、画面を再生成する必要が生じたときです。その時点で重要になるのは、生成されたUIとカスタムコードとの間に明確な境界を保つことです。この分離を厳密に行うほど、何の不安もなくプラグインを再実行できるようになります。
こうした前提を理解したうえで使用すれば、Figma to Qtは本当の意味での生産性向上ツールになります。そして、誰も手作業ではやりたくない、反復的で細部への注意を必要とする作業の大部分を取り除くための、信頼性の高い方法になります。
Pablo氏とUXDiversチームの皆さん、この経験を共有してくださりありがとうございました。Pablo氏は、今後開催される「Behind Your Build Series」の講演で、Figma to Qtのワークフローについてさらに詳しく紹介する予定です。
UXDiversのWebサイトもぜひご覧いただき、同社の活動に関する最新情報をチェックしてください。
