CPQシステム開発の発注/外注/依頼/委託方法について

CPQシステムの発注・外注・依頼・委託は、見積業務を棚卸しし、商品・価格ルールと連携要件をRFPに整理したうえで、標準設定・拡張・スクラッチの提案と総額を比較して進める方法が基本です。

CPQは、営業担当者が商品やオプションを選び、価格を計算し、見積書を発行するだけのツールではありません。商品マスタ、値引き権限、承認フロー、CRM・ERP連携、契約更新まで関係するため、発注先の提案力だけでなく、自社がどこまで業務とデータを整理できるかが成否を左右します。この記事では、発注形態の選び方、RFPと要件定義、契約形態、費用相場、委託先の選定、見積書の比較方法、外注後の受入準備までを、2026年時点の情報を踏まえて解説します。

▼全体ガイドの記事
・CPQシステム開発の完全ガイド

CPQシステムを発注・外注する前に押さえる全体像

CPQシステムの発注全体像を整理する担当者

CPQの発注では、製品を買うか開発会社へ依頼するかだけを決めるのではなく、見積から受注・請求までのどこをシステム化するかを先に定めます。最初から製品名や画面の要望を並べると、業務に合わないカスタマイズや、使われない高機能に予算を使う可能性があります。

CPQシステムは何を発注する仕組みですか?

CPQはConfigure、Price、Quoteの頭文字で、商品・サービスの構成、価格設定、見積作成を支援する仕組みです。たとえば、複数の機器、保守契約、オプション、サブスクリプションを組み合わせるときに、販売可能な組み合わせか、適用価格はいくらか、値引きに承認が必要かをルールに沿って判定します。Oracle Japanも、Oracle CPQを製品やサービスの適切な組み合わせを構成し、正確な見積書を作成するクラウドアプリケーションと説明しています。出典はOracle Japanの公式ページで、内容を確認できます(出典: Oracle Japan「Oracle CPQ」、2026年8月確認)です。

したがって、外注の対象には画面開発だけでなく、商品カタログ、価格表、顧客別単価、数量割引、原価・粗利、承認ルート、帳票、データ移行、操作教育が含まれます。特に「例外価格を誰が、どの条件で、どの証跡を残して許可するか」は、見積ミスと粗利毀損を防ぐために発注前から決める必要があります。

発注範囲は見積作成だけに限定してよいですか?

小さく始めることは可能ですが、見積だけを切り出す場合でも、受注後の在庫、契約、請求、更新にどのデータを渡すかは確認が必要です。CPQで作った見積情報を担当者が再入力する設計では、転記ミスと二重管理が残ります。初期リリースの範囲を見積作成と承認に絞る場合でも、将来のCRM・ERP連携に必要な項目や識別子を最初から設計しておくと、後から作り直すリスクを抑えられます。

発注形態はSaaS標準・クラウド拡張・スクラッチから選ぶ

CPQの発注形態を比較する資料

発注形態は、商材の複雑度、営業人数、既存CRM・ERP、見積から請求までの対象範囲、社内の運用体制で選びます。製品の知名度だけでは適合性を判断できないため、実際の見積シナリオを使って標準機能を検証し、標準設定・個別拡張・自社開発の境界を明確にします。

SaaS・パッケージの標準機能を中心に発注する場合

商品数や価格表が比較的少なく、既存のCRM連携を必要としない企業は、SaaSの標準設定を中心に進めやすいです。初期設定、権限、帳票、データ登録、教育までを導入支援会社へ依頼し、業務を製品の標準に合わせます。標準化できれば導入期間と改修費を抑えやすい一方、ライセンスの最低利用数、追加ユーザー料金、API制限、データのエクスポート方法、サービス終了時の返却条件は契約前に確認します。

クラウドCPQを拡張して発注する場合

多商材、複数の価格体系、値引き承認、CRM・ERP連携がある企業は、クラウドCPQの標準機能に業務固有の設定や連携開発を加える形が現実的です。Salesforce Japanの公式発表(出典: Salesforce Japan「企業の収益ライフサイクル管理を実現するRevenue Cloud」、2025年)では、2025年7月に日本向けRevenue Cloudの提供を開始し、24,000円(税別)・ユーザー・月と示されています。30ユーザーならライセンスだけで月72万円、年864万円(税別)という計算になりますが、実際の予算には導入支援、商品マスタ整備、帳票、連携、保守などを別に加える必要があります。

同じ公式発表では、パナソニックEWネットワークスが基幹システム刷新の一環としてRevenue Cloudの活用プロジェクトを進め、営業活動と見積管理を単一のプラットフォームで実現する方針を示しています。これは導入を決めた企業の成果を保証する数字ではありませんが、CPQを単独の見積画面ではなく、営業と基幹業務をつなぐ収益管理のテーマとして発注する事例です。自社でも、見積作成だけを対象にするのか、受注・請求までを対象にするのかを、このような業務範囲で判断します。

クラウド型では、標準機能に業務を寄せる範囲と、どうしても拡張する範囲をRFPに書き分けます。製品のバージョンアップで拡張部分が影響を受けないか、設定変更を自社で行えるか、ベンダーまたはSIerに依存する作業は何かも、提案段階で確認します。

スクラッチ開発を選ぶ場合

独自の原価計算、複雑な構成ルール、特殊な契約更新、社内業務との深い結合が競争力そのものであれば、スクラッチ開発も候補になります。ただし、自由度の代わりに、商品マスタの保守、税率や制度変更、テスト、監査ログ、障害対応、担当者交代時の引継ぎまで自社の責任になります。スクラッチを選ぶときは、初期開発費だけでなく、5年程度の運用・改修・教育コストを含めた総保有コストで比較します。

発注前のRFP・要件整理をどのように進めるか

CPQの要件を整理してRFPを作成する様子

RFPは、開発会社に「良いシステムを作ってください」と依頼する文書ではなく、同じ条件で提案と見積を比較するための発注条件です。現行業務、対象範囲、データ、連携、非機能、納期、検収条件を具体化し、未確定事項は未確定のまま明示します。すべてを決め切る必要はありませんが、各社が異なる前提で見積を出さないようにすることが重要です。

実際の見積シナリオをサンプル化する

要件整理では、機能一覧より先に代表的な見積シナリオを三つから五つ用意します。たとえば「標準構成の商品に保守を付ける」「複数オプションと数量割引を適用する」「代理店向け価格と顧客別値引きを組み合わせる」「サブスクリプションを途中変更する」「値引き上限を超えて上長承認する」といったケースです。各シナリオに入力項目、期待する価格、承認者、出力帳票、受注後に渡すデータを記載すると、デモで実装可否を確認しやすくなります。

商品マスタと価格ルールの責任者を決める

RFPには、商品・オプション・BOM、価格表、通貨、税、原価、顧客ランク、数量割引、契約期間、更新条件の項目を列挙します。あわせて、誰が登録し、誰が承認し、いつ改定し、過去の見積へどのバージョンを適用するかを明記します。開発会社にマスタ整備を丸投げすると、現場ごとの呼び方や古い価格が混在し、稼働後に見積が合わなくなるためです。

商品数だけでなく、組み合わせ禁止ルール、価格表の数、例外処理、法人・拠点・通貨の数が工数を左右します。RFPでは、現在の件数と1年後の想定件数を分けて記載し、マスタ更新の頻度と担当部門も示します。これにより、初期構築の費用だけでなく、導入後の運用負担も提案に反映されます。

連携と非機能要件を後回しにしない

CRM、ERP、在庫、請求、電子契約、SFA、認証基盤のどれと接続するかをRFPに書きます。APIの有無、連携方向、リアルタイムか日次か、エラー時の再送、データ項目の責任部署まで決めると、連携費用の前提が揃います。見積情報をCSVで渡すだけなのか、受注・請求まで自動化するのかで、設計もテストも大きく変わります。

非機能要件には、SSO・MFA、最小権限、職務分掌、承認履歴、監査ログ、暗号化、バックアップ、障害時の復旧目標、データ保持・削除、委託先管理を記載します。価格・原価・顧客情報を扱うCPQでは、AI機能を追加する場合のデータ利用範囲と人による承認も確認が必要です。IPAが2025年に公開した「クラウドセキュリティの歩き方」(出典: IPA、2025年)などを参照し、クラウド利用時の提供会社と利用会社の責任分界を整理します。

契約形態とプロジェクト管理を発注時に決める

CPQ開発の契約とプロジェクト管理を相談する場面

CPQ開発では、要件が固まっていない段階から全工程を一括請負にすると、変更のたびに追加費用や納期延長が起きやすくなります。要件の確定度、発注者と受託者の役割、成果物の明確さに応じて契約を分け、変更管理と検収基準を契約書に落とし込みます。

請負契約が向いているケース

RFPと要件定義書、画面・帳票、連携仕様、テスト項目、納品物、検収条件が確定している範囲は、請負契約で成果物と金額を定めやすいです。たとえば、標準機能の設定、指定帳票の作成、決められたAPI連携などは、完成条件を具体化できます。一方で、稼働後に業務部門が試して初めて分かる使い勝手や、商品ルールの整理まで請負範囲に押し込むと、変更協議が増えます。

準委任契約が向いているケース

業務整理、アーキテクチャ検討、PoC、標準機能の評価、アジャイルな改善のように、作業や専門知識の提供を重視する範囲は準委任契約が適します。CPQでは、営業・商品企画・経理・情報システムが議論しながら要件を詰めるため、最初の調査と要件定義を準委任で依頼し、確定した開発部分を請負へ切り替える進め方が有効です。作業時間、体制、会議体、成果物、報告方法、責任分担は曖昧にしないようにします。

フェーズ分割と変更管理を組み合わせる

おすすめは、(1)現状分析・RFP、(2)要件定義・PoC、(3)設計・設定・開発、(4)テスト・移行・教育、(5)稼働後支援のフェーズを分け、各段階で継続判断を行う方法です。各フェーズの終了条件、次段階へ進む判断者、未解決課題の扱い、追加見積のルールを決めておくと、発注者と受託者の認識がずれにくくなります。

CPQシステムの費用相場と期間を確認する

CPQシステムの費用と見積を確認する場面

CPQの国内公開見積は案件条件による差が大きいため、以下は製品の定価ではなく、要件定義から導入までの予算取りに使う目安です。特に商品・価格ルール、ERPや在庫との連携、多拠点・多法人、帳票と契約更新の範囲で金額は変わります。ライセンス、初期設定・開発、データ整備、移行、教育、保守を分けて提示してもらうことが、相場を比較する前提です。

発注形態ごとの初期費用と期間の目安

SaaSの標準設定で商品数が少なくCRM連携がない場合は、初期費用100万〜500万円、期間1〜3か月が一つの目安です。クラウドCPQの標準機能に価格ルール、承認、帳票、CRM連携を加える場合は、500万〜1,500万円、3〜6か月程度を見込みます。製造業やSI向けにBOM、原価・粗利、複数通貨、ERP・在庫・請求連携まで行う本格導入では、1,500万〜5,000万円、6〜12か月程度が目安です。これらは個別案件の確定価格ではなく、CPQシステム リサーチノート(2026年8月)を出典とし、NotebookLMリサーチの営業・CRM業務システム相場へCPQ固有の作業を加味した推定レンジです。

多拠点・多法人で独自のQ2Cやグローバル価格、税・契約管理まで含める場合は、5,000万円〜数億円、1〜3年規模になる可能性があります。フルスクラッチは3,000万円〜2億円超、12〜24か月程度が参考レンジですが、独自UIや非機能要件、将来改修を含めると大きく変動します。数字だけを比較せず、範囲、前提、除外項目、成果物をそろえて評価します。

ライセンス費とランニングコストを分ける

クラウド製品の料金は、利用ユーザー数、契約プラン、年間契約、追加機能、サポート条件で変わります。Salesforceの現行の公式ページでは、Revenue Cloudから名称変更されたAgentforce Revenue Managementの案内も表示されているため、発注時点の製品名、機能範囲、日本向け価格、契約条件を見積書で確認します。Microsoft Dynamics 365 Salesは、日本公式ページでProfessionalが9,745円、Enterpriseが15,742円、Premiumが22,488円のユーザー・月相当、年払い・税別と案内されています(出典: Microsoft「Dynamics 365 Salesの価格」、2026年8月確認)。ただし、営業基盤のライセンス価格と、複雑なCPQを実現する導入開発費は別物です。

ランニングコストには、SaaSライセンス、APIや連携サービス、帳票・電子契約、保守、商品マスタ更新、問い合わせ対応、追加教育を含めます。スクラッチや大規模カスタマイズでは、初期費用の年10〜20%を保守予算の目安として確保します。CPQシステム リサーチノート(2026年8月)にある、要件定義10〜15%、設計25〜35%、開発30〜40%、テスト15〜20%、移行・教育5〜10%という作業配分も、見積の偏りを確認する材料になります。

見積金額を左右する五つの要因

金額差を説明する主な要因は、商品・オプションの数、構成可否や価格ルールの複雑さ、連携先の数と方式、拠点・法人・通貨の数、移行・帳票・非機能要件です。たとえば、商品数が少なくても、顧客別価格や販売代理店価格が多く、例外承認が複雑ならルール設計の工数が増えます。反対に、商品数が多くても標準カタログへ整理できれば、標準設定で対応できることがあります。

委託先の選定と見積比較で確認すべきポイント

CPQ開発の委託先と見積を比較する会議

委託先は、CPQ製品を提供するベンダーと、導入・連携・運用を担うSIerや開発会社に分けて考えます。製品を契約すれば要件整理やマスタ移行まで自動で進むわけではありません。候補会社には、CPQ単体の実績なのか、CRM導入をCPQへ拡張した実績なのか、類似する商材・価格ルール・連携環境を経験しているのかを確認します。

実績よりも自社の業務との適合性を確認する

候補会社との打ち合わせでは、会社案内よりも、実見積シナリオを使ったデモと質疑に時間を使います。「構成禁止の組み合わせをどう表示するか」「顧客別価格と数量割引をどの順序で計算するか」「値引き上限を超えたときに誰へ通知するか」「価格改定後も過去見積を再現できるか」「見積からERPへどの項目を渡すか」を質問します。回答が画面の印象だけでなく、データモデル、権限、監査ログ、運用手順まで説明できる会社を評価します。

見積書は同じ条件の内訳で比較する

比較表には、ライセンス、要件定義、設計、標準設定、追加開発、API連携、帳票、データクレンジング、移行、テスト、教育、プロジェクト管理、保守、交通費などの項目を並べます。各社の金額が「一式」だけの場合は、作業時間、担当者、成果物、対象件数、除外事項を質問します。安い提案でも、マスタ整備、受入テスト、ユーザー教育、稼働後支援が除外されていれば、後から追加費用が発生するためです。

見積比較では、初期費用だけでなく、3〜5年の総額と社内負担を見ます。ライセンス値上げ、追加ユーザー、API利用料、保守料、商品マスタ更新、内製化に必要な教育を含め、いつ誰がいくら支払うかを一覧化します。提案の前提条件が異なる場合は、同じ条件で再見積を依頼し、金額差が機能差なのか、体制差なのか、単なる除外なのかを切り分けます。

委託先に必ず聞くべき質問

「標準機能と個別開発の境界はどこですか」「商品マスタを自社で更新できますか」「価格ルールの版管理と過去見積の再現はできますか」「API障害時の再送と監視は誰が担いますか」「担当者が交代しても運用できる設計書がありますか」「稼働後の保守時間と対応時間は契約に含まれますか」「データを返却して別製品へ移行できますか」と確認します。さらに、類似案件の体制、担当者の経験、再委託の有無、セキュリティチェックへの対応、障害時の連絡経路も確認します。

外注後の受入テストと運用定着まで設計する

CPQシステムの受入テストと運用準備

CPQは稼働した日が完成ではなく、営業が正しい商品と価格を選び、承認者が必要な情報を見て判断でき、経理や受注部門へデータがつながって初めて価値が出ます。外注契約の段階で、受入テスト、移行リハーサル、操作教育、問い合わせ窓口、マスタ更新の運用を決めておきます。

受入テストは実データに近いケースで行う

受入テストでは、正常系だけでなく、販売不可の組み合わせ、期限切れ価格、在庫不足、値引き上限超過、承認者不在、途中解約、契約更新、税・通貨の違いを確認します。営業部門には見積作成時間と操作性、商品企画にはマスタ更新、経理には価格と請求データの一致、情報システムには権限・ログ・障害復旧を確認してもらいます。検収条件を「画面が表示されること」ではなく、シナリオごとの期待結果と証跡で定義します。

マスタ移行と教育を発注範囲に含める

Excelにある商品名や価格をそのまま取り込むのではなく、重複、廃番、単位、税区分、旧価格、顧客別例外を整理してから移行します。移行対象、変換ルール、件数、照合方法、切り戻し方法を合意し、リハーサルを実施します。教育は全員に同じ操作説明をするだけでなく、営業、承認者、商品マスタ管理者、管理者ごとに必要な手順と権限を分けます。

稼働後のKPIと改善窓口を決める

稼働後は、見積作成時間、差戻し率、値引き承認時間、見積エラー率、粗利率、受注率、商品マスタ更新リードタイムを測定します。導入前のExcel集計や担当者へのヒアリングで基準値を取り、1か月後・3か月後・6か月後に比較すると効果を判断しやすくなります。AIによる商品候補提示や見積要約を導入する場合も、正解データ、監査ログ、人による承認を先に整え、誤提案をそのまま価格へ反映しない運用にします。

よくある質問(FAQ)

CPQシステムの発注に関するよくある質問

CPQの外注では、費用と製品の違いだけでなく、自社の業務やデータをどこまで準備するかについて質問が集まります。ここでは、発注前に特に確認したい内容を短く整理します。

CPQシステムはスクラッチ開発とSaaSのどちらがよいですか?

商品・価格ルールが標準化でき、既存CRMとの連携を重視する場合は、SaaSやクラウドCPQの標準機能を中心にする方法が適します。独自の原価計算や契約ロジックが競争力で、標準機能へ寄せる費用が高い場合はスクラッチも候補ですが、初期費用だけでなく保守・改修・引継ぎまで比較して決めます。

CPQシステムの発注費用はいくらかかりますか?

標準設定中心なら初期費用100万〜500万円、クラウドCPQの標準+軽微な拡張なら500万〜1,500万円、本格的なERP・在庫・請求連携なら1,500万〜5,000万円程度が予算取りの目安です。商品数、ルール、連携先、拠点数、移行件数で変わる推定レンジなので、ライセンス費、導入費、データ整備費、保守費を分けた見積を依頼してください。

RFPがない状態でも開発会社へ相談できますか?

相談できますが、現行の見積書、商品・価格表、代表的な商談、承認フロー、連携先を用意すると、提案の精度が上がります。RFPを自社だけで完成させるのが難しい場合は、最初の要件整理やPoCを準委任で依頼し、その成果をもとに開発を発注する方法があります。未確定事項を隠すより、未確定であることと決定予定日を示すことが重要です。

委託先は何社くらい比較すべきですか?

要件と比較条件をそろえたうえで、少なくとも複数社へ同じRFPを提示し、価格だけでなく体制、類似業務の経験、標準機能と拡張の考え方、保守範囲を比較します。会社数を増やしすぎると説明と評価に時間がかかるため、製品ベンダー、導入に強いSIer、既存基盤に詳しい会社など、役割の異なる候補を選ぶと比較の意味が出ます。

まとめ

CPQシステムの発注計画をまとめる担当者

CPQシステムの発注・外注・委託では、最初に見積業務の全体像を整理し、SaaS標準、クラウド拡張、スクラッチのどこが自社に合うかを判断します。そのうえで、実見積シナリオ、商品・価格マスタ、承認ルール、CRM・ERP連携、セキュリティ、受入条件をRFPへ記載します。

発注判断で優先すること

費用は、ライセンスと開発費を混ぜず、商品数・ルール数・連携先・拠点数・移行件数を前提にしたレンジで比較します。契約は、要件が固まった成果物を請負、整理や検証を準委任、改善をフェーズ分割で進めるなど、作業の性質に合わせます。委託先には、デモで実業務を再現してもらい、見積の内訳、除外事項、担当体制、保守、データ返却まで確認します。

最初に着手する三つの作業

まず、直近の見積書と例外価格を集め、代表的な商談を三つから五つのシナリオにします。次に、商品・価格・承認・連携・セキュリティの責任者を決め、RFPの前提を整理します。最後に、複数の候補会社へ同じ条件で提案を依頼し、初期費用、ランニング費用、社内工数、将来の拡張性を含む総額で比較します。この順序で進めれば、CPQを導入すること自体ではなく、見積の速さ、正確さ、粗利管理という成果につながる発注を目指せます。

▼全体ガイドの記事
・CPQシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。