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

CPQシステムの発注は、見積業務を洗い出し、要件と価格ルールを整理してから、提案と総額を比べる順に進めると、見積の速さと正確さ、粗利管理につながります。

全体像は、CPQシステム開発の完全ガイドにもまとめています。

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

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

CPQシステムを中央に置き、商品カタログ、価格表、承認、帳票を発注範囲として結んだ図解。
見積画面の外側にある業務要素も、初期の範囲整理に並べておけます。

CPQの発注では、製品を買うか開発を委託するかだけでなく、見積から受注・請求までのどこをシステム化するかを先に決めておく必要があります。範囲を先に決めないまま製品名や画面の要望から始めると、業務に合わないカスタマイズや、使われない高機能に予算を使うおそれがあります。

CPQシステムの役割と発注範囲

CPQの役割と発注範囲は、商品・価格の処理と、それに関連する業務に分けて考えます。

  • 基本機能:Configure、Price、Quoteに沿って、構成・価格・見積を扱う機能
  • 販売判定:機器、保守、オプションを組み合わせたときの販売可否と値引き承認
  • 発注範囲:商品カタログ、価格表、顧客別単価、数量割引、原価・粗利、承認、帳票、移行、教育まで含む範囲
  • 例外価格:許可条件と証跡で、見積ミスや粗利の毀損を防ぐ仕組み

Oracle Japanは、Oracle CPQを、適切な製品構成と正確な見積書作成を支援するクラウドアプリケーションだと説明しています(出典: Oracle Japan「Oracle CPQ」、2026年8月確認)。

発注範囲を見積作成だけに限定する場合の確認事項

見積作成と承認に絞って始めることも可能です。ただし、範囲を絞る場合でも、受注後の在庫、契約、請求、更新へ渡すデータは確認しておく必要があります。

見積情報を人が再入力する設計では、転記ミスと二重管理が残ります。そこで、将来のCRM・ERP連携に必要な項目や識別子を初期設計に含めておくと、再構築のリスクを抑えられます。

発注形態の選択肢(SaaS標準・クラウド拡張・スクラッチ)

発注形態の判断では、商材の複雑さ、営業人数、CRM・ERPとの連携の要否を基準にします。さらに、対象業務と社内体制も判断材料になります。

発注側は、実際の見積シナリオを使って標準機能を検証し、標準設定・拡張・自社開発の境界を決めます。

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

SaaSの標準機能を使う場合は、業務との適合条件と契約範囲を先に確かめておきます。

  • 適合条件:商品数や価格表が少なく、CRM連携が不要な場合
  • 導入支援:初期設定、権限、帳票、データ登録、教育まで依頼する範囲
  • 期待効果:業務を標準化できれば、期間と改修費を抑えられる見込み
  • 契約条件:最低利用数、追加ユーザー料金、API制限、データ出力、終了時の返却条件

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

商材が多く、価格が複数あり、値引き承認やCRM・ERP連携が必要な場合は、クラウドCPQに固有の設定や連携開発を加える形が現実的です。

製品を選ぶ際は、料金だけでなく、業務範囲と拡張の保守条件まで含めて確かめます。

  • ライセンス:Revenue Cloudの月額24,000円(税別)・ユーザー
  • 利用人数:30ユーザーなら月72万円、年864万円(税別)
  • 導入予算:ライセンス料に含めず、別に見積もる項目(支援、マスタ整備、帳票、連携、保守)
  • 導入事例:営業・見積管理を単一基盤にする活用例

Salesforce Japanは2025年7月にRevenue Cloudの日本提供開始を発表しました(出典: Salesforce Japan「企業の収益ライフサイクル管理を実現するRevenue Cloud」、2025年)。

発表では、パナソニックEWネットワークスが基幹刷新の一環で導入を進め、営業と見積管理を単一基盤にする方針を示しています。ただし、成果を保証する数字ではありません。

事例を参考にしながら、見積画面だけを対象にするか、受注・請求までを対象にするかを決めます。標準機能と拡張の境界は、RFPに記載します。

提案の時点で、バージョン更新の影響や、自社で設定変更できる範囲、ベンダーやSIerに依存する作業も確かめます。

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

独自の原価計算や複雑な構成ルールに加え、特殊な契約更新や社内業務との深い連携も競争力になるなら、スクラッチも候補になります。ただし、自由度と引き換えに、自社の保守責任は増えます。

商品マスタや税率変更への対応、テストは、自社で担うことになります。監査ログや障害対応、引継ぎも、同じく自社の役割です。初期費用だけでなく、5年程度の運用・改修・教育費を含めた総保有コストで比べる必要があります。

ポイント

発注形態は、商材の複雑さ、営業人数、連携の要否で選びます。迷うときは、実際の見積シナリオを標準機能で試してから決めると、境界を誤りにくくなります。

発注前のRFP・要件整理の進め方

RFPの要件領域を見積シナリオ、商品マスタと価格ルール、連携と非機能要件の3枚のカードで示す図解。
この3領域を同じ前提で示すと、各社の提案を並べて検討しやすくなります。

RFPは、各社の提案と見積を同じ条件で比べるための発注条件です。現行業務や範囲を具体化したうえで、データ、連携、非機能の条件も示します。さらに、納期と検収の条件も具体化します。

未確定の事項があっても、依頼は進められます。未確定の事項は明示したうえで、各社の見積前提をそろえます。

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

機能一覧より先に、代表的な見積シナリオを三つから五つ用意します。シナリオには、たとえば、標準構成と保守、オプションと数量割引、代理店価格と顧客別値引きなどを含めます。

  • 契約変更:サブスクリプションの途中変更を扱うケース
  • 値引き承認:上限超過時の承認の確認

各シナリオには、入力と期待価格、承認者、帳票、受注後の連携データを記載します。そうすると、デモで実装できるかどうかを確かめやすくなります。

商品マスタと価格ルールの責任者と管理情報

RFPでは、商品マスタと価格ルールの管理情報を、項目ごとに整理します。

  • 担当者:登録・承認する人と、改定の時期
  • 適用版:過去の見積に適用するバージョン
  • 管理対象:商品・オプション・BOM、価格表、通貨、税、原価、顧客ランク、数量割引、契約期間、更新条件
  • 工数要因:商品数に加え、禁止ルール、価格表、例外、法人・拠点・通貨の数
  • 記載内容:現在と1年後の件数、更新頻度、担当部門

整備を委託先任せにすると、現場ごとの呼び方や古い価格が混在し、稼働後に見積が合わなくなるおそれがあります。管理情報をRFPに示しておけば、初期構築費だけでなく、導入後の運用負担も提案に反映されます。

連携と非機能要件の整理

価格・原価・顧客情報を扱うため、連携の範囲と非機能要件を早い段階で整理します。

  • 接続先と方式:CRM、ERP、在庫、請求、電子契約、SFA、認証基盤
  • 連携条件:APIの有無と方向、リアルタイムか日次か、エラー時の再送、項目の責任部署
  • 自動化範囲:見積情報をCSVで渡すか、受注・請求まで自動化するか。この選択で設計とテストの中身が変わります
  • アクセス管理:SSO・MFA、最小権限、職務分掌
  • 運用管理:承認履歴、監査ログ、暗号化、バックアップ、復旧目標、データ保持・削除、委託先管理

AIを利用する場合は、データの範囲と人の承認を確かめておきます。IPAの「クラウドセキュリティの歩き方」などを参照しながら、提供会社と利用会社がそれぞれどこまでを担うかを整理します(出典: IPA、2025年)。

ポイント

RFPは、各社が同じ前提で見積を出せるように書きます。未確定の事項は隠さず示し、決定の予定日を添えると、提案の比較がしやすくなります。

契約形態とプロジェクト管理の決め方

CPQ導入プロジェクトを現状分析とRFP、要件定義とPoC、設計・設定・開発、テスト・移行・教育、稼働後支援の順に示す図解。
各段階の終了条件を定めると、継続や変更を判断する節目が見えます。

要件が未確定のまま全工程を請負にすると、変更のたびに追加費用や遅延が起きやすくなります。そこで、確定度と役割、成果物に応じて契約を分け、変更管理と検収の定め方も決めておきます。

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

要件定義書や画面・帳票、連携仕様が確定している範囲は、請負で成果物と金額を定めやすいです。あわせて、テスト、納品物、検収条件も確定しておく必要があります。

標準設定や指定帳票、決められたAPI連携は、完成条件を具体化しやすい対象です。一方で、使い勝手の検証や商品ルールの整理まで含めると、変更の協議が増えます。

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

業務整理や構成検討、PoCは、作業や専門知識の提供を重視する準委任が適します。標準機能の評価やアジャイル改善も、準委任が合う場面です。

要件を関係部門と詰める初期調査は準委任で行い、確定した開発から請負へ切り替える進め方もあります。その場合は、作業時間と体制、会議の進め方を明確にします。さらに、成果物や報告、責任の範囲も定めます。

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

工程を分けて各段階で継続を判断すると、前提のずれを抑えやすくなります。そこで、各段階の終了条件と判断者を決め、未解決課題と追加見積のルールも定めておきます。

  1. 現状分析とRFP
  2. 要件定義とPoC
  3. 設計・設定・開発
  4. テスト・移行・教育
  5. 稼働後支援

ポイント

確定した範囲は請負、整理や検証の段階は準委任と、契約を分けます。段階ごとの終了条件と追加見積のルールを決めると、変更の扱いが明確になります。

CPQシステムの費用相場と期間

ここで示すのは製品の定価ではなく、要件定義から導入までの予算の目安です。金額は、商品・価格ルールや基幹連携の範囲によって変わります。拠点や帳票、契約更新の範囲も金額に影響します。

見積は費用の項目ごとに分けて提示してもらうと、相場を比べやすくなります。費用の内訳には、ライセンスや設定・開発、データ整備が含まれます。さらに、移行や教育、保守なども入ります。

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

国内の公開見積は案件条件によって差が大きいため、ここに挙げるのは製品の定価ではなく、予算取りの目安です。

  • SaaS標準:商品数が少なくCRM連携がない場合、100万〜500万円、1〜3か月。
  • 標準CPQ拡張:標準機能に価格ルール、承認、帳票、CRM連携を加える場合、500万〜1,500万円、3〜6か月程度。
  • 本格導入:製造業やSI向けにBOM、原価・粗利、複数通貨、ERP・在庫・請求連携を行う場合、1,500万〜5,000万円、6〜12か月程度。
  • 多拠点・多法人:独自Q2Cやグローバル価格、税・契約管理を含む場合、5,000万円〜数億円、1〜3年規模になる可能性があります。
  • フルスクラッチ:3,000万円〜2億円超、12〜24か月程度が参考レンジです。

この金額は、CPQシステム リサーチノート(2026年8月)の推定です。NotebookLMリサーチによる営業・CRM業務システムの相場に、CPQ固有の作業を加味しています。

個別案件の確定価格ではありません。特にフルスクラッチは、独自UI、非機能要件、将来の改修によって大きく変わります。

各社の見積は、範囲、前提、除外項目、成果物をそろえたうえで評価します。

ライセンス費とランニングコストの分け方

クラウド料金は、ユーザー数やプラン、契約期間によって変わります。機能やサポートの内容でも差が出ます。そのため、発注の時点での製品名、機能、国内価格、契約条件を見積書で確かめておきます。

ライセンスを契約するときは、製品の名称変更や、プランごとの料金も確かめておきます。

  • Salesforce:Revenue CloudからAgentforce Revenue Managementへの名称変更の案内
  • Microsoft Dynamics 365 Sales:料金は3プランで案内

年払い・税別で、ユーザー当たりの月相当の価格は、Professionalが9,745円、Enterpriseが15,742円、Premiumが22,488円です(出典: Microsoft「Dynamics 365 Salesの価格」、2026年8月確認)。

営業基盤のライセンス料と、複雑なCPQの導入開発費は別に考えます。ランニング費には、ライセンスのほか、API、連携、帳票が含まれます。さらに、電子契約、保守、マスタ更新、問い合わせ、教育もこの中に入ります。

スクラッチや大規模なカスタマイズでは、保守予算は初期費の年10〜20%を目安にします。

見積の配分も、確認の材料になります。目安は、要件定義が10〜15%、設計が25〜35%、開発が30〜40%です。テストは15〜20%、移行・教育は5〜10%です(CPQシステム リサーチノート、2026年8月)。

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

金額を左右するのは、商品・オプション数とルールの複雑さです。加えて、連携先や拠点・法人・通貨の数も影響します。移行や帳票、非機能も、金額を押し上げる要因になります。

商品数が少なくても、顧客別の価格や代理店価格、例外承認が多ければ、設計の工数は増えます。反対に、商品が多くても標準カタログに整理できれば、標準設定で対応できる場合があります。

ポイント

費用は製品の定価ではなく、要件定義から導入までの予算の目安として捉えます。項目ごとに分けた見積を比べると、各社の金額差の理由を確かめやすくなります。

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

委託先は、製品ベンダーと、導入・連携・運用を担うSIerや開発会社に分けて考えます。製品の契約を結んだあとも、要件整理やマスタ移行は別に進める必要があります。

CPQ単体、CRMの拡張、類似商材や価格ルール、連携環境のそれぞれで、実績を確かめます。

実績よりも自社の業務との適合性

実際の見積シナリオでデモを行ってもらい、構成禁止や顧客別価格、数量割引の扱いを質問します。承認や過去見積、ERP連携の扱いも、同じ場で確かめます。

画面だけでなくデータモデルや権限、監査ログ、運用手順まで説明できるかで、会社を評価します。

見積書の同条件での内訳比較

費用の抜けや条件の差を見つけるため、内訳と数年分の支払い条件を同じ軸でそろえます。

比較表には、ライセンスや要件定義、設計、標準設定を含めます。追加開発やAPI連携、帳票も同じ表に入れます。データクレンジングや移行、テストも比較の対象になります。教育、プロジェクト管理、保守、交通費も、同じ軸で並べます。

  • 一式見積:時間、担当、成果物、件数、除外事項の確認
  • 総額:3〜5年分の値上げ、追加ユーザー、API、保守、更新、教育と社内負担を含めた金額
  • 条件差:前提が違えば再見積もりを行い、機能・体制・除外のどこに差があるかを切り分ける

マスタ整備、受入テスト、教育、稼働後支援が見積から除外されていると、後から追加費用が発生する可能性があります。

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

委託先には、標準と個別開発の境界、マスタ更新、価格版管理について聞きます。さらに、過去見積の再現やAPI障害時の監視、設計書、保守時間、データ返却も確かめます。

発注側は、類似案件の体制や担当者の経験、再委託、セキュリティ対応、障害時の連絡経路も確かめます。

ポイント

委託先は、製品の提供と導入・連携・運用の担当を分けて考えます。見積は同じ条件の内訳で比べ、除外事項と稼働後の支援まで含めて判断します。

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

CPQの価値が出るのは、営業、承認者、経理、受注部門がつながったときです。そのため、契約の時点で受入テストや移行リハーサルを決めておきます。教育、窓口、マスタ更新の決め方も、あわせて定めます。

実データに近いケースでの受入テスト

本番に近いケースを使い、例外処理と部門ごとの確認内容を確かめます。

  • テストケース:正常系、販売不可の組み合わせ、期限切れ価格、在庫不足、値引き上限超過、承認者不在、途中解約、契約更新、税・通貨の違い
  • 営業・商品企画:営業は見積作成の時間と操作性、商品企画はマスタ更新
  • 経理・情報システム:経理は価格と請求データの一致、情報システムは権限・ログ・障害復旧

検収の条件は、画面の表示だけでなく、各シナリオの期待結果と証跡で定めます。

マスタ移行と教育の発注範囲

Excelにある商品名や価格は、そのまま取り込むと誤りが残るおそれがあります。重複や廃番、単位、税区分、旧価格、顧客別例外を整理してから移行します。移行の対象、変換ルール、件数、照合方法、切り戻しを合意したうえで、リハーサルします。

教育は、営業、承認者、マスタ管理者、管理者ごとに、必要な手順と権限を分けて行います。

稼働後のKPIと改善窓口

稼働後は、見積時間、差戻し率、承認時間、エラー率、粗利率、受注率、マスタ更新期間を測ります。

基準値は、導入前のExcel集計や担当者への聞き取りで取っておき、1・3・6か月後と比べます。

AIで候補の提示や要約を行う場合は、正解データとログ、人の承認を整えておきます。誤った提案を価格に直接反映させない運用にします。

よくある質問(FAQ)

費用や製品のほかに、自社の業務とデータをどこまで準備するかも、発注時に確かめておく事項です。

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

商品と価格を標準化でき、CRM連携を重視するなら、SaaSやクラウドCPQが適します。一方で、独自の原価計算や契約が競争力になるなら、保守・改修・引継ぎも含めてスクラッチと比べます。

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

標準設定中心は100万〜500万円、標準機能に軽微な拡張を加えるクラウドCPQは500万〜1,500万円が目安です。

ERP・在庫・請求連携を含む本格導入は1,500万〜5,000万円程度が目安です。

商品数やルール、連携先、拠点、移行件数によって変わる推定のレンジです。見積は、ライセンス、導入、データ整備、保守を分けて依頼します。

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

相談はできます。見積書や商品・価格表、商談例、承認フロー、連携先の情報があれば、提案の精度は上がります。

RFPの作成が難しい場合は、要件整理やPoCを準委任で依頼し、その成果をもとに開発を発注する進め方もあります。その際は、未確定の事項と決定の予定日を示します。

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

少なくとも複数社に同じRFPを示し、価格や体制、類似業務、標準機能、拡張、保守を比べます。

製品ベンダーやSIer、既存の基盤に詳しい会社など、役割の違う候補を選びます。ただし、会社数を増やしすぎると、説明と評価に時間がかかります。

まとめ

発注では、まず見積業務を整理し、SaaS標準、クラウド拡張、スクラッチから適した形を選びます。そのうえで、シナリオやマスタ、承認、連携、セキュリティ、検収条件をRFPに記載します。

発注判断で優先すること

ライセンスと開発費は分けて捉え、件数や連携先を前提にしたうえで総額を比べます。契約は、確定した成果物なら請負、整理や検証なら準委任など、作業に合わせて選びます。

実業務のデモを通じて委託先を見極め、見積内訳や除外事項、体制、保守、データ返却を確かめます。

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

発注の準備では、社内の材料をそろえ、要件の責任者を決めたうえで、同じ条件で提案を募ります。

  1. 直近の見積書と例外価格を集め、商談シナリオを三つから五つ作る。
  2. 商品・価格・承認・連携・セキュリティの責任者を決め、RFPの前提を整理する。
  3. 候補各社へ同条件で依頼し、初期費用、運用費、社内工数、拡張性を含めて比べる。

この順序で進めれば、見積の速さと正確さ、粗利管理につながる発注に近づけます。

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

会社紹介

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

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

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

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

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

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