【Ltech#7 】LIFULLにおけるSalesforceの歴史＋開発環境まわりについて

LIFULLにおけるSalesforceの歴史
＋
開発環境まわりについて
2019/06/20
情報システム部 CoEユニット市来亮介

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。2
自己紹介
市来亮介（いちきりょうすけ）
2012/06：Salesforceの開発に携わり始める
Salesforceの資格をいくつか取得
• Platform App Builder
• Platform Developer II
• Sales Cloud Consultant
• Service Cloud Consultant
2018/05：LIFULL入社
CoEユニットに所属し、社内のSalesforceの開発・運用を行っている
※CoE：Center Of Excellence

1. LIFULLにおけるSalesforceの歴史
2. LIFULLでの開発環境・開発フローについて

Salesforceとは
全世界No.1の営業・サポート・マーケティングに特化した
クラウド型のビジネスアプリケーション。
マーク・ベニオフ氏
これからはNO SOFTWARE
34歳の1999年3月
賃貸アパートの1室でセールスフォース・ドットコムを起業
2019年1月期
約133億ドル
超簡単なCRMとしてスタート
2014 CommunityCloud → HOME'S PRO立ち上げ
2015 ServiceCloud → コールセンタで活用
2016 MarketingCloud
2013？ force.com → 営業がSFA利用開始
LIFULLとSalesforceの
簡易年表

LIFULLにおけるSalesforceの歴史

LIFULLでのSalesforce 始めの一歩
HOME’S PRO 利用者：不動産会社の人
CommunityCloudを活用し、
不動産関係者が問題解決のコミュニケーションを行う場
としてスタート
不動産関係者の業務上の問題も解決できる場として、
アプリケーション認証基盤としての機能追加
SFA 利用者：LIFULL営業マン
SalesCloudを活用し、営業が売上やクライアントを管理
するためのCRM（顧客管理システム）として利用
2013年頃？
2014年

Client Platform(CPF)
HOME'S PRO
取引先（会員）
PRO ID（利用者）
SFA
取引先（店舗）
取引先責任者（お客様）
商談（売上）
サービス
営業不動産会社
同じものを表している
当初、別々に利用していました
CRM（売上、顧客管理）サービス管理
HOME'S Manager
B2Bなどの
アプリケーション
利用

組織の統合
HOME’S PRO
取引先責任者
商談（売上）
サービス
営業
不動産会社
2017年統合しました
大事なのは顧客と営業が繋がったと言う事
そしたら何が出来る？

CPF
取引先責任者
商談（売上）
サービス
営業
不動産会社
オンラインでの受注請求書処理へデータ連携
メールマーケティング
レポートの提供
オンラインでのサポート
DWHでデータ分析
営業戦略に活用
HOME'S PRO からクライアントプラットフォームへ（CPF)
HOME'S Manager
B2Bなどの
アプリケーション
利用
バックオフィス
マーケター

集まってきました
CPF
取引先責任者
商談（売上）
サービス
取引を開始するには審査が必要
取引先審査G
GreenID検索システム
営業統括G
販売管理システム
経理G
契約したら請求が必要
みんないるなら
経費精算もSFで
日次採算G
チームスピリット
生産性を測りたい
＋LIFULL社員全員
オンラインでの受注
メールマーケティング
レポートの提供
オンラインでのサポート
カスタマーサポートG
サポートもSFで
連携
移管予定
統合
活用合理化

HOME'S
サービス
基幹系システム
マーケティング
人が結合させていた情報を

HOME'S
サービス
基幹系システム
マーケティング
人が結合させていた情報を
Salesforce
Salesforceが繋ぐ形に

Salesforce
サービスとバックオフィスの融合
LIFULL 社内インフラ化へ
情報が循環しながら蓄積されるプラットフォーム
反響行動データ
Pardot
Marketing
Cloud
分析

関わる人が増えてきているなかで、
LIFULLはどのように開発を行っているのか？

LIFULLでの
開発環境・開発フローについて

はじめに
• LIFULLのSalesforce開発事情
– 基本的に内製で開発
– リリースは毎週１～3回
– 開発はCoEユニット内だけではなく、
複数の部署で行っている。
– Salesforceのエンジニアは20数名（業務委託含む）

起案からリリースまで
1. 新規/変更案件を起票
2. CABにて起案内容の方針承認
3. 開発
4. CABにて開発内容の変更承認
5. 本番リリース

3. 開発
CABって？

CABって
• CAB＝Change Advisory Board
– 変更諮問委員会
追加・変更を行う上で統制を図る組織
– 変更内容を様々な観点から評価し、Salesforce組織
の統制を図る目的
• 審議している内容
– 開発ポリシーに沿っているか
– データのアクセス権限や実行権限が適切か
– 全体最適であるか
– 追加・変更内容の効果がどれくらいあるか
などなど

3. 開発

Salesforce開発のつらいところ
ソース管理がしにくい

Salesforce開発のつらいところ
ソース管理がしにくい理由（と思っていること）
• ポイント＆クリックでいろいろ作れる
• ソースコードもSalesforce上で直接修正できる
• 年3回のメジャーバージョンアップで機能がどんどん増える
Salesforceのいいところでもある！

LIFULLでのソース管理
※VF＝Visualforce

いまいちなところ
Gitのソース＝本番のソースではない
– GitでApex、Visualforceは管理しているけど、
その他のMetadataは管理していない
– 結局本番環境の設定が正としている

• これからやりたいこと
– SalesforceDXを用いた開発フローに変更
– CIを導入

ご清聴ありがとうございました

【Ltech#7 】LIFULLにおけるSalesforceの歴史＋開発環境まわりについて

More Related Content

More from LIFULL Co., Ltd.

【Ltech#7 】LIFULLにおけるSalesforceの歴史＋開発環境まわりについて