品質管理の仕組みはプラットフォームによって異なる。「Appleの環境に比べると、Androidの環境は品質のばらつきが多い」と各方面で指摘されている。開発者にとっては、iOS向けのアプリ配布の認可を得る方がハードルは高く苦労が多い。Appleが品質を管理しているからだ。Android環境の場合は、開発者やモバイル事業者、OEM、米Googleの全員が品質管理の責任を担っている。

　だが全般的には、アプリケーション開発でハイブリッド方式を採用する開発者が増えている。HTMLやHTML5などのWeb技術やその関連技術を使いこなせる開発者は、1000万人以上もいるのだ。HTML5は多くのコーディングで使われており、将来はHTML5コーディングがネイティブ環境に対応するようになるだろう。つまり、コードの約80％がHTML5で書かれているため、今後はiOSやAndroidなどのプラットフォームのネイティブAPI（Application Programming Interface）にHTML5を適合させる方向に進むということだ。

　これは、過去2年間にわたる開発者の調査の中で浮かび上がった傾向だ。HTML5を使った開発への関心は非常に高まっている。開発コミュニティーでHTML5が一種の共通語になっているからだ。しかし将来的には、iOSやAndroidなどのネイティブプラットフォーム上で動作するようにHTML5を適合させる必要がある。このアプローチの利点は、異なるプラットフォーム間で多くのコードを再利用できることだ。しかし、プラットフォームのネイティブ機能を利用するには、ある程度のコーディング作業が必要になる。

　「ネイティブ開発ではなく、アプリのコーディングにHTMLを多用するというのは、品質を犠牲にするということだ」という見方もある。ネイティブアプリを開発しないというのは、表面的に見ればプラットフォーム間でのコードの再利用を優先し、パフォーマンスと品質の面で何かを犠牲にすることになる。すなわち、開発者がアプリをネイティブAPIに対応させる際にHTML5を多用すれば、アプリの能力の一部が損なわれる可能性があるということだ。

　これは主観的な見方だが、ネイティブ開発ではある程度のスキルセット、ある程度の予算、そしてある程度の時間が必要とされる。だが誰もがそれらを持っているわけではない。この3つの要素は大企業の場合でも問題になり得る。将来に目を向ければ、現在の異種混在状態が今後変化する兆しはどこにも見えない。つまり、これからもAndroid用のコーディング作業が必要になるということだ。iOSやその他のプラットフォームについても同じことがいえる。これらのプラットフォームはそれ自体で互いに競争しているだけでなく、外部に公開されるAPIの基盤およびパフォーマンス特性の面でも競い合っている。この状況が続く限り、APIをめぐる開発競争が今後も繰り広げられるだろう。これは、アプリをライフサイクルにわたって管理する必要があることを意味する。

スピードと品質に加えてテストという大問題が

　「Webベースのアプリケーションか、モバイルアプリケーションか、メインフレーム用アプリケーションかどうかは、あまり関係がない。きちんと動作しない場合に生じるリスクがどのくらいあるかによって、品質にどれくらい力を入れるかが決まるのだ」と指摘するのは、Gartnerのアナリスト、アイアン・フィンリー氏だ。

　モバイルアプリケーションの場合、従来のWebベースのアプリケーションよりもはるかに多くのテストを行う必要がある。多くの人はこの事実を意外に思うだろう。それはアプリケーションの開発の方に目を向け、テストには注目しないからだ（関連記事：モバイルおよびWeb向けアプリのQAテストのコツ）。

　モバイルアプリケーションのテストの特殊性を理解していない人は多い。モバイルアプリケーションの場合、複数の環境で動作することを確認しなければならないのだ。ブラウザ向けのアプリケーションの開発であれば、開発環境とエンドユーザーの環境がどう違っていようともブラウザは似たり寄ったりだ。しかしモバイルアプリケーションの場合、端末が同じ製品ファミリーであってもアプリケーションの動作方法には大きな違いがある。例えば、Android製品ファミリーでは、サイズ、速度、メモリ（これらはパフォーマンスに影響する）、そしてアプリケーションのルック＆フィールが異なる端末が文字通り何百種類も存在し、これらの違いは全て品質の問題につながる。コードが正しく実行されたとしても、ユーザーはそのアプリケーションが使い物にならないと思うかもしれない。

　また、アプリケーションの開発では通常、ネットワークを利用できる環境が想定されている。しかし携帯端末では電波の受信状態が一定ではなく、車の運転中に変化することもある。つまり、アプリケーションのパフォーマンスやルック＆フィールが通信速度によって悪影響を受ける可能性があるということだ。当然ながら、これは接続環境によって大きく左右される（関連記事：アプリケーションのパフォーマンステストを成功させる3つのポイント）。

　こういった要因を考え合わせれば、ユーザーがアプリケーションを使うさまざまな状況を全てテストするのが不可能であることが分かる。代表的な環境をテストするだけでも、デスクトップPC用のWebブラウザを対象としたテストよりもはるかに多くの労力が必要とされる。

　では、どうすればいいのだろうか。重要なポイントは、テストはリスクとのバランスが必要だということだ。例えば、コンシューマー向けのモバイルバンキングアプリケーションであれば、極めて高い品質が要求される。ハッカーに侵入されるようなものであってはならないのだ。こういったアプリケーションは銀行にとって大きなセールスポイントになる可能性もあるため、貧弱なパフォーマンスであったり使い勝手が悪かったりしてはいけない。また、モバイルアプリケーションとして開発するのだから、各種の端末およびOS上での動作をサポートするとともに、さまざまなネットワーク問題にも対処しなければならない。

　このようなケースでは、開発段階でシミュレータなどを使って広範なテストを行う必要がある。多くのユーザーが使用すると予想される端末上でのテストも欠かせない。このテストは開発部門で実施するだけでなく、クラウドテストプロバイダーに委託する必要もあるかもしれない。こういったプロバイダーは全世界にテスターを抱えている。テスターにテストスクリプトを与えて操作を指示し、その結果をクライアントに報告してくれる。モバイルバンキングアプリケーションのようなものを開発する場合は、このような広範なテストを実施することにより、あらゆる利用環境での動作を検証する必要がある。

　逆に、サポート対象のデバイスがiPad 2だけであり、接続状態が良好なネットワーク環境でアプリケーションを利用するだけという状況で、従業員の端末用にシンプルなアプリケーションを配布するというケースもあるだろう。その場合には、シミュレータおよびデバイスレベルでのテストだけで十分かもしれない。品質に対する要求がそれほど高くなく、配備環境（実際にアプリケーションを使うユーザーベース）もずっとシンプルであるからだ。