意思決定に必要な要点を、3つに絞ってご説明します。
頂戴した「ブランドブック Version 1.1」および「工場標準APP 参考情報提示資料 Version 1.0」から、以下のように理解しております。
Version 1 では工場標準APP（iBar - For BLE TPMS ／ 開発元表示：深圳君安软件技术有限公司）を活用され、市場を先行して押さえられています。開発期間中もユーザー評価を蓄積できる状態を作られた点は、極めて合理的なご判断だと考えております。
一方で、UI・音声・状態表現は他社製品と共通のままです。御社が乗用車から大型車まで製品を展開し、実運用・販売・ユーザー対応を通じて積み上げてこられたTPMSノウハウが、製品体験としては差別化に転化できていない状態にあると理解しております。
TPMSセンサーは Advertising を常時発信し続ける方式です。そのため、バックグラウンド受信・省電力・再接続の設計が、そのままAPPの品質を決めます。ここは実装経験の差が最も大きく出る領域であり、本件で最も難しいのはUIでも音声でもなく、この受信層です。
「今回の開発は完成品ではなく、TDR TPMSプラットフォームの出発点」（ブランドブック 07）というご方針を拝読いたしました。初期設計の段階で多軸・多輪、複数車両、クラウド同期を織り込んでおかなければ、Phase 3 で作り直しが発生します。この手当ては、今しか打てません。
ブランドブック 09 に 「ゼロから要件を作る案件ではなく、既存資産を活用して開発を加速」 と明記いただいております。APP機能仕様書・開発確認書、画面デザイン・画面遷移案、かんたん設定／詳細設定仕様、しきい値参考データ集、GIF・脈動演出などのUI素材、TPMS実機センサー・受信機、市場投入後のユーザー評価 ── これら既存資産をお持ちであることが、本件の最大の強みだと認識しております。
御社が定義された3つの体験を、実装要件へ翻訳した上でお受けいたします。
| 御社の定義 | 実装として何をするか | 難易度・論点 |
|---|---|---|
| 運転開始時 正常確認音声 |
新しい運転セッションを機械的に判定し、全センサーの初回受信・状態確認が完了した時点でTTS発話。定型部分は事前収録音声、可変部分はOS標準TTSのハイブリッド構成 | 「どこからが新しい運転か」の判定方式が論点。BLE受信の再開＋一定時間の受信途絶の組合せを第一案として推奨します（追加権限が不要なため） |
| 蛍の光 （受信脈動） |
受信のたびにアンバーのリングが発光し自然減衰。強い点滅を避け、運転中の視線負荷を上げずに監視継続を可視化 | 発光強度・減衰カーブは実車での視認性試験で詰めるべき項目と考えております。直射日光下・夜間の2つの条件で検証します |
| 2段階しきい値 （注意 → 警告） |
標準空気圧を基準に、正常 → 注意（Amber）→ 警告（Red）を圧力・温度の双方で管理。かんたん設定で自動算出し、詳細設定で個別調整できる二層構造 | 境界値付近でのチャタリング（状態の頻繁な行き来）抑制が論点。複数回の連続検知を条件とし、誤警報を出さない設計とします |
設計の要点は、受信・解析層をUIから完全に切り離すことです。ここを分離しておくことで、①OS個別の制約対応をUIに波及させない ②大型車の多輪対応を表示層の差し替えだけで実現できる ③クラウド同期を後から追加してもAPP本体を作り直さずに済む、という3つの利点が得られます。
| 領域 | 採用案 | 採用理由 |
|---|---|---|
| UI層 | Flutter | iOS・Android で画面実装を共通化し、Phase 3・4 の画面追加を二重実装せずに済ませるため |
| BLE受信層 | ネイティブ実装 （Swift / Kotlin） | BLEはOSごとに挙動・制約・省電力の作法が大きく異なり、クロスプラットフォームのプラグイン任せにすると「特定機種だけ受信が途切れる」という再現困難な不具合を抱えます。受信が止まらないことが最優先要件である以上、ここは自前で作り込みます |
| 音声 | 収録音声＋OS標準TTS のハイブリッド | ブランドを担う定型文は収録音声で声質を統一し、可変部分のみTTSで生成するため |
| ローカル保存 | 暗号化ローカルDB | 全計測値に一意ID＋更新時刻を付与し、Phase 4 のクラウド同期をデータ移行なしで追加できるようにするため |
ブランドブック 05 の「Lite／Full から大型車・多車両へ拡張」というご方針について、設計上のご提案が1点ございます。Lite版・Full版を別ビルドとして分けると、以後すべての改修が二重作業になり、不具合も倍に増えます。単一のコードベースに「エディション定義」を持たせ、機能の可否と上限値だけを切り替える方式を強く推奨いたします。ストア上の見え方は分けられますが、保守は一本で済みます。
なお、安全に関わる中核機能（4輪監視・2段階しきい値・正常確認音声）は、Lite でも制限しないことをご提案します。ここを削ると製品そのものの信頼が下がるためです。エディション差は、スペアタイヤ監視・複数車両登録数・走行履歴の閲覧といった領域で設けるのが適切と考えております。
御社が「OS制約を踏まえた現実的な技術提案」を求められている点について、弊社の見解を契約前に開示いたします。
| 状態 | iOS の実際の挙動 | 弊社の対応方針 |
|---|---|---|
| APPを開いている | 制約はほぼなし。高頻度で受信でき、脈動表現・音声もそのまま動作 | ここが主たる利用シーン。運転中はAPPを開いた状態を標準運用として設計します |
| APPを閉じている （バックグラウンド） | スキャン条件が厳しく制限され、受信頻度も大きく落ちる。メーカー独自データの扱いにも制約がある | 受信を止めないための複数のアプローチを検証し、実測データを添えて方式をご提案します。PoCでの事前検証を強く推奨いたします |
| ユーザーがAPPを スワイプ終了した | OSからの自動復帰は保証されない | 仕様として「監視が止まる」ことを明示し、APP側で分かりやすく伝える設計に。仕様で握るべき項目です |
| Android | iOSより自由度は高いが、機種ごとの省電力制御で挙動差が出やすい | 主要メーカー実機での個別検証を試験計画に組み込みます |
正確なお見積と技術検証のため、以下の開示をお願いいたします。開発可否・技術協議の進展に応じて、順次で構いません。
| 項目 | 用途 |
|---|---|
| センサー通信仕様 | Advertisingパケットのフォーマット、データの並び、アラームビットの定義。PoCに必須 |
| 実機センサー・受信機 | EX／IN型の実機一式。PoCに必須 |
| APP機能仕様書・開発確認書 | 要件確定・詳細設計の基礎資料として |
| 画面デザイン・画面遷移案／UI素材 | GIF・脈動演出などを含む。実装設計の入力として |
| しきい値参考データ集 | 車種別の標準空気圧、注意・警告の設定根拠。かんたん設定の自動算出ロジックに直結します |
| Version 1 のユーザー評価 | 市場投入後に蓄積された改善要望。Version 2 の優先順位付けに直結します |
| 国内開発協力先 募集・選定要件書 | 正式なお見積の作成に必要です |
守秘義務のため匿名で記載しております。いずれも「発注側で要件が固まりきっていない状態から、一緒に決めていく」進め方の案件です。
技術検証を先行させ、リスクを早期に潰す進め方をご提案します。
| 役割 | 担当範囲 |
|---|---|
| プロジェクトマネージャー | 御社窓口、進捗管理、仕様調整。連絡窓口を一本化します |
| BLEエンジニア | 受信・解析層のネイティブ実装、OS別最適化、実測検証 |
| APPエンジニア（2名） | UI実装、設定機能、音声・通知、ローカルDB |
| UI/UXデザイナー | 御社提供デザインの実装設計、UI素材整備、改善提案。社内に在籍しており、デザインを外部に発注いたしません |
| QAエンジニア | 試験計画策定、24機種実機試験、実車走行試験、不具合管理 |
デザイナーが社内におり、エンジニアと同じチームで動くため、「デザイン案は上がったが実装すると崩れる」「実機で見たら文字が小さすぎた」といった手戻りが起きません。御社からご提供いただくUI素材をそのまま実装に落とし込む役割と、実機検証を踏まえた高度化提案の両方を、このデザイナーが担います。
TPMSは安全に関わる製品です。机上のテストでは品質を担保できないと考えております。
| 試験区分 | 規模 | 内容 |
|---|---|---|
| iOS 実機試験 | 10機種 | iPhone SE 〜 最新世代 |
| Android 実機試験 | 14機種 | 主要メーカー・価格帯を網羅。省電力設定下での受信可否を個別に検証 |
| 実車走行試験 | 3車種 | 乗用車・軽・商用。音声の聞き取りやすさ、蛍の光の視認性を実環境で確認 |
| 連続稼働試験 | 72時間 | 受信途絶・メモリリークの検証 |
| 電池消費試験 | 実測 | 1時間走行あたりの消費率について合格基準を数値で設定し、実測で判定します |
弊社に依存させないことが、長く続く関係の前提だと考えております。
本資料には、あえて金額を記載しておりません。その理由をご説明いたします。
| 段階 | 前提 | ご提出できるもの |
|---|---|---|
| STEP 1 PoCのお見積 |
センサー通信仕様書と実機センサー・受信機をご提供いただければ、それだけで作成可能です | 2〜3週間の技術検証について、確定金額でご提出できます。成果物は実測データと方式提案書です。ここだけを先行してご発注いただく形でも構いません |
| STEP 2 本開発のお見積 |
「国内開発協力先 募集・選定要件書」の拝受＋PoCの実測結果 | 要件書拝受後、2週間以内に正式なお見積書とご提案書を提出いたします。相見積もりの比較がしやすいよう、他社様と同一の粒度・区分で記載いたします |
正式なお見積では、以下の区分で内訳を明示いたします。総額だけを提示して内訳が見えない形にはいたしません。
| 区分 | 含まれるもの |
|---|---|
| Phase 0：技術検証 | BLE受信の実測、OS別挙動の検証、方式提案書の作成 |
| 初期開発費 | 要件確定・詳細設計／BLE受信・解析層／UI・設定・音声実装／結合 |
| 品質保証費 | 24機種実機試験、実車走行試験、連続稼働試験、試験報告書作成 |
| 公開支援費 | App Store／Google Play の申請・審査対応 |
| 月額保守費 | OSバージョンアップ追従、不具合対応、定例MTG、市場の声の分析と改善提案 |
| Phase 3・4 拡張将来 | 大型車対応、クラウド・法人管理。今回の設計に下地を織り込むため、追加開発のみで到達可能な構成とします |
直近でお願いしたいことを、3段階で整理いたしました。
| 段階 | 内容 | 所要 | お願いしたいこと |
|---|---|---|---|
| STEP 1 直近 |
技術協議の場 | 2時間程度 | BLE仕様・バックグラウンド方針・運転セッション判定について、御社技術ご担当者様と直接すり合わせをさせてください。9月中のご設定をお願いできますと幸いです |
| STEP 2 | 要件書・資料のご提供 | — | 「国内開発協力先 募集・選定要件書」および実機センサー・仕様資料をご提供ください。拝受後2週間以内に正式なお見積とご提案書を提出いたします |
| STEP 3 | 技術検証（PoC） | 2〜3週間 | 実機による受信検証を実施し、実測データをもって方式を確定いたします。PoC単体での先行ご発注も承ります |
| 資料 | 内容 |
|---|---|
| 提案モック（動作デモ） | Version 2 の中核機能が実際にどう振る舞うかを、ブラウザ上で操作しながらご確認いただけます。UIデザインのご提案ではなく、挙動の確認用です |
| 伴走と増収増益のご提案 | Phase 3・4 まで同じ体制で継続する伴走の中身と、売上への貢献についてご説明した補足資料です |
| TPMS APP 活用アイデア集 | スローパンク予兆検知など、既存ハードのまま実現できる機能拡張14案をご契約前の段階でご提出しております |