- 標準機能 vs プログラミング開発（Apex/LWC）の判断基準表
- Apex開発が必要になる「3つの具体的シナリオ」
- Salesforceの標準機能でどこまでできる？外注前に知っておきたいカスタマイズの限界
- salesforce 外注 比較・検討：技術力不足が招く「ガバナ制限」エラーのリスク
- 解決策：高度なApex開発を支える200名の技術集団「sfsolution」
- 高度なシステム連携でDXを加速させた開発事例
- 外注時に提示すべき「テクニカルな要件」とは
- 開発後の「保守」をスムーズにするためのドキュメント納品
- Apex開発の外注に関するFAQ 5選
- 次に読むべき「Salesforce内製化の限界？外注へ切り替えるべきタイミングとメリット」
標準機能 vs プログラミング開発（Apex/LWC）の判断基準表
この記事では、ITエンジニアを200名以上抱え、システム開発を30年以上経験する弊社、DX部 佐々木舞美が、Salesforceの真価を引き出す「高度なカスタマイズ」を外注する際の要諦を解説致します。
まず、どのような場合にプログラミング開発が必要になるのか、判断基準を整理しました。
| 項目 | 標準機能（Flow/設定） | プログラミング（Apex/LWC） |
| 実現可能な範囲 | 定型的な自動化・画面作成 | 複雑な計算・高度なUX・外部連携 |
| 開発コスト | 低い（設定のみ） | 高い（コーディング・テスト） |
| 保守の容易性 | 高い（誰でも修正可能） | 中〜低（専門知識が必要） |
| パフォーマンス | 大量データ処理には不向き | 大量データ・高速処理に最適 |
| sfsolutionの対応 | ノーコードでの最適化を優先 | 200名の専門家による高度実装 |
Apex開発が必要になる「3つの具体的シナリオ」
標準機能の「フロー（Flow）」は進化していますが、以下のケースではApex開発（プログラミング）が不可欠です。
- ガバナ制限を回避する大量データ処理： 数万件規模のレコードを一括更新・計算する場合。
- 独自のユーザーインターフェース（LWC）： 業務効率を極限まで高めるための、標準画面に捉われない操作画面。
- 複雑な外部API連携： 認証認可が必要な基幹システムや、独自の暗号化が必要な外部サービスとの統合。
Salesforceの標準機能でどこまでできる？外注前に知っておきたいカスタマイズの限界
開発費を抑えるコツは「標準機能でできることはコードを書かない」という判断です。過剰なApex開発は、将来の負債になりかねません。
補足リンク： [Salesforce Inspector Reloaded 徹底解説！（関連記事）]
salesforce 外注 比較・検討：技術力不足が招く「ガバナ制限」エラーのリスク
「外注 比較・検討」において、一般的なWeb開発経験はあるがSalesforce特有の仕様に疎いベンダーを選ぶと、以下のような致命的なリスクが生じます。
- ガバナ制限によるシステム停止： Salesforce特有の制限（マルチテナント制限）を考慮しないコードを書かれ、本番環境で突然エラーが多発する。
- テストクラスの不備： 自動テストが正しく書かれておらず、将来のバージョンアップや他機能の追加時にデプロイができなくなる。
- 非効率なクエリ： データの増大に伴い、画面の読み込みが極端に遅くなるパフォーマンス劣化のリスク。
解決策：高度なApex開発を支える200名の技術集団「sfsolution」
複雑なコードを書きつつ、保守性を維持する。この相反する難題を解決するのが、弊社のsfsolution（エスエフソリューション）です。
25年間のシステム開発で培った「規約に基づいた開発」をSalesforceでも徹底しています。
- コーディング規約の徹底： 誰が読んでも理解できる、メンテナンス性の高いソースコードを提供。
- 厳格なテスト工程： 正常系だけでなく、大量データや異常系まで網羅したテストを実施し、リリース後のトラブルを最小化。
- 最新技術（LWC）への対応： 常に最新のSalesforceアーキテクチャを採用し、モダンで高速なシステムを構築。
高度なシステム連携でDXを加速させた開発事例
「基幹システムとのリアルタイム連携をApexで実装し、二重入力を完全に撤廃した」事例など、技術難易度の高いプロジェクトの成功実績をご紹介します。
参考リンク：Salesforce導入・開発事例一覧ページ
外注時に提示すべき「テクニカルな要件」とは
Apex開発を依頼する際は、機能だけでなく以下の点もベンダーに確認しましょう。
- エラーハンドリング： エラー時にどのような通知やログ出力を行うか。
- 一括処理（Bulk）への対応： 大量データが投入されても動作が保証されるか。
- 将来の拡張性： ハードコーディングを避け、カスタム設定などで柔軟に変更できる設計になっているか。
開発後の「保守」をスムーズにするためのドキュメント納品
Apex開発において、ソースコードそのものがドキュメントであるという考え方は危険です。クラス図、シーケンス図、外部設計書など、後任の担当者が迷わないための成果物が納品物に含まれているかを、発注前に必ず合意しましょう。
Apex開発の外注に関するFAQ 5選
- QApex開発をするとバージョンアップで壊れませんか？
- A
SalesforceのAPIバージョン管理と、適切なテストクラスがあれば、基本的には壊れません。
- Q他社が書いたApexコードの修正・リファクタリングは可能ですか？
- A
可能です。コードを診断し、パフォーマンス改善やバグ修正のアドバイスを行います。
- Q開発言語は何ですか？
- A
Javaに似た独自のオブジェクト指向言語「Apex」と、JavaScriptベースの「LWC」を使用します。
- Q費用は標準機能の設定より高いですか？
- A
エンジニアの工数がかかるため高くなりますが、その分、劇的な業務改善が期待できます。
- QLWC（Lightning Web Components）のメリットは何ですか？
- A
Web標準技術に基づいているため、動作が非常に高速で、モバイルアプリのような快適な操作感を実現できます。
次に読むべき「Salesforce内製化の限界？外注へ切り替えるべきタイミングとメリット」
高度な開発を外注した後に、日々のメンテナンスをどう自社で行うか。技術移転と運用の棲み分けについて、次の記事で詳しく解説します。
あわせて読みたい関連記事：
Apex/LWC開発は、Salesforceを最強の武器に変える力を持っています。しかし、その力は確かな技術力があってこそ発揮されます。30年の実績と200名のエンジニアを擁する私たちに、貴社のこだわりを形にするお手伝いをさせてください。
