Mark Hammer's blog

SalesforceやTrailheadに関する情報を投稿しているブログです。

Salesforceでコーディングをしない3つの理由

Twitterのタイムラインを眺めていると、以下のブログ投稿を見かけました。

tyoshikawa1106.hatenablog.com

この投稿を読んで、思うところを書いてみます。

TL; DR

  • 引用したyoshikawa-sanのブログの内容は間違いではないよ。
  • でも、「コーディング導入により発生する考慮点」もあるよ。
  • Apex等の開発機能を使うか決めるときは、「標準機能では必要な機能を満たせないのか」や、「Salesforceの運用にかけられる費用」を考慮した方がいいよ。

はじめに

ここでいう「標準機能」とは、Salesforce.com Inc. における、開発者サポート に含まれない機能をいいます。

具体例

  • 標準機能対象
    • カスタムオブジェクト、カスタム項目
    • プロファイル、ロール、共有ルール
    • ワークフロールール
    • プロセスビルダー
    • レポート、ダッシュボード
  • 標準機能対象外
    • Apexクラス、Apexトリガ
    • Visualforce
    • Lightning Aura Component, Lightning Web Component
    • フロー
    • API

引用したブログについて

内容としては、以下のようなものでした。

  • 「Apex開発やコーディングはやったらダメ」という話があるけど、Apex開発やコーディングを考慮に含めることで、実装可能な機能に幅が広がるよ。
  • ワークフロールール、プロセスビルダーでは手が回らないところを、適切にコーディングすれば実現できるよ。

上記については、まさにその通りだと思います。
ワークフロールールやプロセスビルダーでは、起動条件が複雑な場合の表現が難しく、また項目更新順の指定ができないことから、「特定の順序で項目を更新したい」という希望の実現ができなかったりします。

ただし、Salesforceでの開発は、標準機能のみの利用では考慮する必要がなかった部分を考慮する必要があります。

追加考慮1: Salesforce運用コストの増加

Salesforceの勉強会等でよく聞く悩みに、以下のようなパターンがあります。

  • ケース1
    • 導入時に開発会社にコーディング含む機能開発を依頼した。
    • その後、Salesforceバージョンアップによりコーディング部分が正しく動作しなくなった。
    • 結果、機能変更がないのに追加で費用が発生した。
  • ケース2
    • 導入時に、社内のSalesforce開発者がコーディング含む機能開発を行った。
    • その後、Salesforce開発者が退職したため、何も分からない状況で運用を引き継ぐこととなった。
    • また、Salesforceバージョンアップによりコーディング部分が正しく動作しなくなったため、Salesforceの保守に想定以上の時間を取られている。

これらは標準機能のみ使用した環境でも起こりえますが、以下の理由により、改修に係るコストは一般的にコーディングを行った環境の方が多くなると考えられます。

  • コーディング箇所の改修の場合、当然ながらApex等の開発者スキルが必要になる
  • 問題となっている機能の無効化が簡単にできない(下記「追加考慮2」)
  • Salesforceサポートを使用できないケースが発生する(下記「追加考慮3」)

追加考慮2: 機能無効化のための作業

「トラブルが発生したため、まずは動作を無効化したい」となった場合、ワークフロールール、プロセスビルダーは「無効化」ボタンがあるため、「まずは無効化し、トラブルを止める」ことがだれでも可能です。
一方、Apexクラス、Apexトリガの場合、このナレッジに従い、外部ツールをインストールするところから始める必要があり、「だれでも対応可能」なものではありません。

このように、Salesforceで開発を行った場合、「改修だけではなく、機能無効化も難しい」ことを考慮する必要があります。

追加考慮3: Salesforceサポート範囲の違い

www.salesforce.com

「はじめに」に記載した標準機能の場合、Salesforceサポートではライセンス費用のみで提供されるBasic Success Plan でもサポート対象となります。
一方、開発者サポート の範囲は、追加費用が必要なPremier Success Plan が必要となります。

また、コーディング部分の開発者サポートは、「200行以下」という条件があります。
つまり、「コーディング部分でよく分からないエラーが起きたのでなんとかしてほしい」はもちろん、「1000行程度のApexクラスでエラーが発生したので解決方法を教えてほしい」という問い合わせも対象外になり、「エラー発生個所を200行程度まで絞る」作業が発生します。
このように、トラブル発生時の問い合わせも、ある程度の開発者スキルがないと難しいものになります。

おわりに

「開発機能を使えば、実装可能な機能の幅も広がる。」これについて異論はありません。
しかし、開発機能を使うことで、導入時には見えなかった縛りが発生することも、知っておいて損はないでしょう。

個人的には、Salesforceでコーディングを導入する際は安易に考えず、

  • 標準機能では実装が難しい機能が、業務上必須である。

かつ、

  • 導入、保守まで対応できる開発会社に依頼し、保守分の費用を支払うことができる。
  • または、Premierサポートプランを契約でき、かつ一定以上の開発者スキルを持つ人物が社内に複数おり、「1人辞めたらSalesforce運用が立ち行かなくなる」状況ではない。

という条件を満たすか考慮したうえで決定した方が良いと思います。

おまけ

この投稿では「コーディング導入によって発生するネガティブな面」を主に記載しました。

では、「標準機能を使うメリット」は何か、について資料探しをしたところ、以下のSalesforce公式ブログを見つけました。
標準オブジェクト、標準機能を用いることのメリットについて5つ+おまけの理由が記載されています。

www.salesforce.com

Salesforce導入時にコーディングを導入するか、しないかについては、「コーディング導入による機能の幅の広がり」だけではなく、「コーディング導入によるデメリット」や「標準機能のみを使用するメリット」も知っていただいたうえでご判断いただいた方がいいと考えております。
この投稿がご覧になった方々の参考になれば幸いです。

追記

AppExchange(パッケージ)についてはこの記事を書いているときに頭になかったのですが、

  • パッケージ自体はボタンをクリックすればアンインストール可能(ヘルプ
  • ただし、パッケージの内容前提でカスタムオブジェクトやワークフロー、プロセスビルダー等を組み込んだ場合、アンインストール不可
  • パッケージの中には「サポート提供なし」のものも多く、トラブルがあったとしても対応してくれないケースあり(Salesforce Labs提供のパッケージもサポート提供なし)

と、コーディングほどではないにしろ安易に本番環境に導入するのは控えた方がいいものになっています。

もちろん便利な機能を組み込んだパッケージやサポート付きのものもありますので、そのあたりはケースバイケースで利用するものだと思います。

追記2

以下の引用Tweetをいただきました。ありがとうございます。

IdeaExchange自体はユーザの声から機能を追加する、いい仕組みなのですが、「7万Point集めても3年以上Updateなし」といったケースもあるので、ステータスが「COMING IN THE NEXT RELEASE」とかになったものを参考にするものがいいのかな、と思います。*1

参考

IdeaExchange の概要とステータスについて

*1:ちなみにSandboxプレビューの後にリリースノートから消された機能も存在します