Salesforceの項目を1つ追加するだけで、ベンダーへの見積依頼と社内の稟議に2週間かかる。月額の保守費用は払い続けているのに、実際に依頼している作業は月に数件。役員からは「この費用はいつまで続くのか」と聞かれる。保守契約の更新や担当者の異動を前に、こうした状態で「そろそろ内製化を考えるべきか」と調べ始めた営業マネージャーの方は多いはずです。
同じ悩み方をしている会社は少なくありません。ガートナージャパンが日本国内で2025年に実施した調査では、ITの内製化に踏み切る目的として54.5％の企業が「コスト削減」を挙げました。これに対して同社は、内製化を単なるコスト削減策と位置づけず、「ビジネス要求を反映するまでのリードタイム短縮」と「知見の社内蓄積」を評価軸にすべきだと指摘しています。
出典：ガートナージャパン
費用を起点に検討が始まること自体は自然ですが、目的をコスト削減だけに置くと、内製化は途中でつまずきやすくなります。
そして「全部自社でやるか、これまでどおり全部任せるか」の二択で考えている限り、答えは出ません。全部引き取るには人が足りず、全部任せ続けるには費用の説明がつかないからです。Salesforceの内製化とは、ベンダーとの契約を切ることではなく、自社が判断できる範囲を業務単位で増やしていくことです。
前提として、これまでベンダーに頼ってきたこと自体は失敗ではありません。導入の時期に外部の力で早く立ち上げるのは合理的な進め方です。本来は導入プロジェクトの段階で自社とベンダーの線引きまで決めておけると理想的でしたが、多くの企業はそこまで手が回らないまま稼働を迎えます。局面が変わったいま、線を引き直せばよいだけです。
この記事では、業務難易度別の分担線の引き方、ベンダーロックインの避け方、管理者を1人に依存させない体制のつくり方、稼働後からでも間に合う段階的な移行計画の順で解説します。読み終えたとき、自社が今週から動ける順序が描けている状態を目指します。
内製化の検討は、「やるか、やらないか」ではなく、「どの業務を自社に引き取り、どれを外部に残すか」という分担線から決めます。この章では、内製化の定義を整理したうえで、業務を難易度で並べた分担表と、線を引くための2つの軸、引き取ってよい業務の判断条件を示します。
Salesforceの内製化とは、ベンダー契約の解約ではありません。自社で判断・変更できる業務を段階的に増やし、外部への発注範囲を業務単位で絞っていくことです。
最大のメリットは、コスト削減よりも改善スピードの回復です。現場から「この項目を足してほしい」という声が出てから、ベンダーへの依頼・見積・稟議・実装を経て反映されるまで、2〜4週間かかっている企業は珍しくありません。自社で変更できる業務なら、これが当日〜翌日で完結します。あわせて、「なぜこの設定なのか」という知見が自社に蓄積されることも大きな利点です。
一方でデメリットもあります。担い手の確保と教育に時間がかかること、そして担当を置いても1人に集中すれば属人化することです。この2つには、のちほど体制の章で答えます。
費用面は「減る」というより「置き換わる」が実態です。外注費は減りますが、社内の人件費と教育の工数が増えるため、差し引きの削減額は思ったほど大きくない場合があります。
（内製化で減る費用と発注範囲の整理は、支援サービスの選び方の記事で扱っています。導入時からの費用構造の全体像はSalesforce導入の記事をご覧ください）
だからこそ経営層には、「内製化すればすぐ安くなる」ではなく、「どの範囲を、いつまでに、どういう条件で引き取るか」という形で伝えることをおすすめします。序文で触れたガートナーの指摘（評価軸はコストではなくスピードと知見の蓄積）は、この期待値の調整にそのまま使えます。
なお、外部依存は個社の悩みではなく、日本企業に共通する構造でもあります。
総務省の調査によると、システム開発を「ほぼすべて外部ベンダーに委託している」企業は日本では25.0％にのぼり、米国の2.6％、ドイツ・中国の各1.9％と大きな差があります。
（2026年1〜2月調査。従業員10名以上の企業の管理職以上が回答、日本515社・米国309社・ドイツ309社・中国309社。）出典：総務省「令和8年版 情報通信白書 データ集」図表43
Salesforceの運用に限った調査ではありませんが、「外部に任せたまま自社に知見が残らない」構造は放置して自然に解消されるものではない、という前提に立つ必要があります。
日常の管理業務は、おおむね次の5つのレベルに分けられます。同じ「設定変更」でも、難易度と失敗したときの影響範囲は大きく異なります。
| レベル | 業務の例 | 発生頻度の目安 | 失敗したときの影響範囲 |
|---|---|---|---|
| 1. ユーザー管理 | 入退社・異動にともなうアカウントの追加・停止、権限の変更 | 月数回 | 狭い（対象ユーザーに限られる） |
| 2. レポート・ダッシュボード作成 | 会議用レポートの作成、集計軸の変更 | 週次〜月次 | 狭い（見え方が変わるだけで、データは壊れない） |
| 3. 項目追加・入力規則 | 入力欄の追加、選択肢の変更、必須項目の設定 | 月1回程度 | 中程度（入力画面と既存データに影響する） |
| 4. 自動化フローの作成 | 承認プロセスや通知の自動化 | 四半期に1回程度 | 広い（誤ると業務の流れが止まる） |
| 5. 他システム連携・独自開発 | API連携の改修、独自開発（Apex） | 年1回程度 | 最も広い（営業全体・他部門に及ぶ） |
※発生頻度と影響範囲は、私たちが支援の現場で見てきた企業での目安です。本記事で示す工数や期間の数値も同様に、経験に基づく目安・仮説であり、業界平均や統計値ではありません。
レベル1〜2は、頻度が高い一方で失敗しても影響が閉じており、手順化すれば引き取りやすい業務です。
反対に、レベル5の他システム連携や独自開発は専門技術が必要で、失敗すると営業全体が止まりかねないため、多くの企業で外部に残す業務になります。
レベル4の自動化フローをどこまで自社で作るかは、現場の入力運用と切り離せない論点です。
（入力が定着しない場合の対処はこちら）
この表の目的は、「難しいこと」と「面倒なだけのこと」の区別がつくようになることです。ベンダー任せの期間が長いと、この区別の体感がないまま「全部難しそうだ」と感じてしまいます。
ただし、分担線は技術の難易度だけでは引けません。もう1つ、「自社の営業を知らないとできない業務かどうか」という軸を足すと、引き取るべき業務が浮かび上がります。
| 自社の業務知識が要る | 業務知識はあまり要らない | |
|---|---|---|
| 技術的には易しい | 内製化の本命（レポートの集計軸、項目の並び、入力ルールの調整） | 手順化して引き取れる（ユーザー管理） |
| 技術的に難しい | 要件は自社で決め、実装は外部（複雑な自動化フロー） | 外部に残す本命（API連携、独自開発） |
注目してほしいのは、「技術的には易しいが、自社の業務知識が要る」という象限です。
レポートの集計軸や項目の並び、入力ルールの調整といった業務は、操作自体は管理画面で完結しますが、「何が正しいか」は自社の営業を知らないと決められません。ここが内製化の本命です。
たとえば「商談フェーズの定義を変えたい」という変更は、設定作業そのものは10分程度でも、どう定義するかは営業会議でしか決められません。ベンダーには判断できない業務であり、主導権はもともと自社にあります。
逆に言えば、こうした業務を外部に頼むたびに、営業の意図をベンダーに説明して伝えるコストを毎回払っていることになります。技術の壁ではなく伝達の壁に時間と費用を払っているなら、そこから引き取るのが合理的です。
自社に引き取ってよい業務の条件は、次の3つです。
反対に、外部に残す業務の条件は次の3つです。
重要なのは、どれか1つの条件だけで決めないことです。たとえば「頻度が高いから」という理由だけで自動化フローまで引き取ると、影響範囲の広さに体制が追いつきません。
頻度・影響範囲・必要な知識の3つをセットで見てください。
専任の管理者を置けない会社でも、範囲を絞れば兼務で回ります。レベル1〜2に絞った場合、必要な工数は週2〜3時間程度に収まることが多い、というのが私たちの支援経験からの実感です。（担当者の習熟度や依頼の量によって変わります）「全部は無理」は事実ですが、「うちには無理」かどうかは範囲の絞り方しだいで変わります。
ここまでで線は引けました。ただし、線を引いただけでは移行は始まりません。
外部に残す業務が「誰も触れないブラックボックス」になっていれば線をあとから動かせず、引き取る業務も、受け皿となる体制がなければ持ち続けられないからです。
次の2つの章で、この両側の条件を整えます。
まず、外部に残す側の条件です。残した業務を「あとからでも引き取れる状態」に保てるかどうかは、ベンダーロックインへの向き合い方で決まります。
ベンダーロックインと聞くと「契約を切りにくいこと」を思い浮かべる方が多いのですが、契約は更新のタイミングで見直せます。本当に避けるべきは、設定の意図が失われ、誰も触れなくなった状態です。この状態は、契約を切っても残ります。
「この入力規則はなぜあるのか」「この項目は消してよいのか」に誰も答えられなくなると、システムは「触ると壊れるかもしれないから触らない」ものになります。
変更が止まれば営業の実態とのずれが少しずつ広がり、せっかく定着した運用も数年かけて形骸化していきます。
そしてこの状態は、ベンダーの担当者が交代したときや、自社の窓口担当が異動したときに一気に進みます。契約が続いていても、意図の引き継ぎが行われなければロックインは進行するのです。これはベンダーの怠慢というより、発注側が「なぜそうしたのか」の説明を求めてこなかった構造の問題でもあります。だからこそ、今から自社で手を打てます。
残すべきは、操作手順書よりも「なぜそう設定したか」という設計根拠です。納品時にもらった手順書は操作の仕方を教えてくれますが、「この設定を外してよいか」「変えてよいか」の判断材料にはなりません。
といっても、完璧な設計書を作る必要はありません。作った瞬間から更新されない重厚なドキュメントは、納品物を1つ増やすだけです。必要なのは、変更のたびに1行足す運用です。
この1行があるだけで、次の担当者は「この設定を外してよいか」を自分で判断できます。これが、分担線をあとから動かせる状態です。
今からベンダーに依頼できることもあります。次の設定変更から、「なぜその方法にしたのか」という説明を1〜2行添えてもらうよう頼むことです。多くの支援会社は、求めれば応えてくれます。そして、この依頼への反応は、後述する「手を離していけるパートナーかどうか」を見きわめる材料にもなります。
もう1つの対処は、新しい要望が出たとき、まず標準機能で実現できないかを確認することです。
標準機能で組んだ仕組みは管理画面で完結するため、将来自社に引き取れる範囲が広がります。一方、独自開発による作り込みは専門技術が必要で、外部に残り続けます。さらにSalesforceには年3回のバージョンアップがあり、作り込みが多いほど、その都度の影響確認の負担も増えていきます。
たとえば「承認が通ったら関係者に通知したい」という要望は、標準のフロー機能で組めばあとから自社でも直せますが、独自開発にしてしまうと、次の変更もその次もベンダー行きになります。
既存の作り込みを今すぐ捨てる必要はありません。いま動いているものはそのままに、新しい要望から「まず標準機能で」という方針に切り替えれば十分です。カスタマイズそのものが悪いのではなく、「それは作り込みに値する要望か」という問いを毎回はさむことに意味があります。
次に、引き取る側の条件です。ここでよくあるつまずきが、「管理者を1人決めて終わり」にすることです。
管理者を1人決めただけでは、ベンダー依存が個人依存に置き換わるだけです。その人の異動や退職で振り出しに戻るなら、単一障害点の場所が変わっただけです。
内製化と属人化は違います。内製化とは「自社で判断できる状態」を組織として持つことであり、特定の個人が詳しくなることではありません。設定を触れる人が1人しかいない状態は、契約で継続性が担保されているベンダー任せより、かえって脆い場合すらあります。
そして、その1人になりかけているのは、あなた自身かもしれません。導入時の窓口だったというだけで設定変更の依頼がすべて自分に集まり、自分が休むと何も進まない。心当たりがあるなら、それは内製化が進んでいるのではなく、単一障害点が自分に移ってきているサインです。
実際、窓口担当者の退職後、後任が「どこに何があるのか」を調べ直すところから始めた現場を、私たちは何度も見てきました。育成にかけた投資は、体制がなければその人と一緒に消えます。ただし、これは解決できる問題です。必要なのは特別な人材ではなく、最小限の仕組みです。
「では、詳しい人を採用しよう」は、残念ながら現実的ではありません。帝国データバンクの調査では、正社員が不足している企業は50.6％と、4月時点として4年連続で半数を超えています。業種別では情報サービス業が66.7％で最も高く、AI・DX案件の増加に人材の確保が追いついていません。
出典：帝国データバンク「人手不足に対する企業の動向調査（2026年4月）」
Salesforceを扱えるIT人材は業界を越えた奪い合いのなかにあり、採用を前提にした内製化計画は「採用できるまで動けない計画」になってしまいます。
現実的なのは、いまいるメンバーが管理側の知識を足すことです。先ほどの2軸を思い出してください。内製化の本命は「技術的には易しいが、自社の業務知識が要る」業務でした。この業務の担い手として、営業を誰よりわかっている自部門のメンバーは、外から迎えるIT人材より適任です。
何をどの順で学ぶかという学習の進め方や、管理者にどこまでのスキル水準を求めるかという考え方は、別の記事で解説しています。（Salesforce研修の選び方と計画はこちら）
1人に依存しないための最小の体制は、「主担当＋副担当＋引き継ぎドキュメント＋月1回の定例」の4点セットです。
図：1人に依存しない最小の運用体制
|
ベンダー（外部の支援会社）
連携・独自開発など外部に残す業務を担当
|
||
|
▲▼
依頼・相談 |
▲▼
契約範囲と 連絡先を把握 |
|
|
主担当
設定変更を実行
（兼務でよい） |
月1回・30分の定例
変更履歴を共有
決めたこと・保留を記録 |
副担当
どこに何があるか
分かる人から |
|
▼ 記録
|
▼ 記録
|
▲ 参照
|
|
引き継ぎドキュメント
①管理者アカウントと権限の所在 ②設定の変更履歴 ③ベンダーとの契約範囲と窓口 ④定例の記録
|
||
ベンダーとの窓口も主担当に一本化せず、副担当も契約範囲と連絡先を把握しておく
副担当のハードルは、思い切って下げてください。月1回の定例で変更履歴を聞いているだけでも、主担当の異動時に「ゼロから調べ直す」事態を防げます。完全な代替要員を2人育てる話ではありません。
引き継ぎドキュメントに最低限書くのは次の4項目です。
最後に、この体制を社内でどう通すかです。担当する本人には「営業の片手間」ではなく、担当業務として工数と評価に反映することを約束してください。ここを曖昧にすると続きません。また、権限管理やアカウントの取り扱いについては、情報システム部門との責任分界を先に決めておくと、あとの摩擦を防げます。
線の引き方と体制の絵が描けたら、残る問いは「いつから、何から始めるか」です。
内製化を始める条件は、導入時に準備していたかどうかではなく、いま運用が回っていることです。現場がSalesforceに入力し、データが営業の判断に使われている状態であれば、稼働後半年〜1年は、むしろ内製化を始める適期といえます。
どの業務の依頼が多いか、どこで待ち時間が発生しているかという運用実績が貯まっており、引き取る業務を実態で選べるからです。
「導入時に内製化を見据えた設計を頼んでいなかった」ことは、致命傷ではありません。これから示す順序を踏めば、稼働後からでも移行できます。
一方、入力が定着せず運用が回っていない場合は、内製化より先に定着に取り組んでください。回っていない仕組みを引き取っても、回らないまま自社の負担になるだけです。
段階的に引き取るときの本質は、刻み方の細かさよりも、「失敗しても戻せる単位」を保つことにあります。
| フェーズ | 時期の目安 | 自社に引き取る業務 | 進んでよい条件 |
|---|---|---|---|
| フェーズ1 | 開始〜3ヶ月 | ユーザー管理、レポート・ダッシュボード作成 | 分担表で「今すぐ引き取れる」に入った業務であること |
| フェーズ2 | 4〜6ヶ月 | 項目追加・入力規則 | フェーズ1が兼務の工数内で回っていること |
| フェーズ3 | 7ヶ月以降 | 自動化フローの一部（要件は自社、複雑な実装は外部） | 主担当・副担当の体制が回っていること |
| 当面引き取らない | ー | 他システム連携、独自開発 | 失敗時の影響が広く頻度が低いため、外部に残す |
※時期はあくまで目安の仮説です。兼務できる工数や現在の発注範囲によって変わり、「何ヶ月で内製化が完了する」と約束できる性質のものではありません。
フェーズ1には、分担表と判断条件で「今すぐ引き取れる」となった業務を置きます。そして各フェーズには、「うまくいかなければ発注に戻す」という選択肢をあらかじめ織り込んでください。
たとえばフェーズ1でレポート作成を引き取ってみて、月あたりの作業量が想定の2倍だったなら、フェーズ2に進まず発注に戻す。それは失敗ではなく、自社が引き取れる量を実測できたということです。戻れると分かっているから、安心して試せます。
「本番環境を壊さないか」という不安にも、見当をつけておきましょう。フェーズ1の業務は失敗しても影響が閉じているものばかりです。
加えてSalesforceには、本番に影響を与えずに設定を試せる検証環境（サンドボックス）が用意されており、「試して、確かめてから本番に反映する」という進め方ができます。
保守・運用支援契約の更新通知が来てから慌てる必要はありません。順序は、「まず分担線を引く（今週できる）」、そのうえで「線に沿って発注範囲を見直す（更新時に決める）」です。
更新日までに移行計画のすべてを固める必要はありません。フェーズ1で引き取る業務だけを決め、残りは従来どおりの発注内容で更新すればよいのです。線が引けていれば、更新日は追い立てられる締切ではなく、発注範囲を見直す機会に変わります。
ベンダーへは、「契約を切りたい」ではなく「発注範囲を段階的に絞っていきたい」という枠組みで伝えることをおすすめします。
現在の発注内容の内訳を出してもらい、業務単位でどこを残すかを協議すれば、関係を損なわずに進められます。また、内製化への移行自体を支援してもらう場合は、通常の運用支援の確認に加えて「手を離す前提の支援かどうか」を確かめてください。
具体的には、設定意図のドキュメントを残すか、社内への引き継ぎに協力するか、発注縮小に柔軟に応じるかの3点です。
支援には運用を代行するタイプだけでなく、内製化への移行に伴走するタイプもあります。
支援サービスの種類や選び方は、別の記事で詳しく解説しています。
（Salesforce導入・活用支援サービスの選び方はこちら）
Salesforceの内製化は、ベンダーを切ることでも、全部を自社で抱えることでもありません。自社が判断できる範囲を、業務単位で増やしていくことです。本記事の要点は次の3つです。
経営層への説明は、「内製化すればすぐ安くなる」ではなく「どの範囲を、いつまでに、どういう条件で引き取るか」。外注費が人件費と教育に置き換わる構造と、それでも得られる改善スピードを分けて伝えれば、期待値のずれを防げます。
今週やることは1つで構いません。分担表を眺めて、いま引き取れる業務を1つ決める。あわせて、設定を触れる人が自分1人になっていないかを確認する。その一歩が、内製化の始まりです。