本文へ移動
日系自動車メーカー — アジア太平洋地域統括会社

点検連動型の新しい保証制度を一貫して運用。地域全体への展開を前提に、1つのパイロット市場でMVPを構築

地域統括会社は、正規販売店で点検を受けると適用される保証制度の導入を進めていますが、適格性の確認、保証請求の処理、ディストリビューターとの精算を担うシステムがありませんでした。私たちは業務全体を6つのモジュールに整理し、一貫して運用できるプラットフォームを設計しました。現在は最初のパイロット市場でMVPを構築しており、同じアプリケーションを地域全体に横展開できるようにしています。

6

1つの地域プラットフォームで扱う保証業務のモジュール数

2

設計した基幹システム連携(ディストリビューターのDMS、メーカーのグローバル保証システム)

自動車・モビリティ業務アプリケーションパイロット市場2025年 – 現在読了目安 5分
顧客
日系自動車メーカーの地域統括会社
利用者
地域統括会社の管理者、保証・財務チーム、保証請求の査定者、ディストリビューター、販売店
範囲
見積もり・コンセプトとMVPの設計・構築・研修・保守モデル
期間
2025年12月に見積もり → 2026年3月に提案 → 2026年4月にキックオフ → パイロット市場で本番稼働
状況
最初のパイロット市場でMVPを構築中
3

CI/CDとセキュリティテストを組み込んだ環境(開発・ステージング・本番)

課題

新しい保証制度を運用するシステムがない

地域統括会社は、点検連動型の保証制度を計画していました。車両が正規販売店で点検を受けると延長保証が始まり、点検を続けることで保証も継続する仕組みです。どの車両が対象か、保証はいつ始まるか、どの修理が対象か、誰が請求を査定するか、ディストリビューターと毎月どう精算するか。すべての段階でルールを決める必要がありました。

制度は1つのパイロット市場から始める計画でしたが、地域全体での展開を前提としていました。そのためシステムには、ディストリビューターとグローバル保証のデータで適格性を確認できること、複数の関係者が参加できること、他の市場でも一から作り直さずに使えることが求められました。

関係者ごとに分散したルール

適格性は車齢・走行距離・点検履歴・メーカー保証の状況で決まりますが、これらの情報は別々のシステムにありました。

1件の請求に多くの関係者

ディストリビューター、販売店、外部の査定者、地域統括会社の保証・財務チームが、1件ごとの請求にそれぞれ関わっていました。

1市場だけの個別構築

パイロット市場のためだけに構築すれば、その後に続く市場ごとに作り直しが必要になります。

アプローチ

業務全体を先に定義し、それを運用できる最小限の仕組みを構築

まず社内計画用の見積もりを作成しました。次に保証業務の全体を6つのモジュールに整理し、モジュールごとにルールの例を示しました。これにより地域統括会社は、MVPで対応する範囲と対応しない範囲を正確に確認できます。アーキテクチャではアプリケーションとインフラを分離しているため、将来は同じコードを他の地域にも展開できます。保守は、固定の基本部分、利用量に応じたサポート、個別に承認する変更の3つに区分しています。

保証業務・6モジュール 1 · 設定プログラムのルール 2 · 適格性判定車齢・走行距離・履歴 3 · 保証開始点検時に保証が開始 4 · 保証請求根拠資料を添えて申請 5 · 査定審査・承認 6 · 精算財務と月次で精算 地域統括会社管理者・ルール設定 保証データDMS・グローバル保証 正規販売店車両の点検を実施 ディストリビューター傘下の販売店を含む 保証請求の査定者外部 地域統括会社財務・照合 市場・地域ごとに設定 プログラムのルール適格条件・保証範囲・精算条件 ディストリビューターのDMS連携市場ごとに接続 クラウドインフラネットワーク・データ保管場所(地域ごと) 共通アプリケーション・全市場で再利用 6モジュールのアプリ単一のコードベース ワークフローと監査証跡役割別のアクセス権限 システム連携REST API・webhook 開発・リリース3環境・CI/CD
プログラムの設定から月次精算までの保証業務を6つのモジュールで運用し、すべての関係者が同じワークフローで作業します。適格性は、ディストリビューターのDMSとグローバル保証データに照らして確認します。ルール、データ連携、インフラは市場・地域ごとに設定し、アプリケーション自体は再利用します。

見積もり

2025年11月–12月
  • 社内計画用の概算見積もり
  • インフラの選択肢

コンセプトとMVPの設計

2026年3月
  • ルール例を含む6モジュールの業務プロセス
  • 概念アーキテクチャとセキュリティ対策
  • 主要な依存関係の整理と保守モデルの体系化

キックオフと要件定義

2026年4月–5月
  • 4月末にプロジェクトをキックオフ
  • 5月にパイロット市場のディストリビューターと2日間の業務ワークショップ
  • 保証請求の業務フロー

構築と試作

2026年6月–9月
  • インフラとセキュリティの要件
  • 8月末に試作のウォークスルー
  • 9月に関係者とスケジュールを見直し
成果

設計によって整う仕組み

導入前適格性のルールが担当者の記憶とスプレッドシートに依存
解決策プログラムのルールを設定として管理し、API経由でDMS・グローバル保証データと自動照合
結果設計を完了し、地域統括会社と合意済み
導入前保証請求をディストリビューター・査定者・地域統括会社の間でメールでやり取り
解決策申請・査定・承認・監査証跡を1つのワークフローに集約し、役割別にアクセス権限を設定
結果パイロット市場向けに構築中
導入前月次精算を手作業で照合
解決策承認済み請求の集計・エクスポートで財務部門の照合を支援
結果パイロット市場向けに構築中
導入前市場を追加するたびに個別のシステムが必要
解決策アプリケーションをインフラから分離し、市場固有のルールは設定として管理
結果地域への横展開を前提に設計
コードを書く前に、ルールの整理に時間をかけました。MVPが役に立つのは、その対象範囲を地域統括会社が正確に把握でき、次の市場にも一から作り直さずに展開できる場合に限られます。
プロジェクト責任者、平プロモート デジタル
今後の展開

パイロット市場から地域全体へ

アプリケーションは他の市場でも再利用できるよう設計しています。新しい地域ではそれぞれクラウドインフラ、ネットワーク、データ保管場所の設定が必要ですが、アプリケーションの構成要素はそのまま引き継げます。

ステップ1

パイロット市場での本番稼働

本番稼働の前に、システム結合テスト(SIT)、ユーザー受け入れテスト、第三者によるペネトレーションテスト、社内講師の育成研修を実施します。

ステップ2

パイロットの結果を反映

最初の市場の実データをもとに、適格性ルール、請求ワークフロー、精算方法を調整します。

ステップ3

他市場への展開

制度の拡大に合わせて、同じアプリケーションを他の市場へ展開できるよう設計しています。

プラットフォームとパートナー
AWS EC2Amazon RDS (MySQL)RedisAmazon S3Amazon EFSCloudFrontCloudWatchLaravelVueREST API and webhooksGitHub Actions

同様の課題をお持ちですか

課題を数行でお聞かせください。通常1週間以内に、具体的な最初の一歩をご提案します。