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

第13章. ロールアップとまとめ

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

本書の目的は、Salesforce プラットフォームを構成するシステムの形状のアウトラインを描くことである。本書で取り上げたのはコア要素の一部 に過ぎないが、これらは、Salesforce を使用して構築するソリューションの多くを構成するパワーツールであり、構成要素である。エコシステムの範囲と変化の速さのため、私の経験上、最も一般的に使用され、ライセンスされているツール、および既存の、おそらくよりよく知られている製品に最もよく類似しているツールに焦点を当てることにした。ツールやその機能は、Salesforce のマーケティング資料におけるプレゼンテーションと同様、時間の経過とともに変化していくだろう。本書を読めば、Salesforce の試験に合格できるわけではない。

主要なクラウド・プロバイダーと仕事をしたことがある人なら、そのすべてが本来の役割をはるかに超えて拡大していることを理解しているだろう：アマゾンは単なるショッピング・システムではない。マイクロソフトはソフトウェアを販売しているだけではない。Googleは単なる検索エンジンではない。セールスフォースは単なるCRMシステムではない。新しい機能が次々と登場し、その進化のスピードは驚異的だ。

他のテクノロジーやシステムのバックグラウンドをお持ちの方は、ブランディングの霧を見通すことができるようになっただろう。Salesforceのエコシステムには活用できる機能が数多くあり、それらがどのような場面で威力を発揮するのかを理解した上で、活用すべきである。Salesforce に関連するアーキテクチャのプラクティスは、同様の特性を持つ他のシステムにも当てはまる。もちろん、プラットフォームの内外に存在するツールやコンポーネントには違いがあるが、理解できないほどではない。

ブランドの成長に重点を置いているため、買収や進化に注意を払う必要がある。絶え間ない名前付けや改名、マイナーチェンジによって、Salesforce の機能を把握するのは少々厄介だ。また、Salesforce プラットフォームに特化したユーザは、Salesforce にしかなじみがないため、この課題もさらに深刻になる。多くの実務担当者は、「アカウント」や「オブジェクト」といった単語について、Salesforce のコンテキストに特化した理解を持っているが、プラットフォームに精通していないユーザーにとっては、根本的な定義を理解せずに新しい概念を学んだり、アイデアを交換しようとすると、導入が遅れる可能性がある。本書の基本的なゴールの1つは、このギャップを埋めることであり、Salesforceに精通したユーザが、Salesforceの用語や機能が外部製品とどのようにマッピングされているかを理解できるようにすることである。Salesforceを特殊化しているのであれば、ぜひ他のシステムも理解してほしい。より良いアーキテクトになるために、プラットフォームを横断した知識を身につけよう。

経験豊富なアーキテクトは、さまざまなシステムがどのように機能するのか、常に理解を深める努力を怠らない。どのシステムにも長所と短所があり、それらを学ぶことでスキルが向上する。異なる製品行が提供するさまざまな制約や自由は、ある仕事には最適だが、別の仕事には不向きである。クロスプラットフォーム・アーキテクトになるということは、目の前の問題に対して、どの技術を活用するのがベストな選択かを知るということだ。他に何があるかを知らなければ、最適なソリューションを提供することはできない。Salesforceの中でほとんどすべてのことができるが、それが必ずしも理想的とは限らない。アーキテクトが、顧客がすでに持っている機能（データストレージ、ETLシステム、ミドルウェアなど）にお金を払うことで、ソリューションのコストを倍増させていることを知らなかったために、プロジェクトが失敗したこともある。逆に、利用可能なエコシステムコンポーネントを理解していないと、コストのかかるチャンスを逃すことになりかねない。 ...