Salesforce 外注 判断基準｜内製との分岐点と費用構造を解説

Salesforce の導入・カスタマイズを外注すべきか、それとも内製で進めるべきか。この判断は営業企画部長・情報システム室長・DX推進担当役員にとって、避けて通れない意思決定です。しかも社内に Salesforce を体系的に理解する認定資格保持者がいない状況では、パートナーから届いた 500 万円規模の見積が妥当なのか、そもそも自社の要件は外注に向いているのか、判断軸そのものを持てないまま稟議のタイミングを迎えているケースが少なくありません。

Salesforce は SaaS プラットフォームの中でも「標準機能」「宣言的カスタマイズ（Flow・プロセスビルダー）」「プログラム開発（Apex・LWC）」「外部システム統合」の各レイヤーで必要とされる技術スキルが大きく異なります。この特性を理解しないまま「外注 vs 内製」を単純な二項対立で議論すると、予算超過・仕様凍結・パートナー依存の三重リスクに直面しやすくなります。

一方で、判断軸さえ用意できれば、外注・内製・ハイブリッドのどれが自社に最適かを社内稟議で説明可能な形に落とし込めます。重要なのは「どの業務範囲を外に出し、どの範囲を社内に残すか」を Salesforce 特有の技術構造に沿って分解することです。

本記事では、Salesforce 外注の判断基準として「業務範囲・継続性・社内スキル成熟度」の 3 軸フレームワークを提示し、7 領域の業務範囲別に外注適正を評価するマトリクスを解説します。さらに費用構造の内訳と稟議書に載りにくい隠れコスト、パートナー選定で使える 8 つの質問、失敗の典型パターンと回避策、そして社内稟議通過のための意思決定チェックリストまで、翌日から実務で使える判断根拠を整理します。

Salesforce 導入・カスタマイズの外注で発注者が直面する三重リスク

Salesforce の外注を検討する発注者が最初に整理すべきなのは、「なぜ判断軸が必要なのか」という問いです。判断軸を持たないまま外注を進めると、多くの企業が同じ三重リスクに直面します。

リスク1: 予算超過（追加開発が積み上がる構造）

Salesforce の外注が予算超過を招きやすいのは、標準機能で実現できる範囲と、Apex・LWC などのプログラム開発が必要な範囲の境界線が曖昧なまま発注してしまうケースが多いためです。要件定義段階では「標準機能でできる」と説明されていた項目が、詳細設計の段階で「Apex トリガーが必要」と判明し、追加見積が積み上がっていきます。

初期見積 300 万円のプロジェクトが、途中の仕様変更・追加開発の積み上げによって 600 万円を超えるといった事例は珍しくありません。ガバナーリミット（Salesforce プラットフォームの実行制限）に抵触することが後から判明し、設計を作り直すケースもあります。

リスク2: 仕様凍結（要件が固まらず開発が止まる）

Salesforce は「ノーコードでカスタマイズできる」と紹介されることが多い一方、実際の業務要件を Salesforce のデータモデル（オブジェクト・項目・レコードタイプ）に落とし込むには、業務知識と Salesforce 特有の思想（宣言的開発の優先順位・共有ルール・組織のスコープ）の両方が必要です。

発注者側に Salesforce の思想を理解する人材がいないと、要件が「営業部の希望をそのまま羅列したもの」になりがちで、パートナー側からの技術的制約説明を受けて要件が二転三転します。結果として要件定義フェーズが長引き、開発着手前に予算とスケジュールが破綻する「仕様凍結」状態に陥ります。

リスク3: パートナー依存（外注先を切り替えられなくなるロックイン）

一社のパートナーに Salesforce の全設定・全カスタム開発を任せてしまうと、そのパートナーしか自社の Salesforce 環境を理解していない状態になります。ドキュメントが整備されていない、Apex コードにコメントがない、命名規則がパートナー独自の癖に依存している、といった状態は、後から別のパートナーへ引き継ぐコストを大きく引き上げます。

対応スピードや保守料金に不満が生じても、切り替えると「引き継ぎ費用だけで数百万円かかる」という状況になり、実質的にロックインされます。この構造は Salesforce ライセンスコスト自体とは別のリスクとして、稟議の段階で認識しておく必要があります。

外注か内製かを判断する 3 つの決定軸

三重リスクを回避するには、単に「外注する／しない」を二択で決めるのではなく、複数の軸で自社の状況を分解する必要があります。ここでは「業務範囲」「継続性」「社内スキル成熟度」の 3 軸を提示します。DX 全般における内製・外注の判断軸についてはDXは内製か外注かも併せて確認すると、Salesforce 特有の技術構造と汎用フレームワークの位置付けが整理できます。

業務範囲軸（5 レイヤーで分解する）

Salesforce の業務範囲は技術的な特性から 5 レイヤーに分解できます。それぞれ求められるスキルと保守負担が大きく異なります。

• 標準機能レイヤー: レポート・ダッシュボード作成、カスタム項目追加、レコードタイプ設定など、GUI 操作のみで完結する範囲
• 宣言的カスタマイズレイヤー: Flow・プロセスビルダー・承認プロセスなど、ノーコードで自動化ロジックを実装する範囲
• プログラム開発レイヤー: Apex トリガー・Apex クラス・Batch Apex など、Java 系言語で開発する範囲
• UI 開発レイヤー: Lightning Web Components（LWC）・Aura コンポーネントによるカスタム画面開発
• 統合開発レイヤー: 外部システム（基幹システム・MA ツール・BI ツール）との API 連携、REST/SOAP API 実装、MuleSoft などの iPaaS 活用

このレイヤーごとに「自社で対応できるか」を評価することで、外注すべき範囲と内製で運用できる範囲が明確になります。

継続性軸（一時プロジェクト vs 継続改善）

Salesforce の運用は、一度導入して終わるものではありません。「初期導入プロジェクトのみ外注」なのか、「継続的な改善・機能追加を含めて外注する」のかで、選ぶべき契約形態・パートナーが変わります。

一時プロジェクトであれば SIer との請負契約が適していますが、継続改善を前提とするなら準委任契約による月次リテイナーが現実的です。継続改善を外注する場合、月間 20〜60 時間の稼働枠を確保する形式が一般的で、自社内に「発注する側」の窓口担当を専任で置けるかが成否を分けます。

社内スキル成熟度軸（認定資格・兼任度・退職リスク）

社内に Salesforce を扱える人材がどの程度いるかは、外注範囲を決める最大の変数です。以下の 3 つの観点で棚卸しをしてください。

• 認定資格保持者の人数と種別: 管理者資格（Administrator）／開発者資格（Platform Developer I/II）／アーキテクト資格（Application/System Architect）のどれを何名保有しているか
• 業務兼任度: Salesforce 対応者は他業務との兼任か専任か。兼任の場合、Salesforce に割ける時間比率はどの程度か
• 退職リスク: Salesforce を扱える人材が 1 名のみの場合、その人材が退職した際の業務停止リスクはどう吸収するか

社内スキル成熟度が低い状態で全業務範囲を内製化すると属人化リスクが高まり、逆に高い成熟度があるのに全てを外注すると社内学習機会を失います。

業務範囲別・Salesforce 外注適正マトリクス

上記の 3 軸を使って業務範囲を分解すると、次のマトリクスで外注適正を判定できます。Salesforce 特有の技術制約・ガバナーリミット・保守負担を踏まえた判定です。

このマトリクスの活用ポイントは「〇×△を機械的に当てはめる」ことではなく、自社のスキル成熟度に応じて「△の範囲を内製に寄せるか外注に寄せるか」を意思決定することです。標準機能設定を内製化できないなら、そもそも Salesforce の運用体制自体を見直す必要があります。

Salesforce 外注の費用構造と見落としがちな隠れコスト

外注費用の妥当性を判断するには、見積書に並ぶ表面的な項目だけでなく、稟議書に載りにくい隠れコストまで把握する必要があります。外注コストを一括発注ではなくフェーズ分割で抑える汎用的な考え方については外注コストのスコープ分割にまとめていますので、Salesforce プロジェクトのフェーズ設計にも応用できます。

費用の 5 項目内訳と規模別相場

Salesforce 外注の見積は、一般的に以下の 5 項目で構成されます。各項目の相場感を押さえておくと、パートナーから届く見積の妥当性を判断できます。

規模別の総額相場は、小規模（Sales Cloud の標準的な導入）で 150〜300 万円、中規模（Flow・Apex を含む業務改善）で 300〜600 万円、大規模（LWC・外部システム統合を含む本格開発）で 600 万円以上が目安です。ただし、これは初期導入の相場であり、追加開発・保守運用は別途発生します。費用構造の詳細は Salesforce パートナー各社が公開している事例（例: ナインテック「Salesforce導入の費用相場」）も参考になります。

見落としがちな隠れコスト 4 種

見積書の 5 項目とは別に、稟議書には載りにくい隠れコストが 4 種類存在します。これらを事前に試算しておくと、後から「想定外の費用」として発覚するリスクを防げます。

• 教育・移管コスト: パートナーが構築した Salesforce 環境を社内で運用するには、管理者研修（1 名あたり 20〜40 万円）と業務マニュアル整備（外注する場合 30〜80 万円）が必要です。定着支援フェーズに含めているつもりでも、実際には別費用として発生することが多い項目です
• パートナー依存によるロックインコスト: 1 社のパートナーに全業務を任せた場合、切り替え時の引き継ぎ費用（コード解析・仕様書再作成・データ引き継ぎ）で 100〜300 万円が発生することがあります。契約時にドキュメント整備条件・命名規則の標準化条件を明記しておくと、このコストを抑制できます
• 認定資格保持者の退職リスクコスト: 社内の唯一の管理者が退職した場合、後任育成に半年〜1 年、外部から採用する場合の年収は 700〜1,200 万円が相場です。属人化リスクは金額換算するとかなり大きなインパクトになります
• ガバナーリミット対応コスト: Salesforce のプラットフォーム制限に抵触した際の再設計費用は 50〜200 万円規模になります。初期設計時にスケーラビリティを考慮しなかった場合に発生しやすく、パートナーの技術力によって発生確率が変わります

これらの隠れコストを表面費用の 20〜30% の予備費として稟議に組み込んでおくと、想定外の追加見積で慌てる状況を防げます。

ハイブリッドモデルという第三の選択肢（内製と外注の分担ライン）

「外注 vs 内製」の二項対立では、多くの中堅企業にとって現実的な選択肢が見えなくなります。実務では「業務範囲を分担する」ハイブリッドモデルが最適解になるケースが多いのが実情です。

内製で担う範囲・外注で担う範囲の分担ライン

分担ラインの引き方は、社内スキル成熟度によって次のように整理できます。

• 成熟度が低い段階（認定資格保持者 0〜1 名・専任なし）: 標準機能の項目追加・レポート作成のみを内製し、Flow・Apex・LWC・統合はすべて外注する。初期は外注比率 80%、社内学習を進めながら段階的に内製比率を上げる
• 成熟度が中程度（認定管理者資格保持者 1〜2 名・専任 or 兼任 50%以上）: 標準機能設定と Flow による自動化までを内製で運用し、Apex・LWC・統合開発を外注する。外注比率 50% 前後が現実的
• 成熟度が高い段階（管理者・開発者資格保持者複数名・専任チーム）: 定常的な機能追加は内製化し、大規模な統合開発・アーキテクチャ設計のみ外注する。外注比率 20〜30%

分担ラインを決める際は、「社内で対応できる範囲」だけでなく「社内で対応すべき範囲」を業務変更頻度で判定する視点も重要です。営業部からの項目追加要望のように週次で発生する変更は内製、四半期ごとに発生する大規模改修は外注、と頻度で切り分けると運用が安定します。

社内側の運用体制設計

ハイブリッドモデルを機能させるには、社内側に「Salesforce 管理者」を配置する必要があります。専任 1 名を配置できる企業は限られるため、多くの企業では兼任管理者を置くことになりますが、その場合も稼働時間の 30〜50% を Salesforce に振り向けられる体制が最低ラインです。

管理者の役割は「外注パートナーの技術判断を評価できる程度の Salesforce 知識」を持ち、要件を業務言語からデータモデル言語に翻訳することです。この役割を欠くと、パートナーとの打ち合わせが技術的に噛み合わず、要件が二転三転する状態に戻ってしまいます。

外注パートナーを見極める 8 つの質問（発注前の面談で確認すべき事項）

パートナー選定の局面で、面談時に確認すべき 8 つの質問と、それぞれの回答に対する評価軸を示します。これらの質問は、toBe マーケティングの選び方ガイドなどの選定基準を参考にしながら、発注者視点で「回答をどう評価するか」まで踏み込んだものです。契約後の初回ミーティングで押さえるべきチェック項目は外注エンジニアとの初回ミーティング10項目にまとめており、選定後の立ち上げ設計にも活用できます。

質問1: Salesforce 認定資格保持者は何名いますか？（資格の種別も含めて教えてください）

評価軸: 開発を含む案件なら「Platform Developer I 資格保持者が 3 名以上」が最低ライン。管理者資格のみの企業は宣言的カスタマイズには対応できても、Apex 開発の品質は担保できません。アーキテクト資格保持者が在籍していれば、大規模設計にも対応可能と判断できます。

質問2: 弊社と類似規模・類似業種の実装事例を、名称を伏せてでも構いませんので教えてください

評価軸: 同業種の事例が最低 3 件、類似規模（従業員数・年商）の事例が最低 2 件あるか。事例の具体度（データモデル・自動化ロジック・移行方式まで語れるか）で技術理解の深さも見えます。

質問3: 要件定義フェーズはどのように進めますか？現場ヒアリングの回数・アウトプット物を教えてください

評価軸: 現場担当者ヒアリングが最低 3 回以上あるか、要件整理のアウトプットがフィット&ギャップ分析表・業務フロー図・データモデル図として提示されるか。要件定義を「打ち合わせ議事録」で済ませる企業は要件肥大リスクが高くなります。

質問4: 保守運用フェーズの SLA（Service Level Agreement）はどうなっていますか？

評価軸: 障害対応の初動時間（平日 2 時間以内が目安）、月次改善会議の実施頻度、稼働時間の柔軟性（月次リテイナー時間の繰越可否）を確認。SLA が曖昧なパートナーは、稼働開始後に対応スピードのトラブルが発生しやすくなります。

質問5: ドキュメント整備の粒度と納品形式を教えてください

評価軸: データモデル定義書・自動化フロー一覧・Apex コード仕様書（少なくとも公開メソッドの説明）・共有ルール一覧が納品物に含まれるか。ドキュメント整備を「別途費用」とするパートナーは、後々のロックインリスクが高いと判断できます。

質問6: 追加改修時の見積は、どのような単価・工数積算で提示されますか？

評価軸: 開発工数の単価（1 人日あたりの費用）が明示されているか、機能単位ではなく工数単位で見積を分解できるか。パッケージ料金のみで単価を開示しないパートナーは、追加改修時の妥当性検証が困難になります。

質問7: テスト工程の品質保証はどのように行いますか？（自動テスト・受け入れテスト・回帰テスト）

評価軸: Apex コードカバレッジ 75% 以上を担保するか（Salesforce の本番デプロイ要件でもある）、受け入れテストのシナリオ提示があるか、リリース後の回帰テストの実施範囲が明示されているか。テスト工程を軽視するパートナーは本番障害を招きやすいです。

質問8: 納品後の内製移管サポートは可能ですか？可能な場合の条件を教えてください

評価軸: 移管トレーニング（管理者向け・開発者向け）のカリキュラム・費用が明示されているか、コード解説・設計思想の引き継ぎがサービス範囲に含まれるか。「基本的に移管しない」姿勢のパートナーはロックイン意図があると解釈できるため、契約時に慎重な確認が必要です。

Salesforce 外注失敗の典型パターン 5 選とその回避策

Salesforce 外注が失敗するパターンには、発注者側の準備不足に起因するものが多く含まれます。DX プロジェクト全般で観測される失敗の共通構造はDX内製・外注の失敗パターン6選で整理しており、Salesforce 特有のパターンと重ねて読むと、自社が該当するリスクを立体的に把握できます。以下では Salesforce 外注に特有の 5 パターンと回避策を整理します。

失敗パターン1: 目的曖昧のまま導入着手

「営業部から要望があった」「他社が使っている」といった漠然とした動機で導入を進めると、要件が発散して費用が膨らみます。回避策として、導入の目的（例: 商談進捗の可視化・案件確度予測の精緻化・営業活動時間の削減）を KGI・KPI に落とし込み、「Salesforce 導入で解決する課題」と「Salesforce では解決しない課題」を明文化してから RFP を作成することです。

失敗パターン2: 現場不参画による要件肥大

要件定義に営業部・カスタマーサクセス部などの現場担当者が参画せず、情報システム部門とパートナーだけで進めると、現場が使わないシステムが完成します。逆に現場の希望を全て取り込むと要件が肥大化します。回避策は、要件定義フェーズに現場代表（部門ごとに 1〜2 名）を必ずアサインし、要件の優先度を「業務ブロッカー／効率化／将来的な希望」の 3 段階で分類することです。

失敗パターン3: 丸投げによる仕様凍結

「Salesforce のプロだから任せられる」とパートナーに全て委ねると、業務要件が Salesforce の技術制約に合わないことが判明した際に議論が停止し、仕様凍結状態に陥ります。回避策は、社内側に業務要件を Salesforce のデータモデルに翻訳できる橋渡し役（内製ケイパビリティ）を配置することです。管理者資格保持者を 1 名は育成しておくべきです。

失敗パターン4: 単一パートナー依存のロックイン

契約時にドキュメント整備・命名規則の標準化条件を盛り込まなかった結果、後から別パートナーに切り替えられなくなるケースです。回避策は、契約書に「ドキュメント整備の粒度」「Apex コードのコメント基準」「命名規則の統一（Salesforce ベストプラクティスに準拠）」を明記し、納品物として要求することです。

失敗パターン5: 導入後の運用体制不備

導入プロジェクトを完遂した後、社内に運用管理者を配置しないまま「必要に応じてパートナーに依頼する」体制で運用を続けると、日常的な項目追加やレポート作成に毎回外注費用が発生し、結局現場からの改善要望が積み残されます。回避策は、導入プロジェクトと並行して社内管理者の育成計画を策定し、プロジェクト完了時点で管理者が稼働している状態を作ることです。

意思決定チェックリスト（社内稟議通過のための判断根拠テンプレート）

ここまでの内容を、社内稟議で使える意思決定チェックリストとしてまとめます。以下の 6 項目を埋めることで、「Salesforce 外注の判断根拠」が稟議書に転記できる形になります。

チェック項目1: 業務範囲の分解結果

Salesforce で実現したい業務要件を、5 レイヤー（標準機能／宣言的カスタマイズ／プログラム開発／UI 開発／統合開発）に分解し、レイヤーごとに要件を書き出す。この作業だけで「本当に Apex 開発が必要なのか、Flow で代替できないのか」の再検討ができます。

チェック項目2: 社内スキル成熟度の棚卸し結果

社内の Salesforce 認定資格保持者数・種別、業務兼任度、退職リスクを一覧化する。数値化して稟議書に載せることで、「なぜ外注が必要か」の客観的根拠になります。

チェック項目3: 外注適正マトリクスの当てはめ結果

業務範囲別・外注適正マトリクスの各項目に、自社の状況を当てはめる。「〇：外注」「△：社内スキル次第」「×：内製推奨」の判定結果を業務範囲ごとに記録し、外注範囲の総量を確定します。

チェック項目4: 費用試算（表面費用 + 隠れコスト）

5 項目の表面費用に加えて、隠れコスト 4 種（教育・移管・ロックイン・退職リスク・ガバナーリミット対応）を試算し、予備費として表面費用の 20〜30% を上乗せする。稟議で「予算超過リスク」を先に開示することで、後から追加予算を求める状況を回避できます。

チェック項目5: 選定パートナーの 8 質問回答スコア

複数パートナーに対して 8 質問を提示し、回答内容を評価軸に沿ってスコア化する。1 質問あたり 5 段階評価で、40 点満点中 30 点以上を通過ラインに設定するのが目安です。スコアシートを稟議書に添付することで、「なぜこのパートナーを選んだか」の説明責任を果たせます。

チェック項目6: ハイブリッド運用時の内製側体制設計

外注範囲を確定した上で、社内側に配置する管理者の人数・稼働時間・育成計画を明文化する。専任 1 名を配置できない場合は、兼任 2 名で稼働時間の合計を確保する体制を稟議に盛り込みます。運用開始 6 ヶ月後・1 年後の内製化目標も併せて設定すると、パートナー依存の抑制効果を稟議で説明できます。

このチェックリストを埋めていく過程で、「自社に本当に必要なのは全業務範囲の外注ではなく、Apex 開発と統合開発だけの外注だった」といった気づきが得られるはずです。判断軸を持たないまま稟議を通そうとするのではなく、業務範囲・継続性・社内スキル成熟度の 3 軸で自社の状況を分解した上で、外注・内製・ハイブリッドのどれが最適かを説明できる状態を作ることが、Salesforce 外注を成功させる最初のステップになります。