スマホ・タブレットアプリの開発／リリース／保守におけるポイントと注意点

はじめに

スマートフォンやタブレットなどのスマートデバイスは日常生活になくてはならない存在になり、システム開発でもスマートデバイスを利用するケースが増えています。
このスマートデバイスのアプリを開発する場合、WebアプリやC/S（クライアント／サーバ）とは違う注意すべきポイントがあります。
その知見なくアプリ開発をすると、プロジェクト後半で致命的な問題につながる可能性があります。

アプリ開発におけるポイントは開発ツールやフレームワークなどの技術面だけでなくプロジェクト推進にも多くあります。

そこで、初めてスマートデバイスのアプリ開発をする人向けに、プロジェクト推進に関する注意すべきポイントを解説します。

このポイントは「開発」「リリース」「保守」の分類で説明します。

開発のポイント

スマートデバイスのアプリ開発をするうえで意識すべき点について説明します。
これらはプロジェクト計画や要件定義で方針を決めます。

OSバージョンと端末

スマートデバイスのOSバージョン、また端末の機種によって実装できる機能が異なります。
古い端末だと生体認証もない場合もあります。
全てのOSバージョンや端末を動作保証するアプリ開発は現実的ではありません。

業務用のアプリであれば、同機種の端末を使用するので問題ないのですが、コンシューマ向けでは、どのOSバージョンや端末機種が使用されるかわかりません。
そのため、アプリには動作保証を設定し、対象とするOSバージョンや端末を絞り込むのが現実的です。
その制限をかける方法ですが、OSバージョンであればシェア率を参考にします。
シェア率は「スマタブinfo」などのサイトから情報収集するとよいでしょう。

オフライン時の挙動

業務で利用するアプリでは、電波の届かないような場所で作業をする場合があります。
また社内設置の無線ルータの範囲外にいる場合もあります。
そのような通信状況が悪い場所でもアプリを利用する必要があるのか方針を決めます。

ネットワークがつながっていない状況でも利用可能にするのであれば、オフラインモードで動作する仕組みを検討します。
例えばオンライン時に端末のデータを定期的に最新化する仕組みなど、使い方により実装する機能が増えたりします。

ネイティブとWebブラウザの違い

スマートデバイスでは、アプリをインストールして利用する方法とWebブラウザで操作する方法があります。

ここでいうアプリとは「ネイティブアプリ」のことで、スマートデバイスにインストールして使用します。
Webに比べてアプリはダウンロード、インストール、アップデートといった手間が必要になりますが、アプリにはWebではできない機能が多いです。
例えば「プッシュ機能」「カメラ機能」「位置情報の利用」など、よりユーザと連携するための必須機能が使えます。
スマートデバイスで実現したいことを考慮しながら、アプリ開発するか、Webブラウザだけにするのか検討します。

ちなみにネイティブアプリの中でWebブラウザを表示する「WebView」という方法もあります。
アプリとWebのハイブリッドという選択もあります。

テスト端末の準備

開発したアプリの単体テストは、エミュレータなど開発ツールを使用して確認します。
しかしシステムテストや非機能要件を確認するときは、次の観点から実機を使用します。

• OSやバージョンによる非互換がないか
• 機種による非互換はないか
• アップデートができることを検証する
• 画面サイズによるレイアウト崩れがないか
• 操作性に問題ないか
• 物理キーが正しく設定されていること

このように実機を使ったテストを行いますが、全てのOSバージョンや機種のスマートデバイスを用意することは現実的ではありません。
そのため、ある程度絞り込んで端末を用意することになります。

端末の絞り込みはプロジェクト特性によりますが、例えば次のような絞り込み方法があります。

OS種類	iOS／Android 利用するOSごとに用意
機種	シェア率より選別
画面サイズ	最大サイズ／最小サイズ レイアウト崩れを確認する

ちなみに物理的に検証する端末を用意するのが難しかったり、より多くの機種で確認する必要がある場合は、Remote TestKitのようにオンラインでテスト機種を選択して利用するサービスもあります。
参考にしてください。

リリースのポイント

開発したアプリの新規リリース、バージョンアップするときのリリースにおける注意点です。
アプリ申請は開発のマスタスケジュールやアプリ公開の告知に影響するので、特に注意が必要です。

アプリ申請

ストアに登録して一般公開するようなアプリをリリースするときは、ストア申請の手続きが必要になります。
iPhoneはiTunes Connect、AndroidはGoogle Playストアに登録します。

このストア申請には以下の注意点があります。

承認までの期間

アプリの公開日を告知する場合、この申請の所要期間を見込む必要があります。
Androidは数時間～1日程度の期間で審査ができますが、iPhoneは１～２週間程度の時間がかかります。

しかもリジェクト（申請却下）されることも多く、初回の申請は、まず承認されないと考えた方が無難です。
リジェクトされた後、対応して再申請しても再度リジェクトされる可能性もあります。

プロジェクト計画で全体スケジュールを作成するときに、この申請で要する時間を盛り込む必要があります。
審査者に急ぎ対応を催促することは出来ないので注意しましょう。

審査者の検証環境

審査者が実際にアプリを動かして検証するとき、それは本番環境で操作されます。
検証環境で動作しても本番環境で動かなければ審査の意味ありません。
そもそも開発環境とつながるようにアプリの接続設定したものを申請しても、本番環境用に設定しなおすときに修正版として再申請することになります。

本番環境にテスト用ユーザがあればよいですが、システムによっては本番環境にテストユーザを作れない場合はプロジェクト計画の段階で対策を検討します。

アプリのバージョン管理

iOS、Androidのぞれぞれでアプリ開発を行いますが、アプリのアップグレードおよびメンテナンスを円滑に行うためにバージョニングを計画します。

バージョニングは、ユーザ端末にインストールされているバージョンとストアに登録されている最新バージョンを比較してダウンロード要否を確認するときに使用します。
また設定したバージョンによりサーバ側の処理を分岐させる場合にも使用します。

・アプリのバージョンによってサーバ処理を分岐させ制御する
・Android用にサーバ側のリリースを行う場合、Androidだけメンテナンスモードの画面を表示し、iOSは利用可能にする
　など。

バージョニングはセマンティック・バージョニング（X.Y.Z）のようにドットで区切られた3つの数値で表現することが多いです。
その使用方法はアプリの運用方法によるため、要件定義か基本設計で検討すると良いでしょう。

保守のポイント

アプリを保守するときに注意すべきポイントです。
これらは開発段階や保守契約の中で、あらかじめ計画を立てる必要があります。

運用保守の設計については別記事「運用設計」を参照してください。

OSバージョンアップ

スマートデバイスのOSは頻繁にバージョンアップされます。
そのバージョンアップによりアプリが動かなくなることを防ぐため、バージョンアップごとに互換性確認を行い対処する必要があります。

それらの調査や修正対応にはコストが発生するため、特にアプリの保守作業を外部ベンダーに発注している場合はコストやスケジュール調整を忘れずに行います。

トラッキング

アプリの利用状況などを収集・分析するためにGoogle Analyticsを使用します。
これはアプリだけでなくWebサイトでも使用します。
アクセス解析や利用状況などマーケティングで必要となる情報を収集・分析するために使用しますが、アプリはクラッシュレポートも重要な情報です。

アプリ不具合でエラーが発生したときに、FirebaseのSDKを使用して端末からgoogleにエラーログ情報を送信します。
保守担当者は、このクラッシュレポートを参照して、どのようなエラーが発生しているか知ることができます。

保守担当者はクラッシュレポートで検知した不具合を全て修正する必要はありませんが、エラー内容を定期的に分析し、影響度や発生頻度からアプリの改修計画を立てます。
アプリの不具合が減れば、ユーザの利便性向上につながります。

コンシューマ向けアプリの場合、アプリでエラーが発生しても問い合わせが来ることは少ないです。
一般ユーザが、わざわざ電話などで問い合わせすることはなく、アプリを使用することをあきらめるのが普通です。
保守担当者はクラッシュレポートしてエラー発生状況をもとに優先順位をつけて対処するための保守体制が必要になります。