こうしたことが、開発者が注目すべきポイントを変える。直立したテレビ画面やタイプライター型のキーボードによってITとユーザーが向き合うことはもはやなくなった。両者の関係は密になり、複雑さを増している。インタフェースだけでなく、ユーザーエクスペリエンス全体、そして多様性を増していく機器群にこれまで以上に目を向けなくてはならない。このことは開発者に多くの課題を課すが、同時に大いなるチャンスも生み出す。

サイズの問題

　明らかな問題の1つが、機能と画面サイズの多様化だ。モバイル機器の多様化がもたらす課題は、かなり前から認識されている。

　これには、UAProf（User Agent Profile）などのプロファイルや仕様がある。また、JavaやFlashなどの過去の試みを統一して基盤にしようと努めるHTMLの進化も含まれる。Javaはその誕生から長い年月を経ているにもかかわらず、今でもクロスプラットフォームのツールセットに不可欠な要素を提供する。

　この課題はまだ続いている。

　モバイル端末の画面サイズやアスペクト比が多様化しただけでなく、解像度も高精細や4Kコンテンツに対応するよう進化している。また、抽象化モデルを作成しようとする試みもある。このモデルは、開発者が検討を希望しているものだ。スマートフォンとタブレットのレイアウトを計画する際は、「Android」の開発者は密度非依存ピクセル（DP）について理解することが役に立つ。DPは、画面領域1インチ当たり約160ピクセルになる。Apple製品にも画面上の点の抽象化モデルがあり、DPと（完全にではないが）よく似ている。

　開発コードベースの一貫性を管理するのは今でも難しい。だが、大手企業や新規参入企業が一様にツールを公開している。一部のプラットフォームは、「PhoneGap」が最初に世に広めたモデルを基盤に構築されている。それは、軽量のネイティブアプリが埋め込み型ブラウザを起動するモデルだ。オープンソースの「Apache Cordova」はAdobe Systems、Ionic、Telerik、Framework7、Evothingsが開発したPhoneGapツールから成る多様なエコシステムを内包している。

　クロスコンパイルでは、対象とするモバイル機器のネイティブコードに変換するためにScratchwork Developmentの「RubyMotion」、Xamarin（Microsoft）やAppceleratorの製品などを使用する。アプリケーションがデスクトップとモバイル端末の垣根を越えて適切に機能することを、これからも多くの企業が求めていくと予想される。つまり「Kony AppPlatform」「Pega Application Mobility Platform」（旧称「Antenna Mobility Platform」）、「SAP Mobile Platform」など、完全に機能するマルチデバイスエンタープライズ開発プラットフォームにさらに注目することになるだろう。

ウェアラブルへの対応

　ウェアラブル端末を対象とするアプリケーションの開発はさらに難しくなる。こうした機器は非常に小さな画面を備え、幾つものセンサーとデータフィードを収容する。ウェアラブル端末は急速なイノベーションを遂げている最中にあり、場合によっては突如として姿を消すこともある。こうした不確かさは、開発者が大規模なアプリケーション開発に投資することを難しくする。それでもこの分野が求めているのは、活気があり成長を続けるエコシステムに他ならない。単体で機能する高度な端末（「Galaxy Gear S」や最新の「iPhone」など）も登場しているが、多くのウェアラブル端末はアプリケーションレベルでコンパニオンとして機能する。また、スマートフォンのセルラー接続を許可なく利用することが多い。

　つまり、開発には特殊なスキルと独特のアプローチを必要とする。その結果、ウェアラブル開発プラットフォームはいまだ普及しておらず、汎用（はんよう）化していない。Samsung製端末を対象に開発する場合は「Tizen Studio」が便利な機能を多数提供する。また、Samsungは「Microsoft Visual Studio」を拡張する.NET開発者向けのツールも提供している。

　Googleの「Android Studio」を使用する開発者は、最新の「Android Wear 2.0」を含む全Android機器を対象に開発できる。また、実機がなくてもエミュレーターを使ってテストすることが可能だ。Android Wear 2.0の訴求力が強まったのは、Google製のスマートフォンを経由せず、ウェアラブル端末のGoogle Playストアでアプリを直接ダウンロードできるようにしたためだ。つまり、アプリは「iOS」端末（iPhone）とペアリングされているAndroid Wear端末で実行できる。

　Appleの「watchOS 4 SDK（Software Development Kit）」「WatchKit」やインタラクティブ開発環境の「Xcode」がスマートウォッチアプリの開発者をサポートする。またエンタープライズアプリの開発者には、エンタープライズ開発サポートプログラムや「In-House App Accelerator Guide」などの便利な概説ガイドも提供している。

　Amazonも2017年にリリースした「AVS Device SDK」の簡易版「Alexa Mobile Accessory Kit」により、ウェアラブル分野の幾つかの面でプレゼンスを得ようとしている。より高度な端末用には、レファレンスソリューション「Alexa Premium Far-Field Voice Development Kit」を提供している。このアプローチにより、Amazonはウェアラブル端末と「装飾品のような」機器に同社の音声アシスタントを追加するコストと労力を減らそうとしている。

「話し相手」になるモバイル端末

　音声認識はSFで長く取り上げられてきたテーマで、1980年代初頭から何らかの形で存在している。そしてその人気は昨今、インターネットに接続されるスマートスピーカーによって急成長した。進化を続けるこの音声ユーザーインタフェースは、Amazonが「Alexa」で必要としているだけではない。主なテクノロジー企業も市場でチャンスをつかもうと準備を進めている。「Siri」「Googleアシスタント」（同社の「Google Now」と似ているがより人工知能要素が強い）、Microsoftの「Cortana」、Samsungの「Bixby」など、さまざまなパーソナルアシスタントが登場した。また、IBMの自然言語AIプラットフォーム「Watson」もその1つだ。

　これらのパーソナルアシスタントのモデルは全て、「スキル」と音声コマンドをリンクすることに基づいている。「スキル」とは何らかの操作を指し、典型的なAI対応のバックエンドによって結果として実行される。つまり、構築するエコシステムには音声認識技術とAIプラットフォームだけでなく、この「スキル」も含まれる。

　Siriはパーソナルアシスタントの先駆けの1つだが、Appleは他機器への拡張に慎重で、まだ閉ざされたシステムと見なされている。Microsoftは、自社の開発者遺産、非常に多岐にわたる開発製品（「Microsoft Azure」でクラウドネイティブなアプリケーションをサポートする「Cortana Intelligence Suite」など）を強みにしてパーソナルアシスタント市場に切り込んでいる。一方Googleはあの手この手のアプローチを取ってはいるが「スキル」の量の点で遅れている。そしてBixbyはSamsung製端末のサブセットでしか機能しない。

　最も先を進んでいるのがAmazonだ。Alexaで市場の波を取り込んでいるだけでなく、スキルの強力なエコシステムを作り出している。同社はこれを「Alexa Skills Kit」でサポートする。Alexa Skills KitはセルフサービスのAPI、ツール、ドキュメント、コードサンプルをまとめたものだ。

　これが重要なのは、他のプラットフォーム戦争と同じように、強力なエコシステムとサポートが不可欠になるためだ。開発者はどのプラットフォームが成功を収めるかに賭けることになる。そのため開発者が求めるのはツール、テンプレート、安定したAPIだけではない。信頼できるユースケースに対して市場性のあるソリューションを構築するための、適切なレベルのビジネスサポートも欠かせない。

　音声対応のコマンドとコントロールを扱っているのは大規模ベンダーだけではない。アイルランドの新興企業Voysisは、企業が音声入力を自社の製品、データ、ブランドに合わせて調整できるようにする独自の手法を開発している。他にもこの分野の新興企業にはConvessa、Smartly、Snipsなどがある。だが新興企業のMindMeldが最終的に落ち着いた場所（Cisco Systemsによる買収）を見ると、この分野は急速に成熟を遂げ、統合へと進んでいることが分かる。

　機器がウェアラブル化したり自宅や職場の棚の背後に姿を消したりしていくたびに、音声コマンドの重要性は増していく。1970年代のSFで描かれたレベルに達することは決してないかもしれないが、音声駆動の「スキル」を設計に組み込む最適な方法を、製品とアプリケーションの開発者が知っておくのは非常に有益だろう。

拡張現実

　音声と並んで視覚の強化も見られる。特にスマートフォン、ゴーグル、眼鏡を対象とした開発が進んでいる。没入型スクリーン技術の最近の進化は、デジタル情報で何をすべきかという考え方に変化をもたらしている。結局、データを常に1つの長方形の画像で表示しなければならない理由はなくなっている。「Google Glass」の再開発、「Microsoft HoloLens」、エプソンの「MOVERIO」は、スマートグラスが新しく興味深い段階に移っていることを示している。

　現在、拡張現実（AR）ツールは幾つも存在しており、その数は増え続ける一方だ。モバイル機器の機能、カメラ、センサーがより高度になるにつれ、現実世界と仮想世界をつないで重ね合わせる方法は進化していく。

　エンドポイント端末へのコンピューティング面での影響を最小限に抑える、よりシンプルなアプローチは、現実世界にマーカーを適用するものだ。マーカーは、認識または識別されるオブジェクトになる。もしくは、端末のカメラを使って認識しやすくなるよう環境に適用される。例としては、ARアプリの「Zappar」で使われる一意の円形のカードトークンが挙げられる。

　「Simultaneous Localisation And Mapping」（SLAM）などの技術は、仮想要素を適用する現実のモデルや地図を、機器が独自に構築する。こうした技術が進化するにつれ、マーカーの必要性は少なくなる。モバイル機器にセンサー、GPS、コンパス、加速度計が組み込まれることが増えている。また、それらがドローンに組み込まれることも、「Light Imaging Detection And Ranging」（LIDAR）などの自動運転車に使われる技術に組み込まれることもある。これによりマーカー不要のアプローチが実現されようとしているが、演算処理能力の利用は増える。

　これをクラウドベースのリソースと関連付けるのは非常に有益だ。現在、WikitudeのオールインワンAR SDKなどのツールが人気を集めている。オブジェクトと画像の認識を、インスタント検出とクラウドサービスにインテリジェントに結合するのがこうしたツールだ。企業や消費者を対象とした信頼できるARアプリケーションを試したい、または提供したいという開発者には、さまざまな選択肢が用意されている。

実験のとき

　あらゆる開発者と経理担当者にとって重要なのは、どのイノベーションが変化をもたらすかだ。

　こうした技術の多くは、まだユースケースに最適な形で落とし込む方法が模索され始めたばかりだ。つまり、今後かなりの量の実験をこなさなくてはならない。組織が現在アジャイルやDevOpsのアプローチを採用しているかどうかにかかわらず、新種のモバイル端末やエッジ機器に関していえばこのアプローチに大きなメリットがある。

　まずは具体的な目的を胸に、小規模から始めよう。試行を重ね、ユーザーに素早く導入する。そして最も重要なのが、ユーザーからのフィードバックを集め、それを組み込み、そのフィードバックを基に再構築することだ。選択肢は多数あるため、自分にとって適切なものを前もって判断するのは難しい。だが、ユーザーや顧客をできるだけ理解しようとするのは常に有益な方策だ。