EXECUTIVE SUMMARY
TDR TPMS APP Version 2 開発のご提案
T&D Regulus 御中 ／ ピースフラットシステム株式会社
異常を知らせるだけではなく、
安心して出発できる APPへ。
安心して出発できる APPへ。
More than warnings. Confidence before every journey.
御社ブランドブック Version 1.1 より ／ この二行を、実際に触れる形にしたのが本デモです。
対応プラットフォーム
2OS
iOS ／ Android 同時開発
実装対象機能
38件
機能一覧を見る →
実機試験 対象端末
24機種
試験計画を見る →
本日ご覧いただける画面
9画面
APPデモを開く →
御社の課題認識
頂戴した2つの資料から、以下のように理解しております。
既製APPのままでは、御社の価値が伝わらない
Version 1 では工場標準APP（iBar - For BLE TPMS）を活用して市場を先行して押さえられている一方、UI・音声・状態表現は他社と同一。御社が積み上げてきたTPMSノウハウが製品体験に反映されていない状態です。
iOS／Android 双方で BLE を安定して受け続ける難しさ
TPMSセンサーはAdvertisingを常時発信し続ける方式のため、バックグラウンド受信・省電力・再接続の設計がAPPの品質をそのまま決めます。ここは実装経験の差が最も出る領域です。
乗用車で終わらせず、大型車・クラウドまで繋げたい
「今回の開発は完成品ではなく、TDR TPMSプラットフォームの出発点」。初期設計の段階で多軸・多輪、複数車両、クラウド同期を織り込んでおく必要があります。
弊社からのご提案
3本柱を実装で示します御社が掲げる3つの体験を、そのまま実装要件に落とし込みました。
① 運転開始時 正常確認音声
新しい運転セッションを自動判定し、全センサーの初回受信・状態確認が完了した時点でTTS案内。「監視を開始します。タイヤの空気圧と温度は正常です。安全に注意して運転してください。」
② 蛍の光（受信脈動）
受信のたびに強く点滅させるのではなく、アンバーの発光と自然減衰で「静かに見張っている」ことを伝えます。運転中の視線負荷を上げずに監視継続を可視化します。
③ 2段階しきい値（注意 → 警告）
標準空気圧を基準に、正常 → 注意（Amber）→ 警告（Red）を圧力・温度の双方で管理。かんたん設定で自動算出し、詳細設定で個別調整できる二層構造とします。
Version 1 → Version 2 で変わること
Before ／ 工場標準APP（Version 1）
- 異常が出てから警報が鳴る
- 正常であることは画面を見ないと分からない
- 正常／異常の2値判定
- 設定項目が一階層に並び、どこを触ればよいか迷う
- 受信表示が強い点滅で、運転中に気が散る
- UI・文言・音声が他社製品と共通
After ／ TDR オリジナルAPP（Version 2）
- 出発時に「正常です」と声で確認できる
- 見ていなくても監視状態が伝わる
- 正常 → 注意 → 警告の3段階で予兆を捉える
- かんたん設定＋詳細設定の二層構造
- アンバーの穏やかな発光・減衰で静かに伝える
- TDRブランドの体験として差別化
差別化コンセプトを、実装要件に翻訳する
ブランドブック 05 ／ 行をクリック御社が定義された差別化の4項目に対し、それを画面・コードのどこで実現するかを第3列として補いました。ここが弊社の提案部分です。
一般的な TPMS APP
TDR TPMS APP（御社定義）
弊社の実装方針
異常発生後の警報が中心
正常状態も確認し「安心」を提供
監視ステータスを常時1行で提示し、出発時に正常確認音声を発話。「何も起きていない」を能動的に伝える状態を作ります
設定項目が分かりにくい場合がある
かんたん設定＋詳細設定の二層構造
初回は標準空気圧の入力1つだけ。4種のしきい値を自動算出し、詳細設定は別画面へ退避。触りたい人だけが降りていける導線に
単一車両・単機能で完結しやすい
Lite／Full から大型車・多車両へ拡張
機能の出し分けをビルドではなくエディション定義で制御。車両・軸・輪を可変データ構造で持ち、大型車を表示層の追加だけで賄います
製品購入後の運用支援が限定的
将来のクラウド・法人運用まで一貫設計
全計測値に一意ID＋時刻を付与し、同期キューを差し込める形で保存。Phase 4 を追加開発だけで到達可能にしておきます
この表の3列目が、本日お伝えしたいことのすべてです。1列目・2列目は御社が既に定義済みで、議論の余地はありません。問われているのは「その思想を、iOS／Android の実制約の中で誰が成立させられるか」。弊社はそこに回答を持って参りました。
センサー受信ログ（デモ）
リアルタイム本提案でお約束すること
| ソースコードの帰属 | 成果物一式を御社へ納品。ビルド手順書・設計資料を含みます |
|---|---|
| 改善提案 | 仕様を受け取るだけでなく、実装検証の結果からUI/UX改善案を継続提示 |
| ストア公開 | App Store／Google Play の申請・審査対応まで伴走 |
| 拡張性 | 多軸・多輪、複数車両、クラウド同期を初期アーキテクチャに織り込み |
| 継続保守 | OSバージョンアップ追従、不具合対応、機能追加に継続対応 |
INTERACTIVE PROTOTYPE
TDR オリジナルAPP 動作デモ
右のコンソールから操作してください。スマートフォン画面が実際に反応します。
今回はUIデザインのご提案ではありません。あくまで動きを確認していただくためのイメージです。配色・レイアウト・文言はいずれも仮のものであり、確定した画面デザインをご提示するものではございません。ご覧いただきたいのは「正常確認音声」「蛍の光」「注意 → 警告の2段階」が実際にどう振る舞うかという挙動の部分です。
9:41
タイヤ状態
ハリアー
運転開始時 正常確認音声「運転開始」を押すと音声案内が流れます。
左前
2.40bar
28℃
右前
2.38bar
29℃
左後
2.32bar
27℃
右後
2.35bar
27℃
スペアタイヤ
最終受信 2分前
最終受信 2分前
2.50bar
低圧警告
低圧注意
正常
高圧注意
高圧警告
左前タイヤ
現在の空気圧
2.40bar
標準 2.40 bar ／ 温度 28℃
正常
直近30分の推移
センサー情報
センサーIDTDR-EX-8A41C2
EX型
電池残量約 82%（推定残 14ヶ月）
良好
受信強度-64 dBm ／ 受信間隔 約6秒
安定
車両を選ぶ
登録済みの車両
ハリアー4輪＋スペア ／ 標準 2.40 bar
ハイエース4輪 ／ 標準 3.00 bar
N-BOX4輪 ／ 標準 2.20 bar
将来対応（Phase 3）
4tトラック10輪 ／ 3軸 ／ 大型車モード
準備中
センサー登録
センサー同梱のQRコードを枠内に合わせてください
登録方法を選ぶ
QRコードで登録最速。同梱シールを読み取るだけ
センサーIDを手入力QRが読めない場合の代替手段
装着して自動登録取り付け時の圧力変化を検知して自動割当
登録済みセンサー
左前 ／ TDR-EX-8A41C2電池 82% ／ 受信 良好
EX
右前 ／ TDR-EX-8A41D7電池 79% ／ 受信 良好
EX
左後 ／ TDR-EX-8A41E3電池 88% ／ 受信 良好
EX
右後 ／ TDR-EX-8A41F9電池 84% ／ 受信 良好
EX
かんたん設定
詳細設定 STEP 1
運転席ドアのラベルに書かれた
標準空気圧を入力してください
標準空気圧を入力してください
標準空気圧2.40 bar
1.803.50 bar
入力値から自動算出しました
低圧 注意2.04 bar
低圧 警告1.80 bar
高圧 注意2.76 bar
高圧 警告3.00 bar
この設定で保存するあとから詳細設定で個別調整できます
よく使う設定
運転開始時 正常確認音声ON
蛍の光（受信脈動表示）ON
バックグラウンド監視ON
詳細設定 ／ 2段階しきい値
空気圧
低圧 注意（Amber）2.04 bar
低圧 警告（Red）1.80 bar
高圧 注意（Amber）2.76 bar
高圧 警告（Red）3.00 bar
温度
温度 注意（Amber）75 ℃
温度 警告（Red）85 ℃
通知
注意（Amber）で音声通知ON
警告（Red）で警告音＋音声ON
ホーム
車両
センサー
設定
画面デザインは御社ブランドブックの状態表現（Amber／Red）を踏襲した弊社案です。
確定仕様ではありません。
確定仕様ではありません。
デモ操作コンソールクリックで左の画面が動きます
このデモで見ていただきたい3点
音声が「異常」ではなく「正常」を伝えている
①を押すと、監視開始と同時に正常を読み上げます。運転者が画面を見ずに安心を得られる状態を、出発の瞬間に作ります。御社の思想の中核だと理解しています。
受信のたびに、タイヤが静かに光っている
操作しなくても各タイヤが不定期にアンバー発光しています。これが「蛍の光」の弊社解釈です。点滅の強さ・減衰カーブは実車での視認性試験で詰めるべき項目と考えています。
警告の前に、必ず注意がある
②を押すと圧力が徐々に低下し、黄→赤と2段階で遷移します。下部のレンジ表示も連動します。「異常の手前から知らせる」を画面上で確認いただけます。
デモに含めた画面（9画面）
| タイヤ状態／監視 | 4輪＋スペア、蛍の光、状態レンジ |
| タイヤ個別詳細 | 推移グラフ、センサーID、電池、受信強度 |
| 車両切替 | 複数車両登録、大型車は将来対応 |
| センサー登録 | QR／手動ID／装着自動の3方式 |
| かんたん設定 | 標準空気圧からしきい値を自動算出 |
| 詳細設定 | 圧力・温度それぞれ2段階しきい値 |
| 運転開始時 音声案内 | 初回受信・状態確認後にTTS発話 |
| 注意／警告 遷移 | Amber → Red の段階通知 |
| バックグラウンド通知 | APP終了時の挙動（技術協議が必要） |
FUNCTIONAL SCOPE
機能一覧・画面設計
御社ブランドブック 06「TDR独自APPの主要機能（構想）」を実装単位に分解しました。
Phase 1（必須）
26件
Version 2 リリース対象
Phase 2（改善）
8件
市場評価を見て実装
Phase 3（拡張）
4件
大型車・クラウド →
| 分類 | 機能 | 実装内容 | 区分 |
|---|---|---|---|
| BLE通信 | BLE Advertising 常時受信 | センサーが発信するAdvertisingパケットを受信・解析。接続確立を伴わない方式で電力効率を確保 | Phase 1 |
| ペイロード解析 | 圧力／温度／電池残量／アラームフラグの復号。センサー仕様書の提供を前提 | Phase 1 | |
| バックグラウンド受信 | OS別に最適な受信戦略を実装。iOSは制約が大きく、方式の合意が必要（PoCでの実測を推奨） | 要協議 | |
| 受信途絶検知・自動復帰 | 一定時間受信がないセンサーを「受信なし」表示に切替。復帰時に自動で通常表示へ | Phase 1 | |
| 監視表示 | タイヤ状態画面（4輪＋スペア） | 車両図に沿った配置で圧力・温度を表示。タップで個別詳細へ | Phase 1 |
| 受信脈動表現（蛍の光） | 受信のたびにアンバーのリングが発光し自然減衰。強い点滅を避け視線負荷を抑制 | Phase 1 | |
| 状態レンジ表示 | 低圧警告／低圧注意／正常／高圧注意／高圧警告を帯で可視化し現在位置を強調 | Phase 1 | |
| タイヤ個別詳細 | 推移グラフ、センサーID、電池残量、受信強度・受信間隔 | Phase 1 | |
| 音声・通知 | 運転開始時 正常確認音声 | 新しい運転セッションを判定し、全センサー初回受信・状態確認後にTTS発話 | Phase 1 |
| 運転セッション判定 | 加速度／位置情報／BLE受信再開などから走行開始を判定。方式は要協議 | 要協議 | |
| 異常時 音声通知（TTS） | 注意（Amber）・警告（Red）到達時に該当輪と状態を読み上げ | Phase 1 | |
| 警告音（Red） | 音声に加え警告音を併用。運転中の気づきやすさを優先 | Phase 1 | |
| OS通知（バックグラウンド） | APP非表示時はローカル通知で異常を伝達 | 要協議 | |
| 設定 | かんたん設定 | 標準空気圧の入力のみで4種のしきい値を自動算出。初回起動ウィザードに組込 | Phase 1 |
| 詳細設定（2段階しきい値） | 低圧注意／低圧警告／高圧注意／高圧警告＋温度注意／温度警告を個別調整 | Phase 1 | |
| 単位切替 | bar ／ kPa ／ psi、温度は ℃ ／ ℉ に対応 | Phase 1 | |
| 登録・管理 | センサー登録（QR） | 同梱QRの読み取りでIDと装着位置を一括登録 | Phase 1 |
| センサー登録（手動ID） | QRが読めない場合のID直接入力 | Phase 1 | |
| センサー登録（装着自動） | 取り付け時の圧力変化を検知して装着位置を自動割当 | 要協議 | |
| 複数車両登録・切替 | 車両ごとに標準空気圧・しきい値・センサー構成を保持 | Phase 1 | |
| タイヤ位置入替（ローテーション） | センサーを外さずAPP上で装着位置を入替 | Phase 2 | |
| 記録・その他 | 走行履歴・ログ | 運転セッション単位で圧力・温度推移を保存。不具合解析用ログ出力も兼ねる | Phase 2 |
| センサー電池管理 | 残量推定と交換時期の事前通知 | Phase 2 | |
| 大型車モード（多軸・多輪） | 3軸10輪などの表示レイアウトと個別詳細 | Phase 3 | |
| クラウド同期・法人管理 | 複数車両の一元管理、履歴の集約、管理者向けWeb | Phase 3 |
UI/UX 高度化のご提案
カードをクリックで詳細
ブランドブック 10 に 「既存UIは完成形の固定仕様ではありません。TDRの状態表現・操作体系・安心設計を継承した UI/UX高度化提案を歓迎します」 と記載いただいておりましたので、
現時点で弊社から4案をお持ちしました。いずれも御社の状態表現（Amber／Red）と操作体系を壊さない範囲での提案です。
これらは弊社の社内UI/UXデザイナーが作成しています。デザインを外注せず、エンジニアと同じチームに置いているため、実装可能性を確認した上での提案になっています。
① 出発前チェックを1画面に
「安心して出発できる」を、音声だけでなく画面でも成立させる案
② 色に頼らない状態表現
Amber／Red を色覚特性・直射日光下でも識別可能にする案
③ ナイトモードと蛍の光
夜間走行時の視線負荷をさらに下げる案
④ 輪配置レイアウトの抽象化
乗用車のUIをそのまま大型車へ継承するための設計案
これらは提案であって、押し付けではありません。御社の思想と合わない案があれば、その場で却下いただいて構いません。弊社としては「仕様を受け取るだけでなく改善案を提示できること」というご期待に、初回の段階から応じておきたいと考えました。
「要協議」について。技術的に不可能という意味ではなく、OSの制約と実運用のバランスをどこで取るかを御社と決める必要がある項目です。ここを曖昧にしたまま見積を出す会社もありますが、後で必ず揉めるため、弊社は先に論点として提示します。該当項目は、本開発に先立つ技術検証（PoC）で実測し、保証範囲を御社と合意した上で仕様として明記させてください。
TECHNICAL APPROACH
技術提案・システム構成
将来のクラウド連携を妨げない構成を、初期設計から採用します。
工場標準APP（Version 1）の実機調査結果
頂戴した参考資料に基づく| APP名称 | iBar - For BLE TPMS |
|---|---|
| 配布先 | Google Play ／ iOS版も同名称で提供 |
| パッケージID | com.vince.bluetaiya |
| 開発元表示 | 深圳君安软件技术有限公司 |
継承すべきと判断した点
車両図に沿ったタイヤ配置、圧力を主・温度を従とする情報の優先順位、ゲージ的な状態表現。ユーザーが既に慣れている操作体系であり、Version 1 のユーザーがそのまま移行できることに価値があります。
高度化余地があると判断した点
正常時に伝えるものが無い／設定が一階層に並ぶ／受信表示が強い点滅／状態が2値。いずれも御社が V1.1 で課題として挙げられた点と一致しており、認識の相違はありません。
複製はいたしません。頂戴した資料に「本APPをそのまま複製することを目的としたものではありません」と明記いただいている通り、弊社も iBar を参考APPと位置づけ、操作体系と情報の優先順位のみを参照します。コード・画像アセット・画面レイアウトの流用は行いません。
一方で、本件が「ゼロから要件を作る案件ではない」ことも承知しております。御社にご提供いただける APP機能仕様書・画面デザイン・かんたん設定／詳細設定仕様・しきい値参考データ集・UI素材を土台とし、そこにAPPのコードを新規実装するという進め方です。要件と意匠は既存資産で加速させ、実装は独自に作る。この切り分けが最短で、かつ御社に資産が残る形だと考えています。
一方で、本件が「ゼロから要件を作る案件ではない」ことも承知しております。御社にご提供いただける APP機能仕様書・画面デザイン・かんたん設定／詳細設定仕様・しきい値参考データ集・UI素材を土台とし、そこにAPPのコードを新規実装するという進め方です。要件と意匠は既存資産で加速させ、実装は独自に作る。この切り分けが最短で、かつ御社に資産が残る形だと考えています。
システム構成
TPMSセンサー
EX／IN型
圧力・温度を発信
圧力・温度を発信
BLE Advertising
接続不要の
ブロードキャスト
ブロードキャスト
受信・解析層
ネイティブ実装
OS別に最適化
OS別に最適化
TDR APP
UI・音声・通知
しきい値判定
しきい値判定
クラウド
Phase 3
履歴・法人管理
履歴・法人管理
設計の要点。受信・解析層をUIから完全に切り離します。ここを分離しておくことで、①OS個別の制約対応をUIに波及させない ②大型車の多輪対応を表示層の差し替えだけで実現できる ③クラウド同期を後から追加してもAPP本体を作り直さずに済む、という3つの利点が得られます。
技術スタックのご提案
クリックで詳細| 領域 | 採用案 |
|---|---|
| UI層 | Flutter ／ iOS・Android で画面実装を共通化 |
| BLE受信層 | ネイティブ実装（Swift / Kotlin）＋ 独自ブリッジ |
| 音声 | OS標準TTS＋事前収録音声のハイブリッド |
| ローカル保存 | 暗号化ローカルDB ／ クラウド同期を見据えたスキーマ |
| 将来クラウド | REST＋同期キュー方式。オフライン優先設計 |
なぜ BLE層だけネイティブなのか。BLEはOSごとに挙動・制約・省電力の作法が大きく異なり、クロスプラットフォームのラッパー任せにすると「特定機種だけ受信が途切れる」といった再現困難な不具合を抱えます。UIは共通化して開発効率を取り、品質を左右するBLEはネイティブで作り込む。これが弊社の判断です。
常時監視と電池消費の両立
TPMSは「走行中ずっと受信し続ける」性質上、スマートフォン側の電池消費が製品評価に直結します。以下を設計方針とします。
スキャンフィルタをOS側に委譲
対象センサーのみをOSレベルで絞り込み、アプリ側の起床回数そのものを減らします
走行／停車でスキャン強度を可変
停車中はスキャン間隔を広げ、走行検知で高頻度へ復帰させます
実測での検証を前提に
「1時間走行あたりの電池消費○%以内」を実機試験の合格基準として数値で握ります
車載充電を想定した挙動
給電中は画面点灯を維持するモードなど、実際の使われ方に合わせた設計を提案します
QUALITY ASSURANCE
品質保証・実機試験計画
TPMSは安全に関わる製品です。机上のテストでは品質を担保できないと考えています。
iOS 実機
10機種
iPhone SE 〜 最新世代
Android 実機
14機種
主要メーカー・価格帯を網羅
実車走行試験
3車種
乗用車・軽・商用
連続稼働試験
72時間
受信途絶・メモリリーク検証
試験項目
| 受信安定性 | 走行中の連続受信、途絶からの復帰、電波環境の悪い場所での挙動 |
|---|---|
| しきい値判定 | 境界値前後での状態遷移、チャタリング（頻繁な行き来）の抑制 |
| 音声通知 | 実車内での聞き取りやすさ、他アプリ音声との競合、カーオーディオ出力 |
| 電池消費 | 1時間走行あたりの消費率。合格基準を数値で設定し実測 |
| バックグラウンド | OS別・機種別の挙動差、省電力設定下での受信可否 |
| 高温環境 | 夏場の車内を想定した端末温度上昇下での動作継続 |
| 視認性 | 直射日光下での画面視認性、蛍の光の見え方、夜間モード |
安全に関わる製品としての配慮
誤警報を出さない設計
一時的な受信ノイズで警告を出すと、ユーザーは次第に警告を無視するようになります。複数回の連続検知を条件とし、誤警報を抑制します
警報を見落とさない設計
画面を見ていない前提で、音声・通知・警告音を組み合わせます。視覚だけに頼りません
運転中の操作を要求しない
走行中に画面操作が必要な導線を作りません。設定は停車時に完結する構成とします
責任範囲の明示
APPは点検を代替するものではない旨を、初回起動時と取扱説明に明記する設計をご提案します
解析可能なログ設計
市場で不具合が起きた際に原因を追える形でログを残します。リリース後の改善速度に直結します
ROADMAP
将来拡張とロードマップ
「今回の開発は完成品ではなく、TDR TPMSプラットフォームの出発点」── この前提を設計に織り込みます。
Development Roadmap
01 ／ 実施済
乗用車向け
4輪／4＋スペア
市場評価・販売実績の蓄積
市場評価・販売実績の蓄積
02 ／ 今回
TDR独自APP
独自UI／音声／
2段階しきい値
← 本ご提案の範囲
2段階しきい値
← 本ご提案の範囲
03 ／ 次期
中・大型車
多軸・多輪表示
商用車運用
画面イメージを見る
商用車運用
画面イメージを見る
04 ／ 将来
クラウド
履歴・多車両
法人管理
画面イメージを見る
法人管理
画面イメージを見る
05 ／ 構想
次世代
運行支援・解析
OEM／協業
OEM／協業
Lite ／ Full のエディション設計
ブランドブック 05 より「Lite／Full から大型車・多車両へ拡張」という方針について、設計として先に決めておくべき点を整理しました。 エディションは後から足すと必ず作り直しになる領域です。
| 機能 | Lite | Full | 設計上の考え方 |
|---|---|---|---|
| 4輪監視・2段階しきい値 | あり | あり | 安全に関わる中核機能は Lite でも制限しない。ここを削ると製品の信頼そのものが下がります |
| 運転開始時 正常確認音声 | あり | あり | 御社ブランドの中核体験。Lite で外すと「TDRのAPP」である意味が薄れると考えます |
| スペアタイヤ監視 | — | あり | センサー本数に連動する機能はエディション差を付けやすい領域 |
| 複数車両登録・切替 | 1台 | 無制限 | データ構造は最初から多車両前提。Lite は上限値による制限とし、実装を分岐させません |
| 走行履歴・ログ | — | Phase 2 | 保存は両エディションで行い、閲覧UIのみを出し分ける方式を推奨 |
| 大型車モード | — | Phase 3 | 輪配置を可変データで持てば、表示層の追加だけで到達できます |
エディション分岐は、コードではなく設定で持ちます。Lite版・Full版を別ビルドとして分けると、以後すべての改修が二重作業になり、不具合も倍に増えます。単一のコードベースに「エディション定義」を持たせ、機能の可否と上限値だけを切り替える方式を強く推奨します。ストア上の見え方は分けられますが、保守は一本で済みます。
Phase 3 ／ 中・大型車対応で必要になること
| 多軸・多輪レイアウト | 3軸10輪、4軸14輪など。車両構成を定義できるデータ構造が前提 |
|---|---|
| ダブルタイヤ（内輪・外輪） | 内側タイヤの異常は目視で気づきにくく、TPMSの価値が最も高い領域 |
| リピーター／受信機連携 | 車長が長い大型車ではBLE到達距離が課題。中継機の利用を想定した通信層設計 |
| 積載状態による基準変更 | 空車・積車で標準空気圧が変わる運用への対応 |
| トレーラー連結 | 連結・解放に応じた監視対象の動的な切替 |
これらは Phase 3 で作る機能 ですが、Phase 2（今回）の段階でデータ構造に織り込んでおく必要があります。「4輪固定」で作ってしまうと、大型車対応の際に作り直しになります。今回のアーキテクチャ設計で最も重視している点です。
Phase 4 ／ クラウド・法人運用
| 車両一元管理 | 管理者が全車両の状態を1画面で把握。異常車両を即座に特定 |
|---|---|
| 履歴の集約・分析 | 走行ごとの記録を蓄積し、点検記録・整備計画に活用 |
| 管理者アラート | ドライバーだけでなく運行管理者にも異常を通知 |
| 権限管理 | ドライバー／管理者／整備担当の役割別権限 |
| オフライン優先 | 圏外でもAPP単体で監視は継続し、通信回復時に同期 |
クラウドは「後付け」が最も高くつく機能です。今回の設計段階で、データに一意なIDと時刻を持たせ、同期キューを差し込める構造にしておけば、Phase 4 は追加開発だけで到達できます。逆にここを省くと、APP本体の作り直しが発生します。
ABOUT US & NEXT STEP
弊社について ／ 次の一歩
単発の受託ではなく、長期的に製品を育てる協業をご一緒したいと考えています。
「開発パートナーに期待すること」6項目への回答
ブランドブック 10 ／ 行をクリック御社が挙げられた6つのご期待に対し、逃げずに1対1でお答えします。できないことは、できないと書いています。
| 御社のご期待 | 対応 | 弊社の回答 |
|---|---|---|
| BLE／IoT機器連携アプリの実績 | 対応可 | BLE機器と連携する業務アプリの開発実績があります。TPMS特有のAdvertising常時受信については、PoCで実測してからお約束します |
| iOS・Android 双方への対応力 | 対応可 | UI層は Flutter で共通化、BLE層のみ Swift／Kotlin でネイティブ実装。同一チームが両OSを担当し、挙動差の押し付け合いを構造的に無くします |
| OS制約を踏まえた現実的な技術提案 | 対応可 | iOSのバックグラウンドBLE制約を、契約前に論点として開示しています。「できます」とは即答せず、実測してから保証範囲をお約束しますクリックで詳細 |
| 仕様を受け取るだけでなく改善案を提示できること | 対応可 | 機能一覧ページに UI/UX高度化提案4案 を掲載しました。ご発注前の段階から提案しています |
| 実機評価・品質管理・継続保守への対応 | 対応可 | 24機種の実機試験＋実車走行試験を計画に組込済。リリース後のOS追従・不具合対応・機能追加も継続してお受けします |
| 大型車・クラウド展開まで見据えた設計姿勢 | 対応可 | 輪配置の可変データ構造、一意ID＋時刻の付与、同期キューを差し込める保存層。Phase 2 の今、Phase 3・4 の下地を入れます |
なお 「単発の受託ではなく、長期的に製品を育てる協業を希望」 という一文が、弊社にとっては最も響きました。弊社は上流が固まっていない段階から入り、リリース後も伴走する進め方を主戦場にしています。求められている関わり方と、弊社が最も価値を出せる関わり方が一致していると考えています。
弊社をお選びいただく理由
制約を先に開示します
できないこと・決めるべきことを、契約前に論点として提示します。機能一覧の「要協議」表記がその実例です
エンジニアだけでなく、デザイナーが在籍しています
弊社にはUI/UXデザイナーが社内におり、エンジニアと同じチームで動きます。デザインを外部に発注しないため、「デザイン案は上がったが実装すると崩れる」「実機で見たら文字が小さすぎた」といった手戻りが起きません。
御社からご提供いただく画面デザイン・GIF・脈動演出などのUI素材をそのまま実装に落とし込む役割を担うと同時に、実機で検証した上での高度化提案も、このデザイナーが作成しています（機能一覧ページの4案がその成果です）。
御社からご提供いただく画面デザイン・GIF・脈動演出などのUI素材をそのまま実装に落とし込む役割を担うと同時に、実機で検証した上での高度化提案も、このデザイナーが作成しています（機能一覧ページの4案がその成果です）。
仕様を受け取るだけで終わりません
御社が求められている「改善案を提示できること」を、本デモの段階から実践しています
上流が固まっていない段階から伴走します
要件が確定する前の相談段階からご一緒し、要件そのものを一緒に作る進め方を得意としています
リリース後こそ本番だと考えています
市場評価を受けての改善、OS追従、Phase 3・4 への拡張まで継続してご一緒します
類似案件の実績
守秘のため匿名で記載| 公立医科大学A 教育・医療 | 在籍約900名規模の成績管理システムをスクラッチ開発。要件が固まっていない相談段階から参画し、現行業務様式を活かす形で要件を共同で定義 |
| 電気設備工事業A社 建設業・中堅 | 入口は単一機能の相談だったが、ヒアリングで3部署23項目の課題が判明。単発開発ではなく段階的な伴走支援として再設計し、現在進行中 |
| その他 複数業種 | 業務システム・SaaS・モバイルアプリの受託開発。詳細は個別にご説明いたします |
いずれも 「発注側で要件が固まりきっていない状態から、一緒に決めていく」 進め方の案件です。御社の Version 2 も、詳細仕様は技術協議の進展に応じて順次確定していくと伺っております。この進め方こそ弊社が最も価値を出せる形だと考えています。
ネクストステップのご提案
STEP 1 ／ 直近
技術協議の場
BLE仕様・バックグラウンド方針・運転セッション判定について、御社技術ご担当者様と直接すり合わせをさせてください。
所要：2時間程度
所要：2時間程度
STEP 2
要件書の拝受
「国内開発協力先 募集・選定要件書」および実機センサー・仕様資料をご提供いただき、正式なお見積とご提案書を提出いたします。
STEP 3
技術検証（PoC）
2〜3週間で実機による受信検証を実施し、実測データをもって方式を確定。PoC単体での先行ご発注も承ります。
一緒に「次の TPMS」を育てる
パートナーでありたいと考えています。
パートナーでありたいと考えています。
ピースフラットシステム株式会社 ／ T&D Regulus TDR TPMS APP Project