目次


モバイル・ソリューションを迅速に開発するための手法

小規模な設計・開発チームのための漸進的な実現手法

Comments

IBM CIO Lab Mobile Innovation チームでは、モバイル機器を使用して IBM 従業員の生産性およびセキュリティーを向上させるための社内ソリューションを開発しています。2010年後半の時点では、従業員たちがノート PC、携帯電話、タブレットなどでファイルを共有するのは困難でした。モバイル機器から従来のコンテンツ管理システムや共有ファイルシステムへアクセスするのは、制限が多くて面倒でした。プラグインで完全に補わない限り、特定のファイルは転送してもレンダリングされないか、機能しません。さらに、デスクトップ機器とモバイル機器との間でファイルを移植するのも簡単ではありませんでした。

この状況のなか、私たち CIO Lab Mobile Innovation チームは、社内で認可された機器を従業員が使用して IBM 内部のコンテンツにアクセスするための移植可能なソリューションを提供しなければなりませんでした。そこでチームが決定したのは、全データにアクセスする窓口としての役割を果たすとともに、転送可能なデータの小型キャッシュにもなるパイロット・ソリューションを開発することです。転送可能なデータは、ユーザーが各種のプラットフォームでより快適にコンテンツを使えるように、互換性のあるフォーマットに変換します。私たちはこのプロジェクトに MyMobileHub という名前を付けました。チームは小規模ですが、わずか 2、3 ヶ月で、Android、BlackBerry、および iOS プラットフォームでの使用可能性を示すとともに概念実証を行わなければなりませんでした。そして同じく 2、3 ヶ月後には、ネイティブ版のパイロット・ソリューションが機能することが必要でした。

この記事で説明する、チームがこのパイロット・ソリューションに適用した迅速な開発の概念の多くは、モバイル開発の分野でよく知られているものです。チームがこれらの概念を組み合わせて、マルチデバイス対応のエンド・ツー・エンドの社内ソリューションを開発した方法を知れば、皆さんが開発する次のモバイル・パイロット・ソリューションやモバイル・プロジェクトにも、いかに簡単に同じ方法を適用できるかがわかるはずです。

迅速な開発によるパイロット・ソリューションの計画

革新技術を用いたパイロット・ソリューションの開発は、通常は繰り返しのプロセスです。つまり、使用可能なソリューションを迅速に開発し、そのソリューションを身近な同僚や初期導入者と共有します。その後、ユーザー・ベースの拡大にあわせて機能を拡張し、コメントや提案を参考にして方向を修正していきます。これは、新しいソリューションを探求する場合の一般的な手順です。

急速に進化するモバイル分野でパイロット・ソリューションを成功させるには、これとはまったく異なる開発手法が必要でした。私たちは、チームの助けになる可能性がある数々の再利用可能な技術を詳しく調べました。その結果選んだのが、オープンソースの技術と IBM 社内ツールの組み合わせです。この組み合わせは、迅速な開発、クロスプラットフォーム・サポート、そして最先端機能の基準を満たします。

サーバー・サイドには、Play フレームワークを採用することに決めました。このフレームワークは、Ruby on Rails の MVC (Model-View-Controller) 概念に基づく RESTful なステートレス Java フレームワークです。クライアント・サイドの開発には、すべてのクライアントでルック・アンド・フィールとユーザー・エクスペリエンスに一貫性を持たせるために、PhoneGap、Dojo、Dojo Mobile を採用しました (それぞれの技術については、「参考文献」のリンクを参照)。

フォーマットの変換を予定しているファイルの小型キャッシュは、グループ化する必要があったため、ファイルシステムではなく、単純なデータベースを使用することにしました。選択したデータベースは、Apache CouchDB です。このスキーマレスのドキュメント指向 NoSQL データベースは、MapReduce を利用した単純で素早い動作をするビューでドキュメントの保管をサポートします。

CouchDB と Play は相性が良いため、円滑に作業を進めることができました。文書の変換パイプラインを構成する各種のメッセージとタスクは、Apache ActiveMQ を使用して管理しました。さらに、Apache HTTP Server をフロントエンドに配置することで、制御とロード・バランシングが追加でもたらされました。繰り返しますが、このパイロット・ソリューションで目的としたのは、ソリューションの実現可能性を探るとともに、ユーザーの要件と使用パターンを理解することです。再利用する可能性のある主要なコンポーネント、概念、設計は、本番用の準備が整った時点で簡単に他のプラットフォームに移すことができます。

私たちのチームでは、増え続ける最新のモバイル機器に対応するために、社内ツールの助けを借りて、WURFL プロジェクトから取得するモバイル機器の仕様を特定しました。WURFL プロジェクトは、スマートフォンの機能や画面サイズなどの情報をすぐに入手できるリポジトリーです (「参考文献」のリンクを参照)。このツールにより、機器の機能に応じてアプリケーションのコンテンツを最適に表示する方法を簡単に判別することができました。

チームがこのパイロット・ソリューションから得た価値は、全般的な内部成果物 (コード) そのものだけではありません。ユーザーがこのパイロット・ソリューションをどのように使用するかを理解できたことも得られた価値の 1 つです。さらに重要なことに、モバイルとハイテクに精通したユーザーの問題を解決する経験にもなりました。パイロット・ソリューションの初期導入者は臆することなく、チームが特定の問題を解決しているかどうか、彼らのワークフローに適合しているかどうか、あるいは使いやすさや生産性に対する彼らの期待を満たしているかどうかを伝えてくれました。チームがユーザーの生産性とセキュリティーを向上させるというミッションを果たしていない場合には、私たちはソリューションを新たに考案し、新しい角度から問題に取り組みました。

MyMobileHub の概要

私たちが開発したソリューションは、ユーザーが自分の端末間でファイルを共有する簡単な方法を提供します。モバイル機器で開きたいファイルを自分宛にメールで送る代わりに、MyMobileHub を使ってファイルをデスクトップからブラウザーにドラッグ・アンド・ドロップすれば、そのファイルはブラウザーを介してサーバーにアップロードされます。ユーザーは、このサーバーにモバイル機器から接続することができます。ただし、ユーザーには元の体裁がどうであろうとも、デスクトップ PC の場合とは異なる UI によってファイルを表示できるようにしています。さらに、ユーザーが簡単にマルチメディア・コンテンツを作成してアップロードできるように、このソリューションではモバイル・カメラと音声機能も利用します。

ノート PC とデスクトップ PC のビュー

ノート PC とデスクトップ PC 向けにサポートするブラウザーは、ドラッグ・アンド・ドロップ対応のブラウザーのみです。ユーザーはブックマーク、文書、またはその他のファイルをブラウザー・ウィンドウにドラッグします (図 1 を参照)。私たちのソリューションでは、解釈可能な形式の文書についてはプレビューを提供し、その文書の PDF 版を作成して、モバイル機器でも簡単に使えるようにします。変換を予定しているファイル・タイプは他にもあります。例えば、音声ファイルをテキスト・ファイルに変換するなどです。

図 1. MyMobileHub の外観
MyMobileHub のスクリーン・ショット
MyMobileHub のスクリーン・ショット

デスクトップ・ブラウザーは、ファイルをアップロードして整理するための便利な手段となります。プレビュー・イメージは、ファイルごとに自動的に生成されます。ユーザーはリスト形式または表形式のビューを選択して、ファイルを視覚的に管理することができます。動的に色分けされたラベルによって、従来のファイルシステム階層の不便さに煩わされることなく、ファイルを整理できるようになっています。ファイルとラベルのフィルター、さらにクイック検索機能も加わって、ファイルを素早く簡単に見つけることができます。

モバイル Web アプリケーション

スマートフォンとタブレットのブラウザーは、かなり進化しています。スマートフォンとタブレットのブラウザーでは、Dojo Mobile と JavaScript を使用してリッチ・アプリケーションに対応することができます。機器のタイプを確認する内部の機器識別サービスによって、再利用可能なコード、HTML、CSS の適切な組み合わせを選択し、機器にダウンロードできるようになっています。したがって、機器の能力に応じて最適なページが表示されます。iPad のような機器では、Web アプリーションのページがデスクトップ・ブラウザーでの Web アプリケーションのページと非常に似通った表示になるため、シームレスなユーザー・エクスペリエンスが提供されます。図 2 を見るとわかるように、このユーザー・エクスペリエンスは Web ページというよりも、アプリケーションといった感じです。ユーザーは、ファイルのダウンロードを要求したり、表示および書庫へ格納するために PDF 版のダウンロードを要求したり、あるいは Web ページのブックマークを呼び出したりすることができます。

図 2. MyMobileHub モバイル Web アプリケーション
MyMobileHub モバイル Web アプリケーションのスクリーン・ショット
MyMobileHub モバイル Web アプリケーションのスクリーン・ショット

モバイル・ネイティブ・アプリケーション

ネイティブ MyMobileHub アプリケーションは、モバイル・ブラウザーで動作する Web アプリケーションと同じように見えますが、モバイル機器上で作成されたコンテンツをアップロードする機能が追加されています。ユーザーは、音声や動画を記録したり、写真を撮ったり、ギャラリーから写真を選択したりすることができます。そのいずれのコンテンツも、MyMobileHub から直接アップロードすることができます。

図 3. MyMobileHub ネイティブ・アプリケーション
MyMobileHub ネイティブ・アプリケーションの 3 つのスクリーン・ショット
MyMobileHub ネイティブ・アプリケーションの 3 つのスクリーン・ショット

効率性を実現するための出発点: 方法論、手法、設計

コーディング作業に取り掛かる前に、私たちはさまざまな技術について調査しました。使用するツールの選択は、正しい方向へと踏み出すためのプロセスとして慎重に行いました。私たちは、ユーザー・エクスペリエンスの設計者たちとユーザー・インターフェースの設計者たちを 1 つのグループにまとめ、開発者たち (ユーザー・エクスペリエンスとユーザー・インターフェースの両方) も 1 つのグループにまとめ、さらに Web 開発のエキスパート (ブラジル在住) を引き入れました。各グループに与えられた任務は、使用するさまざまな手段 (グラフィック・デザイン、HTML5、CSS、UI ウィジェット、サーバー機能など) の効率性について互いに教え合うことです。グループが互いに教え合うことによって、問題点や効率的な手法を共有したのです。

また、コマンドが特定のオペレーティング・システム・レベルおよびブラウザー・レベルをサポートしないという決定も行いました。HTML5 対応のブラウザーに対処することに焦点を絞り、それによって開発プロセスを単純化することができました。その効果は、関連する技術の動向を認識し、ソフトウェアとハードウェア両面での進化を予測できたことです。例えば、HTML5 対応のブラウザーに焦点を絞ることを決定した 3 ヶ月後には、すべてのモバイル機器が HTML5 をサポートするようになっていました。

単一のデータを複数の CSS で処理する

モバイルの観点で最初に行った設計上の主要な決定事項の 1 つは、できるだけ多くの UI および体裁に関連する項目に CSS と HTML5 で対処しようとすることです。こうすることで、コードを単純化できるだけでなく、すべてのモバイル・プラットフォームで統一されたコードを使用することができます。

サポートする必要があったのは、iPhone、iPod Touch、iPad、BlackBerry、Android フォン、Android 搭載の 7 インチ程度のサイズのタブレットから 10 インチ前後のサイズのタブレット、そして Mac、Linux、および Windows 搭載のデスクトップ PC です。それぞれのプラットフォームに対応するカスタム・コードの行を加えるごとに、信頼性に対する脅威と複雑さが増してきます。私たちは、単一のデータを複数の CSS で処理するというモデルに従いました。このモデルでは、同じ JSON (JavaScript Object Notation) データ・ソースを使用して、プラットフォームごとにほんのわずかなカスタム CSS を加えるだけで、それぞれのプラットフォーム向けにまったく異なる UI を作成することができます。

これを実現するために、プラットフォームごとにカスタム CSS モジュールを作成しました。Web アプリケーションの場合、機器がサーバーに対して HTML を要求すると、その機器の種類を検出して、該当するカスタム CSS モジュールを動的にロードします。ネイティブ・アプリケーションに関しては、アプリケーションをロードできるプラットフォームの種類はすでにわかっているので、画面のサイズや OS のバージョンだけをカスタマイズするだけで済みます。その一例は、iPhone と iPad のアプリケーションです。この 2 つのアプリケーションは、同じコードの 99.9 パーセントを共通で使用しますが、動的 CSS の能力のおかげで、それぞれの画面サイズに適したルック・アンド・フィールになっています。

リスト 1 に、iPhone と iPad の CSS モジュールを記載します。

リスト 1. iPhone と iPad の CSS モジュール
.loginScreen {
    background-image: url(../images/splashBG.png);
    background-repeat: no-repeat;
    background-size: 320px;
}

.loginScreeniPad {
    background-image: url(../images/splashBGiPad.png);
    background-repeat: no-repeat;
    background-size: 768px;
}

PhoneGap を使用することで効率性を高める

私たちはチームを増員し、ほとんどのモバイル・プラットフォームに対応するカスタム・アプリケーションの開発を専門とするエキスパートを迎えました。通常は、モバイル・プラットフォームごとのエキスパートにカスタム・アプリケーションの開発を要請しますが、期間が限られていたこと、そして比較的単純な UI を想定していたことから、通常とは異なる手法を採りました。そして、Web アプリケーションの機能の大部分を HTML5 と CSS で対処するように努めた結果、HTML5 と CSS を PhoneGap でラップしてネイティブ・アプリケーションに組み込むことができました。

PhoneGap のようなツールは、概念においては単純です。まず、モバイル Web アプリケーションを JavaScript、HTML、および CSS 技術を使って作成します。PhoneGap は、そのアプリケーションをネイティブ・アプリケーションとしてパッケージ化します。パッケージ化されたネイティブ・アプリケーションの主なタスクは、内部ブラウザーを呼び出して、その Web アプリケーション (WebView) だけを表示することです。これで、ネイティブ API (例えば、機器に組み込まれているカメラの API) には、Web アプリケーションをネイティブ・コードにリンクする JavaScript を呼び出すことでアクセスできるようになります。カメラにアクセスするための JavaScriptコードはどの機器でも同じなので、この場合も、複数のプラットフォームに単一のコード・ベースで対処するという目標の達成を確固たるものにします。リスト 2 のコード・スニペットに、単純な JavaScript 関数だけを使って機器に画像を取り込む方法を示します。

リスト 2. 単純な JavaScript 関数による画像の取り込み
mmh.phonegapActions.captureImage = function() {
    navigator.device.capture.captureImage(
		dojo.partial(mmh.phonegapActions._captureSuccess, "image"), 
            mmh.phonegapActions._captureError, {limit: 1});
};

PhoneGap などのツールを使用することには、欠点も伴います。その 1 つは、ネイティブ・コードで作成されたアプリケーションよりも、明らかに効率性と速度に劣ることです。大きな負荷の実行タスク (複雑なグラフィックスのアニメーションなど) のなかには、ネイティブ・アプリケーションが応答性に優れていなければならないものもあります。また、Ripple や WEINRE (「参考文献」を参照) といったツールの登場によって状況は改善されてきてはいますが、デバッグおよびテスト用のツールはまだ初期段階にあります。ハードウェア層については、そのままではネイティブ・アプリケーションでのように柔軟に制御することができません (この欠点を克服するには、カスタム PhoneGap プラグインを作成するという方法があります。また、特定のタスクに使用できるプラグインとして、さまざまなプラグインを利用できるようになってきています)。これらの欠点はあるものの、コードを大幅に再利用できるというメリットは、PhoneGap の欠点を補って余りあるものです。

PhoneGap を使用する際には、ネイティブ・アプリケーションを中心にしたアプリケーションの設計をしなければならないという点も考慮する必要があります。アプリケーション開発者にさまざまなモバイル・プラットフォームの知識があれば、ネイティブ・コードを作成せずにネイティブ・アプリケーションの使い勝手を実現することができます。チームの現在の革新サイクルでは、優れた設計の Web アプリケーションをネイティブ・アプリケーションに変換する作業のスピードは至って十分です。私たちは PhoneGap を使用して、Android Web アプリケーションをわずか 2 日足らずで、音声/動画/画像の記録機能、ネイティブの通知ウィンドウ、およびハードウェアの「メニュー」ボタン、「戻る」ボタン、「ホーム」ボタンをサポートするネイティブ・アプリケーションに変換しました。さらに、そのコードを BlackBerry に再利用することもできました。

効率的に変更を反映する

ユーザー・エクスペリエンスの設計者および UI 設計者と上手く協力して、最善だと思える UI に仕上げたとしても、ユーザーが単純なタスクを行う方法がわからないと苦情を訴える場合もあります。(その部分は設計時にどうして見落とされたのでしょう?)

その場合、ユーザー・エクスペリエンスを単純化するための変更を考え出したとすると、Web アプリケーションとネイティブ・アプリケーションのすべてに、その変更を反映する必要が出てきます。プラットフォームのすべてにわたってコードを大幅に再利用できなければ、開発者が個々のプラットフォームごとにその変更作業を何度も繰り返さなければなりません。プラットフォームの数に再実行しなければならないテスト・ケースの数を掛けると、小さな変更でも恐ろしいほどの作業量になってしまいます。ここでもやはり、体裁の設定を HTML5 と CSS に頼ることで、変更の大部分をより少ない変更量に抑えることができます。単一のデータを複数の CSS で処理するという方向に従うことで、コードの変更による影響は少なくなります。Web アプリケーションをテストした後、その変更を PhoneGap によるネイティブ・アプリケーションに盛り込めば、それで作業は完了です。

私たちが実際に体験した例を挙げると、それは、「更新」ボタンの組み込みです。同期していない可能性があるデータを再スキャンできるという安心感をユーザーに与えられるように、「更新」ボタンを組み込むことにしました。この機能を Android で開発してテストした後、かなり自信を持って、同じコードをすべてのプラットフォームで再利用しました。そして、すべての機器で適切なルック・アンド・フィールになるように CSS をわずかに調整しただけで、この機能が完成しました。

この再利用手法を使用して新しい機能を開発する場合の時間を概算すると、最初に機能の開発にかかる時間が全体の 90 パーセントで、その新しい機能をすべてのプラットフォームで動作させるためにかかる時間が約 10 パーセントです。この同じ機能をネイティブ・プラットフォームごとに、異なる API、言語、フレームワークを使って作成し直さなければならないとしたら、明らかに話は違ってきます。

この再利用手法は、バグを修正する場合にも適用されます。iPhone Web アプリケーションの UI にバグが見つかったとすると、同じコードの 99 パーセントを共有する iPad、Android、および BlackBerry にも同じバグが存在するはずです。けれども、この手法では、1 つのプラットフォームでバグを修正すれば、すべての Web アプリケーションを修正できることになります。さらに、ネイティブの環境ではバグの原因を正確に特定するのも簡単です。

すべてのグラフィックスを処理する一連のスプライトもありますが、CSS と Dojo Mobile によって、大々的な追加作業を行うことなく、それぞれの機器に適した表示内容にしています。

完璧なプロセスに仕上げるための作業

私たちは引き続き、このプロセスの開発および効率化を進めることで、すべてのプラットフォームでのサポートを改善するために必要となるカスタマイズ作業を減らせるようにしています。その一例は、機器でのネイティブ・ナビゲーションです。iOS 機器にはハードウェアによる「戻る」ボタンや「メニュー」ボタンがありませんが、BlackBerry および Android 機器には (少なくとも Android 4.0 までは) これらのボタンがあります。その上、BlackBerry と Android とではメニュー・ボタンの動作が異なります。この違いを克服するために、JavaScript コードを別個のウィジェットに分離することで、コードの他の部分にほとんど、あるいはまったく影響を与えることなく、ウィジェットを挿入したり、それぞれのプラットフォームに合わせてウィジェットを変更したりできるようにしました。コードを CSS から切り離さないようにすることは重要ですが、コードを簡単に再利用または置換できるようにコンポーネントをモジュール化することも同じく重要です。

このように私たちは、単一のデータを複数の CSS で処理するという方針に従い、特殊な例に対処するために作成するコードの量を最小限にすることに成功しました。

Web アプリケーションとネイティブ・アプリケーションの比較

Web アプリケーションとネイティブ・アプリケーションのどちらをデプロイしたほうがより適切なのでしょう? CIO Lab Mobile Innovation での私たちの経験から言うと、その答えは、両方です。最近のスマートフォンとタブレット・コンピューターのブラウザーが進歩したおかげで、Web アプリケーションはモバイル機器でも見事に機能します。ただし、現時点では、ネイティブ・アプリケーションのほうがネイティブ・ハードウェアの機能にアクセスしやすくなっています。

ただし、どちらがより適切なのかだけが、デプロイするにあたっての判断基準となるわけではありません。私たちのソリューションを試験的に使用しているユーザーたちは、ネイティブ・アプリケーションをインストールするのを躊躇しています。その一部は、単にこのソリューションを使用する決心がついていないだけのことです。ユーザーは、ネイティブ・アプリケーションをインストールする前に、試験的に使用することを望みます。そして、ネイティブ・アプリケーションをインストールすると、保守と更新が必要になります。

この革新技術のゼロ・インストール・ポリシーを維持するためには、Web アプリケーションとネイティブ・アプリケーションの両方をサポートしなければなりません。しかも、ユーザーは予想以上に多くの機器を使い回すものです。新しい機器を入手したユーザーは、ネイティブ・アプリケーションをインストールする前に、まず Web アプリケーションを試します。機能、設計、そしてデプロイにかかる時間との間には、常にトレードオフが伴います。

まとめ

この記事で説明したモデルに従ったソリューションのパイロット開発は、私たちと同じようなチームが、自分たちのアイデアの本質的価値を詳しく調査する上で役立ちます。このプロセスは、問題を解決するために使用できる最善のツール (オープンソースのツールと社内ツール) について慎重に調べるところから始まります。ツールを選択した後は、機能と設計のトレードオフを分析することができます。製品化までの速さと機能の完全性との相対的な価値を理解することが、パイロット・ソリューションを成功させるために必要な場合もあります。ユーザーによるフィードバックと導入によって本質的価値が明確になった後は、パイロット・ソリューションを本番サービスまたは製品に変換するプロセスを開始することができます。

この記事から学んだ手法を次のプロジェクトに適用して、皆さんのチームと、そして最終的には皆さんが開発するソリューションのユーザーの効率性と生産性を向上させてください。記事で説明したパイロット・ソリューションには、ユーザーからの要望で多くの変更が必要となっていますが、この小規模なチームでもユーザーの変更要求に対応できることに確信を持っています。最初に選択した手法の効率性のおかげで、私たちは設計を効率化し、数週間の周期で繰り返されるプロセスを開発できたからです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Mobile development
ArticleID=832956
ArticleTitle=モバイル・ソリューションを迅速に開発するための手法
publish-date=09062012