2013年のスマートデバイスと、それを取り巻く環境

2013年のスマートフォンやタブレットのトレンドについて、開発者向けに考えてみました。マクロ（巨視的）な話から始まり、ミクロ（微視的）な話にも触れます。下記のトピックに触れています。

クラウド中心アーキテクチャへの移行
デバイスの多様化
スマートフォンとタブレットの「2台持ち」
デバイスフリー化を推進するための技術
HTML かネイティブか、アプリのアーキテクチャ
ますます普及することで生じる大きな機会

まずは「クラウド中心アーキテクチャへの移行」という話です。

ユーザインターフェースの進化

スマートフォンやタブレットのようなタッチスクリーンデバイスは、次のような大きな歴史の流れの中にあります。

CUI：キャラクタユーザインターフェース（文字ベース）
GUI：グラフィカルユーザインターフェース（視覚的）
NUI：ナチュラルユーザインターフェース（より自然に）

CUI→GUI→NUIという進化は、より多くのマシンパワーをUIに投じるような進化の歴史です。

たとえば、iPhoneの（俗に「ヌルヌル動く」と賞される）滑らかな画面スクロール描画を実現しているGPU（グラフィック処理装置）は、一昔前のスーパーコンピュータよりも高い性能を持ちます。

これは何を意味するのでしょうか。それを考えるために、ネットワークコンピューティングアーキテクチャ（ネットワークを用いたコンピューターの利用方式）の歴史を振り返りながら考えてみましょう。

アーキテクチャの進化

ユーザの手元で動く「ローカル・マシン」と、ネットワークの向こうにある「リモート・マシン」の配置に注目して、ネットワーク・コンピューティング・アーキテクチャの歴史を振り返ってみましょう。

大昔：コンソール（ダム端末）とメインフレーム
1990年代：クライアント（PC）とサーバ
2000年代：ブラウザ（PC・ケータイ）とWebサーバ
2010年代：アプリ（PC・スマホ・タブレット・その他の多様なデバイス）とクラウド

補足すると、「⁠アプリ」と「ブラウザ」の区別が曖昧になってきています。「⁠ブラウザ」は「アプリ」の一種ですし、後述の「クラウド中心アーキテクチャ」において「アプリ」はWebサービスの「専用ブラウザ」であるとも言えます。

さて、現在はどういう時代で、今後どうなっていくのでしょうか。私の解釈は次の通りです。

「ローカルマシンはUIにマシンパワーを惜しげも無く投入し、UI以外の処理（アプリケーションロジック）をリモートマシンに頼る」というアーキテクチャが主流になってきており、また今後もその流れは止まらないでしょう。

このようなアーキテクチャを「クラウド中心アーキテクチャ」と呼ぶことにしましょう。コンピューティングの中心がクラウドにあるからです。

クラウド中心アーキテクチャでの「ローカルマシン」（⁠スマートフォンやタブレット）の役割は、大昔の「ダム端末」に似ています。

「ダム端末」は、処理能力を一切持ちません。サーバに接続されて、初めて役に立つCUI端末です。「⁠キーボードが押された」という信号をサーバに送り、サーバからの文字信号を受け取って画面に表示するだけの、UIに特化した端末です。

スマートフォンやタブレットがUIに特化していくとして、そのような「クラウド中心アーキテクチャ」と、大昔の「メインフレーム中心アーキテクチャ」は、よく似たアーキテクチャです。

今後は、

ローカルマシンはUIに特化し、
リモートマシンにアプリケーションロジックとデータを任せる、

という傾向がより一層進むのではないでしょうか。つまり、

クラウド中心アーキテクチャへの移行
ローカルマシンの「ダム端末」化

が進む可能性が高いと考えています。

「iPhoneの滑らかなUIを可能にするために、一昔前のスーパーコンピューター並みのマシンパワーが投入されていることの意味」を解釈する準備ができました。それは、「⁠クラウド中心アーキテクチャへの移行」と「ダム端末化」の結果として、現代のネットワークコンピューティングアーキテクチャでローカルマシンに残された最も重要な仕事は「ユーザインターフェースの処理」である、ということです。

スマートフォンやタブレットが膨大なマシンパワーをUI処理に投入するように設計されていることは、単なる「スマートフォンの単独進化の結果」ではなく、ネットワークコンピューティングアーキテクチャという「エコシステム」の中での進化の結果なのです。ですから、かなり強い必然性があり、そう簡単には覆らないだろうと考えられます。

もちろん、まだ現時点では過渡期です。クラウドにすべてを依存するアプリは、「⁠ネットワークがつながらなければ、まったく利用できなくなる」という弱点を抱えています。2013年のうちにこの問題が解決されることはないでしょうから、まだまだクラウド中心アーキテクチャへの全面移行は時期尚早です。

もし何年も提供し続けるつもりでアプリを新規開発するなら、「⁠クラウド中心アーキテクチャへの移行」というトレンドを意識しておいたほうがよいでしょう。数年後のエコシステム、とくにネットワークインフラは、ますますクラウド中心アーキテクチャを後押ししているはずだからです。

デバイスの多様化

スマートフォンやタブレットの画面サイズが多様化していきます。それに加えて、周辺機器も多様化していきます。それを後押しするようにFabやMakerのようなハードウェア開発ムーブメントがありますし、KickstarterやCAMPFIREのようなクラウドファンディングのムーブメントもあります。とくにCerevo DASHは独自ハードウェア開発プロジェクトに特化したクラウドファンディングの仕組みであり、注目に値します。

ハードウェア開発の敷居が下がる中で、コンテンツやサービスに携わるWeb開発者も、ハードウェア込みでの企画・設計に取り組める時代になりつつあります。「⁠ネット連動デバイス」を作ることは現実的選択肢になりつつあります。

スマートフォンとタブレットの「2台持ち」も増えるでしょう。それも「デバイスの多様化」です。「⁠スマートフォンとタブレットを同時に使うことで、より便利になるようなアプリ」の提案も、今後は可能でしょう。たとえば「iPadのKeynoteを、Bluetooth接続したiPhoneのRemoteで操作する⁠」⁠ という連携は好例です。

デバイスフリー化

デバイスが多様になっていくと、ある時点から個別デバイスへの対応が非合理的になってきます。個別対応ではコストがかかり過ぎるのです。

そこで、「⁠特定のデバイスに個別対応していく」という考え方から、「⁠特定のデバイスに依存しない（デバイスフリー）ようにする」という考え方への転換が起こるでしょう。

デバイスフリー化を推進するためには多様な技術が必要になります。とくに、HTML5、WAI-ARIA、プログレッシブエンハンスメント、RESTful API、JSON、OAuth などの技術が必要になるでしょう。

そのために、情報アーキテクトやWebデザイナーと、ITアーキテクト（エンジニア）の協力が一層重要になるでしょう。

HTMLかネイティブか

スマートフォンやタブレットのためにアプリを作るうえで最初に悩むポイントが「HTML5 アプリとして実装するか」「⁠ネイティブ・アプリとして実装するか」です。

残念ながら、今後も悩まされることになりそうです。

最近は、ネイティブアプリでありながら、WebView（アプリ内ブラウザ）機能を活用して、ほとんどの機能をHTMLで実装するアプリも増えているようです。そのようなアーキテクチャ（設計方式）を「ガワネイティブ」と呼んでいます。

スマートフォンやタブレットの処理能力が上がったことで、HTMLアプリ方式でも多くの場合、十分な性能を出せるようになりました。「⁠ガワネイティブ」が現実的な選択肢になってきました。

また、「⁠リーン・スタートアップ」的な仮説検証をする上で重要な、ログ解析の面でも、HTMLのほうが有利でしょう。

「最初はHTMLで実装し、あとから段階的にネイティブ化していく」という方法もあります。

HTMLベースなら、基本的にはOSやブラウザを問わず動作することが期待できます。初期にローコストで多くの端末・機種に対応する上では有力な選択肢です。

しかし、HTMLアプリにも欠点があります。Android機種を幅広く対応しようとすることには、大きな工数リスクがあります。Android端末ごとに異なるブラウザの挙動が、開発者を苦しめます。工数の期待値は低い、ローコストなのですが、工数の上ブレリスクが大きい、ハイリスクなのです。

たいていの案件規模・予算規模では、多くの機種でHTMLアプリの動作を保証することは難しいでしょう。ですから、「⁠ネイティブ方式のほうがローリスクだ」と考える開発者も多いのではないでしょうか。

年次予算策定プロセスが堅い会社では、「⁠ハイコストだがローリスク」な選択肢のほうがいいかもしれません。そうでなければ、そもそも予算が組めないかもしれません。あとから「追加予算が必要なのに獲得できない」といった事態に陥らないために。

一方、ネイティブアプリは、AndroidやiOSやWindowsなどのプラットフォームごとに開発する必要があります。複数プラットフォームに対応するため、開発コストは大きくなります。

また、ネイティブアプリは、プラットフォームのバージョンアップにあわせて保守していく必要があります。HTMLアプリは将来の端末でも動くことを期待しやすい（互換性が高い）といえますが、ネイティブアプリはずっと保守し続ける必要があります。

また、プラットフォームのバージョンアップに伴う保守コストを事前に見積もるのは困難なので、いきなり新機種が出た場合（たとえばiPhone 5のように以前と異なる画面サイズが出た場合⁠）⁠、改修予算がなくて困るかもしれません。

結局どちらにしてもプラットフォーム提供者の一方的な都合による突発的な改修コストは発生しうるわけです。じつに悩ましいです。

ひとまず話を整理しておきます。 2013年のアプリ開発者は、下記のような論点のトレードオフで悩まされることになりそうです。

市場に受け入れられる可能性は高いアプリか／チャレンジングなアプリか
直接の収益を生むアプリか
数年に渡って提供し続け、保守し続けるアプリか／キャンペーン用などの単発企画か
複数のプラットフォームをカバーするアプリか／単一のプラットフォームに特化したアプリか

また、自分の開発チームがどちらの技術に長けているか、という組織学習や組織戦略の観点も重要です。「⁠限られた学習リソースを、どの技術に投じるか」という問題。いわゆる技術戦略、CTO（最高技術責任者）マターです。

ちなみに、私自身は「ガワネイティブHTMLアプリ」を新規開発時の出発点にするのが好きです。必要な部分を漸進的にネイティブ化していく想定での「出発点」です。アーキテクチャを、静的な「正解」を選ぶ問題ではなく、動的な「適応」の問題として捉えているので、ガワネイティブは都合が良いのです。

実践上の課題は、開発ロードマップと予算策定プロセスと事業計画プロセスを整合させることです。ディレクターやプロデューサーが、アーキテクチャ選定において大きな役割を担うことになります。そこでは「リーン・スタートアップ」的な考え方が役に立ちます。

社会への普及

最後のトピックは、スマートフォンやタブレットの普及についてです。

2013年1月現在、「⁠スマートフォンの進化はすでに踊り場に差し掛かっている」「⁠タブレットはまだ進化途上だがiPad miniの登場でカテゴリとして成熟してきた」という実感を持つ開発者の方も多いのではないでしょうか。

一方、それらのデバイスの、社会への普及はまだまだこれからです。現在はスマートフォンがフィーチャーフォン（ガラケー）を完全に置き換えていく過程にあります。スマートフォンとフィーチャーフォンの比率がある水準を超えてくると、そこに大きなチャンスが生じるはずです。

たとえば、iPhone登場初期に試された数多くの実験のなかから「早すぎた失敗」を見つけて再挑戦することも考えられます。単にユーザー規模が10倍になるだけで、新規事業の成功の条件は整ったりするものです。

これは歴史の教訓です。 2000年のネットバブルと、2005年のネットバブルでは何が違ったかというと、事業収益の有無です。2000年には期待だけがあり、2005年には利益がありました。その決定的な違いをもたらしたのはインターネットユーザ数の違いであり、その背景には高速で定額の常時接続サービス、いわゆるブロードバンドの普及があります。

ブロードバンド化の過程は「インフラの充実がネットサービスの収益化を用意にした」と言い換えることができます。同じことがスマートフォンにも起こるでしょう。LTE とテザリングの登場は、スマートフォンやタブレットの普及を後押しするだけでなく、スマートフォンとタブレットの「2台持ち」も促進するでしょう。

スマートフォンやタブレットについては、まだまだ大きな機会がありそうです。

おわりに

下記のトピックに触れてきました。

クラウド中心アーキテクチャへの移行
デバイスの多様化
スマートフォンとタブレットの「2台持ち」
デバイスフリー化を推進するための技術
HTML かネイティブか、アプリのアーキテクチャ
ますます普及することで生じる大きな機会

数年前から提唱されてきた「モバイルファースト」という理念が、いよいよ現場の実感を超えてネットユーザの生活実感にも至る。「⁠そういえば家のパソコンを全然触らなくなった」という人が目に見えて増える。 2013年はそのような年になるだろうと予感しています。