Qt Bridges: モダンなソフトウェア設計と開発

本稿は「Qt Bridges: Modernizing Software Design and Development」の抄訳です。

Qt World Summit '25 において、Qt の新しい取り組みである Qt Bridges を発表しました。Qt Bridges は、Qt Quick と QML のソフトウェア設計および開発能力を拡張し、Python、.NET (C#)、Kotlin (Java)、Swift、Rust といった、より多くの言語での使用を可能にします。

これを受けて、ウラジミール・ミネンコ(Vladimir Minenko)がブログ記事「Qtの新しいブリッジ機能：過去を振り返って未来へ前進」で、その歴史、計画、そして私たちが目指しているものについて詳しく書いています。まだ読んでいない方は、ぜひこの先を読み進める前に一読されることを強くお勧めします。私はこの記事の内容をもう少し掘り下げ、現在のQtユーザーだけでなく、新しいユーザーにとってもなぜこれがそれほどまでに画期的なのかを説明したいと思います。

プロダクトマネージャーから見た Qt Bridges

長年、私はいくつかの異なる企業に携わってきましたが、どの企業も製品は大きく異なっていました。しかし、常に変わらなかったことの一つは、アイデアからデザイン、そして製品化に至るまでに必要な時間、繰り返しの作業、そして成果物の引き渡しの多さでした。私が何を言いたいのか、そして Qt Bridges がどのように役立ったか、具体的な例を一つ挙げて説明させてください。

企業が既存のアプリケーションを完全に書き直してコードベースを統合することを検討することは非常に稀です。これは通常、そうすることに非常に明確な利点がある場合にのみ発生し、それでも最良の選択肢として選ばれることはめったにありません。つまり、彼らはゼロから始めることを望んでいるのではなく、他の方法でソフトウェアの設計と開発を簡素化および合理化する方法を必要としているのです。まさにここに、Qt Bridges が彼らの仕事を容易にし、ユーザーエクスペリエンスを向上させ、開発の速度を上げ、新しい機能を取り入れながら、可能な限り最小限のコード変更でこれらすべてを実現する完璧なイネーブラーとして機能すると私は見ています。これは単なる仮説の例ではありません。私の過去の具体的な例を一つお話ししましょう。

舞台設定

チーム構成:

当時、私たちのチームは3つに分かれていました。2つのチームがモバイルアプリ（AndroidとiOS）を担当し、もう1つのチームは、会社で共有しているバックエンドを使用するコンパニオンデバイスに特化していました。さらに、デザイン部門に所属する専任のデザイナーが1名おり、会社全体のすべての製品で使用される統一されたデザインシステムの責任を負っていました。私たちの製品はモバイル専用でしたが、他にも約5つの補完的な製品があり、それらはすべてモバイルと、場合によってはデスクトップ版のアプリケーションが混在していました。

ワークフロー:

新しいユースケースに取り組む際、私たちはまず各プラットフォームのリード、チームのアーキテクト、そしてデザイナーが集まることから始めました。問題点を検討し、ユーザーフローを確認し、解決策を探しました。一貫したユーザー体験を確保するために、プラットフォーム固有の機能や制限も考慮し、最終的にテスト用のプロトタイプを作成しました。デザインシステムに特定の要素または一連の要素がすでに含まれている場合、UXデザイナーはそれを使ってプロダクトデザインを作成しました。含まれていない場合は、デザインチームと既存のアセットで同じソリューションを実現するための合理的な代替手段がないか検討し、必要であれば新しい要素を組み込みました。

Figma で最終的なテスト済みデザインが完成すると、各チームはそれぞれのアプリケーションバージョンでの実装に取りかかりました。必要に応じて、バックエンドとコンパニオンデバイスの機能にも変更を加えることもありました。これは多くの場合、現在アプリにあるコンポーネントを再利用することを意味しましたが、もしそれらが別の製品用に作成されたものであれば、私たちのチーム内でその要素を二度も作り直す必要がありました。

その後、完成するまでデザイナーとの典型的な検証プロセスを経ていました。もし将来的に他のチームが同様のソリューションを求めた場合、彼らも同じプロセスをたどることになります。そして最悪だったのは、デザインチームがブランド刷新に基づいてデザインシステム全体を見直すという決定を下したときでした。

Qt Bridges がどのように私たちのソフトウェア設計と開発を改善できたか

私たちのデザインチームは、多くのチームと同様に Figma で作業していました。コンポーネントやスタイルなどを作成し、それらをチームが選択して再利用し、更新が行われれば製品全体に波及しました。新しいコンポーネントや要素は、デザインチームのツールキットに次々と追加されていきました。これはすべてのデザインチームが採用している、あるいは採用したいと考えているワークフローであり、Figma のようなツールもこのコンセプトを強く推進しています。なぜなら、これによってデザインチームの作業が劇的に改善されるからです。

しかし、多くの摩擦が生じたのは、製品チームと研究開発チームがこの方法を採用していなかったためです。これは、先ほど述べたように、確立された製品が異なるプラットフォーム向けに多様な技術を採用していたため、ボタンやスライダーといった「汎用的な」要素や、ユーザーや成功・失敗のポイントに応じて5つ以上の異なる画面から構成されるサインインワークフローのようなより複雑なコンポーネントを、繰り返し作成する必要があったからです。

私が Qt Bridges に最も期待するのは、プロダクトチームと R&D チームがデザイナーとより統一された方法で作業できるようになり、重複作業を減らし、市場投入までの時間を短縮し、ソフトウェアの設計と開発の方法を再構築することでイテレーションを容易にする点です。コンポーネント（例：サインインフロー）の Figma デザインが一度できれば、それを Qt Quick & QML で作成し、すべてのチームが各製品やプラットフォームごとにボタン、ローディングアニメーション、画像、フォールバックなどをいちいち再作成する必要がなくなります。標準コンポーネントを使用し、アプリ内の基礎となるロジックに接続するだけで、製品固有の変更に対応するための軽微な修正を行うだけで済むようになるのです。

ソフトウェア設計と開発を最前線に据えた新製品開発

上記の例では、Qt Bridges が既存の企業や製品にどのように役立つか、ほんの一例を挙げました。しかし、まだ存在しないチームによって、そして今まさに生まれつつあるワークフローを使って、まだ作成されていない新しい製品の場合はどうでしょうか？

Qt Bridges の潜在的な価値は、ここでも同様に、あるいはそれ以上に大きいと言えます。個々の開発者は、Qt Framework に含まれる、あるいは Qt コミュニティ内で共有されているコンポーネントを、作成、再利用、拡張できます。彼らはまず解決しようとしている問題に焦点を当て、テストに値するものが確立されてからインターフェースの実装に取りかかることができるのです。

彼らのソフトウェア設計や開発の背景に関わらず、AI 搭載の Python アプリケーションであろうと、C# でメニューを必要とするインディーゲームであろうと、あるいはC++ を使用する組み込みデバイスであろうと、彼らは単に「コンポーネント」ツールキットから要素を引っ張ってくることができます。

さらに、ソフトウェア設計と開発のワークフローが変化しても、同じコンポーネントを継続して利用できます。これは開発者が直接行う場合でも、開発者のツールキットの一部として行う場合でも同様です。これにより、チームや開発者にとって、アプリケーションの全体的な品質、一貫性、そして最終的には将来的な持続可能性が向上します。

Qt Bridges に興味があり、最新のアップデートをすべて入手したい方は、ぜひこちらからサインアップしてください。Qt を初めて利用する方で、Qt Quick と QML がどのようなものか知りたい方は、こちらの無料の全機能付きサンプルをご覧ください: try.qt.io

changed to consider