Qtはあなたのプロジェクトに適していますか?
～ソフトウェアスタックを選択する際に考慮すべき８つの要素～
（掲載 2023年4月28日）
新しいソフトウェアプロジェクトを始めるときに、最も難しい選択のひとつが、チームがそれを作るために使用するプログラミング言語とフレームワークです。この仕事に最適なツールだからとQtにこだわるべきか？それともWebベースの技術やモバイル向けに設計されたものに切り替えるべきでしょうか。機械学習機能を組み込むならPythonの方が良いかもしれません。
適切なフレームワークを決定することは非常に難しいことです。Web上の情報は、相反することを言っていたり、一人の開発者の視点に基づく主観的なものであったりします。複数のフレームワークを正しく比較するために、それぞれで同じプログラムを作成するといった方法は非常にコストがかかります。そのため、開発者が最も抵抗の少ない道を選ぶのも無理はありません。明確な理由がなければ、前のプロジェクトで使っていた言語やフレームワークをそのまま使い、慣れ親しんだソフトウェアを再利用するのです。
ソフトウェアスタックの選択は、プロジェクトの将来を導く上で非常に重要であるため、最初の選択は戦略的な決定として扱う価値があります。私たちは確かにQtの開発を多く行っており、素晴らしいツールだと信じています。しかし、道具箱の中にある唯一のツールではありません。実際、あまり適していない場合もあります。
プロジェクトのソフトウェア スタックを選択する際には、次の 8 つの要素を考慮することをお勧めします。
1. 既存のコードベース
すでに持っているコードはどのくらいありますか？それはきれいにファクタリングされ、よく文書化され、簡単に再利用できるものでしょうか？既存の開発は大きな考慮事項です。ただ、再利用が難しいスパゲッティコードがたくさんある場合、強固で信頼性が高く、モジュール化されたコードと同じ重みを持つべきでないということを覚えておく必要があります。QtとC++も例外ではありません。どんな言語で書かれたひどいコードも受け継ぐことができます。既存の遺産に邪魔されて、より新しく、より良いアプローチに移行することができないようではいけません。
一方、既存のコードベースには、多くの知識と経験が詰まっています。これは、ドキュメントやコメントには書かれていないことが多いのですが、長い時間をかけて熟成され、多くの決断、回避策、修正が蓄積された結果なのです。新しいフレームワークやプログラミング言語を用いてゼロから開発すると、過去の失敗を繰り返す危険性があります。これまでと同様、これらの側面を比較検討することは、白か黒かの判断ではなく、微妙なニュアンスと慎重な検討が必要です。
2. スキルと利用可用性
特定のフレームワーク、言語、ドメインの専門プログラマーの人的リソースは、ツールを決定する際に重要な要素となることがあります。特に、C++のように難易度の高い言語ではその傾向が顕著です。Qt は C++ の複雑さを緩和し、様々なレベルのプログラマーの生産性を高めることができると、様々なバックグラウンドを持つ開発者を長年にわたってトレーニングしてきた私たちの経験から分かっています。Qtのすっきりとした構造設計と完全なライブラリ、そしてQMLにより、様々なスキルレベルの開発者が効果的に力を発揮することができます。QMLはJavaScriptに似ているため、ユーザーインターフェースの開発を劇的にシンプルにし、Webベースの開発に近づけることができます。とはいえ、QtやC++の難しい分野である最適化、拡張やカスタマイズに取り組むことができる質の高い人材を確保することはまだ困難です。Qt 以外では、Web ベースの技術に関する求人はより簡単に見つけることができるため、その選択をすることは有益な場合もあります。しかし、Web ベースのフレームワークの内部を掘り下げる必要がある場合は、結局高スキルな人材が必要です。優秀な人材は、言語に関係なく稀少です。人材プールと言語選択の重要性は、業界、地域、給与やその他の待遇で競争できるかどうかによって変わってきます。
多くのツールは、力を発揮する環境とそうでない環境があるため、アプリケーションがターゲットとするプラットフォームは大きな考慮事項となります。Qtの強みの1つは、クロスプラットフォームアプリケーションの構築です。しかし、すべてのプラットフォームで許容できるUIを提供する一方で、各プラットフォームに合わせた微調整は行われません。例えば、将来に渡りモバイルアプリしか作らないのであれば、React NativeやFlutterのようなクロスプラットフォームのモバイル開発に特化したフレームワークを検討した方がよいかもしれません。同様に、Apple iOSとGoogle Androidの2つのモバイル環境のうち1つだけをターゲットにしている場合は、例えばSwiftやKotlinなど、それぞれの環境に最適なツールを調査するのもよいでしょう。さらに、アプリがデスクトップとWebベースのインターフェイスを持つ場合、2つの環境のギャップをより容易に越えられるElectronのようなHTML5ベースのツールを使用することが理にかなっているかもしれません。最後に、プロセッサの大きさが重大な制約となる場合があります。ARMマイクロプロセッサであれば、ほぼすべての最新のツールチェーンを実行できますが、マイクロコントローラには多くの制約があり、言語やフレームワークの選択がより制限されることがあります。Qtはマイクロコントローラをターゲットに最適化されたフレームワークを提供していますが、アプリケーションをうまく動作させるためには、やはりパフォーマンスに大きな焦点を当てる必要があるかもしれません。ハードウェア性能の低さに主眼を置くのであれば、Crank Storyboardのような小規模なアプリケーションを想定した、より軽量なフレームワークを選択する方がよいかもしれません。
4. ユーザーインターフェイスの要件
皆さまのアプリケーションは何を表示する必要があるのでしょうか？単純なテキスト？レスポンシブモバイルページ？3Dグラフィックス？複雑なビジュアライゼーション？グラフィックへの要求が高度であるかどうかは、適切なプログラミング環境を選択する大きな原動力になります。コンソール入力とテキスト出力で済むのであれば、ほとんど何でもよいでしょう。しかし、高度なグラフを大量に作成する場合は、R、Julia、Pythonのようなデータ可視化ライブラリが充実している言語を検討したほうがよいかもしれません。また、3D操作や2DのUIに3Dグラフィックスを組み込むような用途では、Qtの真価が発揮されるでしょう。また、Qt は、よりハードウェアに近いレイヤーでソフトウェアを作ることができるため、科学アプリケーション、高スループット測定システム、リアルタイムデータ収集など、データ管理が最も重要な分野でも非常に優れています。
5. リモートアクセスの要件
リモートアクセスが必要な場合、Webベースのソリューションを選択することは自然なことです。その利点は、開発には当然ブラウザ・インターフェースを使用するため、リモートブラウザアクセスがローカルアクセスと同じになることです。しかし、Web技術がブラウザに制約されるため、最適なデスクトップ体験を作成することが難しいという欠点もあります。Qtは、WebAssemblyやWebGLによってリモートやブラウザベースのUIをサポートすることができ、非常に多機能になっているため、デスクトップやリモートUIをカスタマイズして作成することが可能です。リモートアクセスの要件も考慮する必要があります。ローカルアクセスよりも高い頻度で制御に使用するため、メンテナンス・サポートのため、トレーニング、監視、管理のため、使用頻度やUI のニーズ、柔軟性などに基づいて、Qt と Web ベースのツールのどちらがリモートアクセスの要件に適しているか、より詳細に評価することができます。
6. 垂直市場
製品の市場が、使用するツールキットに影響を与える場合があります。自動車やPOSのように、特定のツールチェーンが特定の分野で強い足場を築いていることもあります。オープンソースライブラリや、サードパーティの専門コンサルタント、既存のソフトウェアスタック、サードパーティが提供する製品にアクセスできれば、開発プロセスを短縮することができます。ところが、あまり一般的でないツールを使って開発すると、例えば一般的なプロトコルやハードウェアデバイスに対応するために開発チームが工数を割く必要が出てくるかもしれません。
一部の垂直市場では、アプリケーションがハードウェアに直接アクセスする必要があります。すべてのハードウェアコンポーネントが既製品で、適切にカプセル化されたドライバがある場合、言語に関係なく問題にはならないでしょう。しかし、カスタムハードウェアは産業用やロボット用の設計に多く、Javaなどの仮想マシンを使用するプログラミング環境やWebベースの技術で使用するのは困難です。
垂直市場が課す可能性のある最後の制約は、規制や安全上の理由から満たさなければならないソフトウェアのライフサイクル、開発および品質基準です。認証機関にとって馴染みのある言語とツールセットを選び、プロンプトなしのガベージコレクションのような問題のある概念を導入しないようにしたいものです。各規格の詳細は異なりますが、IEC 62304認証を必要とする医療機器、ISO 26262に準拠する自動車システム、IEC 61508準拠を必要とする産業システムには、同様の特徴が当てはまります。
7. ツールの面白味と寿命
あなたが使いたい言語は、開発コミュニティで「ホット」なのでしょうか？ツールの人気は、プログラマーがチームに参加しやすいかどうかを教えてくれるかもしれません。「新しくてエキサイティング」というのは、安定性とのバランスが必要です。あまりに新しく、継続的に改良が加えられ、導入後のリリースごとにコードベース全体に変更が必要になるようなものは選ばないようにしましょう。
開発者の関心を測るもう一つの指標は、コミュニティの大きさです。選択したツールに、Stack OverflowやRedditに大規模で活発なフォーラムがあり、GitHubに進行中のプロジェクトがあれば、その分野に興味を持ち貢献しているプログラマーがたくさんいることがわかります。新しいツールは、関心は高いものの実践者が少なく、オンラインコミュニティも小さいかもしれません。
もうひとつの指標は寿命です。長い間使われてきた言語やツールは、その価値が証明され、陳腐化することなく生き続けています。最後に、ソフトウェアのメンテナンスは容易かどうかが重要です。コードベースの保守性が高ければ高いほど、生産的な寿命は長くなります。つまり、複数のプロジェクトでコードを新鮮に保ち、再利用することができます。
保守性の高さは、プログラミングのスタイルやドキュメンテーションに依存することが多いのですが、ツールの特性も保守性の高さに貢献することがあります。さまざまな技術やパラダイムが混在する開発環境では、既存のコードを壊さずにバグを修正したり機能を拡張したりする方法を開発者が把握するのは簡単ではありません。Web 標準で作られたツールは、HTML5、JS、CSS、カスタム JavaScript フレームワークの組み合わせで修正するのが難しい場合があります。Qtアプリケーションは、C++、QML、Qtライブラリが混在しているため、この問題に悩まされることもあります。ユニットテストを開発プロセスに簡単に組み込むことができるツールを見つけることは、保守性を高めることにつながり、最新の開発において優先されるべきことです。
8. 事業戦略
多くの場合、開発ツールの選択は、エンジニアリング部門以外の誰にも考慮されることはありません。しかし、ソフトウェアツールの選択は、人材の採用、利用可能なコンサルタント、サードパーティライブラリのコストと可用性、コードベースの寿命、製品の安定性などに影響を与えるため、チーム全体の意見を聞きながら戦略的に決定することが賢明です。確かに、プログラマーには開発ツールの選択が技術的に適していると感じてもらいたいものですが、経営陣、人事、役職者、関係他部門がソフトウェア選択の技術的側面を十分に理解していないのと同様に、エンジニアは他のすべての下流の検討事項を認識していないかもしれません。重要なソフトウェアツールの選択において、すべての関係者がテーブルに着き、オープンな対話を行うことで、その決定が製品開発に役立つだけでなく、企業の長期的な検討材料となることを保証します。
以上、最初のソフトウェアスタックを選択する際に考慮すべきことはたくさんあります。Qtは多くのプロジェクトに適していますが、Qtだけが特別なわけではありません。本記事の出展元でQtプロフェッショナルであるKDAB、そしてSRAは、Qtに精通し、Qt検討時のサポート、導入コンサルティング等を提供可能です。ご興味ある方は、SRAの営業担当もしく問合せページにご相談いただくか、KDABJapanのWebページよりお問合せください。
出典：Is Qt Right for Your Project?【KDAB】
KDAB日本語トップページ