実用的な Salesforce アーキテクチャ

第8章. プログラミングとカスタマイズ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、Salesforce のプログラミングとカスタマイズについて説明する。多くの読者は、これらのツールがすでに組織や演算子の中に存在しているため、ここで取り上げる概念に精通しているだろう。このような読者は、これらのツールの組み合わせ方や違いについて、より詳しい知識を求めているかもしれない。

プラットフォームをカスタマイズするためにコードを使わなければならないと考えるべきでない。いずれはそうなるかもしれないが、すべての新機能や機能アップグレードを素早く利用するためには、できるだけ多くの機能を「箱から出してすぐに」使えるように努力すべきだ。新しくリリースされた機能を含め）活用できる既存の機能があらかじめ組み込まれていないことを確認しない限り、カスタマイズを始めるべきでない。ソリューション・エンジニアは、コードがなくても、入ってくるニーズの大部分を満たすことができるはずだ。プラットフォームに追加された柔軟で近代的なプログラミング機能は、魅力的すぎるほど魅力的だが、カスタマイズを減らし、コードに拡張することなく、既存のプラットフォーム関数の中で可能性を追求することで、長期的な利点を得ることができる。

Salesforceのプログラミングとカスタマイズの状況は、マルチテナントと 宣言型対カスタム戦略という2つの主要概念に集約される。マルチテナントの制約は、共有される顧客/ユーザのリソースを保護するために、カスタマイズ技術の多くを色付けする。パフォーマンスを犠牲にすることなく最大限の機能を実現するために、Salesforce ではカスタマイズのための「宣言型」オプションを可能な限り表面化している。これらの宣言的オプションは、Webインタフェースからの設定である。クリック・ノット・コード」とも呼ばれ、コードへのアクセスを許可せずに設定や自動化のオプションを提供する戦略は、広くアピールされている。これは、「ローコード」ソリューション構築の世界的な動きと一致している。Salesforceは、より使いやすく、構築しやすいツールに投資しているため、Salesforceからより多くの機能が提供されることを期待したい。

プラットフォームの能力を見分ける方法

なぜアーキテクトにとってプログラミング環境が重要なのか？すべてのタスクを速く、安く、大規模にこなせる完璧なプラットフォームは存在しない。これらの側面は、たとえプラットフォームのネイティブ機能やコア機能をそのまま使っていたとしても、常に変数となる。クラウドプラットフォームを評価する際には、そのプラットフォームがどのような機能を持つのか、どのような制限があるのかを理解する必要がある。これは、オンプレミスの機能から移行する場合や、他のプラットフォームから移行する場合に特に重要である。宣伝されている機能が無制限であったり、他のプラットフォームと完全に同等であったりすると仮定すると、問題を引き起こす可能性がある。ユーザが "無限 "に何でもできるようなプラットフォームは、悪用され、オーバーロードしてしまうだろう。

新しいプラットフォームの適合性と能力を見極めようとするとき、私たちは極端な用語を多用して境界線を発見する。可能であれば、後で参照できるようにセッションを録音する。営業担当者が機能を過剰に説明することもある。図8-1は、能力を理解しようとするときに使用し、注意すべき用語をリストアップしたものである。 ...