Salesforceで営業支援できるように裏側を構築するまでと現状（Salesforceエンジニア）
こんにちは、IT&セキュリティ部の片岡（かたおか）と申します。
私の仕事を簡単に言うと、営業の皆さんが使っているSalesforceを、様々な用途で活用できるように魔改造しているみたいな感じです。
初めてSalesforceの画面を開いたとき、「どうやったら欲しいデータを抽出できるんだろう」と思ったことはないでしょうか？
はたまた「早くデータ取りたいのに、なんで頻繁にエラーが出るんだろう」となったこともあると思います。
今回はSalesforceエンジニア並びに営業の皆さん向けに、Salesforceを裏で改造している私の話をします。
私、片岡とは
私、片岡とは、北海道出身で未経験から企業内のSalesforceエンジニアになった者です。
新卒で入社した大手通信事業を展開する企業では、固定通信回線やスマホのサポートを行いながら、提案件数を目標として追う、ユーザーサポートに近いことをしていました。
そこから2社目への転職と同時に上京し、バックオフィスメンバーとしてパソコン周りのサポートを担い始め、今でいうヘルプデスクのような環境に行き、3社目でLegalOnに入社という変遷です。
LegalOnでも当初はパソコン周りのサポートから始めまして、その後プロジェクト推進、Salesforceの開発チームと辿っています。
（ちなみにSalesforceエンジニアになったきっかけは、上司との1on1で声をかけてもらい、今後のキャリアを想像していくうちに挑戦したいと思ったからです。）
混沌とした状況が広がっていた
初心者の私に課せられたミッション
エンジニアとしてのキャリアを始めた私に課せられた最初のミッションは交通整理と整備でした。
当時の状態
私がSalesforceエンジニアになったのは2022年8月で、シリーズDラウンド137億円の資金調達をした時期です。
大規模調達をして、世間でもニュースとして取り上げられていましたが、対して内部はSalesforceの運用周りが整備されておらず、役割分担が不明確でした。
そのため、Salesforceのアカウントを作成するにも、どの部署に依頼するのかわからず、カスタマーサクセスのリーダーに依頼して作成してもらったり、各々が欲しい機能を専門外の部署がジャストアイデアで作ったりしていたんです。
その結果、権限が広範囲に行き渡ってしまい、Salesforceのカスタマイズが複雑化かつ負の遺産と化していました。（以下、負のカスタマイズ）
役割を明確化したが・・？
負のカスタマイズを崩すために、以下を定め、業務プロセスの改善を進めました。
・権限の所管を定めて属人化を防ぐ
一部の権限管理を営業企画チームにもってもらい、開発とその他管理を私の所属チームで持つ。
・チームの役割分担を明確化
1チーム内にエンジニアチームとプランニングチームを配置。
・Salesforceの改修までの流れを3step化
営業企画：現場から意見収集
プランニングチーム：要件定義
エンジニアチーム：開発
さて、役割を明確にしたものの、なぜか超多忙になりました。
理由は、負のカスタマイズが原因で発生するエラーです。
負のカスタマイズによるエラー
Salesforceの構造
先ず、Salesforceはマルチテナンシー型と言って、1個の大きな箱の中に複数のテナント（企業やユーザー）が存在しており、単一のソフトウェアやデータベースなどを共有して利用する構造になっています。
この構造の特徴として、一つのテナントが暴走しだすと全てのテナントに影響が出るという点があり、この悪影響を防ぐためにSalesforceにはガバナ※制限などが設けられています。
※Governor（ガバナ）：情報量や流す速度を一定にする機能
バッチ処理の上限に到達し、エラー解消が仕事に
先の通りSalesforceには、一度に実行できるバッチ処理の上限が設けられており、バッチ処理の上限に達すると顧客データなどが保存できず、裏で走っている信号がショートしてエラーを起こします。
Salesforceの管理を持ち始めた当初は、バッチ処理の上限によるエラーが1日に10〜20件くらい継続的に発生していたので、エラー解消に明け暮れる時もありました。
本来一つにまとめられる二つの信号が別々で動き、二つの信号をまとめるために三つ目の信号が出てきて上限に達するというイメージです。
根本的なエラーの解消に着手
現状維持だとエラー解消だけに手が取られ、他の改善部分に着手できず、やりたい業務が疎かになっていたので根本的な改善を目検で行っていきました。
アナログなやり方ですが、当時はこれしか方法がありませんでした。
三つの信号を一つにまとめたり、隠れているエラー予備軍を対処したり、根本的におかしな作りを発見し、先回りして改善したことでエラー数を削減しました。
エラー解消による効果
・各エラーの重要度を判断しやすくなった
・Salesforce内にある集計機能の分身を開発・搭載
各エラーの重要度を判別しやすくなった
エラー数の削減をしたことにより、重要度の判断が付きやすくなったことはチームにとって大きな成功体験です。
改善前は1日に数十件のエラーが発生し、どれが重大なエラーか区別が付かず、明らかにまずいエラーが潜んでいるのに全て同じ重要度で見ていたので、一つ一つ細かく対処してしまっていました。
改善後はエラーが起きるたびに重要度の判断が付きやすくなり、的確な優先順位付けと対処の両方ができるようになりました。
Salesforce内にある集計機能の分身を開発・搭載
もう一つは、Salesforce内にある集計機能と同じ挙動をするものを開発・搭載したことも、エラー数削減によって空いた工数で実現できたことです。
商談に関連付く商品の合計金額や、取引先に関連付く商談数などの集計に利用する「積み上げ集計項目」というSalesforceの標準機能と、同じ動作をする機能をエンジニアチームで開発・搭載しました。
例：ある企業に対する商談が1年前に1件、半年前に1件、今月に1件で合計３件あることを簡単に集計可能
「積み上げ集計項目」の分身を開発した背景
「積み上げ集計項目」の特徴
Salesforceの「積み上げ集計項目」には、２つの特徴があります。
①主従関係のあるオブジェクト同士で、主オブジェクトから従オブジェクトの値やレコードを集計することができる。
（例えば取引先と商談でいうと、主オブジェクトが取引先で従オブジェクトが商談）
②「積み上げ集計項目」は作成できる数に上限がある。
主オブジェクトから従オブジェクトのデータを算出するには標準機能だと「積み上げ集計項目」を使うしかなく、さらにマルチテナンシーの構造上、パフォーマンスの安定性を保つため、「積み上げ集計項目」を作成できる数が最大40個までと上限が設けられてます。
自社サービスのオプションが壁に
LegalOnの場合、売ろうとしているサービス、オプションを従オブジェクトである商談に一つ一つ商品として追加し、商談で確定したお客様のプランを計算するために「積み上げ集計項目」を使用しています。
ただ、LegalOnのサービスは「LegalForce」、「LegalForceキャビネ」に関わらず、オプションがたくさんあるんですよね。
新機能やサービスがリリースされたら、営業現場から項目作成の依頼⇒作成というフローをとっていたので、オプションが無限に増えていき、項目作成の最上限である40個に一瞬で到達してしまったんです。
同じ挙動の機能を開発してしまおうということに
結局使ってないものは削除するしかなく、削除してもオプション追加が止まらないのでエンジニアチームで「積み上げ集計項目」と同じ挙動をする機能をコードで書いて開発しちゃおうとなりました。
要は他社のプロダクトをがっつり開発するということです。
実際の「積み上げ集計」は、Excel関数のように自動で数字が動くので、それと同じ動きをするコードを書いて改造しました。
実はこれ、めちゃめちゃ大変で、下手するとガバナ制限に引っかかってエラーを起こすので、そこに引っかからないよう、“Apexクラス”という機能を使用して「積み上げ集計項目」と同じように動く自動化処理を作りました。
開発・搭載した結果
この改修によって、さらに営業現場の依頼に柔軟に対応できるようになり、1年経った今でも役に立っています。
この改修がなければ緊急回避とエラーの連続だったり、営業現場から不満が出たりしたはずなので、現状に対する最善の解決策だったと思っています。
将来的には「積み上げ集計」を多用しない環境を作り、誰もが使いやすいツールにしていくことを目指しています。
私はいかにエラーを出さず、効率化、自動化を実装していくかがSalesforceエンジニアの責務だと考えてるので、保守性を高いレベルで維持しつつ開発し続けていきたいと思っています。
今、なぜSalesforceエンジニアを採用募集しているのか
・毎週1回の定期リリースを担保したい
・内製化を確立し、強固な開発体制にしたい
・チームの改善を助けてほしい
毎週1回の定期リリースを担保したい
LegalOnの場合、1週間単位でリリースサイクルを回しています。
Salesforceの改修は、以下二つが一般的だと思います。
・依頼のたびにSalesforceを改修し、2～3週間ぐらいのバッファを持ってサイクルする
・四半期に1回など、中長期的な期間を設けて改修
ということで、1週間単位となるとめちゃめちゃ忙しいんですよ…。
なぜ1週間単位かと言うと、経営×営業×私のチームが以下の意見の中で出した折衷案です。
・経営
経営方針を一週間ごとに議論し、事業スピードを高めたい！
・営業
経営方針や営業目標に沿って、効率的に営業活動をしたいので、即日対応してほしい！
・私のチーム
Sandboxという開発・テスト環境を用いてリリースの品質管理をし、将来を見据えてしっかり全体整備したい。
要件定義/1日⇒開発/2日間⇒テスト（UAT）/2日間⇒リリースで5日間は欲しい。
（本当は、より高品質なリリースをするためにも2週間は欲しいが、そうすると営業企画による意見収集からリリースまで1か月経ってしまう）
タイトなスケジュールでそれぞれのリソースが取られる上に、突発的なエラーやバグ、インシデント、差し込みが入るとてんやわんや状態です。
それらに耐え得る環境を作ればいいのですが、改善していくリソースもなければ、メンバーも少ないです。
内製化を確立し、強固な開発体制にしたい
もう一つとして、LegalOnは内製化を図っています。
例えば、営業現場から「こういうことをしたい」という要望が出た際、外注することが多いと思うのですが、LegalOnの場合は全部社内で完結しています。
これは環境に左右されない強固な業務プロセスの確立、そして、加速していく事業スピードにも迅速に、且つ柔軟に対応ができるチーム体制の確立のためです。
しかし、問題なのはSalesforceと他ツールとの連携についての知識が不足しているという点です。
LegalOnでは、現場の業務効率を上げるために様々なツールが導入されます。
ただ、導入する場合はSalesforceとの連携が必要になるケースが頻繁にあるんですよね。
そうすると、連携に関する知識も必要ですが、現メンバーでは他サービスとのインテグレーション※に関する知識が不足しているので、頻繁に発生する連携対応のたびに大変な思いをしながら対処しています。
※インテグレーション：複数の異なるシステムを組み合わせて一体化させること
チームの改善を助けてほしい
今後の事業成長も踏まえて、私たちのチームをより最適な状態に改善する必要があります。
しかし、チーム改善を推進するメンバーがエンジニアチームでは私一人しかいない状態なため、私の意見が先行してしまい、その意見が本当に正しいものかどうかも不透明なまま物事が進んでしまいます。
現状では、Salesforceエンジニアとして経験豊富な業務委託の方と一緒に営業現場の意向をなんとか実現できてはいますが、将来的にはAWS※やZuora※など新たなSaaSツールとの連携を検討しており、今のチームメンバーだけでは実現が困難です。
これを実現するためには、あらゆるサービスの知識が深い方が必要であり、チームとして今以上の成長が求められます。
※AWS：データベース、ストレージ、アプリケーションなどをオンデマンドで利用できるクラウドサービス
※Zuora：サブスクリプションのビジネスモデルに対し、収益向上と業務最適化を支援するサービス
大きな募集背景（チームの課題）として、三つ書き出しましたが、たくさんやりたいこと、やるべきことがあるので、力になってくださる方に来ていただきたいと強く思っています！
最後に
LegalOnはすでにできあがった企業だと思われることが最近増えたのですが、実際はまだまだ発展途上です。
事業は留まることなく成長してしまうので、私たちは置いていかれないようになんとかしのいでいるような状態です。
今後、さらに企業としてステップアップを目指しているので、一時的な対処ではなく中長期的にあらゆる変化を楽しみながら一緒に創り上げていただける方がいらっしゃれば、是非ご応募いただきたいですし、純粋に一緒に働けることが嬉しい＆楽しみです！
▼Salesforce エンジニアの募集
この記事が気に入ったらサポートをしてみませんか？