狠狠撸

もう怖くない
モバイルアプリ開発！
知って得する実践Android/iOS業務システム開発
??Copyright?2014?Embarcadero?Technologies,?Inc.?All?Rights?Reserved 1
#natsumiC3
v201407300924

アジェンダ
? 自己紹介 / 会社紹介
? モバイルアプリ開発が怖いってどういうこと?
? 提案?見積のポイント
? アプリケーション方式のポイント
? ソフトウェア開発方式のポイント
? 設計のポイント
? 製造のポイント
? テストのポイント
? アプリケーション配布のポイント
? もっとソフトウェア開発方式のポイント
? まとめ
? おわりに

自己紹介
? エンバカデロ?テクノロジーズに勤務
? シニア?セールスコンサルタント
? C++?と Java?についての豊富な経験
? ブロガー
? いがぴょんの日記
http://www.igapyon.jp/igapyon/
http://d.hatena.ne.jp/igapyon/
? テクニカルライター
? 書籍 /?雑誌 /?Web記事の執筆各種
? OSS 開発者
? OSS?フレームワーク、翻訳ツール、Eclipse?の翻訳など

エンバカデロ?テクノロジーズについて
ビジュアル開発の生産性
コンポーネントのドラッグ＆ドロッ
プによる効率的な開発
エンバカデロの開発ツールの特長
強力なデータアクセス機能
ビジネスアプリで必須となる広範な
データベースに効率的にアクセス
可能
真のネイティブ開発
中間コードや仮想マシンを必要
としない真のネイティブコードを
生成。デバイス機能を100%発揮
マルチデバイスサポート
Windows、Mac、iOS、Androidア
プリを単一のコードベースから
構築可能

モバイルアプリ開発が怖いってどう
いうこと?
? 見積?提案が怖い
? 社内実績が不足気味
? ハマるポイントがよくわからない
? アプリケーション方式やソフトウェア開発方式
が定まらない
? WBS?にブレークダウンできない
エンタープライズにも、そろそろモバイル
アプリニーズが出てきだした。でも…
ということで工程ごとの注意点を見ていきましょうということで工程ごとの注意点を見ていきましょう

提案のポイント
? モバイルデバイスならではのメリットを訴求
? 逆の観点:?Web?や Windows?等のアプリを “そのまま”
モバイルアプリ化する進め方だと、失敗パターンに
乗ってしまいがち
? “ぼんやり” した要求を、いかに具体化できるか、が
今まで以上に重要
? モバイルアプリ開発における “基準” の提示
? アプリケーション方式、ソフトウェア開発方式、テスト
計画、システム構成など…
? 「弊社の標準的な実装」的サンプルがあるとベター
? 開発環境や教育/初期稼働にまつわる様々なコ
スト計上をお忘れなく
ショーケースアプリ「おこさまレストラン」をご覧いただきましょう

見積のポイント
? モバイルアプリ開発の “基準” に沿った見積
? 提案で合意されたアプリケーション方式、ソフトウェア
開発方式、テスト計画、システム構成などから、「弊
社」の生産性が導き出せる
? 特にテスト工数は変動幅が激しい【後述】
? 「弊社の標準的な実装」との相違を適切に反映
? 基準をもとに、各種コストが導出できるような工夫
? 何かしらの前提／仮定に基づいた “基準” を事前に
策定しておく必要がある。
? 最低限の先行投資はやむを得ない!?
? プロトタイピング工程は重要
? モックアップではなくプロトタイプ!
? 後工程から導出される、予め合意形成が必要な
ポイントについて、見積条件に適切に加える

アプリケーション方式のポイント
? モバイルデバイスは、以下のような条件下で動作
? 低速な CPU
? バッテリー駆動
? 不安定で低速なネットワーク環境
? モバイルデバイスの、入出力に関する制約
? 狭い画面
? 端末ごとに異なる画面サイズ
? iOS?系はサイズのバリエーションが少なめ
? 画面が回転する
? キーボード無し、マウス無し
? 代わりにタッチで操作する
? Windows?的なディレクトリ構造が無い
? ダイアログ画面的なものが基本的に利用できない
【制約編】

? 持ち運びやすい
? 使いやすい（!?）
? すぐに使える
? 電源ボタンなどを押したら（あたかも）すぐに起動する
? カメラ、GPS、ジャイロセンサーなどの機能がある
? （不安定である可能性など制約はあるが）通信が
利用可能であることを前提とできる
? UI/UX標準がWindows的なものとは随分と異なる
? アプリを終了するという概念は希薄
【特徴編】

? モバイルデバイスに向いている処理と向いていな
い処理がある
? モバイルデバイスに向いている処理はモバイルデバイ
スで処理させる
? 向いていない処理はモバイルデバイスではない場所で
処理すべき
? ３層構成を採用するのが妥当と考えられる
? プレゼンテーション層：モバイルデバイス
UI?/?UX?やデバイス機能の利用など
? アプリケーション層：Web?アプリケーション?サーバ
CPU、メモリ、安定したネットワーク接続および速度を利
用する処理
? データ層：データベース?サーバ
【分業編】

? 基本的には、Web?リッチアプリケーションに似て
いる
? HTTPS?/?HTTP、SOAP?/?REST?などで通信
? プレゼンテーション層とアプリケーション層の双方に処
理が配置される
? Web?リッチアプリケーションと異なる主要な点
? ネットワークが切断されたとしても動作し続ける
? ローカル上にファイルやデータベースを維持する
? ネットワークが回復したタイミングでプレゼンテーション
層とアプリケーション層とで同期をとる
? カメラ、GPS、ジャイロセンサーなどのデバイス機能を利
用するケースが多い
【Webリッチアプリ
との相違編】
これらを実現するためには、
ネイティブアプリケーションによる実装方式の採用が妥当
これらを実現するためには、
ネイティブアプリケーションによる実装方式の採用が妥当

? アプリケーション方式における「ビッグバン」は避けて
リスクヘッジ
? ポイントとなる新技術採用箇所「以外」は、従来の慣れ親し
んだ方式を踏襲
【既存スキルの
有効活用編】
例： Java?や C#.NET?によるアプリケーション構築スキルやノウハウが豊富にあるなら、
アプリケーション層は Java?および C#.NET?を用いて Web?サービス（SOAP）として実装する
https
http
https
http
DB?I/ODB?I/O
SOAPSOAP
プレゼンテーション層：
ネイティブアプリ
アプリケーション層：
Java?および C#.NET
データ層：
Oracle?や SQL?Server?等
データ層：
既存スキルとノウハウの活用で
クラウド対応も容易に!
サーバ処理サーバ処理
例： Java?や C#.NET?によるアプリケーション構築スキルやノウハウが豊富にあるなら、
アプリケーション層は Java?および C#.NET?を用いて Web?サービス（SOAP）として実装する
https
http
DB?I/O
SOAP
データ層：
サーバ処理

? （もし）アプリケーション?フレームワーク?ライブラリ
を検討する場合には…
? 基本的には Web?リッチアプリと同じ考え方
? HTTPS?/?HTTP、SOAP?/?REST
? ステートレス（or?ステートフル?）
? 認証、認可、エラー情報伝達
? 各種ロギング（on?アプリケーション層）
? 暗号化（プレゼンテーション層のローカルリソース）
? PDF?等の生成および配布（プレゼンテーション層で印刷
しようとせずに、PDF?等で代替させる）
? ネットワークオフライン時のプレゼンテーション層のデー
タをアプリケーション層と同期する仕組み
? トランザクションデータおよびプレゼンテーション層の
キャッシュデータ
【フレームワーク
観点編】

ソフトウェア開発方式のポイント
【デバイス毎のバラバラ環境だと…】
? Android（Java）と iOS（Objective‐C）各々のプログラミング言語
や統合開発環境はずいぶん異なる
? 習熟コスト、開発組織が２倍、３倍になりがち
findViewById(R.id.button1).setOnClickLis
tener(new OnClickListener() {
@Override
public void onClick(View v) {
((TextView)findViewById(
R.id.textView1)).setText(
"Hello World“
);
}
});
Android?(Java)
findViewById(R.id.button1).setOnClickLis
tener(new OnClickListener() {
@Override
public void onClick(View v) {
((TextView)findViewById(
R.id.textView1)).setText(
"Hello World“
);
}
});
Android?(Java)
@interface ViewController :
UIViewController
@property (weak, nonatomic)
IBOutlet UILabel *label1;
- (IBAction)OnButton1Click:(id)sender;
@end
@implementation ViewController
- (IBAction)OnButton1Click:(id)sender {
[_label1 setText:@"Hello World"];
}
@end
iOS?(Objective‐C)
@interface ViewController :
UIViewController
@property (weak, nonatomic)
IBOutlet UILabel *label1;
- (IBAction)OnButton1Click:(id)sender;
@end
@implementation ViewController
- (IBAction)OnButton1Click:(id)sender {
[_label1 setText:@"Hello World"];
}
@end
iOS?(Objective‐C)
：
：
Windows?(C#.NET等)
：
：
Windows?(C#.NET等)

【マルチデバイス開発環境とは】
? 対象 OS?ごとに、Java（Eclipse）、Objective‐C（Xcode）、
C#.NET（VisualStudio）と開発言語や統合開発環境を
切り替えて開発するのはコスト増およびリスク増。こ
れを避けるべき
? Android,?iOS、Windows、Mac?OS?X?アプリを同じプロ
グラミング言語、同じ統合開発環境、統一的な手法
で開発できることが望ましい
? マルチデバイスに対応したプログラミング言語、統合
開発環境が、この問題を解決できる

【共通化の仕組み】
? 生産性向上のために必要となる、共通化の仕組み
? GUI?ソフトウェア部品の利用?開発?再利用の仕組み
? 非 GUI?ソフトウェア部品の利用?開発?再利用の仕組み
? OS?による差異をソフトウェア部品が覆い隠してくれること
? 商用ソフトウェア部品を組み込んで利用できること
? 少ない副作用のもとで、それらソフトウェア部品を利用で
きること
? これらの共通化の仕組みがマルチデバイスに対応
していること

【コーディングからデプロイまで】
? 生産性向上のためには、以下の操作を統合開発
環境から一貫して操作できることが必要
? コーディング
? （リモート）デバッグ実行
? ビルド
? 実機デプロイ

【日本語に対応していること】
? 開発ツールが日本語に対応していないことが、国
内開発において好ましくない生産性低下を引き起
こす場合がある
? 統合開発環境やドキュメントなどが日本語化され
ていることが望ましい

【望ましい統合開発環境】
? Android,?iOS、Windows、Mac?OS?X?アプリを同じプ
ログラミング言語、同じ統合開発環境、統一的な手
法で開発できることが望ましい
? 生産性向上のために必要となる、共通化の仕組み
がマルチデバイスに対応していること
? 生産性向上のためには、コーディングからデプロイ
までの操作を統合開発環境から一貫して操作でき
ることが必要
? 統合開発環境やドキュメントなどが日本語化され
ていることが望ましい
Appmethod、RAD?Studio?等は、これら問題を解決できるAppmethod、RAD?Studio?等は、これら問題を解決できる

設計のポイント
【モバイルアプリ化の妥当性確認】
? 設計を進める過程において、モバイルアプリ
化に適さない機能や画面が見つかる可能性
がある
? 無理にモバイルアプリ化しても、ほとんど誰にも使
われない機能/画面になってしまうリスク
? Web?アプリケーションやクライアントサーバシステ
ムと共存/併用が妥当なケースも多い
? クライアントサーバ型のイメージを引きずった
機能配置をしてしまわないこと
? 大抵の業務処理はアプリケーション層での実施が
妥当
? セキュリティに関する考慮
? お客様がモバイルアプリに持っている要求を
再確認するチャンス

【モバイルアプリらしさ】
? モバイルデバイスの特徴を考慮した設計
? 画面が小さい
→ １画面に情報を詰め込みすぎない
? キー入力しづらい
→ そもそもキー入力を極力要求しない
? タッチした時の感触が薄い
→ 何かしらのリアクションを実装に含める
? 画面遷移を基本とする
ダイアログ画面は（ほぼ）使えない、あるいは推奨されない
→ 直感的で見通しのきく画面遷移にしよう!
? GPS、加速度センサー、カメラ等のデバイス機能を有効活用

【画面設計】
? 機種や画面サイズなどが予め絞り込まれて決定されてい
ることが望まれる
? 実機上の画面（モックアップ）を用いた設計&レビューは非
常に効果が高い
? 設計担当者がツールを用いて画面作成するのがベスト
? 画面を覆い隠してしまうソフトウェア?キーボード
? お客様とのイメージ共有
→ お客様からの「普通のスマホアプリって…」
という話題は設計工程で解決済みに!
→ お客様にゲームスマホアプリの印象が根付
いている可能性に注目
→ お客様から「かっこよさ」的な要求が出てくる
可能性も

【画面設計：回転】
? 画面の回転の考慮（回転するのか、させないのか）

【画面設計：画面サイズ切替】
? 異なるサイズの画面における表示の確認
? 論理座標や論理サイズに対応している必要性

【画面設計：戻るボタン】
? 戻るボタンの戦略が必要

【画面設計：大きさ】
? タッチ操作に由来するサイズの限界
? マウスやキーボードではなくタッチで操作
? 大きさに注意
? 凹凸のあるキーボードですら、19mmピッチ
が一般的
? 重要な選択肢は大きく表示
? 重要ではない選択肢は
小さめでも可
? 例:?「★★★☆☆」
? UI?をシンプルに!

【UI?/?UX】
? 各デバイスの UI?デザインガイドライン
? 操作に対するフィードバック
? ぶんぶん、ぶるぶる、ぴかっ
? …サウンドもお忘れなく
? フローが単純であること、結果を予測できること、
元に戻れること
? 一方で、エンタープライズの業務システムに対し
て、何を適用し、そして何を適用しないのかの判
断も重要
? プロトタイプのフィードバックを有効活用
? ドキュメント化における工夫（モックアップ最大活用）
再びショーケースアプリ「おこさまレストラン」をご覧いただきましょう

【共通化】
? 仕様の共通化による効果
? 統一感
? 規模縮小
? 共通仕様のソフトウェア部品化
? GUI
? 非GUI
? ただし、プレゼンテーション層とアプリ
ケーション層の両方に実装が必要な共
通機能が存在しうる点に注意

製造のポイント
【コーディング事前準備】
? あなたの組織にとっての「普通」の生産性をモバ
イルアプリ開発でも実現していくために…
? 製造タスク開始前に必要な材料を揃えておく
? 開発に利用するマシン
→ 潤沢な CPU、メモリ、HDD?容量が望まれる
? 統合開発環境
→ マルチデバイス開発に対応した生産性の高いもの
? モバイルデバイス実機
? 事前に行うべき各種登録作業
? その他、開発に必要なもの
? プロトタイプ工程のフィードバックが整理および共
有されていること
? 手戻り防止および初期稼働の削減を実現

【コーディング】
? モックアップ画面の具体化作業
? マルチデバイス対応機能の作り込み
? OS?の違いを吸収したり、アンカー指定や配置レイアウト
指定など画面サイズ由来の各種対応も実装
? プレゼンテーション層について、更にビジュアル層
とローカルロジック層へと適切に分離
? 画面によっては、OS?やサイズ (スマホ or?タブレット)?ごと
にフォームを切り替える可能性があるので重要
? こまめなバージョン管理
? 課題の内容により、すみやかに関連箇所への
フィードバック

【ユニットテスト：前提条件】
? ユニットテストとテストとの間でテスト観点が適切
に分担（あるいは意図的に一部重複）されていること
? ユニットテスト対象機種が確定していること
? マルチデバイス?テストが必要なテスト観点が確
定していること
? Web?アプリケーションのマルチブラウザ?テストに類似
→工夫が無いと、テスト件数が機種の数だけ必要などと
いう酷いことが…?（N倍のワナ）
? テスト?エビデンスの取得方針が確定していること
? ちなみに：スクリーンショット取得に「Reflector?Airplay?
Receiver」を利用して効率化などを実施する場合には、
別途費用が発生

【ユニットテスト】
? こまめなビルド?デプロイ?ユニットテストの実施
? それが実現可能な統合開発環境であること
? 課題の内容により、すみやかに関連箇所への
フィードバック
? モバイルデバイスならではのテスト観点
? タッチ、スワイプ、ピンチイン、ピンチアウト
? エフェクト
? 画面回転、モーション、カメラ（デバイス機能の利用）
? 日本語入力（ソフトウェアキーボード）
? サウンド
? Windows?アプリとしてのユニットテスト実施
? ユニットテストの自動化

テストのポイント
? ユニットテストに加えてテスト工程でも
マルチデバイステストは必要
? ある程度の実機準備が必要
? テスト観点を絞り込み
? 機種依存の動作相違は存在
? クラウド実機の有効活用
? テスト?エビデンスの取得方針
? スクリーンショット or?カメラ撮影?
? ネットワーク状況やアプリ状況に関する試験
? 特に課金にまつわるテスト観点はシビア
? テストの自動化 (クラウド実機による自動化)
www.scirocco‐cloud.com

アプリケーション配布のポイント
? アプリ開発と並行してストアへの配布の予行演習
? 開発者登録にまつわる各種手順および費用
? iOS?Developer?Program?に関する長い待ち時間
? Google?Play?アプリ登録に関する待ち時間
? App?Store?アプリ登録に関する長い待ち時間
? クレジットカードが必要になるタイミングの確認
? ある程度の実機が手元にないと、そもそもアプリ登録
を進めることができない
? 実機登録可能台数の上限
? 必要となる選択肢、説明文および URL、スクリーン
ショット、説明画像の洗い出しおよび準備
? 証明書の有効期限に由来する、再度のストア登
録作業タイミングについての確認

もっとソフトウェア開発方式のポイント
? VMware?や Parallels?のような OS?仮想化ソフト
ウェアのうえに開発環境を構築することを推
奨したい
? 潤沢な CPU,?メモリ,?ハードディスク容量を期待
? iOS?や Mac?OS?X?向けアプリをビルドする場合
には、Mac?OS?X?+?Xcode が別途必要
? Appmethod?や RAD?Studio?を利用する場合には、
Mac?OS?X?上の OS?仮想環境にインストールされた
Windows?に対して導入する構成もおすすめ
? 最低限必要と思われるデバイス実機
? Google?Nexus?5,?Google?Nexus?7?(2013,?2012)
? iPhone?5,?iPhone?4,?iPad
? 足りない分は scirocco‐cloud.com?などを活用

まとめ【1/2】
? 業務システムにモバイルデバイスを取り入れたいと
いうユーザーの声は高まるばかり
? スマホアプリ開発は怖いものの、ポイントをおさえら
れれば魅力的な開発ターゲット
? 管理者の方は、エンジニアがモバイルアプリ開発を
“試食” できる環境を整備してあげて欲しい
? モバイル?デバイス実機について、Google?Nexus?5?や
iPhone?5?など、最低限 1?台だけでも…
? （iPhone、iPad、Mac?OS?X?アプリ開発のために）、Mac?OS?X?
および開発者登録を…
? 弊社の Appmethod?や RAD?Studio?を用いると、
今回紹介したポイントの多くを解決

まとめ【2/2】
? 普段から、スマホそのものやスマホアプリに
少しずつ慣れておく
? 例:?スマホアプリな案件を受注してから慌てて
スマホアプリそのものを勉強するのはキケン
? 流行している無料スマホゲームアプリなどを
利用してスマホアプリに慣れていくのも良い
方法
? Android?と iOS?(iPhone,?iPad)?の両方の
経験も重要
? 開発するつもりでスマホアプリを観察
していると、多くの気づきが得られる

おわりに【1/2】
展示ブースでは発表のなかで紹介したデモアプリ
「おこさまレストラン」を展示しています

おわりに【2/2】
? このセッションに関連付けられた無料セミナー
? 本日のセッション内容に関連した、より詳細かつ実際
のアプリ開発を体験できる弊社主催の無料セミナー
（2014/08/26）を予定しています
? 詳細?お申込みは：
http://www.embarcadero.com/jp/seminar/entmobile
? 今回紹介したポイントの多くをカバーする弊社製
品の無料版や体験版をぜひ使ってみてください
? Appmethod?:?
http://www.appmethod.com/jp/
? RAD?Studio?:?
http://www.embarcadero.com/jp/products/rad‐studio

www.embarcadero.com/jp

狠狠撸

もう怖くないモバイルアプリ开発！

More Related Content

もう怖くないモバイルアプリ开発！