Salesforce改修が高額・遅い根本原因と伴走開発で解決する方法

導入：「また高い、また遅い」——Salesforce改修に繰り返すストレスの正体

Salesforceを導入したはずなのに、追加開発や改修を依頼するたびに高額な見積もりが届き、納品まで数か月を要する——そのような状況に陥っている企業は少なくありません。「導入時は順調だったのに、運用フェーズに入ってから動きが鈍くなった」という声は、Salesforceを活用するBtoB企業の情報システム担当者や経営層から繰り返し聞かれます。

問題は、Salesforceというプロダクト自体にあるのではありません。多くの場合、原因はベンダーの契約構造や開発体制の設計にあります。しかし、その構造が見えていないまま改修を依頼し続けると、コストと時間だけが積み上がっていきます。

Salesforceは導入して終わりではない——継続的な改修こそが価値を決める

Salesforceは、導入時点で完成するシステムではありません。営業プロセスの変化、組織再編、新規事業の立ち上げ、法改正への対応——ビジネスが動き続ける以上、Salesforceも継続的に改修・拡張していく必要があります。

つまり、Salesforceへの投資対効果は「導入後にどれだけ柔軟に改修できるか」によって大きく左右されます。初期導入費用よりも、その後の改修コストと速度のほうが、長期的な活用価値を決める要素として重要になるケースがほとんどです。

にもかかわらず、多くの企業では改修のたびに高額な追加費用が発生し、納期も読めない状況が続いています。これは偶発的な問題ではなく、従来型の受託開発モデルが持つ構造的な課題から生じています。

本記事で解説すること——原因の構造から伴走開発という選択肢まで

本記事では、Salesforce改修が高額・長納期になる根本原因を構造的に整理したうえで、課題を解消するための選択肢として「伴走開発」というアプローチを解説します。具体的には以下の内容を順に取り上げます。

• なぜSalesforce改修の見積もりは高くなるのか——ベンダー側の構造的な理由
• Salesforce開発で使われる技術（ApexとLWC）の基本的な理解
• 内製化と外注、それぞれが自社に合うケースの判断軸
• 伴走開発とは何か——従来型受託開発との違いと導入効果
• 伴走開発ベンダーを選ぶ際に確認すべきポイント

Salesforce改修に繰り返すストレスの正体を把握し、自社の開発体制や契約の見直しを検討するうえでの判断材料として、本記事をご活用ください。

なぜ高額・長納期になるのか——Salesforce改修ベンダーの構造的問題

Salesforce改修のコストや納期に課題を感じている企業の多くは、「今のベンダーの対応が悪い」と捉えがちです。しかし実態は、特定のベンダーの問題ではなく、受託開発という商慣行そのものが持つ構造的な課題に起因しているケースがほとんどです。

受託モデルの構造——要件定義・見積もり・承認の往復がコストを生む

受託開発では、改修を依頼するたびに「要件定義→見積もり提出→社内承認→発注」というプロセスを踏む必要があります。小さな画面改修でも、このサイクルが2〜4週間を要することは珍しくありません。

加えて、ベンダー側は要件の曖昧さや仕様変更リスクを見越して見積もりにバッファを乗せます。結果として、実作業が3日分であっても、見積金額が10〜20万円規模に膨らむことがあります。依頼側には「なぜこの改修にこれだけかかるのか」という不透明感が残ります。

Apex・LWCの属人性——開発者のスキルギャップがリードタイムを延ばす

SalesforceのカスタマイズにはApex（エイペックス）というSalesforce専用のプログラミング言語と、LWC（Lightning Web Components：画面構築フレームワーク）の知識が必要です。これらはSalesforce固有の技術であり、一般的なWeb開発のスキルとは異なります。

ベンダー社内でApexやLWCを扱える開発者が限られている場合、担当者のアサイン待ちだけで数週間のリードタイムが発生します。また、担当者が変わるたびにコードの把握から始まるため、引き継ぎコストも積み上がります。

ウォーターフォール型リリース——小さな改修でも大きなプロジェクトになる理由

受託開発の多くはウォーターフォール型、すなわち「要件定義→設計→開発→テスト→リリース」を一方向に進める進行方式を採用しています。この方式では、途中で仕様を変更すると前工程への手戻りが発生するため、変更を極力避ける方向で設計が固められます。

結果として、業務上は「1項目の追加」に過ぎない改修でも、設計書の更新・テスト仕様の作成・本番反映の手続きがセットで発生し、プロジェクトとして管理されます。スピードよりも品質担保と工程管理が優先される構造です。

追加改修のたびに「再見積もり」が発生する契約構造の問題

多くの受託契約は「案件単位の請負契約」で結ばれています。このため、当初スコープ外の改修が生じるたびに、新たな見積もり・発注・契約締結が必要になります。

業務要件が変化しやすいSalesforceの運用においては、この契約構造が特にミスマッチを起こしやすい状況です。改修の頻度が高いほど事務コストが積み重なり、担当者の工数も圧迫されます。Salesforce 追加開発の費用が積み上がる背景には、こうした契約単位のコスト構造が深く関わっています。

Salesforceの開発技術を理解する——ApexとLWCとは何か

Salesforceの改修コストや納期に疑問を感じたとき、ベンダーから提示される見積もりの根拠を読み解くには、開発技術の基礎知識が助けになります。専門的な実装スキルは不要ですが、「何を使って何を作っているか」を把握しておくだけで、ベンダー評価の精度が大きく変わります。

Salesforceの開発言語「Apex」とは——JavaライクなSalesforce専用言語

ApexはSalesforceが独自に設計したプログラミング言語です。構文はJavaに近く、Salesforceのデータベース操作やビジネスロジックの自動化に使われます。たとえば「商談が成立したら自動で請求書レコードを生成する」「特定条件を満たすデータだけを抽出して通知を送る」といった処理を記述するのがApexの役割です。

Salesforceプログラミングの中核を担う言語であるため、Apexの習熟度がそのまま開発品質と工数に直結します。Salesforce専用言語であることから、汎用のJavaやPythonエンジニアがそのまま担当できるわけではなく、専門的なトレーニングと実務経験が必要です。

LWC（Lightning Web Components）とは——画面カスタマイズを担うUI開発技術

LWCはSalesforceの画面（UI）をカスタマイズするためのフレームワークで、Web標準のJavaScriptをベースに設計されています。営業担当者が使う入力フォームや、ダッシュボードの独自パネルなど、「見た目と操作性」に関わる部分はLWCで構築されます。

SalesforceにおけるJavaScript開発の主戦場がLWCです。Apexがサーバーサイドのロジックをカバーするのに対し、LWCはブラウザ上のインターフェースを担当します。両者をセットで扱えるエンジニアがいるかどうかが、改修の一気通貫対応を左右します。

発注者がApex・LWCを知っておくべき理由——ベンダー評価と工数査定に直結する

発注者がApexやLWCを理解することのビジネス的な意味は、技術の習得ではなく「妥当性を問える立場になる」ことにあります。

たとえば、ある改修の見積もりに「Apex実装：40時間」と記載されていたとします。要件の規模とApexの特性を知っていれば、その工数が標準的か、あるいは過剰かを判断する材料になります。知識がなければ、提示された数字をそのまま受け入れるしかありません。

また、ベンダー選定の場面でも差が出ます。ApexとLWCの両方を扱えるエンジニアが社内にいるか、過去の実績はあるかを確認するだけで、対応力の目安になります。この二点を押さえておくだけで、ベンダーとの対話の質が変わります。

Salesforceの開発言語・技術スタックへの基礎理解は、発注者にとっての「交渉力」です。高額・長納期の構造を変えるための第一歩として、まずこの二つの名前と役割を把握しておくことをおすすめします。

内製化 vs 外注——どちらが自社に合っているかの判断軸

「ベンダーへの依存をやめて自社で開発できるようにしたい」という声は、Salesforceの改修コストや納期に悩む企業から頻繁に聞かれます。しかし内製化が現実的な選択肢かどうかは、自社のリソース状況を踏まえた冷静な判断が必要です。

完全内製化の現実——Apex・LWC人材の採用難と育成コスト

Salesforceのカスタム開発に必要なApexエンジニアやLWC（Lightning Web Components）の経験者は、国内の採用市場でも絶対数が少ないのが現状です。求人を出しても応募が集まらないケースは少なくなく、採用できたとしても相応の人件費がかかります。

既存のエンジニアをゼロから育成する場合も、実務レベルに達するまでに1〜2年程度を要することが多く、その間の開発は止まるか外注に頼り続けることになります。内製化は中長期的な選択肢ではあっても、短期的な課題解決にはなりにくい点を認識しておく必要があります。

外注継続の限界——スピードとコストの問題は構造的に解決しない

一方、現行ベンダーへの外注を継続する場合、前セクションで触れた構造的な問題——多重下請け・人工単価の硬直性・要件定義の非効率——はそのまま残り続けます。ベンダーを変更したとしても、同じ受託開発モデルを採用している会社であれば、同じ課題が再現される可能性が高いです。

第三の選択肢——伴走開発（アジャイル型外注）という考え方

内製化と従来型外注の中間に位置するのが、伴走開発（アジャイル型外注）と呼ばれるモデルです。固定のチームが継続的に関与しながら、短いサイクルで開発・改修を繰り返す形態で、社内にノウハウを蓄積しながら外部リソースを活用できる点が特徴です。

以下の表で3つのモデルを比較します。

自社にApex・LWCのエンジニアがいない、あるいは採用の見通しが立たない場合、伴走開発は現実的な代替案になります。次のセクションでその具体的な仕組みを整理します。

アジャイル伴走開発とは何か——従来型受託との違いと導入効果

伴走開発の定義——スプリント単位で改修を積み重ねるアジャイル型外注

伴走開発とは、発注側と開発会社が継続的なパートナー関係を結び、短いサイクル（スプリント）で開発・リリース・フィードバックを繰り返す開発形態です。一般的には1〜2週間または1か月をスプリント単位とし、優先度の高い機能から順に実装していきます。

従来の受託開発が「要件定義→設計→開発→テスト→納品」という一方向のプロセスを取るのに対し、伴走開発では要件の確定を小さな単位に分割します。最初から完全な仕様書を用意する必要がなく、業務の変化に応じて途中で優先度を変更することも可能です。

従来型受託開発との比較表——コスト・スピード・柔軟性の違い

両者の構造的な違いは、以下の比較で整理できます。

特にコスト面での差は大きく、従来型では見積もり・契約・仕様調整のたびに管理コストが積み上がります。伴走開発では月次の固定費の範囲内で開発量を調整するため、予算管理が格段にシンプルになります。

業務設計と開発を分離しない——「何を作るか」から一緒に考える体制の意味

従来型受託では、発注側が「何を作るか」を決めてから開発会社に渡すのが一般的です。しかしSalesforceの改修においては、業務フローの設計ミスが実装段階で判明するケースが少なくありません。結果として手戻りが発生し、追加費用と納期延長を招きます。

伴走開発では、業務設計の段階から開発チームが関与します。「現場でこの項目が入力しづらい」「承認フローをもう一段階追加したい」といった現場課題を、開発側がSalesforceの制約・可能性を踏まえた上で一緒に整理します。業務と実装を分離しないことで、設計ミスを早期に発見でき、無駄な開発コストを削減できます。

月次リリースで変化に追いつく——Salesforceを生きたシステムにする運用サイクル

Salesforceは導入時点が完成形ではなく、業務の変化に合わせて継続的に育てていくプラットフォームです。しかし従来型の受託契約では、改修のたびに発注手続きが発生するため、現場の小さな改善要望が後回しになりがちです。

伴走開発では、月次サイクルでバックログ（改修候補リスト）を見直し、優先度の高いものから順に実装・リリースします。発注側は新たな見積もり依頼や契約変更をせずとも、業務変化をシステムに反映し続けることができます。Salesforceを「入れっぱなし」にせず、現場で使われ続けるシステムとして維持するには、このような継続的な改修サイクルが不可欠です。

伴走開発ベンダーを選ぶ際の確認ポイント——失敗しないための評価軸

ベンダー変更や新規選定を検討する際、「実績が豊富」「対応が丁寧」といった抽象的な評価だけでは失敗するリスクがあります。伴走開発に適したベンダーかどうかは、具体的な確認事項を通じて見極める必要があります。

技術力の確認——Apex・LWCの実装実績と対応できるカスタマイズの範囲

Salesforceのカスタマイズ開発において、ApexとLWC（Lightning Web Components）の習熟度はベンダーの技術力を測る基本的な指標です。しかし「対応できます」という回答だけでは判断できません。以下のような質問で実態を確認することをお勧めします。

• 「直近1年で手がけたApexのカスタム開発の事例を教えてください」
• 「LWCを使って構築したUIコンポーネントの具体例はありますか」
• 「標準機能では対応できないケースに遭遇したとき、どのように判断・対処しましたか」

標準機能の設定変更だけを得意とするベンダーは、複雑な業務要件に対してカスタム開発で対応する力が不足している場合があります。実績の具体性と幅広さを確認することが重要です。

業務設計力の確認——要件を翻訳する力があるかどうか

伴走開発に求められるのは、コードを書く技術力だけではありません。「営業フローを変えたい」「承認プロセスを整理したい」といった業務上の言葉を、Salesforceの設計に落とし込む力——いわゆる要件翻訳力——が不可欠です。

以下の質問で、業務設計力の有無を見極めることができます。

• 「要件定義はどのように進めますか。ヒアリングから設計までの流れを教えてください」
• 「発注側が要件を整理しきれていない状態でも対応できますか」
• 「過去に業務課題から設計提案を行った事例はありますか」

「言われた通りに作る」だけのベンダーでは、追加開発のたびに発注側が仕様書を用意しなければならず、コストと工数が膨らみます。業務とシステムの両側から議論できる担当者がいるかどうかが選定の分かれ目になります。

契約形態の確認——準委任契約と請負契約、伴走開発に向いているのはどちらか

契約形態は、伴走開発の機動性に直接影響します。請負契約は成果物を事前に定義し、その納品に対して報酬を支払う形式です。一方、準委任契約はエンジニアの稼働そのものに対して報酬を支払うため、仕様変更や優先度の調整に柔軟に対応できます。

継続的な改修・追加開発が想定されるSalesforce伴走開発では、準委任契約が実態に合いやすい傾向があります。ベンダーに対しては以下を確認してください。

• 「伴走開発の契約形態として準委任と請負のどちらを推奨しますか。その理由も教えてください」
• 「月次の稼働時間や作業内容はどのように報告・共有されますか」

実際にベンダーに投げかけたい確認事項リスト

最後に、選定時にベンダーへ直接確認しておきたい事項を整理します。回答の具体性と一貫性が、ベンダーの実力と誠実さを測る材料になります。

• スプリントはどのサイクルで運営しますか（1週間・2週間など）
• 進捗共有の頻度とツール（Slack、Notion、Jiraなど）はどのように設定されますか
• 担当エンジニアが変わる場合、どのように引き継ぎを行いますか
• Salesforce追加開発の費用はどのような基準で見積もられますか
• ベンダー変更時のソースコード・設計ドキュメントの引き渡しはどう対応されますか

これらの質問に対して明確・具体的に答えられるベンダーは、実務経験と透明性を兼ね備えている可能性が高いといえます。逆に曖昧な回答が続く場合は、選定の見直しを検討する判断材料になります。

CLANEの伴走開発アプローチ——Apex・LWCを軸にSalesforceを企業OSへ進化させる

Apex・LWCによるフルカスタマイズ——標準機能の限界を超える実装力

CLANEのSalesforce伴走開発では、ApexとLWC（Lightning Web Components）を組み合わせた実装を基本としています。標準機能やフロービルダーで対応できる要件はそちらを優先しますが、業務ロジックが複雑な場合や既存システムとの連携が必要な場合は、Apexによるサーバーサイド処理とLWCによるUI実装を組み合わせたSalesforce改修を行います。

たとえば、承認ルートを案件金額・顧客属性・担当組織の複数条件で動的に切り替える処理や、外部ERPとのリアルタイム連携が求められる場面では、標準機能だけでは設計の限界に達するケースがほとんどです。CLANEはこうした局面でApexを使ったカスタムロジックを実装し、LWCで操作性の高いUIを構築することで、業務に即した画面・処理を提供しています。

業務設計から入る開発——「動くシステム」ではなく「使われるシステム」を作る

CLANEの伴走開発では、実装着手の前に業務フローの整理を行います。「どの部門が・どのタイミングで・何のためにSalesforceを操作するか」を発注側の担当者と共に言語化し、要件の優先順位を決めてから開発に入ります。

この工程を省略すると、技術的には動作するが現場では使われないシステムが出来上がりがちです。CLANEが業務設計を開発の起点に置くのは、Salesforce改修の成果を「稼働率」ではなく「業務上の変化」で測るためです。

スプリント型で小さく速く積み上げる——CLANEの伴走開発サイクルの実際

CLANEのSalesforce伴走開発は、2〜4週間を1スプリントとするサイクルで進めます。スプリントごとに動く成果物をリリースし、発注側の担当者がバックログ（積み残しタスクの一覧）を確認しながら次の優先順位を決める形を取っています。

バックログは機能単位で可視化されており、「何が完了していて・何が次に着手されるか」を発注側が随時確認できます。これにより、追加要件が発生した際も「差し込みか・次スプリントに回すか」を担当者が判断しやすい状態を維持できます。大きな仕様変更を一括で発注するのではなく、優先度の高いものから順に積み上げていく進め方が、コスト管理と納期の安定につながります。

まとめ——Salesforce改修を「高い・遅い」から脱却するために

Salesforce改修における「高い・遅い」の問題は、特定のベンダーの怠慢ではなく、受託型開発の構造そのものに起因しています。要件定義から納品までの工程を一括で委託する従来モデルでは、仕様変更のたびに契約変更が発生し、コストと工数が積み上がる仕組みになっています。この構造を理解したうえで、自社に合った開発体制を選ぶことが、問題解決の第一歩です。

整理すると、判断のポイントは以下の3点に集約されます。

• 高額・長納期の原因は構造的な問題である：人工単価の積み上げ方式と一括請負契約の組み合わせが、改修コストを押し上げる主因です。ベンダーを変えるだけでは根本解決にならないケースも少なくありません。
• 内製化・外注継続・伴走開発の三択を自社状況で判断する：Salesforceエンジニアの採用が困難な企業でも、伴走開発モデルであれば技術移転を受けながら段階的に内製化へ移行できます。いずれの選択肢も、自社のエンジニアリソースと改修頻度を基準に評価することが重要です。
• ベンダー選定では技術力と業務設計力の両方を確認する：ApexやLWC（Lightning Web Components）の実装実績だけでなく、業務フローの上流から改修要件を整理できる提案力があるかどうかを評価軸に加えてください。技術力のみ高いベンダーに依頼した場合、要件定義の質が低く手戻りが発生するケースがほとんどです。

Salesforce伴走開発は、改修のたびに発注・納品を繰り返す非効率から脱却し、継続的な改善サイクルを組織に組み込むためのアプローチです。自社の開発体制や現行ベンダーとの契約内容を改めて見直す際に、本記事の視点が判断の一助になれば幸いです。