もう怖くないモバイルアプリ開発！【デブサミ関西2014】

もう怖くない
モバイルアプリ開発！
知って得する実践Android/iOS業務システム開発
#kansumiC4
エンバカデロ・テクノロジーズ伊賀敏樹
v201408191040
© Copyright 2014 Embarcadero Technologies, Inc. All Rights Reserved 1

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア開発方式のポイント
【デバイス毎のバラバラ環境だと…】
• Android（Java）とiOS（Objective‐C）各々のプログラミング言語
や統合開発環境はずいぶん異なる
• 習熟コスト、開発組織が２倍、３倍になりがち
Android (Java)
findViewById(R.id.button1).setOnClickLis
tener(new OnClickListener() {
@Override
public void onClick(View v) {
((TextView)findViewById(
R.id.textView1)).setText(
"Hello World“
);
}
});
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
：
：
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 等は、これら問題を解決できる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アプリケーション配布のポイント
• アプリ開発と並行してストアへの配布の予行演習
• 開発者登録にまつわる各種手順および費用
• 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/09/09）を予定しています
• このセミナーはUstream 経由でリモートでも参加できます
• 詳細・お申込みは：
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

もう怖くないモバイルアプリ開発！【デブサミ関西2014】

Recommended

Recommended

More Related Content

Similar to もう怖くないモバイルアプリ開発！【デブサミ関西2014】

Similar to もう怖くないモバイルアプリ開発！【デブサミ関西2014】 (20)

もう怖くないモバイルアプリ開発！【デブサミ関西2014】