スマートデバイスSIの落とし穴と適した開発手法とは？

スマートデバイスSIの落落とし⽳穴と適した
開発⼿手法とは？
2015年年3⽉月17⽇日
NCデザイン＆コンサルティング株式会社

Copyright ©2015, NC Design & Consulting Co., Ltd. All rights reserved.
本⽇日の内容
n  スマートデバイスSIとは
•  スマートデバイスを利利⽤用したシステムをSIする事
n  従来型のSIとスマートデバイスSIの違いについての説明
•  システムの利利⽤用シーン（環境・状況）
•  システムアーキテクチャ
•  プロジェクト体制
•  開発プロセス
n  従来型のSIとの違いの中に潜む落落と⽳穴の解説と、その対応
策について説明
2

システムの利利⽤用シーンの違い

従来の業務システム
n  システムは現場ではなくオフサイトで利利⽤用されていた
4
事務
担当者
担当者
業務データの
記録
アナログデータ
の受け渡し
の印刷
の印刷
移動
持ち出したデータ
の確認
データの
登録・出⼒力力
業務システム
現場（客先／店頭／⼯工場／etc…）オフィス／デスク

　
スマートデバイスを使った業務システム
n  システムを現場（オンサイト）で直接活かせる仕組へ
n  利利⽤用シーンが固定されたオフサイトでの利利⽤用から、利利⽤用シーンが多様化する
オンサイトでの利利⽤用へ
5
オフィス
担当者
現場（客先／店頭／⼯工場／etc…）
相⼿手（顧客／作業員／etc…）
業務システム
データの直接⼊入⼒力力
／直接表⽰示
システムを直接利利⽤用
した対話とインタラ
クション
加速度度地磁気
ジャイロ Bluetooth
カメラ GPS
センサや端末機能
を利利⽤用して現場の
データを直接収集

利利⽤用シーンの変化に伴う落落とし⽳穴
6
利利⽤用シーンが拡⼤大し要件が多様化
移動中？屋外？対話中？オフライン？etc…
未経験分野に対して正解をイメージできない要件定義
利利⽤用シーンの読み違えや思い込み
従来と変わらない機能・ユーザーインターフェース設計
利利⽤用シーンの分析
利利⽤用シーンに合わせたユーザーインターフェースの設計

n  既存でも⾏行行っている業務フロー分析に、「場所」、「デバイス」と「利利⽤用
シーン」、「UX特性」という項⽬目を追加する
7
営業支援システム 2015/03/16 powered by Astah
営業支援システムact
マネージャー営業顧客
営業目標立案
営業訪問スケ
ジュール作成
客先訪問
カタログ提示カタログ参照
営業メモ入力
営業訪問スケ
ジュール確認
営業報告書の承認
営業報告書の作成
場所利利⽤用シーンデバイス
オフィス
客先
カフェ
ベンチ
電⾞車車
徒歩
オフィス
オフィス
電⾞車車
PC
iPad
iPad
iPhone
PC
PC
iPad
顧客と⼀一緒に画⾯面を⾒見見ながら話をする
顧客の意⾒見見に反映させながら商品を探す
次の訪問予定までの間に作業
時間もないのでキーワードだけ素早くメモする
移動中に次の訪問スケジュールを確認
カバンを持っているので⽚片⼿手で操作
⼊入⼒力力項⽬目も多くグラフの整形なども⾏行行う
重要案件はオフィスで腰を据えて確認
それ以外は移動中にタブレットから操作
UX特性
⾒見見やすさ
操作の利利便便性
⼊入⼒力力効率率率
オフライン対応
操作性
⼊入⼒力力効率率率
操作の⼀一貫性
継続性

利利⽤用シーンに合わせた
ユーザーインターフェースの設計
n  分析した結果をUI（ユーザーインターフェース）に反映させる
•  移動中に⽴立立ったまま操作
メニュー階層は浅く、⽚片⼿手操作が可能なUIに
•  物流流や倉庫での検品作業
流流れてくる製品を⼿手際よく検品できる操作性とレスポンス
•  建設現場での設計図の確認
屋外での太陽光の反射や映り込みがあって
も⾒見見やすい⾊色調にする
•  顧客との対話中
対話の内容をリアルタイムで画⾯面に反映
n  モックやプロトタイプを使った検証が有効
•  実際のユーザーからのフィードバックや実際の業務の利利⽤用シーンでの検証を⾏行行う
8

ベンダーガイドラインへの準拠
n  iOSヒューマンインターフェイスガイドライン
•  https://developer.apple.com/jp/documentation/MobileHIG.pdf
•  フラットデザイン
n  Android Design
•  http://developer.android.com/design/index.html
•  マテリアルデザイン
n  ガイドラインが対象端末の利利⽤用環境下での
ユーザー体験を⼀一定レベルまで引き上げて
くれる
n  ⾃自社向けガイドラインの作成
•  ボタンの位置、⾊色の指定、⽤用語の統⼀一
•  マニュアルレスへ
9
出典：http://developer.android.com/

システムアーキテクチャの違い（１）

サーバーサイド
従来型のWebアプリケーションアーキテクチャ
n  全ての処理理を１つの技術（⾔言語）だけで実装可能
n  全ての処理理をサーバーサイドエンジニアだけ実装可能
11
ブラウザ
HTMLの⽣生成
リクエストの
ハンドリング DB業務ロジック
ブラウザ
リクエスト
HTML
レスポンス
Call Call SQL
委譲
Java（JSP/Servlet）
.NET（ASP.NET MVC）
Ruby（Ruby on Rails）
etc…
データアクセス
ロジック
Call

フロントエンドサーバーサイド
スマートデバイス向けアーキテクチャ
12
Objective-‐‑‒C
Web API
インターフェー
ス
DB業務ロジック
JSON／XML
リクエスト
JSON／XML
レスポンス
Call SQL
n  フロントエンドとサーバーサイドで技術（⾔言語）が分離離する
n  エンジニアを個別に調達する必要がある
Java（JAX-‐‑‒RS）
.NET（ASP.NET Web API）
etc…
ロジック
Call
iOS
Android Java
Android
HTML5
Mobileブラウザ

フロントエンド
従来型システムとの共存
n  フロント業務はスマートデバイス、バックエンド業務はPC Web
n  両アーキテクチャ間でモジュールが重複
13
DB
Android Java
HTML5
Web API
インター
フェース
業務ロジック
JSON/XML
リクエスト
JSON/XML
レスポンス
同じロジック
を複数作成さ
れてしまう
接客
現地調査
営業
etc…
ブラウザ
HTMLの
⽣生成
リクエストの
ハンドリング
業務ロジック
ブラウザ
リクエスト
HTML
レスポンス
報告書作成
承認業務
システム管理理
etc…
ロジック
ロジック
Mobile OS

システムアーキテクチャの変化に伴う落落とし⽳穴（１）
14
複数の技術によるシステム構築
多様化するアーキテクチャ
アーキテクチャ複雑化による保守コストの増⼤大
エンジニアの調達不不⾜足やスキルの偏り
アーキテクチャの最適化
mBaaSの利利⽤用

n  Client MVCアーキテクチャの導⼊入
n  サーバーサイドアーキテクチャを⼀一本化しロジックの重複を排除
15
フロントエンドサーバーサイド
DB
Web API
ス
業務ロジック
JSON
リクエスト
JSON
レスポンス
JSON
リクエスト
JSON
レスポンス
ロジック
ブラウザ
Client MVC
JavaScript
jQuery
AngularJS
etc...
Java（JAX-‐‑‒RS）
.NET（ASP.NET Web API）
etc…
Android Java
HTML5
Mobile OS

mBaaS
n  mBaaS（mobile Backend as a Service）
n  サーバーサイドをノンコーディングにしエンジニアリソース調達を単純化する
16
DB
Android Java
HTML5
Web API
ス
ロジック
ブラウザ
Client MVC
JavaScript
Parse.com
Windows Azure
AppPot
etc…
業務
ロジック
業務
ロジック
Mobile OS
Web APIインター
フェースやデータア
クセスロジックはノ
ンコーディングで利利
⽤用可能

システムアーキテクチャの違い（２）

３つのフロントエンド実装技術
18
iOS/Android iOS/Android iOS/Android
ネイティブアプリケーション
ネイティブアプリケーション
WebViewコンポーネント
HTML5/CSS/JavaScript
Webブラウザ
HTML5/CSS/JavaScript
ネイティブアプリハイブリッドアプリ Webアプリ
開発⾔言語
ハード機器連携
アプリの配布
クロスプラット
フォーム
Objective-‐‑‒C / Android Java HTML5 / CSS / JavaScript HTML5 / CSS / JavaScript
◎ ◯ △
必要初回のみ必要不不要
✕ ◯ ◯
オフライン ◯ ◯ △

システムアーキテクチャの変化に伴う落落とし⽳穴（２）
19
デファクトスタンダードな実装技術が定まっていない
開発者がアプリの特性を⾒見見極めながら技術選定する必要がある
バランスの良良い特⻑⾧長を持つハイブリッドアプリを採⽤用しがち
会社標準など盲⽬目的にアーキテクチャを選択しがち
ハイブリッドアプリも万能ではない
要件と実装技術の特性を⾒見見極めて選択する

要件に応じた実装技術の選択
n  ハイブリッドアプリのデメリット
•  デバイスの機能は40％程度度しか活⽤用できない
•  性能⾯面ではネイティブより劣劣る
•  アニメーションの描画などHTMLの枠組みを超える表現はできない
•  ソースコードが覗けてしまうのでセキュリティが脆弱
•  従来のWebアプリとは異異なるスキルセットが必要になる（SPAなど）
20
•  UXを重視する
•  デバイスの機能をフル
に使う
•  単⼀一プラットフォーム
向け
•  クロスプラットフォー
ムの⽣生産性
•  HTML5へのスキルセッ
トの集約
•  デザイナとの分業
•  キャンペーン的なサイ
ト／アプリ構築
•  既存スキルの活⽤用
ネイティブアプリハイブリッドアプリ Webアプリ

プロジェクト体制の違い

開発チームの体制
n  技術毎に開発チームが分かれる縦割り型の体制になりがち
n  １つの機能をチームをまたいでリレー形式で対応する
22
設計チーム
開発チーム
開発チーム
Web管理理システム
開発チーム
PM
仕様の合意
I/Fの連携
モジュール
の結合
責任範囲の
定義
仕様の合意
I/Fの連携
モジュール
の結合
責任範囲の
定義
•  チーム間コミュニケー
ションのコントロール
•  タスクフローのコント
ロール
チーム毎に会
社が異異なる
ケースも
デザイナ

プロジェクト体制変化に伴うの落落とし⽳穴
23
プロジェクトチームの縦割り化
チーム間を横断した複雑なWBS調整
WBS組み換えミスによる⼿手待ちの発⽣生と⼯工期遅延
終盤のビックバン結合による不不具合と⼿手戻り
チーム間の認識識齟齬
縦割り体制を考慮した計画作り
頻繁なモジュールの結合
チーム間コミュニケーションの促進

縦割り体制を考慮したプロジェクト計画
n  ビックバン結合を避け、⼩小さく何度度も結合する
n  チーム間の作業依存関係と遅延・⼿手戻りを考慮した計画を⽴立立てる
24
API 1
フロント 1
合流流
バッファ結合
API 2
フロント 2
結合
合流流
バッファ
API 3
フロント 3
合流流
バッファ結合
合流流
バッファ
チーム間の依存関係と⼿手戻りを考慮した⼯工期
全体
結合
⾼高頻度度での結合に
よるリスク回避
API 1
API 2
API 3
フロント 1
フロント 2
フロント 3
APIと
フロントの結合
単純なクリティカルパスによる⼯工期
APIのインター
フェースを設計す
る期間
計画に
⾒見見込めていない
⾒見見えないリスクへの対応
インターフェースや仕様の⾒見見
直し、⽚片⽅方の遅延に伴うもう
⼀一⽅方への影響を吸収するため
のバッファァ

チーム間のコミュニケーション促進
n  担当者間が迅速にかつ⼿手軽にコミュニケーションができる環境作り
n  メンバー同⼠士が⾃自発的にコミュニケーションを⾏行行う
25
Web管理理システムチームサーバーサイドチーム
フロントエンドチーム
個⼈人
個⼈人個⼈人
個⼈人
個⼈人個⼈人
個⼈人
個⼈人個⼈人
デイリー
ミーティング
デイリー
ミーティング
デイリー
ミーティング
ウィークリー
プロジェクト
ミーティング
プライベートSNS
プライベートSNS
Slack
Skype
ChatWork
etc…
会話のログが残る
ので後から⾒見見返す
事ができる

開発チームC
機能横断的なチームを作る
n  T型スキルエンジニアの採⽤用、または育成
n  作業に依存関係のある機能は、同⼀一チーム内で対応する
26
設計チーム
開発チームB開発チームA
PM
周辺スキル周辺スキル
専⾨門スキル
T型スキルエンジニア
状況に応じて
相互に補完し
合う

スマートデバイスSIの持つリスク
28
新しく多様な状況を想定した
要件定義の難易易度度が上がる
縦割りチームの統制に伴い
プロジェクト管理理の複雑度度が増加する
多様なアーキテクチャや実装技術
をコントロールする必要がある
リスク①
リスク②
リスク③

プロジェクトの複雑さによって変わるアプローチ
n  シンプル（Simple）
•  対象の問題を誰が⾒見見てもすぐに理理解できる
•  プロジェクトを組む必要がなく、すでにあるベストプラクティスで
対応できる
n  煩雑（Complicated）
•  対象の問題を理理解するには、専⾨門知識識が必要
•  正解は複数あり、専⾨門家の分析（問題の整理理）によって計画的なプ
ロジェクト化が可能
n  複雑（Complex）
•  対象の問題を理理解するには、分析するだけでは無理理で、探査が必要
•  対象がどんな反応をするかを、⼩小さく反復復しながら、検査とフィー
ドバックを実施する必要がある
n  カオス（Chaotic）
•  対象を理理解することも難しいので、常に間違いがないか確認しなが
ら進める必要がある
•  計画を⽴立立てることは難しく、プロジェクト化は困難。研究的な要素
となる 29
クネビンフレームワーク
•  問題ドメインを複雑さに応じて分類するフレーム
ワーク
•  http://en.wikipedia.org/wiki/Cyneﬁn
複雑煩雑
カオスシンプル
探査
知覚
対応
知覚
分析
対応
知覚
分類
対応
⾏行行動
知覚
対応
グッドプラクティス
ベストプラクティス
プラクティスを
探しあてる
新しい
プラクティスを作る
無秩序
従来のSI
スマートデバイスSI

プロジェクト運営の複雑化に伴う落落とし⽳穴
30
複数のリスクが混在した複雑なプロジェクト運営
盲⽬目的に従来と同じ⼿手法を採⽤用する事による失敗
⼩小さく検査と改善を繰り返すアプローチへ

イテレーティブな開発スタイルの適⽤用
n  プロジェクトを2〜～4週間程度度に区切切り、設計／開発／検証を繰り返す
n  ⼩小さく早期に失敗し、改善を繰り返す事で複雑性に対処する
31
要件定義
外部設計
システム
テスト
設計
開発
検証
検証と改善を繰り返しな
がらシステムをブラッ
シュアップしていく
モジュール
の結合とテ
スト
ユーザー
テスト
プロジェク
ト計画の⾒見見
直し
プロセスの
改善

UI設計フェーズをイテレーティブに回す
n  プロジェクト全体をイテレーティブな開発にする事が難しい場合の対応
n  最もリスクの⼤大きい要件定義部分だけでも、できるだけクリアにする
32
要件定義設計開発
UI設計プロト
タイピング
検証
テスト
•  モックやプロトタイプの作成
•  HTMLやプロトタイプツールを利利⽤用
•  ペーパープロトタイプでもOK
ユーザー
テスト
プロジェク
ト計画の⾒見見
直し

スマートデバイスSIの落落とし⽳穴への対処
34
利利⽤用シーンに合わせたUI設計
チーム間コミュニケーションの促進
作業の依存関係と頻繁なモジュール結合を考慮した計画
要件と技術特性を⾒見見極めた実装技術の選択
多様化する利利⽤用シーン
複合技術により複雑化するアーキテクチャ
縦割り化するプロジェクト体制
⼩小さく検査と改善を繰り返すイテレーティブなプロセスへ
複数のリスクが混在した複雑なプロジェクト運営

スマートデバイスSIの落とし穴と適した開発手法とは？

スマートデバイスSIの落とし穴と適した開発手法とは？

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to スマートデバイスSIの落とし穴と適した開発手法とは？

Similar to スマートデバイスSIの落とし穴と適した開発手法とは？ (20)

More from Takuya Kitamura

More from Takuya Kitamura (8)

Recently uploaded

Recently uploaded (8)

スマートデバイスSIの落とし穴と適した開発手法とは？