デバイスと連携するモバイルアプリ開発を成功へ導くポイント

IoTデバイスやハードウェア製品の価値を最大限に引き出し、ユーザー体験を高める上で、それらを制御・連携するモバイルアプリ（iOS/Android）の存在は不可欠です。しかし、デバイス特有の仕様、OSごとの開発手法の違い、そして継続的な運用負荷は、開発担当者にとって大きな障壁となりがちです。

本ウェビナーでは、特に「デバイスと連携するアプリ開発を、どのように企画し、成功に導くか」に悩む開発・企画担当者の方々を対象に、プロジェクトの初期段階からリリース・運用を見据えた実践的なポイントを解説します。

あわせて、「連携するデバイスの種類と特性」「アプリ連携時の主な通信方式」「モバイルアプリとのデバイス連携構成」といった、技術選定や要件定義に欠かせない基礎知識から丁寧に解説します。
事例を交えた具体的な戦略やロードマップも提示するため、デバイス連携アプリの開発から運用まで、一連の流れを詳しく理解したい方にもおすすめです。

主な内容
・企画・要件定義の重要ポイント
・技術選定と開発体制の最適化
・デバイス連携アプリ特有の非機能要件への対応
・ベンダー選定と運用上の戦略

こんな方におすすめ
・デバイスの活用方法やユーザー体験向上の新たな手段を検討している方
・デバイスと連携するモバイルアプリの開発方法に悩んでいる方
・デバイス連携アプリにおける非機能要件や運用負荷の課題を解決したい方
・デバイス連携アプリの開発から運用までの一連の流れを掴みたい方

Transcript

1. デバイスと連携する モバイルアプリ開発 NCDC Online Seminar 2026 / 1 / 28 NCDC株式会社
2. 自己紹介 2 エンジニア 塚本 雄人 モバイルアプリ開発を得意とするフロントエン ドエンジニア。 要件定義から開発、保守運用フェーズまで、ア プリ開発プロジェクト全体に携わり、高品質な プロダクト提供に貢献。 車載システム開発等異なる領域で得た幅広い知 識と経験を活かし、プラットフォーム固有の仕 様やユーザー体験を考慮した設計・実装を強み とする。
3. 本セミナーについて
4. 本セミナーについて l 本セミナーでは、「デバイスと連携するモバイルアプリ開発」 を検討する際のポイントについてお話します l 本セミナーのゴール： デバイス連携アプリ開発における、 ”見落としがちなコストや隠れたリスク” を把握し、 プロジェクトを成功へと導く知識を得ること 4
5. 本セミナーについて 以降、以下の項目について主に話します l デバイス連携の全体像と連携方式について l 見落としがちな企画・要件定義時のポイント 5
6. はじめに：モバイルアプリについて
7. モバイルアプリについて l 「モバイルアプリ: Mobile Application」とは l スマートフォンやタブレットなどのモバイルデバイスに、直接インス トールすることで動作するアプリのことを指します 7
8. モバイルアプリについて l Webアプリケーションとの違い 8 特徴 モバイルアプリ Webアプリ 利用方法 ストアからインストールが必要 ブラウザ上で動作（Safari, Chrome） 通信要件 機能次第ではオフライン対応可能 通信環境が必要 デバイス連携 カメラ、位置情報、Bluetoothなどの デバイス機能が連携しやすい 一部デバイス機能に制限あり 互換性 機種やOSで動作が異なる場合あり ブラウザが同じであれば端末による 差異は基本的には無し リリース ストアの審査あり いつでもリリース可能 容量負荷 デバイスのストレージを使用 ブラウザが使用するストレージのみ バージョン依存 OSアップデートに追随が必要 使用ブラウザのバージョン （影響は少） 開発コスト プラットフォームごとの開発が 必要になる場合あり プラットフォーム共通
9. モバイルアプリについて l 過去には「失敗しないモバイルアプリ開発」というセミナーも実施 しております 資料も公開しておりますのでよければご閲覧ください 9
10. デバイス連携の全体像と連携方式について
11. デバイス連携の全体像と連携方式について l 詳細な開発・企画のポイントに入る前に、まずはデバイスとアプリ が連携する上での「土台となる知識」を整理しましょう l 本セクションでは、以下の3点を中心に 「技術選定や要件定義の成功に不可欠な基礎知識」を見ていきます l ①連携するデバイスの種類と特性 l ②デバイスの主な通信種類 l ③モバイルアプリとのデバイス連携構成 11
12. ①連携するデバイスの種類と特性 モバイルアプリと連携する「デバイス」 皆様はどういったモノを想像しますか？ 12
13. ①連携するデバイスの種類と特性 l デバイス種類 l 自立デバイス l 装着デバイス 13
14. ①連携するデバイスの種類と特性 l 自立デバイス l ヘルスケア機器 l 家電機器 l 産業機器 14
15. ①連携するデバイスの種類と特性 l 自立デバイスの特徴 l 使用する場所が限定的 l バッテリ容量が大きい、または電源供給可能 l Wi-Fi 経由のものも多く、通信の安定性が高い l 大型・高性能センサー搭載可能 l モバイルアプリ連携時の特徴 l 収集したデータの可視化 l リモートでの制御・監視 15
16. ①連携するデバイスの種類と特性 l 装着デバイス l 特化タイプ l 腕時計型 l ヘルメット・衣類装着型 l 多用途タイプ l スマートリング l スマートウォッチ 16
17. ①連携するデバイスの種類と特性 l 装着デバイス l 特化タイプ：事例 17 引用：大林組 作業員向け体調管理システム Envital® https://www.obayashi.co.jp/solution_technology/detail/tech073.html 引用：村田製作所作 業者安全モニタリングシステム https://solution.murata.com/ja-jp/service/wms/
18. ①連携するデバイスの種類と特性 l 装着デバイスの特徴 l 身体活動や生体情報の取得 l 軽量性、携帯性 l リアルタイム情報 l モバイルアプリ連携時の特徴 l リアルタイム性 l クラウドへ送るための中継機の役割 18
19. ②デバイスの主な通信種類 l デバイスの主な通信種類 l BLE（Bluetooth Low Energy） l LTE（Long Term Evolution） l Wi-Fi l その他 19
20. ②デバイスの主な通信種類 l BLE（Bluetooth Low Energy） l 低消費電力 l ネット環境に依存しない l 近距離通信 l 少規模のデータ送信向け l 1対1 or 1対多 の接続 20
21. ②デバイスの主な通信種類 l LTE（Long Term Evolution） l 基地局を介したインターネット接続（SIM必須） l 超広域通信 l 高速かつ安定した通信 l 中〜大容量のデータ送信可 l 消費電力が大きい l セキュリティが高い 21
22. ②デバイスの主な通信種類 l Wi-Fi l ルーターを介してインターネットに接続可能 l 通信速度が高速 l 大容量のデータ送信可 l 消費電力が大きい 22
23. ②デバイスの主な通信種類 23 特徴 BLE LTE Wi-Fi 電力消費 低い 高い 高い 通信速度 遅い 早い 非常に早い インターネット 接続 不可 可能（SIM必須） 可能（ルーター経由） 通信距離 近距離 遠距離 中距離 送信データ容量 小さい 大きい 非常に大きい
24. ②デバイスの主な通信種類 l その他の通信種類 l NFC系 (Near Field Communication) l 超近距離通信、電源不要、スマホが読み書きするReaderになること多い l 例）交通系ICカード、スマホタッチ決済 l LPWA系（LoRaWAN, NB-IoT, LTE-M, Sigfox） l 低速・低電力・広域・低容量データ、SIM内蔵によるインターネット通信 l 例）インフラ設備の監視 l スマートホーム系（Zigbee, Z-Wave, Thread） l 低電力、多数デバイス連携、ゲートウェイ（ハブ）経由で通信 l 例）アレクサ 24
25. ③モバイルアプリとのデバイス連携構成 l デバイス通信：BLE l 構成：デバイス⇔ スマホ（⇔ クラウド） 25 【アプリ構成パターン①】 ・ローカル環境で完結 ・ユーザー体験の向上 ・リアルタイム性 ・省電力 ・デバイス側との密な連携 【アプリ構成パターン②】 ・必要に応じてクラウド連携 ・データの収集・分析 ・段階的な開発 ＋ BLE
26. ③モバイルアプリとのデバイス連携構成 l デバイス通信：Wi-Fi、LTE（+BLE） l 構成：デバイス⇔ クラウド ⇔ スマホ 26 ルーター / ハブ BLE（初回セットアップ時など） 【アプリ構成パターン】 ・遠隔操作・監視 ・データの一元管理 ・データ分析 ・認証などによる信頼性 ・BLEとのハイブリッド ・デバイス側との責務の分離 Wi-Fi LTE
27. 見落としがちな企画・要件定義時のポイント
28. 見落としがちな企画・要件定義時のポイント 先程までの解説で「アプリ構成の全体像は掴めた！これで大丈夫！」 という訳にはいきません 28
29. 見落としがちな企画・要件定義時のポイント l デバイス連携のモバイルアプリ開発は、 ハードウェア制約とOS環境の複雑さから、通常のアプリ開発よりも 上流工程（企画・要件定義）での綿密な設計・考慮が不可欠です l 本セクションでは、重要な以下の4つのポイントを解説します l ①ハードウェア仕様がモバイルアプリ開発に与える影響 l ②非機能要件の制御の難しさ l ③モバイルアプリ開発の技術選定 l ④段階的なリリース計画 29
30. ①ハードウェア仕様がモバイルアプリ開発に与える影響 30 l ①ハードウェア仕様がモバイルアプリ開発に与える影響 l ②非機能要件の制御の難しさ l ③モバイルアプリ開発の技術選定 l ④段階的なリリース計画
31. ①ハードウェア仕様がモバイルアプリ開発に与える影響 1. デバイスのハードウェア仕様を把握する 2. SDKの隠れたリスク 3. デバイスの通信方式がアプリ開発に与える影響 31
32. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-1. デバイスのハードウェア仕様を把握する l 目的・用途の再確認 l 他社デバイス購入使用などの場合は特に l SDK l 対応OSについて、SDKの提供があるのか、何がどこまで提供されているのか l 通信方式 l BLE、LTE、Wi-Fi、NFC、など l その他 l センサー種類：性能、精度、外部環境影響、ユースケース l バッテリー：何時間持つか、電源確保方法 l メモリ容量：何日分のデータを蓄積できるか l ファームウェアアップデート手段、etc. 32
33. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-2. SDKの隠れたリスク SDKとは 、”Software Development Kit” の略であり、ソフトウェア開発 する上で必要なプログラム、API、サンプル、設計情報などの文書を まとめてパッケージ化したものです 33 指示 SDK SDK ≒ デバイスを操作するためのツール ・getData関数 ・setAlert関数 ・deleteData関数 ・etc.
34. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-2. SDKの隠れたリスク l 提供物の種類と充実度 l 保守・サポート体制 34
35. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-2. SDKの隠れたリスク l 提供物の種類と充実度 l デバイス本体と併せてSDKも提供されることが一般的 l SDKの中身の認識すり合わせ・事前確認を l ソースコードだけではなく、「ドキュメントや手順書、サンプルコード」 なども含まれるか また、それらがどこまで充実した記載なのかの確認、など 35 SDK
36. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-2. SDKの隠れたリスク l 保守・サポート体制 l デバイス/SDK の提供後に、アプリ側の開発/検討に進む流れが一般的 l 柔軟な保守/質問対応が可能かどうか l ブラックボックスな提供ライブラリの仕様確認 l 毎年のOSアップデート対応 l ドキュメント類の不整合や意図の確認 36 SDK
37. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響 37 特徴 BLE LTE Wi-Fi 電力消費 低い 高い 高い 通信速度 遅い 早い 非常に早い インターネット 接続 不可 可能（SIM必須） 可能（ルーター経由） 通信距離 近距離 遠距離 中距離 送信データ容量 小さい 大きい 非常に大きい
38. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響：BLE l モバイルアプリ開発コスト：高 l SDK呼び出しがマスト & OS毎それぞれで呼び出し部分の実装 l OSによる制約: “位置情報”、”付近のデバイス検索許可” などの権限制御 l → OS固有知識やネイティブコードの知識が必要に l ベンダー間での連携対応の増加 l SDK仕様やデバイス仕様についての確認対応 l デバイスベンダーとクラウドベンダーとのブリッジ的立ち位置 l 双方の確認対応によるスケジュール遅延のリスク 38 iOS Andro
39. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響：Wi-Fi, LTE l モバイルアプリ開発コスト：低 l 基本的にはクラウドとの通信が主となるため、一般的なAPI開発の構成に l モバイルアプリ開発としての責務・範囲の分離 l デバイス開発会社との責務の分離 l ブリッジ的役割はクラウドベンダー側 l クロスプラットフォームでの開発の選択肢が取りやすい 39
40. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響 これだけを見ると、デバイス連携方式は「Wi-Fi, LTEによるインター ネット経由」のパターン一択？ 40
41. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響：BLE l 特徴： l リアルタイム性が高い l インターネット環境が無いところでも動作・連携可能 l デバイス l モジュール費用：安 l バッテリ消費：低 l 制御もシンプル l クラウド側の開発コスト：低 l 一般的なシンプルな構成で対応可能 41 iOS Andro
42. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響：Wi-Fi, LTE l 特徴： l クラウド経由なのでリアルタイム性は悪い l インターネット環境 や 電源確保 がある前提での利用 l デバイス l モジュール費用：高 l バッテリ消費：高 l 開発コスト：高めの傾向 l クラウド側の開発コスト：増 l ブリッジ的役割がクラウドベンダー側に 42
43. ①ハードウェア仕様がモバイルアプリ開発に与える影響 ①-3. モバイルアプリ開発におけるデバイス通信方式の影響 l どちらの構成も一長一短 l 「モバイルアプリ開発」や「デバイス開発」だけに囚われず、 「ユーザーの利用シーン」や「どのようなサービスを実現したい のか」から逆算してシステム全体の検討を 43
44. ②非機能要件の制御の難しさ 44 l ①ハードウェア仕様がモバイルアプリ開発に与える影響 l ②非機能要件の制御の難しさ l ③モバイルアプリ開発の技術選定 l ④段階的なリリース計画
45. ②非機能要件の制御の難しさ l 非機能要件 = 機能一覧（メイン機能）以外の要件 l デバイス連携機能やモバイルアプリ特有の”非機能要件”についての 事前把握が鍵 45
46. ②非機能要件の制御の難しさ 1. 通信の不安定さ 2. OS権限の取り扱い 3. 保守性（エラーログ対応） 4. OSアップデート対応 5. etc. 46
47. ②非機能要件の制御の難しさ ②-1. 通信の不安定さ l Bluetooth接続の不安定 l リトライ処理の考慮 47
48. ②非機能要件の制御の難しさ ②-2. OS権限の取り扱い l OS側での制限により モバイルアプリ側で完全なコントロールが困難 l OS毎に制限内容に差異があるため、OS毎の対応が必要なことも l 例）バックグラウンドタスク、位置情報、 48 OS
49. ②非機能要件の制御の難しさ ②-3. 保守性（エラーログ対応） l エラー発生時、どの箇所が原因の不具合なのか特定が困難 l 実運用時にはエラー監視ツールの導入が重要に l エラーログから「デバイス内処理、SDK処理、アプリ処理」など、 どこが意図しない動きになっているのかを切り分けれる エラーログ設計が重要に 49 SDK Device App
50. ②非機能要件の制御の難しさ ②-4. OSアップデート対応 l Android, iOS共に、毎年OSバージョンが更新 l モバイルアプリ側も追随してバージョンアップ対応を実施しないと、 ストアへのリリース更新ができない制約 l SDK側のOSバージョンアップ対応も必要となること注意 50 Store Target OS Version: 15 SDK Target OS Version: 15 Required OS Version: 15 ↓ 16 ↓ 16 ↓ 16
51. ②非機能要件の制御の難しさ l デバイス連携特有の「非機能要件」は、企画・要件定義時に見落と しがち l 機能一覧（やりたいことリスト）からは見えにくい 隠れたリスクや隠れた対応事項を、事前にどこまで洗い出せるかが円 滑なプロジェクト進行に影響 51
52. ③モバイルアプリ開発の技術選定 52 l ①ハードウェア仕様がモバイルアプリ開発に与える影響 l ②非機能要件の制御の難しさ l ③モバイルアプリ開発の技術選定 l ④段階的なリリース計画
53. ③モバイルアプリ開発の技術選定 l モバイルアプリ開発における開発言語の特徴 l OSに最適化された言語 (ネイティブ言語) l Android：Kotlin (Google) l iOS： Swift (Apple) l クロスプラットフォーム l React Native (Facebook) l Flutter (Google) 53 ネイティブ言語 クロスプラットフォーム 開発コスト 実質2アプリ分（Android, iOS） 約半分（1つのコードで両OSに対応） 保守コスト 実質2アプリ分（Android, iOS） 約半分（1つのコードで両OSに対応） 新しい技術 最新のOS機能を活用可能 対応されるまで少し時間はかかる傾向 パフォーマンス 高い 若干劣る可能性あり
54. ③モバイルアプリ開発の技術選定 l クロスプラットフォーム での構成イメージ 54 iOS Andro Swift Native Code （SDK呼び出し処理） Kotlin Platform Bridge Code （ブリッジ的な役割） Flutter Flutter Device Responsibility Mobile App Responsibility SDK UI / API
55. ④段階的リリース戦略 55 l ①ハードウェア仕様がモバイルアプリ開発に与える影響 l ②非機能要件の制御の難しさ l ③モバイルアプリ開発の技術選定 l ④段階的なリリース計画
56. ④段階的リリース戦略 56 よくある失敗模範事例① l デバイスやSDK側の開発が一段落し、連携するモバイルアプリ開発 を検討・開発に進んだが、デバイス側の不具合や求めた機能に認識 齟齬があった ↓ l ハードウェア側の仕様変更は大変で手戻りに時間がかかる
57. ④段階的リリース戦略 57 よくある失敗模範事例① l デバイスやSDK側の開発が一段落し、連携するモバイルアプリ開発 を検討・開発に進んだが、デバイス側の不具合や求めた機能に認識 齟齬があった ↓ l ハードウェア側の仕様変更は大変で手戻りに時間がかかる ↓ 当初の計画より大幅にリードタイムが長くなってしまった
58. ④段階的リリース戦略 58 よくある失敗模範事例② l 初回リリース時に完璧な理想を求めすぎ、以下のような問題が発生 l 開発規模が大きくなりすぎて社内の許可が降りない、予算が足りない l 計画したもののリリース時期が延びる、開発スコープが肥大化 l 時間と手間をかけてリリースをしたが、想定した成果が得られない l リリースまでに時間がかかり、市場やユーザーニーズが変化 l リリース後の軌道修正工数の増加
59. ④段階的リリース戦略 59 よくある失敗模範事例② l 初回リリース時に完璧な理想を求めすぎ、以下のような問題が発生 l 開発規模が大きくなりすぎて社内の許可が降りない、予算が足りない l 計画したもののリリース時期が延びる、開発スコープが肥大化 l 時間と手間をかけてリリースをしたが、想定した成果が得られない l リリースまでに時間がかかり、市場やユーザーニーズが変化 l リリース後の軌道修正工数の増加 適切なスコープ単位での段階的なリリース計画はとても重要
60. ④段階的リリース戦略 60 リリース計画例 l PoCフェーズ：技術検証、最低限のコア機能の動作確認、 ビジネス的価値の再確認 l フェーズ1：機能追加、限定的なユーザー公開 l フェーズ2：フィードバッグ取り込み、機能追加、一般ユーザー公開 l フェーズ3：フィードバッグ取り込み、不具合対応、次フェーズ計画 フェーズ3 フェーズ1 フェーズ2 PoC ・・・ フィードバック/軌道修正 フィードバック/軌道修正 フィードバック/軌道修正
61. ④段階的リリース戦略 61 リリース計画例 l PoCフェーズ：技術検証、最低限のコア機能の動作確認、 ビジネス的価値の再確認 l フェーズ1：機能追加、限定的なユーザー公開 l フェーズ2：フィードバッグ取り込み、機能追加、一般ユーザー公開 l フェーズ3：フィードバッグ取り込み、不具合対応、次フェーズ計画 ・技術検証 ・UX確認 ・データ収集/分析
62. ④段階的リリース戦略 62 PoCフェーズの目的や意図をしっかりと認識したうえで、 “構想から素早くPoCフェーズを立ち上げること” が、成功への第一歩
63. 番外編：事例紹介
64. 事例｜ウェアラブルデバイス連携モバイルアプリ開発 64 Client｜FrontAct株式会社 Keyword｜UX/UIデザイン , 先端テクノロジー UXを重視した ヘルスケアアプリの開発を⽀援 お客さまの課題 | ウェアラブルデバイスで取得で きるバイタルデータ等を活⽤し、疾患予防に繋げ る先進的な医療サービスの開発を検討しており、 アイデアを実装できる技術⼒とデザイン⼒のある パートナーを求めていた。 ソリューション | ⾼齢者を含む幅広いユーザーを 意識したUX/UIデザインと、リストバンド型活動 量計との通信（データ取得）⽅法やクラウド基盤 との連携⽅法の検証を⾏ったうえで、モバイルア プリのフロントエンドを開発（Flutterを採⽤し、 iOS/Android対応アプリを開発）。 NCDCの役割 | モバイルアプリの要件定義から設 計、開発、技術検証、リリース後の改善⽀援まで ⼀貫して担当。バックエンド側担当ベンダーへの 要件伝達など専⾨知識が不可⽋な場⾯では実践的 な助⾔を⾏い、お客さまが抱える多様な課題の解 決とプロジェクトの円滑な推進に貢献。 この事例の詳細記事へ
65. 事例｜モバイルアプリ開発 65 Keyword｜サービス企画 , UX/UIデザイン,アプリ開発 スマート農業の新規事業企画 とプロトタイプ開発。 お客さまの課題 | 遠隔地にある菜園の現地視察に 要する移動コストの抑制やCOVID-19の流⾏によ る地域間移動の制約に対処するため、DXプロジェ クトの⼀環で菜園の状況をリモートチェックでき るシステムを検討していた。 ソリューション | 当初検討されていた事業者がリ モートで菜園をチェックする仕組みだけでなく、 ⼀般消費者がモバイルアプリを通じたリモート栽 培で⾃分好みの野菜を育てられるサービスを企画 しNCDCから提案。リモート菜園アプリによる新 たなビジネスの⽴ち上げを⽀援。 NCDCの役割 | サービス企画から、UX/UIデザイ ン、プロトタイプの実装に⾄るまで、アプリ開発 に必要な機能をワンストップで提供。現地菜園へ のネットワークカメラの導⼊もNCDCが⽀援。 Client｜カゴメ株式会社様 この事例の詳細記事へ
66. 事例｜IoTデバイスを活用したサービス開発 66 Client｜三井住友ファイナンス&リース株式会社様 Keyword｜新規サービス開発 , PoC , IoT IoTを活⽤した 設備稼動可視化サービスの開発。 お客さまの課題 | モノをたくさん保有している リース会社にとってIoTは⼤きなテーマ。デジタル イノベーションによる新規事業の開発が今後必要 となるため、その推進役となるパートナーを求め ていた。 ソリューション | 年間契約でリースされるが、稼 働率が低い時期もあるフォークリフトを、稼働状 況に応じてお客さま同⼠でシェアリングできる仕 組みを開発。（ジャイロセンサー＋Bluetooth＋ SIMで稼働状況をリアルタイムでクラウドに記 録） NCDCの役割 | ワークショップ形式でお客さまと ⼀緒にペルソナづくりやカスタマージャーニー マップの設計などに取り組み、ビジネスモデルの 検討から実施。その後もPoC、プロトタイピング （UIの設計）まで、プロジェクト全体を担当。 この事例の詳細記事へ
67. 事例｜スマートデバイスによるハードウェア制御PoC 67 Client｜アズビル株式会社様 Keyword｜PoC , UX/UIデザイン,アプリ開発 ハードウェアと連携するアプリ で直感的な操作を実現。 お客さまの課題 | ⼯場の計測制御機器の設定作業 ⽤にPC向けツールを提供しているが、同ツールで はユーザーが現場で作業場所の確保や有線接続す る⼿間がかかるため、将来に向けて改善策を検討 していた。その⼀環として、スマートデバイスを ⽤いて直感的なUIで機器の設定を⾏うことができ ないか、UX⾯、技術⾯の両⽅から検証したい。 ソリューション | 制御装置とスマートデバイスの 通信⽅法の提案（Bluetoothで実現）から、アプリ のUX/UIデザイン・開発に⾄るまで、PoCに必要 な機能をワンストップで提供。 NCDCの役割 | HTML5とJavaScriptによるアジャ イル開発を⾏うことで、定期レビューでの意⾒を 取り⼊れたプロトタイプを素早く提供。マニュア ルなしで誰もが直感的に操作できるUIを実現し、 ユーザーテストでは良好な結果を得た。 この事例の詳細記事へ
68. 本日のまとめ
69. 本日のまとめ l デバイス連携の全体像と連携方式について l 見落としがちな企画・要件定義時のポイント 69
70. 本日のまとめ l デバイス連携の全体像と連携方式について l ①連携するデバイスの種類と特性 l ②デバイスの主な通信種類 l ③モバイルアプリとのデバイス連携構成 70
71. 本日のまとめ l 見落としがちな企画・要件定義時のポイント l ①ハードウェア仕様がモバイルアプリ開発に与える影響 l デバイスのハードウェア仕様の把握 l SDKの隠れたリスク l デバイスの通信方式がアプリ開発に与える影響 l ②非機能要件の制御の難しさ l 通信の不安定さ、OS権限の取り扱い、保守性、OSアップデート対応、etc. l ③モバイルアプリ開発の技術選定 l ④段階的なリリース計画 71