エンタープライズモバイル活用指南(6) BtoCのモバイル活用における課題と解決策（後編）

エンタープライズモバイルのなかで成功への難易度が最も高いBtoCのエンタープライズモバイルについて、前回は「いかに使ってもらうか?」について説明しました。今回は、「作る（開発する）うえでの注意点」について説明したいと思います。作るうえでの課題について、解決策を明示するのはなかなか難しいのですが、まずはリスクとなるポイントを認識しておくことが重要です。

対象機種の多様性による課題

多くの日本企業では、個人所有のスマートフォンやタブレットを利用することは認めず、会社から支給しているケースが多いと思います。その場合、支給端末は1種類であることがほとんどであるため、アプリでは複数機種に対応する必要がありません。

一方、今回テーマとしているBtoC（コンシューマー向け）となると、バージョン違いを含むさまざまなOSや多様な解像度、画面サイズに対応しなければなりません。特に設計から開発工程においては、以下のような事項に対して注意が必要です。

1. 開発言語の選択
2. 端末やOS固有の特徴（クセ）を考慮した開発
3. UIデザインの調整
4. OSベンダー（AppleやGoogle）からの仕様変更などへの対応

以降では、それぞれについて説明していきましょう。

1. 開発言語の選択

iPhone、iPadのOSであるiOSの場合、Objective-C、SwiftといったAppleが提供している開発言語を使って開発するか、HTML5と呼ばれるWeb系の技術を使って開発するかの2つの選択肢があります。サムスンのGalaxyやソニーのXperiaのOSであるAndroidであれば、開発言語の選択肢はJavaかHTML5のいずれかです。

したがって、両OSに対応したアプリを作るにはOS固有の開発言語を使ってOSごとに開発するか、HTML5といった共通の言語で開発するかを選択する必要があります。

それぞれのメリット・デメリット、特徴など、アーキテクチャの話はここでは説明しませんが、どちらを選択してもかなりの可能性で起こりうる課題や注意点を以下に挙げておきます。

iOS、Android固有の言語での開発（ネイティブアプリ）

各OS固有の言語で開発する場合、言語を変えるだけで、ほぼ同じ開発を2度実施しなければなりません。つまり、開発工数は単純に2倍になります。開発側も顧客側も、初期開発時においてはそうした認識を持って進めているのですが、サービス開始後の機能追加や改善の際にも、当然2つのアプリケーションに改修が必要ですし、テストも2倍の手間が発生するということは忘れがちです。BtoCのアプリの場合、業務システムとは異なり、運用後に改善などが頻繁に発生するという特性があるので、その部分も考慮して予算計画などを立てておく必要があります。

HTML5での開発

HTML5で開発すれば、1つのプログラムでiOS・Android両方に対応可能なアプリを実現できます。ただし、注意が必要なのは、サクサク軽快に動くようにするためにはチューニングが必要だったり、iOSとAndroidでどうしても同じ挙動にならない部分が出てきたりする点です。それらを不具合とするか仕様とするかの議論には、想定以上に工数がかかる可能性があります。単純に「HTML5ならば、プログラムを1つ用意すればいいから少ない工数で済む」と考えるのは早計です。

2. 端末やOS固有の特徴（クセ）を考慮した開発

iOSとAndroidとでは、同じようにアプリを開発したつもりでもUIデザインや挙動に違いが出ます。さらにAndroidの場合、同バージョンOSでも端末メーカーが異なると挙動が異なったり、フォントの大きさやデザインに違いが出たりする事態が比較的頻繁に発生します。これに対応するには、あらかじめさまざまなAndroid対応機種でテストするしかないのが実情です。どの機種を対象にどのくらいテストをするのか、事前に計画しておかないとプロジェクト全体の計画に大きく影響が出ます。

また、アプリ上からどこかのWebサイトを参照するような画面があった場合、OSに標準で搭載されているWebブラウザで表示するのと、アプリの中から「WebView」というコンポーネントで表示するのとで挙動に違いが出るケースもあります。早い段階でサンプルプログラムを作り、やりたいことが実現できるかどうかを確認することが必要です。

3. UIデザインの調整

BtoCの多くのアプリでは、iOSとAndroidで同じUIデザインを提供したいと考えるでしょう。しかし、それは口で言うほど容易なことではありません。iOSでは簡単に実現できるUIデザインでも、Androidでは手間がかかるといったケースもあります。また、Androidは画面サイズや画面解像度、画面縦横比がさまざまなので、イメージどおりのUIデザインにならないものも出てきます。とはいえ不可能なわけではないので、時間をかければかけるほど精度は上がるのですが、どこまでやるかの判断が必要です。

プロジェクトフェーズでいちばん問題になるのは、どこまでが仕様でどこからが不具合なのかという基準を決めるのが難しいことです。テスターからは、「UIデザインが仕様書とは異なる」という理由で「不具合」として記録されます。筆者の経験で言うと、機能を満たしていない、いわゆる一般的なバグの数に比べて、UIデザインが仕様と異なることによる通称”デザインバグ”の数は5倍くらい上がってきます。それら1つ1つについて、「これはバグとしてすぐ修正しましょう」、「これは仕様なのでOKとしましょう」といった判断をしなければなりません。また、バグと判断されたUIデザインをすぐに修正するとして「費用は瑕疵の範囲として対応するのか? それとも仕様変更として費用を発生させるのか?」といった調整が必要になります。

4. OSベンダーからの一方的な仕様変更への対応

急にAppleやGoogleからの仕様変更が通知され、対応するためにアプリを改修しなければならないケースがあります。機能追加のような前向きな要素のない改修ですし、プログラミングレベルの内容になるため、顧客への説明も難しく、理解してもらいにくいなかでコストが発生することになります。

たとえば最近の例で言うと、iOS9をXcode7でビルドした場合、アプリ内で参照しているWebサイトがSSL対応（https）になっていないと表示されなくなるという仕様変更がありました。WebサイトのほうをSSL対応にしてもらうというのは現実的ではないので、アプリ側で修正を行わなければなりません。

*　*　*

以上のように、BtoCのアプリ開発において、iOSやAndroidのさまざまなメーカーの端末に対応しようとすると、当初想定していた以上にプロジェクト後半で工数がかかる傾向にあります。そして、プロジェクト後半における想定外の工数増は、そのまま高いプロジェクトリスクになります。これをできるだけ回避するには、次のようなポイントに留意することが有効です。