自動車メーカーDMS刷新を、
「コア + AI駆動拡張」の二層構造で解く
多数の販売会社それぞれが固有の業務要件を抱えるDMS（ディーラーマネジメントシステム）領域では、 「全要件を吸い上げて一本の基幹システムを刷新する」アプローチは破綻しやすい。 私たちは 最大公約数機能だけを束ねたコア（MVP） と、 各販売会社固有の要件をAI駆動開発で外付けする層 という二層構造に再設計し、 業務知識を持つコンサルとAIエンジニアによるハイブリッドチームで現在も伴走している。
01顧客課題：B2B2C DMSが抱える「多様性 × 規模」の壁
自動車メーカー（OEM）が販売会社（ディーラー）を介してエンドユーザーに車を届けるB2B2Cの構造において、 DMSは販売・整備・在庫・顧客管理を束ねる基幹システムであり、 OEMと販売会社の双方の業務に深く接続している。
難所は、販売会社ごとに歴史・業態・地域特性が異なり、業務要件が大きく分かれることにある。 すべての販売会社の要件をそのまま吸い上げて一本の基幹システムに統合しようとすると、 要件定義は長期化し、スコープは膨張し、ソースは固まらず、刷新そのものが座礁する。
02アプローチ：コア（MVP）と外付け（AI駆動開発）の二層構造
私たちは、すべてを一枚のシステムに織り込むのではなく、 要件の「共通部分」と「個別部分」を構造的に分離することを選んだ。
(a) コア：最大公約数のMVP
基盤システムは、各販売会社に共通して必要な機能のみに絞り込み、MVPとして固める。 要件のコアを安定させることで、ソースを固め、刷新リードタイムを短縮する。
(b) 外付け：AI駆動開発による個別要件の充足
各販売会社が固有で必要とする機能は、コアに無理に取り込まず、外付け層として開発する。 この外付け層を AI駆動開発（Claude Code・Cursor等のコーディングエージェントと、 要件定義・設計フェーズにおける生成AIの活用）で構築することで、 従来であれば見送られていた個別要件にも、現実的なコストとスピードで応えられる体制をとっている。
03FDE的ケイパビリティの内訳
この二層構造を成立させているのは、二つのケイパビリティの掛け算である。
① 現場に入り込んだドメイン理解
- OEM本社・販売会社の両側と複数年規模で伴走
- 多拠点での現地ヒアリングを通じ、販売・サービス・バックオフィスの業務実態を把握
- 設計書を受け取って作るのではなく、課題設定・上流要件・業務設計から関与
② AI駆動開発
- 業務知識を持つコンサル × AIエンジニアのハイブリッドチーム編成
- 現場でその場で要件を固め、プロトタイプを作り、実装する
- AIを前提にした少人数高生産性のチーム設計
04導入の効果
| 観点 | 効果 |
|---|---|
| リードタイム | 要件をコア（最大公約数）に絞り込むことで、基幹システム刷新のソースを早期に固め、リードタイムを大幅に短縮。 |
| コスト | 個別要件を外付け層でAI駆動開発することにより、全体コストを抑えつつ、従来は切り捨てられていた販売会社固有要件にも柔軟に充足。 |
| 多様性への対応 | 販売会社ごとに異なる業務要件を、一本の基幹に押し込まず、外付け層で個別最適に実装。コアの安定性と個別の柔軟性を両立。 |
| 顧客との関係 | 上流から伴走しているため、要件の出し戻しではなく、課題そのものの再定義・優先順位付けから議論できる。 |
05これができるチーム
本事例で提供しているのは、単発の受託開発でもなく、汎用パッケージの導入でもない。 顧客のドメインに入り込み、課題と要件をその場で構造化し、AI駆動開発でそのまま実装まで進める 「現場伴走 × AI駆動実装」のワンチーム型ケイパビリティである。
要件多様性が高く、従来型の一括刷新では座礁しやすい基幹システム領域であれば、 DMS以外のドメインにも同様のアプローチで適用できる。