01御社が、開発パートナーに求められていること
ブランドブック Version 1.1 を拝読して
単発の受託ではなく、長期的に製品を育てる協業を希望
仕様を受け取るだけでなく改善案を提示できること
大型車・クラウド展開まで見据えた設計姿勢
一緒に「次の TPMS」を育てるパートナーを探しています。
出典：TDR APP PROJECT ブランドブック Version 1.1「10 開発パートナーに期待すること」
この一文を、弊社は「アプリを納品する会社ではなく、TPMS事業そのものを一緒に伸ばす会社を探している」と受け取りました。本資料は、それに対する回答です。
| 御社が期待されていること | 弊社の回答 |
|---|
| 長期的に製品を育てる協業 | Version 2 で終わらせず、Phase 3（大型車）・Phase 4（クラウド）まで同じ体制で継続します（02章） |
| 仕様を受け取るだけでなく改善案を提示 | すでに追加機能14案を、ご契約前の段階で提出しております |
| 実機評価・品質管理・継続保守 | 24機種の実機試験計画と、リリース後のOS追従・改善サイクルをご提示します |
| 大型車・クラウドまで見据えた設計 | 今回のデータ構造・通信層に、後から拡張できる構造を織り込みます |
| BLE／IoT機器連携アプリの実績 | センサーから値を取り、判定し、人に知らせるシステムの構築実績があります（04章） |
APPを作るだけなら、他社にもできます。
私たちがご一緒したいのは、その先です。
伴走の中身・売上への貢献・機器連携の実績。この3点をご説明します。
02伴走とは、具体的に何をするか
言葉ではなく、работとしてお約束できること
ロードマップ全体に、同じチームで関与します
01 ／ 実施済
乗用車向け
工場標準APPで市場評価を蓄積
02 ／ 今回
TDR独自APP
独自UI／音声／2段階しきい値
03 ／ 次期
中・大型車
多軸・多輪表示／商用車運用
◀ 弊社の関与範囲：Phase 2 から Phase 5 まで、継続してご一緒します
伴走の中身
1
同じチームが続きます
Phase 3・4 で担当者が入れ替わると、設計の意図が失われ、毎回説明のやり直しが発生します。弊社は同一チームでの継続を前提に体制を組みます。BLE受信層のような、なぜそう作ったかが重要な部分ほど、この差が効いてきます。
2
週次または隔週の定例を置きます
開発中はもちろん、リリース後も継続します。検討の経緯を可視化し、双方向で進めるためです。「言った・言わない」を残さない運用にします。
3
市場の声を、次の開発に還元します
御社は Version 1 の市場投入ですでにユーザー評価という資産をお持ちです。リリース後も、ストアレビュー・お問い合わせ・販売店からの声を継続的に分析し、次の改善に反映する仕組みをご一緒に回します。
4
OSのバージョンアップに追従します
iOS・Android は毎年秋に大きな更新があります。BLE・バックグラウンド動作・通知は、OS更新の影響を最も受けやすい領域です。ここを放置すると、ある日突然アプリが動かなくなります。月額の保守に含めて対応します。
5
Phase 3・4 で、作り直しをさせません
今回の設計段階で、多軸・多輪、複数車両、クラウド同期を織り込みます。「4輪固定」で作ってしまうと、大型車対応の際に作り直しになります。ここは今しか手を打てません。
6
御社に、資産として残します
ソースコード・設計資料・ビルド手順書を納品します。他社でも引き継げる粒度で記述します。弊社に依存させないことが、長く続く関係の前提だと考えています。
なぜここまで言えるか。
弊社は再発注率95%以上で事業を続けています。1件を高く売るのではなく、長くご一緒することで成り立つ会社です。伴走は姿勢の話ではなく、弊社の事業モデルそのものです。
03私たちは、売上の話までします
APPは、御社のTPMS事業の収益をどう変えるか
開発会社は通常、「何を作るか」までしか話しません。しかし御社にとってVersion 2 は、コストではなく事業投資のはずです。だとすれば、その投資がどう回収されるかまで一緒に考えるのが筋だと考えています。
TPMSの売上は、おおむね次のように分解できます。
# TPMS事業の売上
売上 ＝ 本体販売 ＋ 消耗品 ＋ 継続課金
本体販売 ＝ 取扱店舗数 × 店舗あたり販売数 × 単価
消耗品 ＝ 稼働台数 × 交換発生率 × 単価 （電池・センサー）
継続課金 ＝ 法人契約数 × 車両数 × 月額 （Phase 4 以降）
この式の中で、APPが直接効く箇所は3つあります。次章で1つずつご説明します。
増収の経路 ①
取扱店舗数を増やす
APPを「店舗にとって売る理由がある製品」にすることで、販売チャネルそのものを広げます。
増収の経路 ②
消耗品を取りこぼさない
電池切れを「故障」ではなく「交換のお知らせ」に変えることで、継続的な売上に転換します。
増収の経路 ③
法人・大型車市場を開く
個人向けの「安心」ではなく、法人向けの「損失回避」を売る。価格の説明がしやすい市場です。
04増収の3つの経路
APPが、売上に効く具体的な仕組み
① 取扱店舗数を増やす ── 販売店にとって「売る理由」を作る
日本ではTPMSの装着義務がありません。米国・欧州では新車への装着が法規で義務化されている一方、国内は「必要だと納得した人が、後から買う」後付け市場です。この市場では、販売チャネルの確保が売上を決めます。
そこでAPPを、店舗を巻き込む道具として設計します。
1
店舗が顧客のタイヤ状態を確認できる（顧客の同意のもと）
「そろそろ交換時期です」を店舗から案内できる。店舗にとっての来店動機の創出になります。
2
初期設定を店舗が代行し、使える状態で納車する
後付け製品の最大の離脱ポイントは初期設定です。ここを店舗が代行できる導線を作れば、店舗の作業が付加価値になり、返品・クレームも減ります。
3
取扱店マップをAPPに載せ、ユーザーを店舗へ送客する
店舗にとって「置くと客が来る製品」になれば、営業の質が変わります。
② 消耗品を取りこぼさない ── 電池切れを、売上に変える
センサーの電池切れは、ユーザーが最も「壊れた」と感じる瞬間です。
突然監視が止まれば、サポートへの問い合わせとレビュー低下に直結します。しかし事前に伝えられていれば、それは「交換のお知らせ」になります。同じ事象が、コストにも売上にもなり得ます。
法人・多輪の運用では、交換計画の一覧管理そのものが実務価値を持ちます。加えて、問い合わせ件数が減るぶん、サポートコストも下がります。
③ 法人・大型車市場を開く ── 「損失回避」を売る
| 個人向け | 法人・商用車向け |
|---|
| 売るもの | 安心 | 損失回避 |
| 顧客の判断軸 | 「あったら安心だな」 | 「止まると、いくら損するか」 |
| 価格の説明 | 体験価値で伝える必要がある | 事故・遅延の損失と比較できる |
| 1契約あたり | 1台・4輪 | 複数台 × 多軸多輪＝センサー数が桁違い |
| 継続性 | 買い切り中心 | クラウド管理の月額課金が成立 |
商用車の運行事業者にとって、タイヤの脱輪・バーストは事業を止める事故です。とくにダブルタイヤの内側は、目視でも打音でも異常に気づきにくく、TPMSの価値が最も高い箇所です。
Phase 3 の営業は、機能一覧では動きません。
「内輪は見えない」という現場の実感、その一点に絞るだけで説得力が変わります。多軸多輪の表示機能は、そのための手段として位置づけるべきだと考えています。この観点を、今回の設計段階から織り込みます。
05増益 ── コスト側にも効きます
売上を増やすだけが、利益ではありません
| 効く箇所 | 仕組み |
|---|
| サポート問い合わせの削減 | 電池切れの事前予告、季節による空気圧低下の自動説明、迷わない初期設定。「よくある問い合わせ」をAPPが先に答えることで、対応工数が減ります |
| 誤警報による信用毀損の回避 | 誤報が続けばユーザーは通知を無視し、レビューが下がります。連続判定・温度補正・復帰判定で誤報を抑え、評価と広告費に効かせます |
| 外部依存の解消 | 工場標準APPに依存している限り、UI・機能・不具合対応の主導権は御社にありません。独自APPは意思決定の速度そのものを上げます |
| 作り直しコストの回避 | Phase 3・4 で作り直しが発生すると、初期開発と同等の費用がかかります。今回の設計で織り込めば、追加開発だけで到達できます |
| 解析可能なログ設計 | 市場で不具合が起きた際に原因を追える形でログを残します。改善の速度は、そのまま対応コストです |
06私たちが「調べて」ご提示できること
数字と根拠を、こちらから持ち込みます
増収増益の話は、思いつきでは意味がありません。調べて、根拠のある形でご提示します。以下は、ご要望があれば弊社側で実施できる調査です。
1
Version 1 のユーザー評価の分析
御社は市場投入によりすでにユーザーの声という資産をお持ちです。ストアレビュー・お問い合わせ内容・返品理由を分類し、「何が不満で、何が評価されているか」を定量化します。Version 2 の機能優先順位を、勘ではなくデータで決められます。
2
競合TPMS APPの調査
国内外の競合製品のAPPを実際に使い、UI・機能・レビュー評価・価格帯を横並びで比較します。御社が「勝てる箇所」と「捨ててよい箇所」を切り分けます。
3
先行市場（米国・欧州）の動向調査
両地域はTPMSの装着が義務化されており、日本の数年先を走っています。とくに商用車向けのタイヤ管理サービスは先行事例があり、Phase 3・4 の設計に直接活かせます。
4
収益シミュレーションの作成
03章の分解式に御社の実数（販売実績・稼働台数・店舗数）を入れて試算します。「APPにいくら投じると、どの経路で何が返ってくるか」を数字で議論できる状態にします。この資料に金額を記載していないのは、御社の実数を伺う前だからです。
5
APP利用データの分析（Phase 4 以降）
どの機能が使われ、どこで離脱しているか。実際の利用データに基づく改善提案を継続的に行います。これは伴走を前提としているからこそできることです。
1点、正直にお伝えします。
上記のうち①ユーザー評価の分析は、御社からのデータ提供が前提です。②③は弊社単独で実施できます。④は御社の販売実績を伺えれば作成できます。いずれも、まず何が手元にあるかを教えていただくところからです。
07IoTデバイス連携の実績
センサーから値を取り、判定し、人に知らせる ── 同じ構造の構築経験
TPMSのシステム構造を分解すると、次のようになります。
この構造を、弊社は別の現場で構築し、納品しています。扱う機器がパワーコンディショナーからタイヤに変わるだけで、設計上の勘所は同じです。
実績 01 ／ 産業設備の監視・警報システム 納品済
他社製の計測機器から値を取り、異常を判定し、警報を鳴らす
自治体の浄水場 ／ 太陽光発電設備 370kW ／ 電気設備工事の元請様経由
| 難しかった点 | セキュリティ制約によりクラウドが使用不可。構内LANのみで完結する構成が前提。加えて、他社製の計測機器から自動でデータを取得できるかが未確認の状態からのスタート |
|---|
| 実施したこと | 機器仕様の調査とデータ取得方式の検証／表示方式3案の比較提示／異常判定ロジックの設計／誤報防止（連続判定・復旧判定）／警報出力方式の設計（音声・ネットワーク制御信号灯） |
|---|
| 納品後 | 機器構成資料・操作説明書を納品し、その後も点検フェーズを継続。システム構成図・全体系統図・配線図を整備しながら運用を支えています |
|---|
TPMSとの共通点。
①他社製センサーの仕様を読み解いて接続する ②しきい値で異常を判定する ③誤報を出さない設計にする ④人に確実に伝える ⑤納品後も動き続けさせる。本件で必要だったことは、そのままVersion 2 で必要になることです。
※ 守秘義務に配慮し、施設名・企業名・機器の型式は伏せております。詳細は個別にご説明いたします。
実績 02 ／ ウェアラブル × 音声AI 提案・協業中
イヤホンをセンサーとして扱い、スマホ経由でクラウドAIにつなぐ
大手通信グループの流通事業会社様 ／ AI搭載イヤホン・レコーダー製品
省電力の無線デバイスとスマートフォンアプリを組み合わせた構成の設計、および音声通知・読み上げ（TTS）を含む体験設計に取り組んでいます。「デバイス側は軽く保ち、処理はスマホ／クラウドへ寄せる」という考え方は、TPMSセンサーとAPPの関係とそのまま同じです。
あわせて、既存ハードのままソフトウェア更新で実現できる機能拡張を10案、次世代デバイスを前提とした提案を4案、計14案を提示しています。御社にご提出した追加機能提案も、同じ考え方で作成しました。
実績 03 ／ 空域・モビリティ
世界初となるドローン航路の開通
国内2エリアにて正式開通 ／ 経済ニュース WBS（ワールドビジネスサテライト）にて紹介
2025年3月27日、世界で初めてとなる「ドローン航路」が国内2つのエリアで正式に開通し、この事例が WBS にて紹介されました。画面の中で完結せず、現実の機器・空間を扱う領域に継続して取り組んでいます。
| Version 2 で必要になること | 対応する弊社の実績 |
|---|
| 他社製センサーの仕様解析と接続 | 実績01：他社製計測機器の仕様調査から接続設計まで |
| 省電力無線デバイスとの連携 | 実績02：BLE等のウェアラブル機器とアプリの連携設計 |
| しきい値判定・誤報防止 | 実績01：連続判定・復旧判定による誤報防止ロジックの設計 |
| 音声通知（TTS） | 実績02：音声インターフェースの設計・実装 |
| 実機での検証・現地試験 | 実績01：現地調査から現地試験、納品後の点検フェーズまで |
| 安全に関わる製品としての姿勢 | 実績01：インフラ設備の警報システムそのもの |
08ネクストステップ
ご相談させていただきたいこと
| No. | アクション | 内容 |
|---|
| 1 | 技術協議の場 | BLE仕様、バックグラウンド動作の保証範囲、運転セッション判定について、御社技術ご担当者様と直接すり合わせをさせてください（2時間程度） |
| 2 | 事業面のご相談 | 販売チャネル・消耗品・法人展開について、現状の課題をお聞かせください。調査してお持ちできることが具体化します（1時間程度） |
| 3 | 要件書の拝受 | 「国内開発協力先 募集・選定要件書」および実機センサー・仕様資料をご提供いただき、正式なお見積とご提案書を提出いたします |
| 4 | 技術検証（PoC） | 2〜3週間で実機による受信検証を実施し、実測データをもって方式を確定します。PoC単体での先行ご発注も承ります |
2番について、少しだけ。
開発会社が事業の話を聞きたがるのを、意外に思われるかもしれません。ただ、何が売上のボトルネックなのかが分かっていないと、どの機能を優先すべきかも決められないというのが弊社の考えです。作る前に、伺わせてください。
一緒に「次の TPMS」を育てる
パートナーでありたいと考えています。
株式会社ピースフラットシステム ／ T&D Regulus TPMS APP Project