【決定版】Salesforce Apex/LWC開発に特化した優良ベンダーを見極める技術的評価ポイント10選

はじめに
標準機能の限界と、Apex/LWC開発が必要になる致命的なケース
Apexコードの品質が将来の保守・運用に与える影響
認定資格だけでは見抜けない！真のApex開発力を測る3つの指標
Salesforce 開発ベンダーによる「過剰なカスタム開発」や「プラットフォーム制限の無視」のリスク
技術的な専門性と品質を両立し、持続可能な開発を実現する「解決策」とは？
LWC（Lightning Web Components）開発のトレンドとベンダーの対応力を評価する
複雑なシステム連携（インテグレーション）実績とセキュリティ対策の評価
開発標準とテスト戦略：ベンダーが遵守すべき品質管理プロセス
開発完了後のパフォーマンスチューニングと最適化のノウハウ
まとめ

はじめに

Salesforceの導入・活用において、標準機能だけでは解決できない高度なビジネス要件に対応するために、ApexやLightning Web Components (LWC)によるカスタム開発は不可欠です。しかし、このカスタム開発を担うベンダー選びで失敗すると、将来的な保守コストの増大、システムのパフォーマンス低下、最悪の場合はプラットフォームの制限に抵触し、システムが破綻するリスクを招きます。

本記事では、ITエンジニアを200名以上抱え、システム開発を25年以上経験する弊社、FS部　佐々木舞美が、認定資格や表面的な実績だけでは見抜けない、真のApex/LWC開発力を持つ優良ベンダーを見極めるための10の技術的評価ポイントを徹底的に解説します。

標準機能の限界と、Apex/LWC開発が必要になる致命的なケース

Salesforceは非常に多機能ですが、以下のようなケースではApexやLWCによるカスタム開発が必須となります。

複雑なビジネスロジックの実現: 複数のオブジェクトにまたがる複雑な計算処理や、標準ワークフローでは実現不可能なきめ細やかな自動化が必要な場合。
高度なUI/UXの要求: 標準のLightningレコードページでは実現できない、業務効率を劇的に向上させるカスタムユーザーインターフェースが必要な場合。
外部システムとのリアルタイムかつ複雑な連携: 外部APIとの双方向連携において、標準の外部サービス機能では対応できない認証処理やデータ変換が必要な場合。

この「標準機能の限界」を正しく見極め、本当にカスタム開発が必要かを判断できる技術的な提案力こそが、優良ベンダーの最初の評価ポイントです。

Apexコードの品質が将来の保守・運用に与える影響

「動くコード」と「高品質なコード」は全くの別物です。特にSalesforceにおいては、Apexコードの品質が将来のシステム維持コストに直結します。

技術的負債の蓄積: 命名規則の不統一、過度なトリガーの利用、再利用性の低いコード（Spaghetti Code）は、機能追加や改修のたびに工数を増大させます。
ガバナ制限（Governor Limits）の無視: ApexコードはSalesforceプラットフォームの共有リソース上で動作するため、ループ内でのSOQL発行（$1\verb|:\verb|N$ クエリ）など、ガバナ制限を無視した開発は、ユーザー数の増加に伴いパフォーマンス低下や処理エラーを誘発します。
テストカバレッジの低さ: テストクラスが不十分なコードは、予期せぬバグを生み出し、リリース・保守を困難にします。テストカバレッジ75%以上は最低限の基準です。

ベンダー選定時には、「どのようにしてコードレビューを行うのか」「ガバナ制限対策をどのように組み込むのか」を具体的に質問することが重要です。

認定資格だけでは見抜けない！真のApex開発力を測る3つの指標

Salesforceの認定資格は前提知識の証明にはなりますが、実務能力とは限りません。真の開発力を見極めるには、以下の3つの指標に着目してください。

非同期処理の適切な使い分け: $Future$メソッド、Queueable Apex、Batch Apex、Scheduled Apexなど、処理の要件に応じて最適な非同期処理メカニズムを使い分けているか。特に大量データ処理におけるBatch Apexの分割処理（Chunking）設計能力は重要です。
デザインパターンの適用実績: Apex開発におけるトリガーフレームワークの利用や、ビジネスロジックとデータベース操作を分離するService Layerパターン、Selector/Domainパターンなどの実績があるか。これにより保守性と拡張性が担保されます。
セキュリティ設計（CRUD/FLS）: コード内でプロファイルや権限セットを考慮し、ユーザーのデータアクセス権限（CRUD/FLS）を逸脱しないように開発するセキュリティ意識が徹底されているか。特にwith sharing/without sharingの適切な利用は必須です。

【関連リンクのご提案】

真の技術力を持つベンダーと協業するためのノウハウにご興味があれば、こちらの記事もご覧ください。

Salesforce開発における内製化支援ベンダーの選び方と失敗しないための連携術

Salesforce 開発ベンダーによる「過剰なカスタム開発」や「プラットフォーム制限の無視」のリスク

優良なベンダーは、「標準機能でできることは標準機能で」を原則とします。カスタム開発が過剰になると、以下のリスクが顕在化します。

アップグレード・メンテナンスの複雑化: 標準機能のアップデート時にカスタムコードとの競合が発生しやすくなります。
コスト増: 開発・保守コストが肥大化し、システムのTotal Cost of Ownership (TCO)が高くなります。
プラットフォーム制限の無視（Technical Debt）:
- カスタムメタデータ型やカスタム設定の不適切な利用。
- 極端に大きなオブジェクトやトランザクションサイズの設計。
- 特にデータボリュームに対するガバナ制限の事前評価を怠るベンダーは危険です。

ベンダーには、なぜそのカスタム開発が必要なのか、標準機能ではなぜ代替できないのかを明確に説明してもらうべきです。

技術的な専門性と品質を両立し、持続可能な開発を実現する「解決策」とは？

持続可能な開発を実現する「解決策」は、「プラットフォームの哲学を理解した上での、戦略的なカスタム開発」に尽きます。具体的には、以下の3つの要素を満たすベンダーを選ぶことです。

最小限のカスタムコード: 必要な箇所にのみApex/LWCを適用し、フローやプロセスビルダー（現行はフローへの移行推奨）などのノーコード/ローコード機能を最大限に活用するスキル。
DevOpsの導入: バージョン管理システム（Gitなど）とCI/CDパイプライン（Salesforce DXなど）を活用し、安全かつ迅速なデプロイを実現する体制。
ドキュメントと引継ぎの徹底: 開発標準、設計書、コードコメントを整備し、将来的に自社や別のベンダーへ引き継ぐ際の障壁を最小限にする姿勢。

SFsolution（https://www.fdc-inc.co.jp/sfsolution/）

複雑なApex/LWC開発から、大規模システム連携、内製化支援まで、お客様の持続的なSalesforce活用を支援するソリューションを提供しています。技術的な課題解決とビジネス成果を両立したいお客様は、ぜひご検討ください。

LWC（Lightning Web Components）開発のトレンドとベンダーの対応力を評価する

Lightningコンポーネントは、Aura ComponentsからLWCへと主流が移行しています。LWCは標準化されたWeb技術（Web Components）をベースにしており、パフォーマンスと開発効率が大幅に向上します。

LWCへの習熟度: Auraでの開発経験だけでなく、LWCの標準仕様、リアクティブプログラミング、Wire Service、Lightning Data Service (LDS) の適切な利用実績があるか。
モダンな開発手法: JavaScriptの最新仕様（ES6以降）、Jestによるユニットテスト、そしてShadow DOMを考慮したコンポーネントの分離・再利用性を意識した設計ができるか。
UI/UX設計力: Salesforce Lightning Design System (SLDS) を遵守し、一貫性のあるユーザー体験を提供できるデザインセンスと技術力を持っているか。

ベンダーが、いまだに古いAuraコンポーネントを主要なカスタムUIとして推奨していないかを確認してください。

複雑なシステム連携（インテグレーション）実績とセキュリティ対策の評価

Salesforceは外部システムとの連携が不可欠です。インテグレーションの評価ポイントは以下の通りです。

連携パターンの経験: REST API、SOAP API、プラットフォームイベント、外部オブジェクト（Salesforce Connect）など、連携要件に応じた最適な技術を選択できる実績。
エラーハンドリングとリトライ設計: 外部システム障害発生時のデータの整合性を保つための堅牢なエラーハンドリング（再試行ロジック、キューイングなど）が設計されているか。
OAuth/JWTなどの認証・認可知識: 機密性の高いデータ連携において、最も安全で最新の認証プロトコル（例: JWTベアラーフロー）を適切に利用できるか。
IP制限、ネットワークセキュリティの提案力: 連携におけるセキュリティリスクを事前に評価し、ネットワークレベルでの強固な対策を提案できるか。

開発標準とテスト戦略：ベンダーが遵守すべき品質管理プロセス

開発ベンダーがどのような「開発のルール」を持っているかが、納品されるシステムの品質を決定づけます。

コーディング標準の明文化: 命名規則、インデント、コメントのルールなど、誰が見ても理解できる一貫したコーディング標準が存在するか。
厳格なテスト戦略: 単体テスト（Apex Test Class / LWC Jest）、結合テスト、システムテストの計画が明確か。特にテストデータ作成の自動化や、本番環境に似たテスト環境（Partial/Full Sandbox）でのテスト実行がルーチン化されているか。
変更管理プロセス: 変更リクエストから開発、テスト、本番リリースに至るまでのフロー（DevOpsパイプライン）が、誤動作のリスクを最小限に抑えるよう設計されているか。

開発完了後のパフォーマンスチューニングと最適化のノウハウ

開発が完了し、本番稼働を開始した後も、データ量の増加やユーザーの利用方法の変化に伴い、パフォーマンスのボトルネックは発生します。

パフォーマンス診断ツールへの習熟: Developer ConsoleのQuery Plan Tool、Debug Logs、Profiling機能などを用いて、ApexコードやSOQLクエリの非効率な箇所を特定し、改善できるノウハウがあるか。
インデックス戦略の提案: 大量データのSOQL実行速度を向上させるためのカスタムインデックスの必要性を評価し、Salesforceサポートと連携して構築できるか。
ビューの最適化: Lightningページの表示速度を改善するために、コンポーネントの非同期読み込みや、コンポーネント分割（Lazy Loading）の設計ができるか。

納品後もパフォーマンス監視と継続的な改善を提案できるベンダーは、長期的なパートナーとして信頼できます。