EXECUTIVE SUMMARY
A社 TPMS APP Version 2 開発のご提案
A社 御中 ／ ピースフラットシステム株式会社
異常を知らせるだけではなく、
安心して出発できる APPへ。
安心して出発できる APPへ。
御社ブランドブック Version 1.1 より ／ この一行を、実際に触れる形にしたのが本デモです。
対応プラットフォーム
2OS
iOS ／ Android 同時開発
実装対象機能
38件
機能一覧を見る →
実機試験 対象端末
24機種
試験計画を見る →
本日ご覧いただける画面
9画面
APPデモを開く →
御社の課題認識
頂戴した2つの資料から、以下のように理解しております。
既製APPのままでは、御社の価値が伝わらない
Version 1 では工場標準APP（海外工場の標準APP）を活用して市場を先行して押さえられている一方、UI・音声・状態表現は他社と同一。御社が積み上げてきたTPMSノウハウが製品体験に反映されていない状態です。
iOS／Android 双方で BLE を安定して受け続ける難しさ
TPMSセンサーはAdvertisingを常時発信し続ける方式のため、バックグラウンド受信・省電力・再接続の設計がAPPの品質をそのまま決めます。ここは実装経験の差が最も出る領域です。
乗用車で終わらせず、大型車・クラウドまで繋げたい
「今回の開発は完成品ではなく、A社 TPMSプラットフォームの出発点」。初期設計の段階で多軸・多輪、複数車両、クラウド同期を織り込んでおく必要があります。
弊社からのご提案
3本柱を実装で示します御社が掲げる3つの体験を、そのまま実装要件に落とし込みました。
① 運転開始時 正常確認音声
新しい運転セッションを自動判定し、全センサーの初回受信・状態確認が完了した時点でTTS案内。「監視を開始します。タイヤの空気圧と温度は正常です。安全に注意して運転してください。」
② 蛍の光（受信脈動）
受信のたびに強く点滅させるのではなく、アンバーの発光と自然減衰で「静かに見張っている」ことを伝えます。運転中の視線負荷を上げずに監視継続を可視化します。
③ 2段階しきい値（注意 → 警告）
標準空気圧を基準に、正常 → 注意（Amber）→ 警告（Red）を圧力・温度の双方で管理。かんたん設定で自動算出し、詳細設定で個別調整できる二層構造とします。
Version 1 → Version 2 で変わること
Before ／ 工場標準APP（Version 1）
- 異常が出てから警報が鳴る
- 正常であることは画面を見ないと分からない
- 正常／異常の2値判定
- 設定項目が一階層に並び、どこを触ればよいか迷う
- 受信表示が強い点滅で、運転中に気が散る
- UI・文言・音声が他社製品と共通
After ／ A社 オリジナルAPP（Version 2）
- 出発時に「正常です」と声で確認できる
- 見ていなくても監視状態が伝わる
- 正常 → 注意 → 警告の3段階で予兆を捉える
- かんたん設定＋詳細設定の二層構造
- アンバーの穏やかな発光・減衰で静かに伝える
- A社ブランドの体験として差別化
センサー受信ログ（デモ）
リアルタイム本提案でお約束すること
| ソースコードの帰属 | 成果物一式を御社へ納品。ビルド手順書・設計資料を含みます |
|---|---|
| 改善提案 | 仕様を受け取るだけでなく、実装検証の結果からUI/UX改善案を継続提示 |
| ストア公開 | App Store／Google Play の申請・審査対応まで伴走 |
| 拡張性 | 多軸・多輪、複数車両、クラウド同期を初期アーキテクチャに織り込み |
| 継続保守 | OSバージョンアップ追従、不具合対応、機能追加に継続対応 |
INTERACTIVE PROTOTYPE
A社 オリジナルAPP 動作デモ
右のコンソールから操作してください。スマートフォン画面が実際に反応します。
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分の推移
センサー情報
センサーIDSNS-EX-8A41C2
EX型
電池残量約 82%（推定残 14ヶ月）
良好
受信強度-64 dBm ／ 受信間隔 約6秒
安定
車両を選ぶ
登録済みの車両
マイカー4輪＋スペア ／ 標準 2.40 bar
商用バン4輪 ／ 標準 3.00 bar
軽自動車4輪 ／ 標準 2.20 bar
将来対応（Phase 3）
4tトラック10輪 ／ 3軸 ／ 大型車モード
準備中
センサー登録
センサー同梱のQRコードを枠内に合わせてください
登録方法を選ぶ
QRコードで登録最速。同梱シールを読み取るだけ
センサーIDを手入力QRが読めない場合の代替手段
装着して自動登録取り付け時の圧力変化を検知して自動割当
登録済みセンサー
左前 ／ SNS-EX-8A41C2電池 82% ／ 受信 良好
EX
右前 ／ SNS-EX-8A41D7電池 79% ／ 受信 良好
EX
左後 ／ SNS-EX-8A41E3電池 88% ／ 受信 良好
EX
右後 ／ SNS-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「A社独自APPの主要機能（構想）」を実装単位に分解しました。
Phase 1（必須）
26件
Version 2 リリース対象
Phase 2（改善）
8件
市場評価を見て実装
Phase 3（拡張）
4件
大型車・クラウド →
| 分類 | 機能 | 実装内容 | 区分 |
|---|---|---|---|
| BLE通信 | BLE Advertising 常時受信 | センサーが発信するAdvertisingパケットを受信・解析。接続確立を伴わない方式で電力効率を確保 | Phase 1 |
| ペイロード解析 | 圧力／温度／電池残量／アラームフラグの復号。センサー仕様書の提供を前提 | Phase 1 | |
| バックグラウンド受信 | OS別に最適な受信戦略を実装。iOSは制約が大きく、方式の合意が必要（技術課題ページ参照） | 要協議 | |
| 受信途絶検知・自動復帰 | 一定時間受信がないセンサーを「受信なし」表示に切替。復帰時に自動で通常表示へ | 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 |
「要協議」について。技術的に不可能という意味ではなく、OSの制約と実運用のバランスをどこで取るかを御社と決める必要がある項目です。ここを曖昧にしたまま見積を出す会社もありますが、後で必ず揉めるため、弊社は先に論点として提示します。詳細は「技術課題への回答」をご覧ください。
TECHNICAL APPROACH
技術提案・システム構成
将来のクラウド連携を妨げない構成を、初期設計から採用します。
システム構成
TPMSセンサー
EX／IN型
圧力・温度を発信
圧力・温度を発信
BLE Advertising
接続不要の
ブロードキャスト
ブロードキャスト
受信・解析層
ネイティブ実装
OS別に最適化
OS別に最適化
A社 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時間走行あたりの電池消費○%以内」を実機試験の合格基準として数値で握ります
車載充電を想定した挙動
給電中は画面点灯を維持するモードなど、実際の使われ方に合わせた設計を提案します
KEY TECHNICAL ISSUES
技術課題への回答
御社が「OS制約を踏まえた現実的な技術提案」を求められている点について、弊社の見解を先に開示します。
最初にお伝えしておきたいこと。本件で最も難しいのは、UIでも音声でもなく 「iOSでアプリを閉じている間もBLE Advertisingを受信し続けること」 です。ここを「できます」とだけ回答する提案があれば、実装経験がないか、制約を理解していない可能性があります。弊社は制約を正確にお伝えした上で、実運用として成立する落としどころをご提案します。
課題① iOS のバックグラウンドBLE制約
最重要| 状態 | iOS の実際の挙動 | 弊社の対応方針 |
|---|---|---|
| APPを開いている | 制約なし。高頻度で受信でき、脈動表現・音声もそのまま動作 | ここが主たる利用シーン。運転中はAPPを開いた状態を標準運用として設計 |
| APPを閉じている （バックグラウンド） | スキャン条件が厳しく制限され、受信頻度も大きく落ちる。メーカー独自データの扱いにも制約がある | 受信を止めないための複数の技術的アプローチを検証し、実測データを添えて方式をご提案。PoCでの事前検証を強く推奨 |
| ユーザーがAPPを スワイプ終了した | OSからの自動復帰は保証されない | 仕様として「監視が止まる」ことを明示し、APP側で分かりやすく伝える設計に。仕様で握るべき項目 |
| Android | iOSより自由度は高いが、機種ごとの省電力制御で挙動差が出やすい | 主要メーカー実機での個別検証を試験計画に組込 |
ご提案。この論点は、見積を確定する前に 2〜3週間の技術検証（PoC） を実施し、実機の実測値をもって方式を決めることを推奨します。ここを曖昧にしたまま本開発に入ると、後工程で仕様変更が発生し、結果的に御社の負担が大きくなります。
課題② 運転開始をどう判定するか
「新しい運転セッション開始後、初回データ受信・状態確認後に正常状態を音声で案内する」を実装するには、どこからが新しい運転かを機械的に判定する必要があります。
| 判定方式 | 特徴 |
|---|---|
| BLE受信の再開 | センサーは走行で起動するため自然。追加の権限が不要で、実装も軽い。推奨 |
| 加速度センサー | 走行を直接検知できるが、常時監視は電池消費が増える |
| 位置情報 | 精度は高いが、ユーザーへの権限要求のハードルが上がる |
| 手動スタート | 確実だが「自然に安心を届ける」という御社の思想と相性が良くない |
弊社はBLE受信再開＋一定時間の受信途絶を組み合わせた判定を第一案として推奨します。追加権限なしで実現でき、御社が重視する「迷わせない」設計とも整合します。
課題③ 音声を、いつ・どう鳴らすか
車内では音楽やナビ音声が同時に流れています。TTSの発話設計は体験を左右します。
他アプリ音声との競合
音楽を一時的に絞って割り込むか、終わるまで待つか。警告レベルによって挙動を変えるべきと考えます
カーオーディオへの出力
Bluetooth接続時にどちらから鳴らすか。実車での検証項目です
繰り返しの抑制
警告が続く間ずっと鳴り続けると、かえって無視されます。再通知の間隔設計が必要です
合成音声か、収録音声か
定型文は収録音声で品質を確保し、可変部分はTTS。ブランド体験としての声の統一をご提案します
ご提供をお願いしたい情報
正確な見積と技術検証のため、以下の開示をお願いいたします。開発可否・技術協議の進展に応じて順次で構いません。
センサー通信仕様
Advertisingパケットのフォーマット、データの並び、アラームビットの定義
実機センサー・受信機
EX／IN型の実機一式。PoC段階で必要です
APP機能仕様書・開発確認書
御社にご用意があると伺っております
画面デザイン・画面遷移案
GIF・脈動演出などのUI素材を含む
しきい値参考データ集
車種別の標準空気圧、注意・警告の設定根拠
Version 1 のユーザー評価
市場投入後に蓄積された改善要望。Version 2 の優先順位付けに直結します
QUALITY ASSURANCE
品質保証・実機試験計画
TPMSは安全に関わる製品です。机上のテストでは品質を担保できないと考えています。
iOS 実機
10機種
iPhone SE 〜 最新世代
Android 実機
14機種
主要メーカー・価格帯を網羅
実車走行試験
3車種
乗用車・軽・商用
連続稼働試験
72時間
受信途絶・メモリリーク検証
試験項目
| 受信安定性 | 走行中の連続受信、途絶からの復帰、電波環境の悪い場所での挙動 |
|---|---|
| しきい値判定 | 境界値前後での状態遷移、チャタリング（頻繁な行き来）の抑制 |
| 音声通知 | 実車内での聞き取りやすさ、他アプリ音声との競合、カーオーディオ出力 |
| 電池消費 | 1時間走行あたりの消費率。合格基準を数値で設定し実測 |
| バックグラウンド | OS別・機種別の挙動差、省電力設定下での受信可否 |
| 高温環境 | 夏場の車内を想定した端末温度上昇下での動作継続 |
| 視認性 | 直射日光下での画面視認性、蛍の光の見え方、夜間モード |
安全に関わる製品としての配慮
誤警報を出さない設計
一時的な受信ノイズで警告を出すと、ユーザーは次第に警告を無視するようになります。複数回の連続検知を条件とし、誤警報を抑制します
警報を見落とさない設計
画面を見ていない前提で、音声・通知・警告音を組み合わせます。視覚だけに頼りません
運転中の操作を要求しない
走行中に画面操作が必要な導線を作りません。設定は停車時に完結する構成とします
責任範囲の明示
APPは点検を代替するものではない旨を、初回起動時と取扱説明に明記する設計をご提案します
解析可能なログ設計
市場で不具合が起きた際に原因を追える形でログを残します。リリース後の改善速度に直結します
ROADMAP
将来拡張とロードマップ
「今回の開発は完成品ではなく、A社 TPMSプラットフォームの出発点」── この前提を設計に織り込みます。
Development Roadmap
01 ／ 実施済
乗用車向け
4輪／4＋スペア
市場評価・販売実績の蓄積
市場評価・販売実績の蓄積
02 ／ 今回
A社独自APP
独自UI／音声／
2段階しきい値
← 本ご提案の範囲
2段階しきい値
← 本ご提案の範囲
03 ／ 次期
中・大型車
多軸・多輪表示
商用車運用
画面イメージを見る
商用車運用
画面イメージを見る
04 ／ 将来
クラウド
履歴・多車両
法人管理
画面イメージを見る
法人管理
画面イメージを見る
05 ／ 構想
次世代
運行支援・解析
OEM／協業
OEM／協業
Phase 3 ／ 中・大型車対応で必要になること
| 多軸・多輪レイアウト | 3軸10輪、4軸14輪など。車両構成を定義できるデータ構造が前提 |
|---|---|
| ダブルタイヤ（内輪・外輪） | 内側タイヤの異常は目視で気づきにくく、TPMSの価値が最も高い領域 |
| リピーター／受信機連携 | 車長が長い大型車ではBLE到達距離が課題。中継機の利用を想定した通信層設計 |
| 積載状態による基準変更 | 空車・積車で標準空気圧が変わる運用への対応 |
| トレーラー連結 | 連結・解放に応じた監視対象の動的な切替 |
これらは Phase 3 で作る機能 ですが、Phase 2（今回）の段階でデータ構造に織り込んでおく必要があります。「4輪固定」で作ってしまうと、大型車対応の際に作り直しになります。今回のアーキテクチャ設計で最も重視している点です。
Phase 4 ／ クラウド・法人運用
| 車両一元管理 | 管理者が全車両の状態を1画面で把握。異常車両を即座に特定 |
|---|---|
| 履歴の集約・分析 | 走行ごとの記録を蓄積し、点検記録・整備計画に活用 |
| 管理者アラート | ドライバーだけでなく運行管理者にも異常を通知 |
| 権限管理 | ドライバー／管理者／整備担当の役割別権限 |
| オフライン優先 | 圏外でもAPP単体で監視は継続し、通信回復時に同期 |
クラウドは「後付け」が最も高くつく機能です。今回の設計段階で、データに一意なIDと時刻を持たせ、同期キューを差し込める構造にしておけば、Phase 4 は追加開発だけで到達できます。逆にここを省くと、APP本体の作り直しが発生します。
PROJECT PLAN
開発計画・体制
技術検証を先行させ、リスクを早期に潰す進め方をご提案します。
スケジュール案
M1M2M3M4M5M6M7M8
Phase 0：技術検証（PoC）BLE実測・方式決定
要件確定・詳細設計仕様書・画面設計のレビュー
BLE受信・解析層ネイティブ実装
UI・設定・音声実装Flutter共通実装
結合・実機試験24機種＋実車走行
ストア申請・公開支援審査対応
納品・引継ぎソース・設計資料・手順書
Phase 0 を必ず先に置いてください。iOSのバックグラウンドBLE挙動を実測で確認しないまま本開発に入ると、後半で仕様変更が発生します。2〜3週間の検証で方式を確定させることが、結果として最短ルートになります。Phase 0 のみを先行してご発注いただく形でも構いません。
体制
| 役割 | 担当範囲 |
|---|---|
| プロジェクトマネージャー | 御社窓口、進捗管理、仕様調整。連絡窓口を一本化します |
| BLEエンジニア | 受信・解析層のネイティブ実装、OS別最適化、実測検証 |
| APPエンジニア（2名） | UI実装、設定機能、音声・通知、ローカルDB |
| UI/UXデザイナー | 御社提供デザインの実装設計、改善提案、UI素材整備 |
| QAエンジニア | 試験計画策定、24機種実機試験、実車走行試験、不具合管理 |
納品物
ソースコード一式
iOS／Android 双方。リポジトリごとお渡しし、権利は御社に帰属します
ビルド手順書
環境構築からストア提出用ビルド生成まで。他社でも引き継げる粒度で記述します
設計資料
アーキテクチャ図、データ構造定義、BLE解析仕様、画面遷移図
試験報告書
実機試験結果、電池消費実測値、既知の制約事項一覧
ストア公開用アセット
申請用の説明文案、スクリーンショット、審査対応記録
ABOUT US & NEXT STEP
弊社について ／ 次の一歩
単発の受託ではなく、長期的に製品を育てる協業をご一緒したいと考えています。
弊社をお選びいただく理由
制約を先に開示します
できないこと・決めるべきことを、契約前に論点として提示します。本資料の「技術課題への回答」がその実例です
仕様を受け取るだけで終わりません
御社が求められている「改善案を提示できること」を、本デモの段階から実践しています
上流が固まっていない段階から伴走します
要件が確定する前の相談段階からご一緒し、要件そのものを一緒に作る進め方を得意としています
リリース後こそ本番だと考えています
市場評価を受けての改善、OS追従、Phase 3・4 への拡張まで継続してご一緒します
類似案件の実績
守秘のため匿名で記載| 公立医科大学A 教育・医療 | 在籍約900名規模の成績管理システムをスクラッチ開発。要件が固まっていない相談段階から参画し、現行業務様式を活かす形で要件を共同で定義 |
| 電気設備工事業E社 建設業・中堅 | 入口は単一機能の相談だったが、ヒアリングで3部署23項目の課題が判明。単発開発ではなく段階的な伴走支援として再設計し、現在進行中 |
| その他 複数業種 | 業務システム・SaaS・モバイルアプリの受託開発。詳細は個別にご説明いたします |
いずれも 「発注側で要件が固まりきっていない状態から、一緒に決めていく」 進め方の案件です。御社の Version 2 も、詳細仕様は技術協議の進展に応じて順次確定していくと伺っております。この進め方こそ弊社が最も価値を出せる形だと考えています。
ネクストステップのご提案
STEP 1 ／ 直近
技術協議の場
BLE仕様・バックグラウンド方針・運転セッション判定について、御社技術ご担当者様と直接すり合わせをさせてください。
所要：2時間程度
所要：2時間程度
STEP 2
要件書の拝受
「国内開発協力先 募集・選定要件書」および実機センサー・仕様資料をご提供いただき、正式なお見積とご提案書を提出いたします。
STEP 3
技術検証（PoC）
2〜3週間で実機による受信検証を実施し、実測データをもって方式を確定。PoC単体での先行ご発注も承ります。
一緒に「次の TPMS」を育てる
パートナーでありたいと考えています。
パートナーでありたいと考えています。
ピースフラットシステム株式会社 ／ A社 TPMS APP Project