Force.comのテクニカルアーキテクトに求められる知識とスキル - TECH BLOG

はじめに

本ブログの読者の中には、Force.comを活用した周辺システムを含む、システム全体のアーキテクチャーをデザインする方も多くいらっしゃると思います。今回はそのような役割を担う上で、どのような知識やスキルが求められるかについてお伝えしたいと思います。

アーキテクトに求められる知識やスキルと言ってもなかなかピンと来ないかも知れませんが、salesforce.com認定テクニカルアーキテクト（TA）のStudy Guideに記されている内容の一部をピックアップし、補足する形で説明したいと思います。また、自身の過去記事の中でテーマとして取り上げたものや、セールスフォース・ドットコム社が提供する一度は目を通しておきたい大事なドキュメントもありますので、合わせてご紹介しておきます。

Study Guide

プラットフォームアーキテクチャーの概念

システムの利用者は社内ユーザ、あるいは社外ユーザも含まれるでしょうか？社内ユーザの場合、求める要件や利用者のロールによってはSalesCloud、ServiceCloudのライセンスを選択することにより、標準機能を活用できる可能性があります。

社外ユーザも使用する場合、Partner Community／Customer Communityの何れを選択するのが適すでしょうか？機能面の違いを押さえると共に、特にセキュリティ面も考慮した選択が重要になります。社内ユーザ・社外ユーザ含め、選択したライセンスの違いにより、標準機能で実現できること、制限事項となることを押さえたいものです。

また、Force.comはプラットフォームとして優れていることは言うまでもありませんが、例えば大量データの分析を行う要件に対して、場合によっては別途BIの導入を検討するなど、プラットフォームとしての特性や制限も踏まえ、ビジネス要件に対する代替案を具体的に提言できるようにしたいものです。（例に上げたBIはWaveが発表されたわけですが。）

セキュリティ

セキュリティ要件は大変重要な位置付けとなり、Force.comが提供する強力なセキュリティコントロールを活用できるかの見極めがポイントとなります。

オブジェクトレベル／レコードレベルのアクセスコントロール、ライセンスの違いによるアクセスコントロールの違いを理解します。セキュリティ要件によっては、Apexを使用して対応せざるを得ないケースがあるでしょう。この時、Visualforceのコントローラーのロジックでアクセスコントロールするのか、あるいはApexトリガ等を使用して適切な共有をシェアオブジェクトに更新するのでしょうか？Apexを使用した実装としても、実装方法の違いによりセキュリティリスクに違いが生じる点を考えたいものです。

また、Partner Community／Customer Communityでは、アクセスコントロールの仕組みが大きく異なります。機能面の違いに着目するだけではなく、アクセスコントロールが標準機能でどのように実現されているかの違いを十分理解しておくことが重要です。

最近では、Single Sign-On（SSO）のニーズは多いです。そのため、社内のActive DirectoryやLDAPといったID管理が既に入っている場合、Force.comとIDを一元管理するための実現手段とそのメカニズムを理解します。

社外ユーザが利用する場合、FacebookやTwitterのようなSNSのIDを使ったログインを行いたいニーズもあることでしょう。そのようなニーズを満たすためにForce.comが提供している機能や、そこで使われるメカニズムも押さえておきたいものです。

SSOに関してはスタンダードな認証方式を取り入れる方向性をまずは検討すると思いますが、SAMLやOAuthはSalesforceのDeveloper Editionを準備するだけで試すことができますので、理解を深めるためにも実際に設定してみることをお勧めします。

【過去記事】
Salesforce／Force.comのデータセキュリティ（オブジェクトアクセス）
Salesforce／Force.comのデータセキュリティ（レコードアクセス）
SalesforceだけでSSO（OAuth2.0）を試す：事前準備編
SalesforceだけでSSO（OAuth2.0）を試す：実装編

アプリケーション設計パターン

Force.comを活用する上で、いかに標準機能（宣言的開発）を活用するかは重要なポイントとなります。そのため標準機能を活用することのメリット／デメリットを正しく理解しておきたいものです。

標準機能で実現不可能な要件の場合、ApexやVisualforceを使用した個別開発を行うケースが生じます。ApexやVisualforceで開発したものが、将来的なユーザ数やデータ量の増加に伴い、ガバナ制限やViewStateの制限等に抵触するなどの発生し得るリスクやその軽減策、保守性を高めるための技術的な対応手段を押さえておきたいものです。また、大容量データを扱う場合のパフォーマンスを劣化させる要素、それを軽減するための対応策も合わせて理解が必要になります。

【本家サイトより】
大量データを使用するリリースのベストプラクティス
Visualforce のパフォーマンス: ベストプラクティス

連携パターンとベストプラクティス

Force.comの機能を補う目的でForce.comとシステム連携するケースは多々あります。Force.comを周辺システムと連携させるために標準機能で提供される機能やその特徴、Apexを使う場合のリスクや制限事項、連携のために使用するAPIの種類とその使い分けを理解します。（例.SOAP API、Bulk API、Rest API、Streaming API）

また、連携を行うためにEAIやETLの使用を想定するケースもあると思いますが、そのようなツールを使用することのメリットも押さえておきたいものです。

周辺システムとの連携は日常の運用として連携を行うものもあれば、マイグレーションの一部として行われるケースもあります。マイグレーションを伴うケースの場合、特に初期データ移行が難航するケースが多々あるため、そこでのリスクや実施手順等を理解しておきたいものです。

【過去記事】
Salesforceシステム連携のデザイン考察 1（ニーズとアプローチ）
Salesforceシステム連携のデザイン考察 2（ビジネスロジック連携／データ連携の検討ポイント）
Salesforceシステム連携のデザイン考察 3（仮想シナリオから考える連携デザイン）
初期データ移行の勘所

開発ライフサイクルとリリース計画

要件定義を行い収集したビジネス要件が最終的なリリースに至るまでの過程をトレースすることは出来るでしょうか？

実施するテストとその計画、リスクを軽減するために重点的に行うテストなどが考慮できる必要があります。また、最終的なリリースに至るまでの開発環境やステージング環境をSandboxを使ってどのように構成し、メタデータを各環境にどのようにデプロイするのかが設計できる必要があります。複数あるデプロイのための手段と特徴を理解しておく必要があります。 Force.comを導入するうえで、開発手法はどうされていますか？ウォーターフォール／アジャイル、あるいは両方をハイブリッドに行うケースもあると思います、各手法のメリット／デメリット、開発手法を適用しデリバリするうえで、顧客特性や案件の特性に合わせた使い分けの必要性などの知見を持ちましょう。（開発手法の選択に正解があるというものではありませんが。）

【過去記事】
開発ライフサイクルとリリース計画で意識したいこと

コミュニケーション

テクニカルアーキテクトはステークホルダーに対して、Force.comを活用したEnd to Endのシステム全体像、技術的な制限・課題等を具体的な代替案含めて説明できる必要があります。説明にあたり、適切な図解を用い、明確かつ簡潔に説明することを心掛けたいものです。また、ステークホルダーからの予期せぬ質問等に慌てることなく、冷静に対応できるコミュニケーション能力も求められます。

おわりに

Force.comを活用したシステムは、周辺システムとのSSOやインテグレーションを含め、システム構成は複雑化／拡大化しており、システム全体を拡張性や保守性に優れたデザインに出来る能力が求められていると感じます。簡単な内容でしたが、ご紹介した内容を通じてForce.comを活用するための良いアーキテクチャーを考えていくためのヒントや気付きになれば幸いです。

おわりに、Force.comのエンジニアの方には是非とも認定テクニカルアーキテクトを目指して欲しいと願ってます。最難関資格であり、合格までの道のりは簡単ではありませんが、大変意義ある資格だと思います。今年めでたく合格した岩井もブログに寄稿していますので、こちらも参考にしてみて下さい。