1
/
5

Salesforceエンジニア必見!Salesforce導入を成功させる設計のコツ

セールスフォース開発事業及び

エンジニアのキャリアアップ支援を行っております

株式会社CENTOです。


「Salesforceって、プロジェクトやってると顧客が業務に合わせようとしてどんどんリクエスト出てくるんだよな」
「顧客の業務にSalesforceを合わせていくと開発入ってくるけど、どこまでSalesforceに手を入れたらいいんだろう」

Salesforceエンジニアの方はこのように悩むこともあるでしょう。
Salesforceのプロジェクトに取り組んでいくと、顧客からのリクエストが広がって予定外の開発に発展することも。

Salesforceプロジェクトを成功させるには、十分に設計を行うべきです。
後出しの要件が増えるほど、全体設計に影響を与えてSalesforceの良さが潰れかねません。
そこで今回は、Salesforce設計のコツを解説します。

Salesforce設計のコツ:標準機能をベースにしましょう


Salesforceの設計は標準機能を中心に組み立てるべき理由は、以下の3点です。

  • Salesforceのバージョンアップに対応するため
  • Salesforceを自社でカスタマイズさせるため
  • SalesforceをシステムのHubにするため

それぞれ解説していきます。

Salesforceのバージョンアップに対応するため

まず、Salesforceの進化についていくためには、開発は最小限にすべき。

開発を入れるとSalesforceが年3回実施するバージョンアップにおける恩恵を受けにくくなるからです。

Salesforceのバージョンアップは、多い時は100個近い機能追加があります。
その度に、開発部分における影響度合いをチェックする必要がでてしまいます。
場合によっては革新的な機能なのに使えない、ということもあるわけです。

もちろん、機能の有効化をしなければ勝手に環境が変わるということはありません。
一方、Salesforceのバージョンアップは世界で20万社ある既存顧客のリクエストに応じて、億単位の資金をかけた開発がされているわけです。

例えば、社内SNS「chatter」は、2010年にバージョンアップの中で機能追加されました。
社内SNSの機能は、当時、IBMなどから提供されるものを導入すると数千万円かかるというケースもあるほどでした。それをSalesforceユーザーはバージョンアップの機能追加で導入できています。
さらに、今後はAIの機能もバージョンアップで組み込まれるかもしれません。

こうしたバージョンアップの恩恵を得やすくするため、できるだけ標準機能をベースに設計しましょう。

Salesforceを自社でカスタマイズさせるため

導入後も現場リクエストに対応しやすくするために、標準機能を中心に設計しましょう。
なぜなら、開発してしまうと安易に設定変更しにくくなるから。

例えば、ある企業のコンタクトセンターを例にみてみましょう。

その企業では、Service Cloudを導入した際にオペレータが後から要件を追加して画面開発をしました。
それにより、設定変更のたびに影響範囲の確認が必要に。
その結果、例えばオペレーターのヒアリング項目が変更になっても、Salesforce側の変更がすぐにはできない状態になってしまいました。
開発が入ると、システム環境が複雑になって変更を加えにくくなり、結果として業務の変化についていけなくなります。
一方、Salesforceは標準機能の範囲であれば、ポイント&クリックで変更可能です。
つまり、標準機能を基本に作っておけば、現場の変化にすぐ対応できるわけです。
Salesforceの強みでもあるため、うまく活かしていきましょう。

SalesforceをシステムのHubにするため

Salesforceは、関連ソリューションとシームレスに連携ができるように最初から作られています。
例えば、マーケティングならPardotやMarketing Cloud、帳票系ならApp Exchangeの関連ソリューション、というようなイメージ。
それに対して、開発を多く加えていくと、連携する際に影響が出ることがあります。
綺麗にシステム連携できるように、開発を加える際には注意しながら進めることをおすすめします。

標準機能を使わずにうまく連携できないシーンは、例えば、Pardotだと以下の通り。

  • リードの機能に開発を加えてしまう
  • 使いにくいからと行ってカスタムオブジェクト でリードもどきを作ってしまうこと

このような判断をしてしまうと、マーケティングなど関連する領域への拡張性が失われてしまいます。
設計のタイミングで意識しておくことで、最適な利用シーンを作っていきましょう。

設計後の構築段階で開発要件が出てきたらどうすべきか?


それでは、顧客からのリクエストで構築段階で開発要件が出てきたらどうするか?
設計段階ではどうしても洗い出せなかった要件というのは、よくありますよね。
追加の要件が開発を加えないと満たせない場合は注意して進める必要があります。
その際の進め方を以下、解説していきます。

顧客にデメリットをしっかり説明する

Salesforceに対して予定外の開発をする時は、メリット・デメリットをしっかりと伝える必要があります。
できれば資料ベースで用意して、残るようにするべき内容といえるでしょう。
プロジェクトが大規模になると、過去の経緯が曖昧になりがち。トラブルに発展した時に、顧客から「そっちがもっと説明するべきだった」と責められることもあります。
そうならないように、しっかり説明を入れておきましょう。

将来的にどこまで拡張するかを確認する

次に、顧客はSalesforceをどこまで展開したいと考えているかを確認しましょう。
予定外の開発をすることで、顧客の求める完成型になるならいいわけです。
開発した状態で塩漬けにし、Salesforceのバージョンアップも有効にしないなど気をつけていくだけですみます。
とはいえ、Salesforceのプロジェクトは大抵の場合、うまくいくほど拡張を考えていくことが多いもの。
そう考えると、拡張性の担保をするためにも、予定外の要件は標準機能で可能な限り対処すべきといえます。

Appexchangeなどアドオンで解決できないかを模索

構築段階で後から出る要件として、どうしても帳票などSalesforceが弱い部分の要件にあたることもあります。
そんな時はAppExchangeを活用しましょう。AppExchangeでは、購入してダウンロードするだけで簡単にSalesforceと連携して使えるアプリが取れます。その中では帳票ツールや名刺管理など3000種類以上のアプリが提供されています。
顧客の要件対応に困った時は、こちらをみてみましょう。

どうしても必要な要件のみ開発

どうしても開発が必要な場合は、最小の開発に抑える方法を考えましょう。
特に、画面開発や大幅な機能追加を伴う開発には注意が必要です。

問題点を解説するため、某ハウスメーカーの営業向けに導入された事例をご紹介します。

こちらの企業では、2013年にSalesforceを導入。
プロジェクトの中で、以下のような要件があり実装しました。

商談フェーズの進捗を右から左に追いかけたい(標準は左から右)
フェーズの進捗ごとにヒアリング項目を表示させたい(約120個)

上記要件を満たすために開発を押し進めた結果、以下のような問題が起きてしまいました。

  • 市場に合わせてヒアリング項目の変更ができない
  • バージョンアップで得られる機能を追加できない(影響度合いをチェックする予算がない)
  • Lightningへの移行に多額の費用が必要になる
  • 社内で「Salesforceの開発は高いらしい」と噂が流れ活用推進しずらくなる

Lightningがリリースされた頃には、Salesforceの担当者は2回も変わっていて、導入時の背景を知りませんでした。
このようなケースから、現場の要求に合わせて画面開発をしてしまったのが、後々大きく影響してしまうことがわかります。
設計から外れた開発を安易に入れてしまうと、後々、柔軟性を落とす結果になるため注意が必要です。

まとめ:Salesforceの導入は設計を重視しましょう

Salesforceは設計を重視し、標準機能を大切にしましょう。
Salesforceは進化を続けるツールである上に柔軟性の高さが強み。開発を入れすぎてしまうと、柔軟性がなくなってしまうこともあります。
Salesforceプロジェクトは業務に深く入りこむため、個別要件が出やすいもの。
うまく最小の開発でSalesforceに落とし込むのがエンジニアの腕の見せ所といえます。
実際にSalesforceの設計をする時は、標準機能を強く意識して進めましょう!


弊社ではエンジニア様と同じ目線に立ち

キャリアについて考えています。

弊社事業にご興味ある方は

気軽にお声がけください。

株式会社CENTO's job postings
5 Likes
5 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more