課題の背景：なぜ保守性が重要か

Salesforceでは、簡単な設定のみで利用ができる標準機能や、画面上の操作でカスタム処理を作成できるローコード開発機能を活用することで、比較的短期間に業務アプリケーションを構築することが可能です。
画面の入力項目、入力時のチェック処理、データの自動更新処理など、多くの業務要件をノンプログラミングで実現できるため、従来型のスクラッチ開発と比べて、早期に業務利用を開始しやすい点が大きな特長です。

一方で、Salesforce導入において本当に難しいのは、最初に処理を「作ること」だけではありません。
むしろ運用開始後に、業務変更、組織変更、権限見直し、外部システム連携、データ量増加、新機能追加などに継続的に対応しながら、システムを健全な状態で維持することが重要になります。短期間で作れるからこそ、設計意図が曖昧なまま設定や開発を重ねてしまうと、後から「どこを直せばよいのか分からない」「影響範囲が読めない」といった問題が顕在化しやすくなります。

また定期的に自動バージョンアップを行うプラットフォームであるがゆえ、「使っていた機能がサポート終了し新機能への移行が必要」という状況も発生します。
セールスフォース社が公開しているArchitecture CenterというサイトのSalesforce Well-Architected Frameworkでは、設計をするうえで重要なTrusted、Easy、Adaptableという考え方が示されています。
これは、信頼性や安全性だけでなく、理解しやすさ、変更のしやすさ、ビジネス変化への適応力を重視する考え方です。
Salesforceを長く使う前提に立つと、保守性は単に開発者向けの話ではなく、業務継続性や将来の投資対効果にも関わる重要な設計テーマだと言えます。

観点1：ローコード開発とプロコード開発の使い分け

Salesforceでは、画面フロー、レコードトリガフローなど、ノンプログラミングで処理を作れるローコード開発により、多くの業務自動化を実現できます。業務部門やシステム管理者でも理解しやすく、軽微な変更に対応しやすい点は大きなメリットです。
一方、Lightning Web Component、Apexなどプログラミングを必要とするプロコード開発は、複雑な処理、処理の再利用性、外部システム連携、大量データ処理などが求められる場面で有効です。
この2種類の開発方法の使い分けで重要なのは、「欲しい処理がローコードで作れるかどうか」だけで判断をしないことです。
単一ではローコードで実現できる処理であっても、全体を考えた時に条件分岐や例外処理が複雑になると、かえって保守が難しくなる場合があります。一方で、単純な項目更新や定型的な通知処理であれば、プロコード化せずローコードを活用することで、変更スピードや運用部門の関与を高めることができます。該当処理の重要度、利用量、業務影響、変更頻度、将来の拡張可能性、等を踏まえ、「なぜその実装方法を選ぶのか」を明確にすることが大切です。

観点2：利用する機能の選定

Salesforceは継続的に進化するプラットフォームとして新しい機能が追加される一方で、互換性維持のために従来の機能も一定期間利用できることがあります。
そのため、過去の開発経験があることや、既存処理の使いまわしができることを理由に従来の機能を使い続けたくなりますが、この点には注意が必要です。
例えば処理自動化の機能としては、長い期間「ワークフロー」「プロセスビルダー」が使われてきました。ただし現在では後継機能の「フロー」がリリースされたことにより機能の移行が推奨され、2025 年 12 月 31 日に公式サポートが終了しました。
従来機能がまだ使えるからと言って処理の新規開発で使い続けると、将来的な移行作業等が増加する可能性があります。
画面開発の機能についても同様に、Visualforce、Aura Component、Lightning Web Componentなど複数の選択肢があります。
新しい技術の採用には学習コストがかかり、技術課題が発生するリスクもありますが、将来の機能拡張性、開発者の確保、製品ロードマップとの整合性を踏まえ、現時点の作りやすさだけでなく、数年後の改修までを想定して方針判断をすることが大切です。

観点3：ベストプラクティスに基づいた設計

Salesforceは柔軟性が高い反面、設計ルールを設けずに開発を進めると、処理の重複や依存関係の複雑化が起こりやすくなります。例えばApexトリガやレコードトリガフローで自動化処理を作る際、1つのオブジェクトに対して複数のトリガやフローが存在すると、処理順序や影響範囲を把握しづらくなります。1オブジェクトに対して処理の入口を整理し、ビジネスロジックを適切に分離するなど、責務を明確にする設計が推奨されています。
このようなベストプラクティスの考え方はプロコード開発においてはコーディング規約として開発前にルールが決められることが多いですが、ローコード開発でも同様にルール整備をして開発者に周知することが大切です。

まとめ

機能の保守性を高めるSalesforce設計とは、単にプログラムをきれいに書くことではありません。業務変更に追従できる構造にすること、設計意図を後から理解できるようにすること、利用する機能の将来性を見極めること、そして開発者・管理者・業務部門が共通理解を持てる状態を作ることです。
Salesforceは柔軟性が高いからこそ、設計の自由度も高くなります。その自由度を活かすためには、公式ドキュメントやArchitecture Centerなどの情報を継続的に確認し、最新の推奨事項を踏まえて判断することが重要です。なお、本記事の内容は2026年6月時点の公開情報をもとにしています。

参考URL

●Salesforce Architecture Center
https://architect.salesforce.com/