Salesforceはなぜ負債になりやすいのか

※Salesforceを悪く言うつもりは全く無く、使い方を間違えなければとても良いツールだと思うし、何を使っても使い方と適材適所ですよね、という話です…！

Salesforceの負債の95%くらいは以下の3つの機能・特徴にあると思っています。

1. DMLをフックとした機能全般
2. データの取り回しのしづらさ
3. Apex/VF/LWCなどの開発・保守性が悪くなりがちな機能

1. DMLをフックとした機能全般

Salesforceに限らずDMLをフックとした機能は処理が追いづらく、影響範囲が読めないため保守性の悪化につながりやすいです。

Salesforceだとワークフロールール/プロセスビルダー/フロー/トリガーが該当しますし、Salesforce以外だとRails / ActiveRecordで言うところのcallback、Laravel / Eloquent でいうところのモデルイベント、DBでいうところのトリガーになります。

Salesforceだとノーコード・プロコードの機能が混在していてさらに処理が追いづらく、それらの処理が互いに作用してうまく動かないこともよくあります。トリガーが２回評価されたり、評価順による不具合発生もよくあります。フローのようなノーコード機能だとテストコードを書かないことがほとんどなので不具合も発生しやすいです。

Salesforce以外の場合はDMLフックの機能を利用せず、DMLと一緒にベタに処理を記述するというアプローチができます。Laravelだとこんな感じでコントローラなどに処理を書いていく形になります。

$hoge = Hoge::create($attr);
$hoge->sendMessage(...)

対象DML全てで共通化できないデメリットはありますが、処理の追いやすさと不具合の発生しづらさという意味では許容できるトレードオフなのかなと思っています。

では、Salesforceではどうなのかというと、VF/LWCなどApexが記述できる カスタムなページ や カスタムのAPI であれば対応できます。一方で、Salesforceの 基本 は標準機能である「一覧画面」「詳細画面」「作成・編集画面」　です。全てのオブジェクトでカスタムページを作って対応するのはとてもコストが高くSalesforceの良さを活かしきれません。そのため、画面に関しては標準機能を使って、それでも実現できないビジネスロジックはDMLフックの機能で実現するのがSalesforceの一般的なプラクティスです。データインポートウィザードやデータローダーによる一括作成・更新などのユースケースにも対応できるため、そこまでロジックが複雑でなければ比較的安牌な選択肢とも言えます。

しかしながら、前述のようにロジックが肥大化したりいろんな場所に無秩序に実装されたりすると負債化するのと、途中でDMLフック方式からカスタムページ形式に移行するのは腕力・体力のいる作業になるため、DMLフックの力学が強く働いてしまいます。テストコードのない処理に対して振る舞いを変えずにノーコードをコードに置き換えないといけない、という難しさは容易に想像がつくのではないかと思います。

2. データの取り回しのしづらさ

Salesforceの標準機能の詳細画面では1:N前提の関連表示しかありません。そのため、1:1でテーブル切って、詳細画面には親テーブルの項目と並列で項目を表示する、といった表現ができません。また、レポート機能では1:1の参照として項目を横並びに表示することが実質的¹にできません。

以上から、Webで言う1:1でテーブル分割した方が良いようなケースにおいても、1テーブルに全てまとめた方がSalesforceとしては取り回しが良いことになります。こうして1テーブルに項目が大量に詰め込まれるという力学が働くことになります。

データ移行に関してもWebと比べると難易度が高いです。一般的なRDBだと UPDATE xxx INSERT INTO ... SELECT ... のような一括更新の作業は考慮事項の多さはあれど、手順としてそこまで複雑になるケースは少ないような気がします。

一方、Salesforceはこれらの一括更新をするにはデータインポートウィザードやデータローダーを使ってCSVでそれぞれのレコードを入力する必要があり、移行作業の複雑さが増える傾向にあります。また一時テーブルを作るような操作も実質的に難しいので取れる選択肢が多くありません。なにかあったときにPITRやDBインスタンスから復元するといったこともできません。フルバックアップも厳しいです。また、オブジェクトが各機能と密結合だったり、影響範囲を特定する難易度が高かったりと、Webでは「難易度高い」案件もSalesforceでは「実質不可能」になることも少なくないです。

3. Apex/VF/LWCなどの開発・保守性が悪くなりがちな機能

Apex/VF/LWCいずれもプロプライエタリな技術なため、Webな人がコードを読みづらい、あるいはスキルポータビリティが低くなる傾向があります。

VF/LWCではReactなどの技術スタックで記述することが可能ですが、相当技術感度が高い組織じゃない限りは採用されていない気がします。²

Apex・Visualforce・LWC ・SOQL・ガバナなどの制約によりコードの保守性が悪くなる傾向もあります。ライブラリなどのエコシステムも育っているとは言い難く、Web開発よりは導入ハードルが高くなりがちです。