モバイルアプリ開発は75％が失敗を経験、成否を分ける「MADP」選び：IT導入完全ガイド（4/4 ページ）

企業におけるモバイル活用は業務改善につながる多くの可能性を持つ一方、開発成功例は多くない。成否を分けるポイントはどこにあるのか？

[土肥正弘，ドキュメント工房]

モバイルアプリ開発の流れ

　モバイルアプリのビジネス効果は適時リリースできるか否かが大きく影響する。そこで短期に高品質の（しかし機能は絞り込まれた）アプリを作成できるアジャイル開発手法が採られる。開発プロセスのイメージは図8のようになる。

図8　アプリ開発のプロセスとおおよその期間 ※提供検討中サービス（出典：ソフトバンク）

　特徴的なのは要件定義からアプリ設計にかけてUI／UXのプロトタイピングを行い、入念に改善してユーザーと開発者間で同意しておくところと、運用・保守フェーズにおいてユーザーの利用状況のモニターや評価情報を集め、分析し、次の開発にフィードバックするところだ。このような開発スタイルを念頭に、MADP製品選びのポイントを考えてみよう。

MADP製品の選定ポイント

　国内の一般企業では従来「自社では開発業務を行わないので、ツール選びは業者任せ」というケースが多い。しかしアプリ開発本数が多くなり、ライフサイクルが短くなり、モバイルアプリを利用した新サービスのリリースが度重なるようになると、ツールも業者任せとはいかなくなってくる。アジャイル開発を推進していくとたとえ開発技術者が社内にいなくとも、ユーザー部門として開発に参加する形になるからだ。また積極的に開発に関与してこそ、よりビジネス効果が高くUI／UXにも優れたアプリを作成できる。その関与の仕方には、企業の事情により次の3通りがあるようだ。

　それぞれについて、重要視すべきMADP評価ポイントを挙げてみる（表1）。

表1　開発への関与のパターンと重視すべきツール評価ポイント

　最も多いのが（3）のパターンになるだろう。MADPツールは企業自身が購入し、SIerに利用してもらう形をとるのが安全で、企業にとってのメリットが大きい。逆にSIerにしてみれば個別のネイティブ開発の方がうまみがあるので利害対立が起きがちなところかもしれない。そこで長期の運用・保守も視野に入れ、トータルのコストで開発・サポート契約を行うケースが生まれ始めている。料金設定が難しいが、どちらにもメリットがある新しい契約形態として普及する可能性がある。

　なお表の3ケースの他、成果物の納期と内容は点検するが開発手法やツールには口を出さない業務委託スタイルを取るケースもある。しかしモバイルアプリの活用を目指すなら、SIerへの丸投げはもっての外だ。失敗確率を下げたいなら、積極的に関与して仕様決定の迅速化、テストへの関与による品質向上、ユーザーデータ分析結果のフィードバックなどの「協働」開発が肝心だ。MADPはそんな業務委託スタイルを実現するのにも役に立つ。

　では以下に、開発フェーズに沿って簡単に製品選びのポイントを紹介しよう。

企画から要件定義フェーズを考えた場合

　継続的に改善するアプリの場合はユーザー分析機能に注目したい。前回のリリースに対するユーザー評価や利用状況分析結果をフィードバックし、機能追加ばかりでなくさらなる利便性・操作性向上などの改善が可能になる。また、プロトタイプ作成の容易さ、迅速性、修正・改善の速さ、ビジュアルに操作仮体験ができるデバッグ／テスト機能などもチェックしておく。

アプリ設計、開発、テストフェーズを考えた場合

　ここはできるだけ出来合いのパーツ（フレームワークやライブラリ、テンプレートなど）を活用し、Webリソースなど既存資産も利用しながら省力化して、実コーディング量を抑えるのがポイントになるだろう。工数短縮効果もあれば品質担保効果もある。また、優れたデバッグや自動テスト機能を利用することも工数短縮の決め手になる。

　なお出来合いのパーツの中には、クラウドAPIやマッシュアップ可能な公開APIも含まれる。例えば、インドのICICI Bankでは、残高照会や振込など銀行サービスのアプリ化を進めた上、利用者間の無店舗送金、割り勘機能、オンラインショッピング、クーポン発行、ウォレット管理など、フィンテック関連サービスのAPIを利用して多彩な機能を取りそろえて提供している。これはAPI活用の見本として参考になる。

　またクラウド基盤の活用はスケーラビリティを確保するには必須になる。例えば中国のChina Railwayのモバイルアプリでは、繁忙期には1日1億件のヒットがあり、これをセキュアに保たれた400台のバックエンドサーバでさばいている。社内保有の環境だけを考えていると、機能面でも規模面でも限界が見えてくる。積極的なアプリ活用には外部サービスの利用は欠かせない視点だ。社内既存システムのAPIも含め、各種のAPIが自由かつ容易に利用できるかどうかが1つのポイントになるだろう。

運用、保守フェーズを考えた場合

　OSバージョンアップへの対応や利用フレームワークの変更などへの対応機能があるのがMADPの特徴だ。単一のフレームワーク利用ではあまり問題はないが、柔軟性を求めてオープンソースフレームワークなどを多用する場合には、ベンダー側での対応が図られるとはいえ、ビルドのタイミングなどに注意が必要だ。MADPツールにはアプリ配信（アプリストアでの公開など）や自動更新の機能が備えられているが、現実の更新や利用開始までのタイムラグをどう縮められるかをツール機能を援用しながら設計する必要もあるだろう。

次期リリースの改善を考えた場合

　ユーザー分析機能が鍵になる。BIツールのようにグラフィカルに利用状況をチャート表現にする機能は多くのMADPツールに備えられている。それに加えてSNSなどを利用したユーザー評価の収集や分析、要望やクレームなどの分析などを通して改善ポイントを明確にすることができる。ツール機能としてデバイス操作とクラッシュの関係の自動分析、アプリ利用時にデバイスシェイクで行えるバグレポートとサポートチケット発行、アプリストアのレビュー文言の分析（今のところ日本語未対応）、さらには機械学習技術を応用したコグニティブサービス（IBM Watson Developer Cloudには、iOS SDKがある）も利用可能な時代になろうとしている。どのような手法をとるにせよ、ユーザー中心のアプリ改善を容易にする手段が豊富に備わったツール選びが重要だ。