★テーマ
比べてわかるフィーチャーフォンとスマホのアプリ開発・運用のポイント
●スピーカー
株式会社野村総合研究所 ユビークリンク事業部
北村 雄騎 氏
独自交通情報（UTIS）を活用した携帯電話向け総合ナビゲーション・サービス「全力案内！」の企画・開発・運用等の業務に携わっている。
●アジェンダ
モバイル端末の変遷の中でアプリ開発がどう変わって来ているのか？
開発の周辺にも目を向ける
企画、開発、運用の諸々比較
１、全力案内！とは
各キャリア、SP、FPにナビゲーションサービスを提供
プローブデータベースが核
タクシー等からの交通情報をGPSを使用して取得するサービス
渋滞回避性能にすぐれたカーナビ
カーナビに出るような最短ルートより、渋滞情報とかを取ってさらに短い時間で行けるルートを見つける
カーナビは大きな道路しか見ないが、タクシーは裏道のような狭い道も行くので、情報が抱負
基本機能はシンプル＆安価に提供
iPhoneのナビカテゴリーで常に上位にいる
２、企画のポイント
●まず考えるべき事
コンセプト
マーケット
プラットフォーム
競合
予算
スケジュール
誰に提案する？
コスト
誰にどうなって欲しいのか？
なぜ必要か？
自信がユーザーになりきって考える。
女性向けなど、自分がなりきれない時は、一番ユーザーに近い人に聞くのがいい。
iPhoneが出たとき、ナビアプリはなかった。
出しては行けない規約もあった。
３、仕様・設計
ブラウザ
アプリ
フィーチャーフォン
スマホ
キャリア
国内 or 国外
タブレットを含むか？
キー操作ありか、タッチのみか？
●まず、実機を買って使い倒すべき。
ユーザーの日常のどこで使ってもらえるか？
を自分で使い倒す事によって把握する
●操作性の比較
○フィーチャーフォン
物理キーの操作（ほぼ統一されている）
○スマホ
タッチ中心の操作、両手の場合も（キーの位置が機種によって違う事もある）
●画面の解像度も大分違う
スマホの他にタブレットもやるとなると、デザインも大きく変えないといけない場合もある
●操作の再構築
画面のボタンがタッチ出来ると分かるか？
FPのUIからそのまま移植すると、間隔も狭くてタッチしづらい。
スマホで選択肢をカーソルで移動出来るのは特定機種のみ。
ダブルタップ、長押しの操作は難しい。
ユーザーが気付かないので、ヘルプを付けるべき。
●画面の密度
今の日本のであれば、大体200dpi
●端末の機能
○フィーチャーフォン
SUID認証、マイメニューから課金
○スマホ
GPS、センサー、課金API、アプリ間連携、Wi-Fi、マルチタスク
●サービス仕様
フィーチャーフォンのサービスをどこまで、どう実現するか？
必ずしも全部移植する必要は無い
画面サイズ、スペック等も違うので、端末に特化した物を考えた方がいい。
全力案内！だと、スマホ向けではタイミング(道路混雑時、余裕のある時等)によってBGMを変えて流したりする
４、開発・テストのポイント
OS
開発環境
言語
ライブラリ
バージョン管理
何をテストする？
流用できるものは？
●やっぱり実機が必要
実機が無いと分からない事はたくさんある。
全く同じアプリでも、端末によって動かなかったりすることも普通にある。
●実機で大事なポイント
○節電
ナビゲーションのサービスは長時間使うので、稼働時間を考える。
節電すれば端末の負荷も下がる。
端末の稼働時間を計測
↓
アプリを使った際の稼働時間を計測
フィーチャーフォンはひたすら実測あるのみ。
スマホはバッテリー計測アプリを併用。
●ライフサイクルの違い
○iアプリ
簡単に言えば起動、実行するだけ。
画面を閉じれば、アプリも落ちる。
○スマホアプリ
画面を閉じた後、バックグラウンドで活かすか殺すかも考えなければならない。
５、テスト、テスト、テストのポイント
●デバイスにアクセスするAPIのテスト
GPS（昨日自体は使えても、アプリから実行されたら落ちてしまう場合もある）、
センサー、Bluetooth、SDカード
Bluetoothでデータのやり取りをする際は、機種によっては対応していない場合もあり、要注意。
出来ればターゲット機種毎に確認する。
●課金系API
キャリアによって課金遷移が異なる。
Googleのデベロッパーコミュニティでもやり取りが活発な内容。
６、デプロイのポイント
●フィーチャーフォン
○１MB～２MBのサイズ制限がほとんど
●スマホ
○50MB、場合によってはGB単位もある。
○ユーザの通信環境を考慮する(20MB以上の場合はWi-Fi必須)。
○端末容量も考慮する。特にAndroidは内蔵ストレージが少ない機種あり。
○SDカードコピーを許さない場合は、なるべく最終的なアプリ容量のアナウンスをする。
とにかく容量は極力小さくした方がいい。
７、リリースのポイント
●Android
○審査も無く、自由にリリースも出来る
●iPhone
○審査がある
一度は差し戻されることを前提としたスケジュールを組む。
実際に作って審査を通るまでは、出せるかどうかすら分からない。
○リリースタイミングのコントロール
リリースは～日以降という形でだけ日付に指定が出来る
○「旧戻し」「リリース待ちの差し戻し」はできない
App Storeは待ったなし。
審査が通ったあとに修正を加えたりすることは出来ない。
８、運用のポイント
●マーケットのアナウンスを注視する
開発者向けメール、公式アナウンス全て
例）App Storeの価格変更（円高の影響で入ったりする）
いつやるというのは無く、近々やるという程度の情報だが、いきなりやられるので把握しといた方がいい。
●マーケットの動きを注視する
公開されている統計情報も利用する。
どの端末が多いのか、どのOSのバージョンが多いのか等。
現在はAndroid2.2、2.3が８０％くらいを占めている。
シェアの多いところをターゲットに作るべき。
●ユーザーの声を聴く
問い合わせ
マーケットレビュー
ブログ
ソーシャルメディア
リアルタイムの生な意見はソーシャルメディアが一番多い。
ユーザーの作って欲しい物等も知れたりする。
終わりに
実際に使う人の近くで作る。
時にはコードから離れ、技術限界スタンスから離れること事も必要。
仕様や不具合も含めて、ユーザーは使ってくれている。
●感想
スマホアプリについてという、流行りの話題だったため、興味深い内容だった。
割と定番な話も多かったが、実際に現場で開発に携わっている人から改めて聴けて、
非常に参考になった。
特にこうして振り返ってレポートにまとめてみると、
フィーチャーフォン、スマホアプリの比較がしっかり出来て、
ポイントを掴めたと思う。
ちなみにこのセッションで使用された資料は下記で公開されている
http://www.slideshare.net/devsumi/16-d6-1
比べてわかるフィーチャーフォンとスマホのアプリ開発・運用のポイント
●スピーカー
株式会社野村総合研究所 ユビークリンク事業部
北村 雄騎 氏
独自交通情報（UTIS）を活用した携帯電話向け総合ナビゲーション・サービス「全力案内！」の企画・開発・運用等の業務に携わっている。
●アジェンダ
モバイル端末の変遷の中でアプリ開発がどう変わって来ているのか？
開発の周辺にも目を向ける
企画、開発、運用の諸々比較
１、全力案内！とは
各キャリア、SP、FPにナビゲーションサービスを提供
プローブデータベースが核
タクシー等からの交通情報をGPSを使用して取得するサービス
渋滞回避性能にすぐれたカーナビ
カーナビに出るような最短ルートより、渋滞情報とかを取ってさらに短い時間で行けるルートを見つける
カーナビは大きな道路しか見ないが、タクシーは裏道のような狭い道も行くので、情報が抱負
基本機能はシンプル＆安価に提供
iPhoneのナビカテゴリーで常に上位にいる
２、企画のポイント
●まず考えるべき事
コンセプト
マーケット
プラットフォーム
競合
予算
スケジュール
誰に提案する？
コスト
誰にどうなって欲しいのか？
なぜ必要か？
自信がユーザーになりきって考える。
女性向けなど、自分がなりきれない時は、一番ユーザーに近い人に聞くのがいい。
iPhoneが出たとき、ナビアプリはなかった。
出しては行けない規約もあった。
３、仕様・設計
ブラウザ
アプリ
フィーチャーフォン
スマホ
キャリア
国内 or 国外
タブレットを含むか？
キー操作ありか、タッチのみか？
●まず、実機を買って使い倒すべき。
ユーザーの日常のどこで使ってもらえるか？
を自分で使い倒す事によって把握する
●操作性の比較
○フィーチャーフォン
物理キーの操作（ほぼ統一されている）
○スマホ
タッチ中心の操作、両手の場合も（キーの位置が機種によって違う事もある）
●画面の解像度も大分違う
スマホの他にタブレットもやるとなると、デザインも大きく変えないといけない場合もある
●操作の再構築
画面のボタンがタッチ出来ると分かるか？
FPのUIからそのまま移植すると、間隔も狭くてタッチしづらい。
スマホで選択肢をカーソルで移動出来るのは特定機種のみ。
ダブルタップ、長押しの操作は難しい。
ユーザーが気付かないので、ヘルプを付けるべき。
●画面の密度
今の日本のであれば、大体200dpi
●端末の機能
○フィーチャーフォン
SUID認証、マイメニューから課金
○スマホ
GPS、センサー、課金API、アプリ間連携、Wi-Fi、マルチタスク
●サービス仕様
フィーチャーフォンのサービスをどこまで、どう実現するか？
必ずしも全部移植する必要は無い
画面サイズ、スペック等も違うので、端末に特化した物を考えた方がいい。
全力案内！だと、スマホ向けではタイミング(道路混雑時、余裕のある時等)によってBGMを変えて流したりする
４、開発・テストのポイント
OS
開発環境
言語
ライブラリ
バージョン管理
何をテストする？
流用できるものは？
●やっぱり実機が必要
実機が無いと分からない事はたくさんある。
全く同じアプリでも、端末によって動かなかったりすることも普通にある。
●実機で大事なポイント
○節電
ナビゲーションのサービスは長時間使うので、稼働時間を考える。
節電すれば端末の負荷も下がる。
端末の稼働時間を計測
↓
アプリを使った際の稼働時間を計測
フィーチャーフォンはひたすら実測あるのみ。
スマホはバッテリー計測アプリを併用。
●ライフサイクルの違い
○iアプリ
簡単に言えば起動、実行するだけ。
画面を閉じれば、アプリも落ちる。
○スマホアプリ
画面を閉じた後、バックグラウンドで活かすか殺すかも考えなければならない。
５、テスト、テスト、テストのポイント
●デバイスにアクセスするAPIのテスト
GPS（昨日自体は使えても、アプリから実行されたら落ちてしまう場合もある）、
センサー、Bluetooth、SDカード
Bluetoothでデータのやり取りをする際は、機種によっては対応していない場合もあり、要注意。
出来ればターゲット機種毎に確認する。
●課金系API
キャリアによって課金遷移が異なる。
Googleのデベロッパーコミュニティでもやり取りが活発な内容。
６、デプロイのポイント
●フィーチャーフォン
○１MB～２MBのサイズ制限がほとんど
●スマホ
○50MB、場合によってはGB単位もある。
○ユーザの通信環境を考慮する(20MB以上の場合はWi-Fi必須)。
○端末容量も考慮する。特にAndroidは内蔵ストレージが少ない機種あり。
○SDカードコピーを許さない場合は、なるべく最終的なアプリ容量のアナウンスをする。
とにかく容量は極力小さくした方がいい。
７、リリースのポイント
●Android
○審査も無く、自由にリリースも出来る
●iPhone
○審査がある
一度は差し戻されることを前提としたスケジュールを組む。
実際に作って審査を通るまでは、出せるかどうかすら分からない。
○リリースタイミングのコントロール
リリースは～日以降という形でだけ日付に指定が出来る
○「旧戻し」「リリース待ちの差し戻し」はできない
App Storeは待ったなし。
審査が通ったあとに修正を加えたりすることは出来ない。
８、運用のポイント
●マーケットのアナウンスを注視する
開発者向けメール、公式アナウンス全て
例）App Storeの価格変更（円高の影響で入ったりする）
いつやるというのは無く、近々やるという程度の情報だが、いきなりやられるので把握しといた方がいい。
●マーケットの動きを注視する
公開されている統計情報も利用する。
どの端末が多いのか、どのOSのバージョンが多いのか等。
現在はAndroid2.2、2.3が８０％くらいを占めている。
シェアの多いところをターゲットに作るべき。
●ユーザーの声を聴く
問い合わせ
マーケットレビュー
ブログ
ソーシャルメディア
リアルタイムの生な意見はソーシャルメディアが一番多い。
ユーザーの作って欲しい物等も知れたりする。
終わりに
実際に使う人の近くで作る。
時にはコードから離れ、技術限界スタンスから離れること事も必要。
仕様や不具合も含めて、ユーザーは使ってくれている。
●感想
スマホアプリについてという、流行りの話題だったため、興味深い内容だった。
割と定番な話も多かったが、実際に現場で開発に携わっている人から改めて聴けて、
非常に参考になった。
特にこうして振り返ってレポートにまとめてみると、
フィーチャーフォン、スマホアプリの比較がしっかり出来て、
ポイントを掴めたと思う。
ちなみにこのセッションで使用された資料は下記で公開されている
http://www.slideshare.net/devsumi/16-d6-1