「業界パッケージを一通り試したが、自社の下取り評価やオークション仕入のフローに合わない」「Excel との二重入力が慢性化していて、車両登録の抜け漏れが顧客トラブルにつながっている」――中古車販売やカーディーラーで業務システムの限界を感じ、外部への開発発注を検討し始めた経営者・DX 担当者の方は多いのではないでしょうか。
一方で、いざ発注しようとすると次のような不安が頭をよぎります。「うちの業界の商慣習を理解していない開発会社に頼んで、現場で使われないシステムが納品されたらどうしよう」「パッケージ・業界特化 SaaS・スクラッチ開発のどれを選べばよいのか、判断軸が持てない」「複数社から見積が届いても、相場観がないので妥当性を評価できない」。
中古車販売・カーディーラー業界は、車両1台ごとの個別性（車歴・整備歴・オークション評価点）、独自の下取り評価ロジック、ポータルサイト（グーネット・カーセンサー等）やオークション（USS・JU 等）との連携、車検繁忙期の運用負荷など、汎用的な業務システムでは吸収しきれない業界特有の要件が数多く存在します。この業界特性を理解していない開発会社に発注すると、要件定義の段階で認識齟齬が積み重なり、追加開発費が膨らんだり、納品後に現場で使われないという結果を招きがちです。
本記事では、中古車販売・カーディーラーが業務システムを外注する際に、発注者側が意思決定するための判断軸を整理します。パッケージ・業界特化 SaaS・スクラッチ開発の選び方、業界を理解した開発会社を見極めるためのチェックリスト、費用・期間の目安、RFP（提案依頼書）に含めるべき業界特有情報、そして業界理解不足による失敗パターンまで、発注者目線で解説します。
読み終える頃には、複数の開発会社と相談する際の目線が揃い、自社の業界特性を的確に伝えられる状態を整えていただけるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
なぜいま中古車販売・カーディーラー業界でシステム開発の外注ニーズが高まっているのか
中古車販売・カーディーラー業界を取り巻く環境は、この5〜10年で大きく変化しました。既存の業界パッケージや紙・Excel を組み合わせた運用では吸収しきれない業務ニーズが顕在化しており、その対応策として外部への業務システム開発の発注ニーズが高まっています。
業界を取り巻く構造変化と DX の圧力
まず、業界全体の構造課題として、若年層のクルマ離れによる買い替えスパンの長期化、少子高齢化に伴う新車販売台数の縮小、カーシェアリング・サブスクリプションといった新しい所有形態の普及が挙げられます。総務省「情報通信白書」でも、モビリティサービスの多様化とそれに伴うデータ活用の重要性が繰り返し指摘されています（総務省 情報通信白書）。1台1台の販売から得られる粗利が縮小するなか、顧客生涯価値（LTV）の最大化――整備・車検・買替への継続的な誘導――がこれまで以上に重視されるようになりました。
そのため、顧客情報・車両情報・整備履歴を横断的に把握できる業務システムが不可欠になっています。加えて、グーネットやカーセンサーといったポータルサイトへの出品自動化、USS・JU 等のオークション仕入データの取り込みなど、外部サービスとのデータ連携要件も年々複雑化しています。
現場でよくある「紙・Excel・古いパッケージ」の限界
中規模までのカーディーラー・中古車販売店では、10 年以上前に導入した業界パッケージと Excel、紙台帳を組み合わせて業務を回しているケースが依然として多く見られます。よくある症状は次のとおりです。
- 車両情報を業界パッケージに登録した後、ポータル出品用に Excel へ再入力している
- 下取り査定額の算出ロジックが担当者ごとに異なり、標準化されていない
- 整備システムと販売システムが別々で、車検時期の顧客リストを紙で突合している
- 従業員退職で顧客対応履歴が失われ、次回の営業提案に活かせない
こうした症状は「システムを入れ替えれば解決する」ようで、実際にはそう単純ではありません。既存パッケージで賄える範囲、業界特化 SaaS で吸収できる範囲、自社独自の業務プロセスに合わせて開発が必要な範囲を切り分けたうえで、発注戦略を組み立てる必要があります。
中古車販売・カーディーラーの主要な業務領域とシステム化の対象
発注の第一歩は「どの業務領域をシステム化するのか」を言語化することです。中古車販売・カーディーラー業界には、汎用的な販売管理システムには収まらない業務領域が数多く存在します。以下、システム化の対象になりやすい主要業務領域を整理します。
車両1台ごとの個別性が生む在庫管理の難しさ
中古車の在庫管理は、他業界の在庫管理とは根本的に性質が異なります。同じ車種・同じ年式であっても、走行距離・修復歴・オプション装備・オークション評価点・整備状況によって商品価値がまったく異なるためです。1台1台に固有の識別番号（車台番号・管理番号）を紐づけ、以下の情報を統合管理する必要があります。
- 仕入情報（仕入先・仕入価格・仕入日・オークション評価点）
- 整備・修復履歴（整備工場・整備内容・整備原価）
- 追加コスト（陸送費・清掃・板金・車検取得費）
- 販売価格・値下げ履歴・展示場所
- ポータル出品状況（グーネット・カーセンサー等の掲載可否）
- 販売確定後の顧客・登録情報
これらを漏れなく紐づけないと、粗利計算や在庫回転率の可視化が困難になります。
顧客・販売・整備の三位一体の情報統合が必要な理由
前述のとおり、中古車販売業のビジネスモデルは「販売時点の粗利」だけでは成立しづらくなっています。整備・車検・買替までを含めた顧客生涯価値の最大化が事業の柱です。そのため、顧客情報・販売情報・整備情報を統合し、以下のような業務を回せる状態が理想です。
- 車検・法定点検の案内タイミングを顧客ごとに自動抽出
- 過去の下取り履歴から次回買替時期を予測して営業提案
- 整備時の追加提案（タイヤ交換・オイル交換）を車両状況に応じて自動リコメンド
- 事故対応・保険連動の履歴を含めた顧客カルテの一元化
この統合が実現できていないと、担当者退職時に顧客対応履歴が失われ、営業機会の逸失につながります。
外部サービス（ポータル・オークション・会計・金融）との連携要件
中古車販売業では、社外の複数サービスとリアルタイムに連携する要件が発生します。代表的な連携先は次のとおりです。
- ポータルサイト: グーネット・カーセンサー等の在庫ポータルへのデータ自動連携
- オークション: USS・JU・アライオートオークション等の仕入データ取込・落札後の入庫処理
- 信販・自動車ローン: オリコ・ジャックス・アプラス等の与信申込・審査結果連携
- 保険・整備予約: 自賠責・任意保険の申込、車検予約システムとの連動
- 会計・請求: 会計ソフト・電子帳簿保存法対応の証憑管理
これらの連携仕様は各サービス提供元の API 仕様やデータフォーマットに依存するため、開発会社が同種の連携実績を持っているかが選定時の重要な確認ポイントになります。
パッケージ・業界特化SaaS・スクラッチ開発の選択肢と判断軸
システム化の対象範囲が見えてきたら、次はどの方式で実現するかを決めます。中古車販売・カーディーラー業界向けの選択肢は大きく3つに分類されます。それぞれに向き・不向きがあり、判断軸を明確にせずに選ぶと後戻りコストが大きくなります。
業界パッケージで賄える領域と賄えない領域
業界パッケージ（JOCAR / Symphony / 楽商 / EBE 等）は、中古車販売の標準的な業務フロー（車両登録・見積・注文書作成・登録手続き・請求）に沿って設計されています。導入コストが比較的抑えられ、業界標準の帳票（注文書・自動車注文書・登録依頼書等）がすぐに使える点が最大の強みです。
一方で、以下のような要件はパッケージ単体では吸収が難しいことが多く、追加カスタマイズや外付けシステムが必要になります。
- 自社独自の下取り査定ロジック・仕入評価ロジック
- 特定のオークション会場との深い連携（落札結果の即時取込・オークション評価点の自動反映）
- 複数拠点で異なる業務フロー（メーカー系ディーラー併設・整備工場併設・輸入車専門店等の混在）
- 独自の顧客ランク付け・LTV スコアリング
- 独自の販売キャンペーン・値引き承認フロー
現状のパッケージで賄えていない業務がどれくらいあるかを棚卸しし、「パッケージ準拠にできる業務」と「独自性を維持すべき業務」を切り分けることが最初の判断ポイントです。
業界特化SaaSに寄せる場合の判断基準
近年は中古車販売業向けのクラウド SaaS が増えており、初期費用を抑えつつクラウド上で在庫・顧客・販売を一元管理する選択肢が広がっています。SaaS を選ぶ際の判断基準は次のとおりです。
- 標準機能で自社業務の 70〜80% がカバーできるか: 標準機能に業務側を寄せる判断ができるかがカギ
- ポータル・オークション連携の実績があるか: 主要な外部サービスとの連携が標準で用意されているか
- カスタマイズ・API 公開の柔軟性: 標準で足りない部分を外付けで補える設計になっているか
- 多拠点対応・権限管理: 拠点別売上・在庫の把握、店舗長権限の設定が可能か
「業務側をシステムに合わせられる範囲」を経営として決めきれるかが SaaS 導入成功の分岐点です。
フルスクラッチ・パッケージ拡張・SaaS+個別開発の使い分け
3 つ目の選択肢は、フルスクラッチ開発またはパッケージ・SaaS への個別開発の追加です。以下のような場合にスクラッチや個別開発の妥当性が高まります。
- 自社の下取り評価ロジックや仕入評価ロジックが競争優位の源泉になっている
- 複数拠点で業務フローが大きく異なり、標準化が難しい
- 業界パッケージ・SaaS の更新頻度・改修対応スピードが自社の意思決定スピードに追いつかない
- 既存の基幹システム（会計・給与・整備システム）と密結合したデータ連携が必要
- 5〜10 年単位でシステム資産として保有し、事業成長に合わせて拡張したい
現実的な折衷案として多いのは、コア業務（在庫・顧客・販売）はパッケージまたは SaaS で回し、独自性が強い部分（下取り査定・オークション連携・独自ポータル出品ロジック）だけを個別開発するハイブリッド構成です。
業界を理解した開発会社を見極める選定チェックリスト
外注方針が固まったら、次は開発会社の選定です。中古車販売・カーディーラー業界の商慣習を理解しているかを見極めるために、次のチェックリストを提案・面談時に活用してください。
実績・事例の見方（自社と近い規模・業態かを判定する軸）
開発会社の実績ページや提案資料を確認する際、単に「自動車業界の実績あり」で判断せず、以下の軸で近さを測ります。
- 業態: メーカー系ディーラー / 独立系中古車販売店 / 輸入車専門店 / 整備工場併設型 / トラック・商用車販売など、自社と同種の業態での実績があるか
- 規模: 拠点数・車両点数・従業員数が自社と同規模の実績があるか（1店舗と 50 店舗では要件がまったく異なる）
- システム範囲: 部分的な機能開発（ポータル出品自動化のみ等）か、基幹システム全体の構築経験があるか
- 連携実績: グーネット・カーセンサー等のポータル、USS・JU 等のオークション、信販会社との連携実績があるか
「業界実績あり」の内訳が新車メーカーディーラーばかりで、中古車販売店の商流を知らないケースもあります。事例の解像度を上げて確認しましょう。
業界用語で対話できるかを確かめる質問例
初回商談では、以下の質問を投げかけて業界理解度を測ることを推奨します。
- 「オークション仕入の落札後、入庫までの間に発生する陸送費・整備費・清掃費を車両原価に取り込む運用は、御社の類似案件ではどのように実装されましたか？」
- 「下取り査定額の算出ロジックを自社独自で持ちたいのですが、御社のこれまでの事例ではロジックの実装をどこまで柔軟に対応されていますか？」
- 「グーネットやカーセンサーへの出品自動化について、CSV 連携以外の連携手段を提案いただけますか？」
- 「車両ステータス（仕入 → 整備中 → 展示中 → 商談中 → 販売済 → 登録待ち → 納車済）を業務側の承認フローとどう連動させるのがよいでしょうか？」
これらに対して具体的な事例や設計方針を語れるかどうかで、業界理解の深さが判断できます。「これから調べます」ばかりの回答であれば、要件定義に時間とコストがかかることを想定する必要があります。
保守・改修体制の確認ポイント
システムは納品して終わりではなく、事業成長・法改正・外部サービス仕様変更に応じて継続的な改修が必要です。以下は必ず契約前に確認しておきたい項目です。
- 車検繁忙期（3 月・9 月）の障害対応 SLA: 応答時間・復旧時間の目安
- 法改正対応: 消費税率変更・電子帳簿保存法対応・自動車税制改正時の改修範囲と費用
- 外部サービス連携の仕様変更対応: グーネット等の API 仕様変更時の追随可否と費用負担
- 担当者の継続性: 要件定義した担当者が保守フェーズまで継続的に関わるか、引き継ぎ体制はどうか
- 月次改修サイクル: 小規模改修の月次リリース枠が用意されているか
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
費用と期間の目安
見積の妥当性を判断するためには、方式ごとの費用レンジと期間の相場観を持っておく必要があります。ここでは中古車販売・カーディーラー業界での典型的な目安を示します。実際の見積金額は要件の粒度・拠点数・連携先の数によって大きく変動するため、あくまで発注準備段階での目線合わせとしてご活用ください。
方式別の費用レンジ・期間目安
- 業界特化 SaaS: 月額 数万円〜数十万円 / アカウント数課金 + 初期セットアップ数十万円〜100 万円 / 導入期間 1〜3 か月
- 業界パッケージ導入: 初期費用 200 万円〜1,000 万円 / 導入期間 3〜6 か月 / 年間保守料 導入費用の 10〜20%
- パッケージ + カスタマイズ: 上記に加えて 100 万円〜500 万円のカスタマイズ費用 / 期間 +2〜4 か月
- フルスクラッチ開発: 500 万円〜数千万円 / 期間 6 か月〜1 年半 / 追加保守費 年間 100 万円〜数百万円
初期予算 300 万円未満であればスクラッチ開発は現実的でなく、SaaS または業界パッケージが選択肢となります。500 万円以上の予算がある場合はスクラッチも視野に入りますが、要件範囲・連携先数によっては1,000 万円を超えることもあります。
見積書で確認すべきポイント（要件粒度・追加費用条件・保守費）
複数社から見積を取得したら、金額の総額だけでなく、以下の観点で内訳を比較します。
- 要件の粒度: 「在庫管理機能一式」のように括った見積は要注意。機能別・画面別に工数が分解されているほど、追加開発時の交渉がしやすい
- 前提となる要件範囲: 見積に含まれる連携先・帳票数・拠点数・ユーザー数が明記されているか
- 追加費用の条件: 要件追加・変更が発生した際の単価（人日単価）・見積プロセス
- テスト・移行費用: 既存データからの移行、テスト工数、ユーザー教育費用が含まれているか
- 保守費用の内訳: 月次保守で対応する範囲（軽微な修正 / 障害対応 / バージョンアップ）と、範囲外作業の追加費用条件
- 請負契約 or 準委任契約か: 契約形態によって成果物責任・追加請求条件が変わる
安価な見積の背景に、要件範囲の限定的な解釈や保守費用の高さが隠れていることがあります。「なぜこの金額になるか」を各社に説明してもらうプロセスが、信頼できるパートナーを見極める過程そのものです。
発注前に自社で整理しておくべきこと（RFPの要点）
「業界を理解している開発会社に頼みたい」と考えるなら、その裏返しとして「自社の業界特性を伝えられる情報を整理しておく」ことも欠かせません。RFP（提案依頼書）の質が、提案の質を決めます。ここでは中古車販売・カーディーラー特有の RFP 項目を整理します。
RFP に最低限含めるべき業界特有情報
以下の項目を整理しておくと、開発会社は具体的な提案を返しやすくなります。
- 企業概要: 拠点数・従業員数・年間販売台数・年間仕入台数（オークション/下取り/買取の内訳）
- 取扱車種: 国産／輸入、乗用車／商用車、新車／中古車の比率
- 現状の業務フロー図: 仕入 → 整備 → 展示 → 商談 → 販売 → 登録 → 納車 → 車検・保守 の流れとそれぞれで使っているシステム・帳票
- 既存システム構成: 業界パッケージ名・SaaS 名・独自 Excel シート・会計ソフト等の一覧
- 外部連携先: 使用中のポータルサイト、オークション、信販、保険、整備予約サービス
- 業務ピーク: 車検繁忙期（3 月・9 月）と閑散期の業務量差、繁忙期の応援体制
- 優先順位: マスト機能（必須）／ベター機能（あると嬉しい）／不要機能の切り分け
- 予算・スケジュール: 想定予算レンジと稼働開始希望時期
- 将来拡張: 3〜5 年後に見込まれる出店計画・新規サービス展開
「マスト／ベター／不要」の切り分けは、開発会社に伝えるだけでなく、社内で経営層と現場が優先順位について合意する場としても機能します。
現場責任者を巻き込む重要性
RFP を作成する際は、経営者・DX 担当者だけでなく、現場責任者（店長・整備長・営業リーダー）を必ず巻き込んでください。理由は次のとおりです。
- 現場でしか把握していない例外業務・裏フローがある（値引き承認の口頭ルール、特殊車両の登録手順など）
- 現場が使わないシステムは投資回収できない。要件定義段階から現場を巻き込むことで導入後の定着率が上がる
- 現場責任者の懸念事項が要件に反映されないと、システム稼働開始後に「使いにくい」というクレームで運用が停滞する
現場ヒアリングの結果を RFP に反映し、「現場から見た理想の業務フロー」と「現在の業務フロー」の両方を開発会社に伝えると、より現実的な提案が得られます。
失敗パターンから学ぶ注意点
最後に、業界理解不足による失敗パターンを共有します。同じ轍を踏まないための予防策としてお読みください。
業界理解不足で起こりやすい失敗3パターン
失敗パターン1: オークション連携仕様が要件定義から漏れて追加開発費が膨らんだ
要件定義段階で「オークション連携」とだけ記載していたところ、開発会社は CSV 手動アップロードの想定で見積を作成。実際には USS の落札結果を毎日自動取込したかったため、追加開発費 300 万円が発生した。連携先ごとの API 仕様書・データ形式・更新頻度を要件定義書に明記していなかったことが原因。
失敗パターン2: 下取り評価ロジックの独自性を伝えきれず現場で使われなかった
自社独自の下取り査定ロジック（車種別下限価格・年式減価率・走行距離補正・オプション加点）を伝えずに標準ロジックで実装したところ、現場の査定士が「システムの査定額が実勢と合わない」と Excel での並行運用に戻ってしまった。ロジックが競争優位の源泉になっていることを開発会社側にも共有し、要件段階で複数パターンのテスト査定を用意すべきだった。
失敗パターン3: 保守契約の内容を確認せず、車検繁忙期に対応してもらえなかった
導入時に「月額 20 万円で保守します」と提案された内容の中身を精査せず契約したところ、3 月の車検繁忙期にシステム障害が発生した際、契約上は「翌営業日対応」となっており復旧まで丸2日を要した。契約前に SLA（応答時間・復旧時間・繁忙期対応）を明示的に確認しておくべきだった。
これらはいずれも「業界特有の要件を、要件定義書・契約書という文書レベルで明文化できていなかった」ことが共通の原因です。口頭合意ではなく、業界特有情報を文書化する習慣を徹底しましょう。
契約形態（請負・準委任）の使い分け
システム開発の契約形態は主に請負契約と準委任契約に大別されます。それぞれの特徴を理解し、フェーズごとに使い分けることが重要です。契約形態の詳細は IPA（情報処理推進機構）が公開する「情報システム・モデル取引・契約書（第二版）」も参考になります（IPA 情報システム・モデル取引・契約書（第二版））。
- 請負契約: 成果物完成責任を開発会社が負う。要件が固まっている工程（詳細設計・製造・単体テスト）に向く
- 準委任契約: 労務提供が契約対象で成果物完成責任は負わない。要件が流動的な工程（要件定義・PoC・保守運用）に向く
中古車販売・カーディーラー業界のシステム開発では、要件定義フェーズを準委任で丁寧に進め、要件が固まった後の開発フェーズを請負に切り替える段階契約が推奨されます。要件定義から一括請負にすると、要件変更のたびに追加費用交渉が発生し、認識齟齬が積み重なりやすくなります。
まとめ｜発注前に踏むべき次のアクション
中古車販売・カーディーラー業界のシステム開発外注を成功させるには、「業界を理解した開発会社を選ぶ」という抽象的な目標を、具体的な行動に翻訳することが不可欠です。本記事で紹介した内容を踏まえ、明日から実行できる次のアクションを 3 つに整理します。
- 現状業務フローの棚卸し: 仕入 → 整備 → 展示 → 商談 → 販売 → 登録 → 納車 → 車検・保守の流れを図示し、それぞれで使っているシステム・帳票・Excel を書き出す
- マスト／ベター／不要の切り分け: 現状の課題リストから、業界特有要件（オークション連携・下取り評価・ポータル出品・整備連動）ごとに優先順位を経営層と現場で合意する
- 複数社への相談準備: 本記事で紹介した業界理解度を測る質問リストを持って、少なくとも3社（業界特化 SaaS ベンダー / 業界パッケージ提供会社 / 独立系 SIer）と初回商談を行う
外注の成否は、開発会社選定よりも「発注者側の準備」で決まることが多いのが実態です。自社の業界特性を言語化できていれば、開発会社が変わっても再現性の高い提案が得られます。逆に、社内の要件整理が不十分なまま複数社に相談しても、提案内容がばらつき、比較検討そのものが困難になります。
まずは現状業務フローの棚卸しから着手し、社内で業界特有要件の言語化を進めてください。準備が整った段階で複数の開発会社と対話することで、「業界を理解しているパートナー」との出会いに近づけるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- パッケージ・業界特化SaaS・スクラッチ開発のどれを選べばよいか判断できません。
標準機能で自社業務の7〜8割をカバーできるかが分岐点です。カバーできるなら業界特化SaaSやパッケージ、下取り評価ロジックなど競争優位の源泉となる独自業務が多い場合はスクラッチや個別開発を検討してください。
- 開発会社が中古車業界を理解しているかをどう見極めればよいですか。
実績の『解像度』と商談での回答の『具体性』の2軸で判定するのが実務的です。実績面では自動車業界実績の有無だけでなく、業態（独立系中古車店・輸入車専門店・整備工場併設型など）や拠点規模が自社に近いか、ポータルサイトやオークションとの連携実績があるかまで踏み込んで確認します。商談では、オークション落札後の入庫処理や下取り査定ロジックの実装方針など具体的な質問を投げかけ、自社に近い類似案件を挙げて即答できるかを見てください。抽象的な一般論に終始する会社は要注意です。
- システム開発の費用や期間はどのくらいを見込めばよいですか。
業界特化SaaSは初期数十万円〜100万円・月額数万〜数十万円、業界パッケージは初期200万〜1,000万円、フルスクラッチは500万円〜数千万円が目安です。予算300万円未満であればSaaSかパッケージが現実的です。
- RFP（提案依頼書）には最低限何を書けばよいですか。
拠点数や年間仕入台数などの企業概要に加え、現状の業務フロー図・既存システム構成・外部連携先・マスト/ベター機能の優先順位を含めてください。現場責任者を交えて整理すると提案の精度が上がります。
- 契約形態は請負と準委任のどちらを選ぶべきですか。
仕様が確定しているかどうかで使い分けます。RFPで整理したマスト機能の仕様がまだ固まっていない要件定義段階は、柔軟な調整ができる準委任契約が適しており、仕様確定後の設計・開発フェーズでは成果物の完成責任を開発会社が負う請負契約に切り替えます。逆に開発フェーズまで準委任のままにすると、成果物の完成責任が開発会社側に発生せず、納期や品質を担保しづらくなる点に注意してください。
