WORKS

TOP

>

Works

>

自動車整備プラットフォーム「FLEET PITLOCK」の開発支援

自動車整備プラットフォーム「FLEET PITLOCK」の開発支援
保守運用基本設計画面設計脆弱性診断要件定義開発実装
業界: 自動車整備

開発支援事例:FLEET PITLOCK株式会社

業界横断の合意形成から標準化API構築まで、DXとBPO化の基盤構築を伴走

法人向け自動車リース業界の主要企業が参画する共通プラットフォーム 「FLEET PITLOCK(以下、FPL)」 は、リース会社と整備工場の間に立ち、車両・契約情報、入庫予約、請求といった業務データをつなぐことで、現場の負担を減らし、業界全体の生産性を高めることを目的とした取り組みです。

本プロジェクトは、各社が長年積み上げてきた異なる業務フロー・運用・システム仕様を「業界標準」に落とし込む必要があり、各社との合意形成とアーキテクチャへの落とし込みの両方が問われる難易度の高い案件でした。

Sun*は大手開発ベンダーからこの取り組みを引き継ぎ、開発体制を柔軟に構築しながら、サービスの中核となる 「基幹システム連携」「請求一元化」 を含む 約300機能 を実装。FPLが目指す“整備工場のバックオフィス化(BPO化)”に向けた基盤づくりを、ビジネスと技術の両面から伴走しました。


 

サービスの概要

FPLが提供する価値

FPLは、リース会社と整備工場をつなぐ 「情報連携のパイプ」 として機能し、以下の3つを主要機能として提供します。

  1. 情報一元化機能:車両・顧客・契約データを一元管理し、確認・照会工数を削減
  2. 基幹システム連携:リース会社システムと整備工場の基幹システムをデータ連携し、二重入力の手間を解消
  3. 請求一元化機能:請求・納品書発行・承認などの業務をプラットフォーム上で一括処理

これらの機能により、整備工場は「整備に集中できる環境」を整え、リース会社側も運用の標準化・効率化を進めやすくなります。

 

クライアントの課題

共同プラットフォームならではの課題

本プロジェクトは、技術的な実装以前に、業界横断のプラットフォームならではの「標準化」と「現場の運用負荷」という2つの大きな壁に直面していました。

課題1:異なる仕様を「標準化」する難しさ

FPLは複数企業が参画する共同プラットフォームです。各社が持つフロントシステム、データ定義、業務フローには差異があり、そのままでは共通化できません。本プロジェクトでは、開発以前に「何を標準とするか」を定める必要がありました。標準化の設計が曖昧なまま実装を進めれば、後から変更が連鎖し、参加企業が増えるほど運用が破綻するリスクが高まります。

加えて、実装段階では取り扱うデータ量が大きいことに加え、想定外なパターンが多くあり取り込みバッチがエラーになりやすい、取り込めても画面表示に不整合が出る、といった課題が顕在化していました。

課題2:整備現場の人手不足と、アナログ起点の業務フロー

整備業界では人材不足が深刻化する一方、現場業務において電話・FAXによる調整、複数システムへの入力など、時間を奪う業務が残っています。特にリース車両は、リース会社ごとに手続きや入力が異なり、整備工場は 「各社システムへの入力」と「自社基幹への入力」 という二重入力を改善することが求められていました。

整備現場の人手不足と、アナログ起点の業務フロー after
整備現場の人手不足と、アナログ起点の業務フロー before

 

Sun*の支援

信頼される“共通基盤”を成立させるために

共同基盤では、実装の前に「何を標準とするか」を決めきることが重要です。Sun*は、標準化の判断を実装に落とし込むことを前提に、判断基準の整理と引き継いだアーキテクチャの整備を並行して進めました。

1)標準化を見据え、会社間の差分を吸収できる“共通の型”を設計

設計では、まず既存の参画企業の要件差を現実的に吸収することを優先しながらも、将来的にはより多くの企業に利用してもらえるよう、運用と実績を踏まえて標準化できる領域を段階的に広げていくことを前提にしました。
拡張性・変更容易性・運用性といった技術面の根拠を踏まえ、判断が分かれる論点を一つずつ整理して前に進めました。常設のMTGで継続的に議論し、必要に応じて合宿形式で集中的に検討する場も設け、担当者の皆さまと連携しながら合意形成を進めました。

2)拡張と変更に強い構造を設計

FPLは、予約・車両・契約・請求など複数ドメインが絡み合うプラットフォームです。将来の機能追加や参加企業の増加を見据え、Sun*は引き継いだ既存構成を評価した上で、疎結合化を前提とした改善方針を整理。「どこを分割し、どこを共有するか」を業務ドメイン起点で整理し、連携境界をAPIとして定義することで、変更影響を局所化しました。
BRMSツール(ビジネスルールマネジメントシステム)を導入し、ロジック変更については定義変更で対応できるようなアーキテクチャとしました。

3)企業間データ連携に必要な“セキュリティと運用”を土台から整備

複数企業間でデータを扱う共同基盤では、セキュリティは実装項目ではなく“前提条件”です。Sun*は、参加企業が安心して接続できる基盤を整備し、ペネトレーションテストによる脆弱性診断も実施しました。
また、開発移管後は体制や品質、開発運用が揺れやすい局面でも、レビュー・テスト方針・リリース手順を整備し、継続的に開発が回る状態づくりを支援しました。

 

得られた成果

300以上の機能を実装し、DXからBPO化へ進む基盤を整備

300を超える機能の実装は、単なる“追加開発”ではありません。Sun*は開発移管後、機能を積み上げながら、FPLが目指すDXの先にある「BPO化する」を見据えた、運用に耐える基盤を目指して整備しました。

成果1:「基幹システム連携」により、整備工場の二重入力を解消

FPLの価値の核となるのが、リース会社側システムと整備工場側が利用する基幹システムの接続。これにより、整備工場で発生していた「各社システムと基幹システムへの重複入力」を減らし、事務作業の負担軽減に直結する土台を構築しました。

成果2:「請求一元化」により、遠隔での請求入力代行(BPO)を可能に

従来は整備会社が複数工場へ各社独自のフォーマットで請求がなされ、整備担当者が事務も担う現場では請求処理が滞りやすい状況でした。FPLでは請求業務を共通化し、処理の効率化を進めました。あわせて、FPLの運用チームが請求業務を代行できる運用も視野に入れたことで、BPO化に向けた土台が整いました。今後はBPOサービスの展開を本格化していきます。

 

今後の展望

FPLで整えた「情報連携のパイプ」と標準化の枠組みは、整備領域だけでなく、周辺業態や物流、アフターマーケットへも“横展開できる土台”になり得ます。今後、接続先が増えるほど、データの価値は高まり、業務の自動化・省力化の余地も広がっていきます。
Sun*は、運用のなかで見えてくる改善ポイントを継続的に拾い上げながら、API・データモデルの拡張、連携先追加時の標準化設計、運用・品質のアップデートまで含めて、長期的に伴走していきます。

 

ユーザーの声

契約確認・請求一元化で現場負担を削減

『約30社のリースメンテナンスを受託する中で、リース会社ごとに異なるシステムへの入力が必要となり、サービスフロントの事務負担が大きい状況でした。FLEET PITLOCK導入により、車両単位で契約内容を確認できるようになり、請求入力も一元化されることで、現場の負担軽減やミス防止に期待しています。店舗の効率化に加え、本部での収益管理の精度・スピード向上にもつながる点を評価しています。』

関東地区ディーラー(サービスマネージャー)

 

二度打ち解消で事務負担を大幅削減

『リース会社ごとの請求サイトへの登録と自社整備システムへの売上登録が必要で、いわゆる「二度打ち」により1台あたりの処理時間が膨らんでいました。紙請求が残る店舗もあり、入力漏れや請求遅延のリスクに常に気を遣う状況でした。FLEET PITLOCKにより、ひとつのシステムで複数リース会社への請求に対応でき、整備システム連携で二度打ちが解消されることで、事務負担の大幅な削減と、整備に集中できる環境づくりへの貢献を期待しています。』

九州地区ディーラー(サービスアドバイザー)