Salesforceのカスタマイズが技術的負債になる前に | 保守しやすい設計と運用の作り方

#「便利にしたはずが、誰も触れない」問題

Salesforce導入時にコンサルタントや開発者が作ったカスタマイズ。当時は業務にぴったりフィットしていたのに、数年後には「なぜこの設定があるのか誰もわからない」「変更したいが影響範囲が読めない」「触ると何かが壊れそう」という状態に変わっている。これがSalesforceにおける技術的負債です。

技術的負債が蓄積すると、以下の悪循環に陥ります。

1. 既存のカスタマイズが複雑で変更できない
2. 新しい要件に対応するために、さらにカスタマイズを上乗せする
3. 全体の複雑さが増し、ますます変更できなくなる
4. 管理者の工数が「保守」に消費され、「改善」に回す時間がなくなる

#カスタマイズが負債になる3つの原因

#原因1: 標準機能で対応できるのにカスタマイズした

Salesforceの標準機能は年3回のリリースで継続的に強化されています。5年前にカスタマイズが必要だった要件が、現在は標準機能でカバーされているケースは珍しくありません。しかし、一度カスタマイズを作ると「動いているから触らない」という判断になりがちで、標準機能への移行が後回しにされます。

#原因2: 変更の理由を記録しなかった

「なぜこのカスタムフィールドが作られたのか」「なぜこの入力規則がこの条件になっているのか」。作成時の背景と理由が記録されていないと、後任者は設定の意図を推測するしかありません。意図がわからない設定は「消すと何かが壊れるかもしれない」という恐怖から放置され、不要なカスタマイズが蓄積し続けます。

#原因3: 影響範囲を把握せずに追加した

新しいカスタマイズを追加する際に、既存のフロー、入力規則、トリガーとの整合性を確認しないと、予期しない副作用が発生します。「フィールドを1つ追加しただけなのに、レポートの数字がずれた」「入力規則を変更したら、フローがエラーになった」。こうした問題は、影響範囲の事前確認不足から生じます。

#カスタマイズの棚卸し手順

#ステップ1: カスタマイズ資産の全体像を把握する

以下の項目を一覧化します。

#ステップ2: 使われていないカスタマイズを特定する

以下の基準で「使われていない可能性が高い」カスタマイズを特定します。

• カスタムフィールド: 値が入っているレコードが10%以下
• カスタムオブジェクト: レコード数がゼロ、または最終作成日が半年以上前
• フロー: 無効化済み、または最終更新日が1年以上前
• レポートタイプ: カスタムレポートタイプで、参照しているレポートがゼロ

#ステップ3: 標準機能で代替可能なカスタマイズを特定する

特に以下のパターンは、現在の標準機能で代替できる可能性があります。

• カスタムボタン（JavaScript）: Lightning Experienceのクイックアクションや画面フローで代替
• Apexによる単純な項目更新: レコードトリガーフローで代替
• カスタムメール送信ロジック: フローのメールアクションで代替
• カスタム承認プロセス: 標準の承認プロセスまたはフローオーケストレーションで代替

#ステップ4: 優先順位をつけて整理する

全てのカスタマイズを一度に整理する必要はありません。以下の優先順位で着手します。

1. エラーが頻発しているカスタマイズ: 業務に支障を来しているもの
2. リリース対応で毎回修正が必要なカスタマイズ: 保守コストが高いもの
3. 使われていないカスタマイズ: 無効化・削除で複雑さを減らせるもの
4. 標準機能で代替できるカスタマイズ: 中長期的に保守コストを削減できるもの

#保守しやすい設計の5原則

今後のカスタマイズで技術的負債を予防するための原則です。

#原則1: まず標準機能を検討する

新しい要件が出たら、最初に「標準機能で対応できないか」を確認します。標準機能で要件の80%を満たせるなら、残りの20%を業務プロセス側で調整できないか検討します。カスタマイズは最終手段です。

#原則2: 1つのカスタマイズは1つの目的

フローやApexクラスに複数の責務を持たせない。「商談の更新時に、通知メールを送り、タスクを作成し、関連レコードを更新し、外部APIを呼び出す」という1つのフローは、4つの独立したフロー（またはサブフロー）に分割します。

#原則3: 理由を必ず記録する

カスタマイズのDescription欄、またはカスタムメタデータに「なぜ作ったか」「誰の要望か」「いつ作ったか」を記録します。3行で十分です。

#原則4: 影響範囲を事前に確認する

新しいカスタマイズを追加する前に、対象オブジェクトに既に設定されているフロー、入力規則、トリガーを確認します。競合する可能性がある場合は、既存のカスタマイズとの整合性を検証してから追加します。

#原則5: 定期的に棚卸しする

四半期に1回、カスタマイズの棚卸しを実施します。使われていないものを無効化し、不要になったものを削除します。リリース対応のタイミングに合わせると効率的です。

#まとめ

Salesforceのカスタマイズは業務効率化の強力な手段ですが、管理されなければ技術的負債に変わります。予防策の基本は「標準機能を優先する」「理由を記録する」「影響範囲を確認する」「定期的に棚卸しする」の4つ。既に複雑化している場合は、使われていないカスタマイズの無効化から始め、段階的に整理します。カスタマイズの数を減らすことは、管理者の負荷を減らし、リリース対応の工数を削減し、組織のSalesforce活用をより柔軟にします。

#aileadでカスタマイズの複雑さを軽減

aileadは対話データAIプラットフォームとして、Web会議の対話データをSalesforceに自動連携します。商談情報の手入力を前提としたカスタマイズ（入力リマインドフロー、データ補完ロジック、整合性チェック入力規則など）を削減し、対話データから直接Salesforceにデータを反映。カスタマイズの複雑さを根本から軽減します。400社以上の導入企業でSalesforceとの連携実績があります。お問い合わせからお気軽にご連絡ください。

#関連記事

• Salesforceフローが複雑になりすぎた時の整理術｜自動化を管理可能な状態に保つ方法
• Salesforceの年3回バージョンアップに疲弊しない｜効率的なリリース対応プロセス
• Salesforceの権限設定が複雑すぎる？プロファイルと権限セットを整理する実践ガイド
• Salesforce導入の失敗パターン5つ｜現場が使わなくなる原因と立て直し方