マルチクラウドを採用したアーキテクチャで、狙い通りの効果を実現

三越伊勢丹グループのクレジットカード事業を担当されるエムアイカード様のCRMシステムをクラウドサービス上で構築しました。これまでエムアイカード様のコンタクトセンターでは、お客様からのお問い合わせに対してオペレーターが基幹システムを操作して回答したり、承ったご依頼を紙に起票して事務処理を行うなど、前時代的な形式で運用してきました。そこでSalesforceを用いてコンタクトセンターの省力化やペーパーレスを推進し、さらには全社の業務基盤を構築するという目的でプロジェクトが立ち上がりました。

私はプロジェクトマネージャーとしてプロジェクト全体の運営を担当しました。

私はアーキテクトとしてプロジェクトを横串で見ていて、リーダー的に動くこともあれば、実装面だけフォローして入るケースなど、時々によって役割を変えて取り組んでいました。

一番の工夫は、お客様のご要望を実現するために、拡張性の高いマルチクラウドにしたことです。Salesforceは画面をつくるところは簡単にできるのですが、コスト面などの観点から膨大なデータを溜めることが苦手で、Salesforceの外にデータを置いて連携させたほうが、それぞれの特徴が活かせて効率のいいシステムになります。クラウドサービス間のデータ連携ハブとしてSkyOnDemandを選択し、APIやバッチで連携を行っています。

クレジットカード会社には１年で数億件になってしまうデータも存在します。そういったデータはSalesforceではなく、Amazon Web Service（AWS）を使ったのです。

AWSは、性能を段階的にスケールアップできるので、使うぶんだけデータ容量を拡げられるのも都合がよかったですね。無事、サービスに影響もなく対応できました。実際にやってみるとデータの増え方が想定していたよりだいぶ早かったので、AWSにデータを溜めるという判断をしていなかったら作り直しになっていたかもしれませんね。

今回は開発期間が短かく、すべての機能を一からつくることは現実的じゃなかったので、CRMのための基本機能が用意されているSalesforceが最適でした。一方でSalesforceには適さない機能についてもクラウドサービスを採用することで短納期を実現しました。

そうですね。今回は比較的素直にSalesforceやAWSを組み合わせていますが、お客様によっては、コストやユーザビリティの観点で「あえてSalesforce内に置く」といったケースもあると思います。アーキテクチャの決定にあたっては、機能上の要件だけで決めるのではなく、「長期的にメンテナンスしていくシステムなのか」といった保守性なども含めるべきです。

利便性を損なわずにセキュリティを担保するところが大変でした。顧客情報を扱うのでセキュリティを重視しなくてはなりませんが、単純にセキュリティだけを取ると使い勝手が悪くなってしまうので、どこまでどういった情報をSalesforceに置くのかはだいぶ議論を重ねました。

Salesforceの制約にも苦労しました。ツールって、うまく使えれば便利ですけど、ツールでできること・できないことを理解していないとスムーズに進められません。試行錯誤になるところもあったので、そういった中で社内の体制をつくっていくことには難しさを感じました。

まだまだSalesforceを十分に理解しているメンバーが少ないので、もっと分かるエンジニアを増やしていきたいと思います。理解が深くなればお客様への提案の幅も広がりますし、プロジェクトのスピード感にもつながります。Salesforceは「プロトタイプをつくってデモをやってフィードバックを受けて、修正して…」という進め方が向いているので、その特性を活かしてもっとお客様に価値を提供できればと思います。

2014年の暮れからプロジェクトが始まって段階的にリリースを繰り返していますが、いまも「社内の休暇申請などのワークフローの仕組みにSalesforceを使おう」だとか、「法人向けの営業にSalesforceを活用しよう」だとか、様々なアイデアをカタチにしようとプロジェクトが続いている状況です。

今後は全社の基盤としてSalesforceを使っていきたいという想いがあるので、引き続き最適だと思われる提案をしていきながら「グロースエクスパートナーズと一緒に作っていく」といった関係性を深めていけたらと思います。