Salesforceの再構築パターンを考察する

2000年にセールスフォース・ドットコムの日本法人が設立されてから、20年以上立ちました。現在では、日本全国で15万社以上が何かしらSalesforce製品を利用しているのではないでしょうか？

特に、コア製品であるSales Cloud、Service Cloud、Pardot、Community Cloud（Experience Cloud）を長年利用している企業が増えてきたかと思います。

長年、Salesforceを利用していると以下のような声を多く聞きます。

・導入当初とは設計思想が変わってしまった。
・セルフで構築した為、あまり活用できていない。
・見様見真似で構築して項目や自動化プロセスが複雑化してしまった。
・Apexなどのプログラムを組み込んでブラックボックス化してしまった。
・構築を担当したベンダーが引き上げてしまった。
・システム管理者が退職してしまった。
・Platformで構築したので、Sales CloudやService Cloudの標準機能が使えない。

導入当初とは設計思想が変わってきたとか、見様見真似で構築を進めてしまったとか、依頼したベンダーにすべておまかせしてしまったとか、Salesforce組織自体が複雑化と声を多く聞きます。Salesforce組織自体が複雑化してしまい改修が困難になった、標準機能を使わず構築した為、新機能やAppExchnageが利用出来ない、そもそもSalesforceをデータベースとして使ってしまっている。さまざまな問題や歪が出てきます。
そういった事象が発生している場合は、Salesforceを再構築を検討しなければ、ますます今後のビジネスの変革についていけないシステムになってしまします。Salesforce自体は、柔軟にカスタマイズできる反面、しっかりと将来性を見て標準機能を活用しないと本当に痛い目に会います。

ここで再構築する場合のパターンを考察してみたいと思います。といっても、再構築するパターンは以下の2つに絞られれます。なお、Salesforceを解約して他のシステムに移行するのは除外します。

既存のSalesforceを再設計して構築する
新たなSalesforceを契約して旧組織から新組織に移行する

過去に私は上記の2パターンの両方とも支援した経験があります。そちらをベースに考察したいと思います。

既存のSalesforceを再設計して構築する

Salesforceはサブスクリプションモデルの課金体型のため、ライセンス費用（年間コスト）が掛かります。そのためまずは、ライセンス費用を抑えることができる、既存のSalesforceをうまく活用して再構築できるか考える必要があります。見極めるポイントは以下の4つです。

見極めるポイント

・カスタマイズ部分が少ない。（オブジェクトや項目など）
・標準オブジェクトを変な形で使っっていない。
・ApexやVFといったプログラム開発が無いもしくは限定的である。
・他のシステムとAPI連携などが少ない。

再構築の方法

既存の組織を生かして再構築しますので、運用と平行してすすめる必要があります。既存の運用面に影響が出ないように考慮し、Sandbox等で新たな部分を再設計してリリースおよびデータの変換等を行います。
カスタマイズやプログラム開発が極小の場合に有効なので、カスタマイズ部分が多ければ多いほど難易度が高くなります。

新たなSalesforceを契約して旧組織から新組織に移行する

カスタマイズが多くプログラム開発が入り組んでいる場合は、スクラップ＆ビルドであるこちらのパターンが望ましいです。ライセンス費用も移行時には二重に発生する可能性はありますが、PlatformからSales CloudやService Cloudへの移行等であれば、年間のライセンス費用負担は上がりますが、移行に伴うライセンス契約期間を調整がしやすいです。（例えば特例で年間契約途中でも旧組織の契約期間を変更するなど）
ライセンス費用は、コストでなく
Sales CloudやService Cloudなどの標準機能を使えるメリット（ビジネスの変化に順応して事業を成長させることができるもの） ＞ ライセンス費用 
と考えてもらったほうがいいかと思います。

再構築の方法

運用面や移行等もこちらのほうが断然やりやすいです。
新たな組織で再構築して、旧環境からデータ移行を等を実施し運用を切り替えてもらうだけです。再構築時は、プログラム開発を最小にして、積極にAppExchangeアプリを活用します。また、旧環境は、移行不備などに備えてしばらくは契約が残るのうにしておいたほうが無難です。

さいごに

いかがだったでしょうか？
企業規模によっては、なかなな再構築も難しい場合もあるかと思いますが、今後は、標準機能をうまく活用しノーコード・ローコードで実装することがビジネスが変化しても継続的に成長できるプラットフォームにつながると考えています。