1．Salesforce開発の概要
①Salesforceで実現できること
Salesforceは世界No.1のCRMソリューションです。顧客管理、デジタルマーケティング、営業支援、ポータル、コンタクトセンタ・・・SoEの全領域をカバーしています。
②Salesforce開発の特徴
Salesforceの開発ではオブジェクト構成がキモになります。最初にオブジェクトと項目を定義すると、レコードの登録/参照/更新/削除操作を行うための画面が自動生成されます。自動生成された画面をカスタマイズしたり、フローチャートやバリデーションルールなどのビジネスロジックを定義したり、レポート・ダッシュボードを定義して追加することで、プログラム開発なしでビジネスアプリケーションを作成することができます。
Salesforceの開発では、これらのオブジェクトと項目、画面、ビジネスロジック、レポート・ダッシュボードなどのアプリケーションの定義をマウス操作のみで行うことができます。
個別のプログラム開発が必要になるのは、難しいビジネスロジックが必要な場合や、他システムとの連携が必要な場合、高度なユーザインタフェースが必要な場合など、標準機能ではお客様の要件を満たせない場合になります。
2．Salesforce開発を始める前に理解しておくべきポイント
ポイント1：プロトタイプ中心の仕様定義
開発におけるSalesforce活用の利点の1つは、画面/機能を非常に短期間で作成でき、実環境ベースで仕様を確認できることです。そのため、要件定義、場合によっては基本検討の段階からプロトタイプを作って、お客様と早期に仕様を確認することができます。
プロトタイプ中心の仕様決定プロセス
その反面、注意しなければならない点があります。
- 各プロトタイプでの確認範囲が不明確になりやすい
- 顧客との合意結果が曖昧となる傾向がある
プロトタイプの段階では、作り込んで完成に近い機能もあれば、省略して作らない機能も混在するため、その範囲をお客様とすりあわせること、曖昧にしないことが重要です。そのため、プロトタイプでの仕様定義では、プロトタイプでどこまで確定するのか、プロトタイプはどこまで作るのか？といったことを予め認識合わせすることが必要です。
要件定義における画面機能のプロトタイプ進め方（例）
このフローは、要件定義での仕様合意プロセスの例です。
プロトタイプを３段階に分け、
- サイクル1の利用イメージ確認では画面構成/データ構造の確定
- サイクル2では項目の確定
といったように、観点を明確にしていきます。
何回プロトタイプを回して要件定義を着地させるかによって、必要な期間も工数も異なってきますので、この辺のプランを予めたてておくことは、見積もりをする上でも重要です。
ポイント2：テストの考え方
続いて、2つ目のポイント、試験の考え方についてご説明いたします。
主に設定部分の試験をどのレベルで行うか、という点なのですが、処理テスト以降、スクラッチに近いレベルでの試験が最大では必要となると考えておいた方が無難です。
というのも、Salesforceの設定は、分岐や数式、複数の設定の組み合わせなどにより複雑化することが多く、その場合、必要なテスト観点はコード開発とかなり近くなってきます。
データバリエーションは多少削ってもよいものの、安易に試験項目を削減すると、設定部分のバグすり抜けにつながりリスクとなりますので注意してください。
ポイント3：非機能面の考慮点
最後に、非機能面での考慮点をご説明します。
Salesforce案件では、インフラの構築はいりません。
逆にいうと、サービス仕様に従うしかない領域が多いということでもあります。
よって、サービス特徴や制約について、お客様と早い段階で合意し、ものによっては運用や外部での対応を検討するといったこともタスクとして定義していく必要があります。
どのような制約があるか、注意点の例を紹介します。
（1）性能
Salesforceでは、特定ユーザがSalesforceのリソースを過剰に専有し、他ユーザのパフォーマンスに影響を与えないよう、制限（ガバナ制限）が設けられています。たとえばAPIのコール数や大量データの分析・計算処理など、サーバ負荷の高い処理はガバナ制限によって効率よく実施できない可能性があるため、それに抵触しないか、要求定義や設計時点であらかじめ漏れなく考慮しておく必要があります。
こうした考慮点は、成果物の非機能要求グレード表でも明記しており、漏れないように対応する必要があります。
（2）セキュリティ
また、セキュリティなど、非機能に関するタスクが全く不要というわけではありません。
セキュリティについては、かなりSalesforceとしても重視して投資をしているので、サービスとしてのセキュリティ対策は堅牢と言えると思います。
ただし、企業ごとに設定可能なパスワードポリシーやログイン可能なIPアドレスの制限、セッション管理、ログイン履歴管理など、プロジェクト側で設定等で対応しなくてはならない要素は多岐に渡るので、ガイドラインや社内ルール等を参照しながら必要な対策を計画します。
そのような、エアポケットに陥りやすい考慮点についても、必要なタスクとして定義します。
最後に、Salesforceは顧客接点系システムをワンストップで素早く提供できる強力なプラットフォームですが、Salesforce開発の特徴を理解し、それに合わせた開発手法が必要です。NTTデータには、Salesforceの開発手順、成果物雛形、規約雛形/ガイドライン・ツール、ナレッジ等が揃っています。是非、ご相談ください。
NTTデータのSalesforceソリューションについて詳しく知りたい方はこちら
https://www.nttdata.com/jp/ja/lineup/salesforce/
