点検連動型の新しい保証制度を一貫して運用。地域全体への展開を前提に、1つのパイロット市場でMVPを構築
地域統括会社は、正規販売店で点検を受けると適用される保証制度の導入を進めていますが、適格性の確認、保証請求の処理、ディストリビューターとの精算を担うシステムがありませんでした。私たちは業務全体を6つのモジュールに整理し、一貫して運用できるプラットフォームを設計しました。現在は最初のパイロット市場でMVPを構築しており、同じアプリケーションを地域全体に横展開できるようにしています。
1つの地域プラットフォームで扱う保証業務のモジュール数
設計した基幹システム連携(ディストリビューターのDMS、メーカーのグローバル保証システム)
- 顧客
- 日系自動車メーカーの地域統括会社
- 利用者
- 地域統括会社の管理者、保証・財務チーム、保証請求の査定者、ディストリビューター、販売店
- 範囲
- 見積もり・コンセプトとMVPの設計・構築・研修・保守モデル
- 期間
- 2025年12月に見積もり → 2026年3月に提案 → 2026年4月にキックオフ → パイロット市場で本番稼働
- 状況
- 最初のパイロット市場でMVPを構築中

CI/CDとセキュリティテストを組み込んだ環境(開発・ステージング・本番)
新しい保証制度を運用するシステムがない
地域統括会社は、点検連動型の保証制度を計画していました。車両が正規販売店で点検を受けると延長保証が始まり、点検を続けることで保証も継続する仕組みです。どの車両が対象か、保証はいつ始まるか、どの修理が対象か、誰が請求を査定するか、ディストリビューターと毎月どう精算するか。すべての段階でルールを決める必要がありました。
制度は1つのパイロット市場から始める計画でしたが、地域全体での展開を前提としていました。そのためシステムには、ディストリビューターとグローバル保証のデータで適格性を確認できること、複数の関係者が参加できること、他の市場でも一から作り直さずに使えることが求められました。
関係者ごとに分散したルール
適格性は車齢・走行距離・点検履歴・メーカー保証の状況で決まりますが、これらの情報は別々のシステムにありました。
1件の請求に多くの関係者
ディストリビューター、販売店、外部の査定者、地域統括会社の保証・財務チームが、1件ごとの請求にそれぞれ関わっていました。
1市場だけの個別構築
パイロット市場のためだけに構築すれば、その後に続く市場ごとに作り直しが必要になります。
業務全体を先に定義し、それを運用できる最小限の仕組みを構築
まず社内計画用の見積もりを作成しました。次に保証業務の全体を6つのモジュールに整理し、モジュールごとにルールの例を示しました。これにより地域統括会社は、MVPで対応する範囲と対応しない範囲を正確に確認できます。アーキテクチャではアプリケーションとインフラを分離しているため、将来は同じコードを他の地域にも展開できます。保守は、固定の基本部分、利用量に応じたサポート、個別に承認する変更の3つに区分しています。
見積もり
- 社内計画用の概算見積もり
- インフラの選択肢
コンセプトとMVPの設計
- ルール例を含む6モジュールの業務プロセス
- 概念アーキテクチャとセキュリティ対策
- 主要な依存関係の整理と保守モデルの体系化
キックオフと要件定義
- 4月末にプロジェクトをキックオフ
- 5月にパイロット市場のディストリビューターと2日間の業務ワークショップ
- 保証請求の業務フロー
構築と試作
- インフラとセキュリティの要件
- 8月末に試作のウォークスルー
- 9月に関係者とスケジュールを見直し
設計によって整う仕組み
コードを書く前に、ルールの整理に時間をかけました。MVPが役に立つのは、その対象範囲を地域統括会社が正確に把握でき、次の市場にも一から作り直さずに展開できる場合に限られます。
パイロット市場から地域全体へ
アプリケーションは他の市場でも再利用できるよう設計しています。新しい地域ではそれぞれクラウドインフラ、ネットワーク、データ保管場所の設定が必要ですが、アプリケーションの構成要素はそのまま引き継げます。
パイロット市場での本番稼働
本番稼働の前に、システム結合テスト(SIT)、ユーザー受け入れテスト、第三者によるペネトレーションテスト、社内講師の育成研修を実施します。
パイロットの結果を反映
最初の市場の実データをもとに、適格性ルール、請求ワークフロー、精算方法を調整します。
他市場への展開
制度の拡大に合わせて、同じアプリケーションを他の市場へ展開できるよう設計しています。
同様の課題に、こうしたサービスでお応えします
関連する事例
次の事例 →

