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

第11章. アーキテクト

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

これまでの章では、Salesforce の基本的な技術概念について説明してきた。ここからは、Salesforce で働くアーキテクトの役割について、より具体的に掘り下げていく。第 5 章で触れたように、アーキテクトは情報技術の世界でよく誤用され、混同される用語のリストに入っており、Salesforce では他のどの領域よりも明確な定義はない。さまざまな定義の区別はせいぜい曖昧で、ほとんどすべての定義に例外やオブジェクトが存在する。

話を始めるにあたり、非常に単純な定義を用い、そこから広げていくことにする。この章でわかるように、プロジェクトにおいてアーキテクトが取り得る役割には様々なものがあり、それらは様々な職種にまたがる。私が一緒に仕事をしてきた中で、最も熟練したアーキテクトの中には、プロジェクトマネジメント、ビジネス分析、ユーザ体験、顧客関係のスキルを融合させ、複雑な傑作機能を実現した人もいる。また、アーキテクトのキャリアを通じて、多様な実践的構築スキルや開発スキルを蓄積してきた人たちにも多く会ってきた。このような役割を職種に明記するか、1人または数人に分散させるかは、取り組みの規模による。たいていの場合、これらの役割の目標を見据えた上で、それぞれにどれだけの時間を割くかを決める。これらの概念の多くは、大規模なプロジェクトや、調整すべきチームが多数ある場合にのみ重要になる。プロジェクトを計画する際には、コミュニケーションプロセスを適用し、文書化と図式化を計画に加えることをお勧めする。

ビルダー対アーキテクト

ビルダーは、定義された一連のスキルやツールを使ってものを作成する。開発者、エンジニア、デザイナーはビルダーの一例である。ビルダーは通常、特定の水平または垂直領域で働く。フルスタックエンジニアは、同じ垂直方向または水平方向の複数の階層で構築する。(フルスタック」とは、フロントエンドとバックエンドの両方のコードを書くという意味もある。）

アーキテクトは、複数のスタックにまたがる様々な構成要素を複合的なソリューションに組み立てる計画を構築する。アーキテクトのスキルは多次元的であり、効果的で全体的なソリューションを提案するためには、各コンポーネントの特性に関する十分な知識が必要となる。ソリューションには、技術的な側面だけでなく、予算、セキュリティ、システムリソース、従業員リソース、スキルセット、長期メンテナンス、パフォーマンス、プロセス、成功指標、暴露、コミュニケーション、適合性、利害関係者の調整など、シナリオ全体の他の側面も考慮しなければならない。

ビルダーとアーキテクトの役割は、互いに排他的なものではない。Salesforceエコシステムの成長は、多くのビルダー・アーキテクトを作成してきた。"ビルドできない人がアーキテクトになる "という定義が正しいかもしれない。プロジェクト・アーキテクトとして私が好きな例えは、あるウェブを操るスーパーヒーローの役割を担うことだ。つなげるべきものを見つけ、理解の架け橋を作成してつなげる。間接的につながっている概念間の関係を共有する。人やアイデアをつなぐために理解の網を張る。まさに身近なパターン人間だ。

アーキテクトの役割の種類

大規模な Salesforce 実装やカスタマイズプロジェクトでアーキテクトが果たす役割の多様性は、ほとんど認識されていない。また、プロジェクトを全体像に整合させるというアーキテクトの役割に、直接的な価値を代入することも難しい。セキュリティの役割と同様、アーキテクトの価値が明らかになるのは、アーキテクトの不在によって何か問題が発生した後であることが多い。一部の役割は、将来を見据えたものであり、演算子の少ない未開拓の分野で活動するものである。しかし、ほとんどではないにせよ、多くは基本的にサポート役である。はっきりさせておきたいのは、これらはすべて ...