ランサーズの技術負債になってしまったSaleseforceをリプレイスしました


## はじめに
この記事は [Lancers（ランサーズ） Advent Calendar 2020](https://qiita.com/advent-calendar/2020/lancers) 8日目のエントリーです。

2020年、ランサーズでは5年間利用して技術負債が溜まったSalesforceをリプレイスしました。その過程について記録になります。社内システムは直接顧客の目に触れることは有りませんが根本のUXを生み出すシステムだと信じています。今回のリプレイスでデータが繋がり可視化され適切にお客様対応ができるようになり広義のプロダクト品質に繋がったと考えています。
今回の記事でSalesforceを理解せずに実装していくと残念なことになるという反面教師と、同じ状況でお困りのシステム管理者の方々への一つの選択肢として伝われば幸いです。

## 背景

### 導入期(2014〜2015年)

2014年、大量の発注ができる法人向けサービス「ランサーズ for Business(現 [Lancers Outsourcing](https://www.lancers.jp/business?ref=q_t))」がスタートしました。業務管理システムとしてSalesforce Sales Cloudを導入します。見積、発注、売上、原価を管理するための機能を構築しました。業務管理システムになぜSalesforceなの？と疑問持たれそうですが、システム化が急務だった上にカスタム要件が高いことが見えていたので拡張性の高い同製品を選ぶのは有りだったと思います。当時はマーケティングやインサイドセールスといったCRM機能に対しての優先度は高くありません。
この頃、自分はLancersプラットフォーム本体の開発をする傍らでSalesforce管理者を担当しました。

### 拡大期(2016〜2019年)

その後、マッチングをサポートする[Lancers Pro](https://www.lancers.jp/pro?ref=q_t)、秘書業務や営業業務を依頼できる[Lancers Assistant](https://www.lancers.jp/assistant?ref=q_t)、タレントプール構築や発注管理ができる[Lancers Enterprise](https://www.lancers.jp/enterprise?ref=q_t)といった法人向けサービスが拡充してきました。これに併せて与信管理、契約管理、請求管理といったバックオフィス部門をサポートする機能を構築しています。
この頃から自分がSalesforce主担当になりました。

### リプレイスへの決断(2019年)

突貫で増築に増築を重ねたシステムにほころびが出てきました。

#### 各サービス、各チームに対応した業務フローによる開発コスト負担増
各サービスごと、チームごとに業務フローを実装していました。同じサービスでもセールス部門とバックオフィス部門で業務が変わるため自然と実装が複雑になります。数式にIF文が増え合計サイズエラー(5000Byte)に悩みました。画面数もそこそこ増加。最終的に商談オブジェクトはページレイアウト１８つ。１項目追加するのに全ページレイアウト更新するなんてことが起きていました。

#### Salesforce標準のCRM機能をカスタムしてしまった
マーケティング部門からSalesforce利用の要望を頂いたときには時すでに遅し。取引先、商談を独自にカスタムしてしまったためCRM業務が乗らない状態になっていました。Salesforceの強みであるCRM機能が使えない、それってSalesforceを使う意味あるの？といった議論が挙がるようになりました。

ただ、これが決定打になりリプレイスに踏み込むことになります。

##### 法人格と部署を指す取引先オブジェクト

取引先オブジェクトに法人格のデータ、部署のデータが混在していました。
デフォルメしていますがデータ構造はこんな感じです。

| システムID  | 法人ID  | 法人名 | 部署 | 親ID
|-----------:|-----------:|:------------:|:------------|------------:|
| 1| 1 | 株式会社AAA        |          | |
| 2| 1 | 株式会社AAA      | システム部       |1 |
| 3| 1 | 株式会社AAA        | マーケティング部        |1 |
| 4| 2 | 株式会社BBB        |          | |
| 5| 2 | 株式会社BBB      | 営業部       |2 |
| 6| 2 | 株式会社BBB        | 経理部        |2 |

導入当初はさほど気にならなかったのですが、次々と問題を生み出していきました。

- クライアントの部署統廃合なんて日常茶飯事。部署の統廃合情報が手に入らないので形骸化。
- 部署レコードについた取引先責任者情報を取りに行くのがしんどい。Apexがカオスに。
- 標準機能が使えない。リードの「取引開始」が利用できずApexで実装。
- 導入したかったAppExchangeが利用できず

##### 受注後工程管理をするための商談オブジェクト
もともと業務システムとして導入していたので商談オブジェクトを受注後のステータス管理として活用していました。売上、発注、請求管理をガチガチに組んでしまったため、本来の使い方である受注前の商談情報が載せられませんでした。商談情報の置き場が無くセールスメンバー各個人で持っていたスプレッドシートに情報が逃げていくのが悔しかったです。

## 移行

### 計画
現在利用しているSalesforce組織(以下、旧組織)とは別に、もうひとつ新たにSalesforce組織(以下、新組織)を契約。段階的に移行することになりました。旧組織をリファクタするよりも、まっさらな状態から構築したほうが早いという判断です。

この手法でネックになるのがコスト。2重で組織を立ち上げるためSalesforceアカウント費用がかさみます。旧組織の契約更新日がXデーとなり、それまで全員が新組織に乗り換える必要がありました。短期間での移行になり非常にキツかったのですが逆に明確な締切が決まることで社内関係者の士気が上がりました。

### 経過
#### 新組織立ち上げ(2019年10月〜2020年05月)

新組織を立ち上げ、システム化が必要だったマーケティング、インサイドセールスメンバーが利用できる環境を構築しました。後述していますがSalesforceそのままの機能とAppExchangeの各プラグインで実装しています。楽ちん。

##### Salesforce基本機能、AppExchangeの恩恵
リード、取引先、取引先責任者、商談など、基本オブジェクトをそのまま利用しました！！当然といえば当然なのですが今度は無駄に開発しないことを誓いました。旧組織で抱えていた問題がこれで解消しました。

念願のAppExchange、プラグインも利用できました。マーケ、インサイドセールス系のプラグインsinclo、Miitel、BOXIL、FORCAS、Sansan、HubSpotを導入しました。

##### カスタマーサクセスチーム始動
嬉しい事例紹介。1ヶ月で15名体制のカスタマーサクセスチームが立ち上がりリード数が一気に3倍に。
https://tips.lancers.jp/articles/2339/

マーケティングチームから「来週、チームが稼働するんです」と懇願されたときはマジか！！と思いましたがSalesforce + Miitel + sincloで実現することができました。Salesforceの恩恵をしっかり受けられたと感じた瞬間でした。

#### 旧組織 → 新組織 業務システム移行(2020年04月〜10月） 

無事に新組織にCRM機能を構築することができました。いよいよ業務システムの旧組織を新組織に移行します。

##### 開発メンバー増員

このころ旧・新両方の保守をしながら移行開発を進めていたのでなかなかのハードモードだったのですが、心強いエンジニアメンバーが2名増えて合計3人になりました。チーム開発がスタート。二人が居なければ移行は完了しませんでした。ありがとう。

##### カスタムオブジェクト、宣言型開発で実装する業務システム

リード、取引先、取引先責任者、商談といった基本オブジェクトは原則そのままで、カスタムオブジェクトで業務システムを実装しました。CRMと業務システム、いい具合に棲み分けできました。
Apexでゴリゴリに組んでいたソースは可能な限りプロセスビルダー、フローといった宣言型開発で実装しました。特に最近のフローはトリガーやスケジュール起動できるんですね。だいぶローコード化が進みました。あとはUPSERTできると完璧(要望)。

##### 統一された画面

各サービスやチームごとに画面(ページレイアウト)を分けるのを辞めました。御用聞きになるのではなく統一デザインをこちらで提供し、それに併せて頂く形をとりました。LEXになってタブが使えるようになったので必要な情報が1クリックで出せるようになったので操作性に大きな問題は出ていないと思っています。ちなみに新組織の商談ページレイアウトは一つのままです。
この施策で開発スピードが大きく上昇したことに加え、業務フローや情報自体を見直すいいきっかけになりました。

##### サービスごとに移行

サービスごとに4回に分けて移行を行いました。金曜日１８：００に旧組織での業務を止めてもらい土日にデータ移行作業、月曜日から新組織で業務開始。旧組織と新組織でデータ構造が異なるためそのまま移行することはできませんでした。旧組織→CSVダウンロード→Excelでデータ加工→新組織に投入という地道な作業を行いました。

## 現在(2020年12月)

### 開発体制強化
社内エンジニア3人に加え、社外のSalesforceエンジニア、管理者にご協力頂く体制を整えています。弊社サービス上で募集をかけてマッチングすることができました。足元、チーム開発できるように環境整備しています。単純に開発力が増強するだけでなく社外からの視点で設計を見ていただくことにより独善的になっていないか把握することができます。そして高いスキルに刺激を受けてSalesforce資格試験も取得していく動きも出てきました。

## 最後に

長く社内業務システムに携わってきましたが、この規模のリプレイスを担当させて頂いたのは初めてでした。信じて後押ししてくれた決裁者のみなさま、社内で巻き込まれてくださったみなさま ありがとうございます。これから皆さんを押し上げお客様まで届くUXを作っていきます。
そしてSalesforceの負債に悩んでいる管理者の皆様のお役に立てれば本望です。最後までお読み頂きありがとうございました。