aptpod Advent Calendar 2023 12月1日の記事です。
みなさまお久しぶりです。アプトポッドで営業企画をしている神前（こうさき）と申します。
前回の登場からちょうど1年ですね。
これで3年連続でAdvent Calendarのトップバッターを飾ることと相成りました。
去年の記事でも触れてますが、昨年12月に事業部に異動となり、今日でちょうど1年でもあります。
その1年の中でもメインの業務がタイトルにもあるSalesforceの導入だったのでそのことについて書いていきたいと思います。
「これから自社でSalesforceを導入しようかな」、「色んなサービスを使っているけど一つにまとめたいな」という人がもしいたら参考になるかもしれません。
当時の状況
さて、ではそもそもの始まりあたりから書いていきたいと思います。
実は、というほどでもないのですが、Salesforceを導入しようという話自体はいまから約2年前くらいからあがってはいました。
その当時は何かしらSFAを導入しよう、であればSalesforceも候補の一つだね、という感じでしたが、あくまでSFAの導入という文脈であったことや、金額面やその他の事情も重なり、他のSFAを導入することとなったのです。
しかし、実際にSFAを導入して運用を開始すると、もちろんそれでよくなった面も大幅にあった一方で、今度は他のシステム周りとの連携面が課題としてあがってきました。そして、それを皮切りに、「そもそもうちは色んなシステムを入れてるけども、連携してるものもあればそうでないものもあって、結構不便なことが多いよね」となっていきます。
弊社も15年以上の歴史があるため、その長い時間の中で様々なシステムが導入されるものの、それは局所最適化や金額面といったミクロな理由からの導入が多く、全体最適にはほど遠い状態だったのです。
事業部に関連した話で行くと、例えばこんな不便な事案が発生していました。
- SFAを導入し、案件の管理は楽になったが、見積書や請求書はERPで作成する、かつ、SFAとERPが連携していないためそれぞれに案件や商品のデータを毎回いれないといけない（データの二重入力）。
- 案件の議事録は別の社内wikiに記録していたため、詳細を知りたければそちらに飛ぶ必要がある（データの分散）
- 勤怠入力のシステムと工数を登録するシステムが別で、かつ、連携していないため、目検で月の稼働時間がちゃんとあってるか確認する必要がある（データの整合性）
この他にも様々な、「一つ一つは小さいけども、積み重なるととてつもない無駄」が各所で発生している状況でした。
こうした背景に加えて、「各種数値をレポート化できるのはいいけども、小回りがきかないからcsvで吐き出してスプレッドシートで加工する必要がある」、「各種項目に小回りが利かない」といったSFAそのものへの不便さも加わり、さらにカスタマーサクセス部門の立ち上げと、それに伴う顧客管理や問い合わせへの対応の実現をきっかけに、「だったらいっそのこと前々からリプレイスしたかったERPも含めて全体最適ができるようにしよう」となっていったのでした。
導入プロジェクトの立ち上げ
といっても立ち上げ自体に私は参加しておらず（そういうプロジェクトを立ち上げるよー、とは事前に聞いてはいましたが）、途中から参加した形になります（立ち上げのわりとすぐ後ではあるけど）。
（自分に関連するところを中心に）時系列でいうと
- 3月：管理部を中心にツールの選定と各企業からヒアリング
- 4月：社内での稟議承認。プロジェクトに神前参加。
- 5月：正式にプロジェクトがスタート。
- 6月：パートナーさんも含めてSFA、CRM構築のキックオフ
- 6～9月：SFA、CRMの構築
- 9月：事業部内でのSalesforceプレ運用開始
- 10月：旧SFAからSalesforceにSFAを完全移行。全社で運用開始。
という感じです。
私以外のメンバーもそれぞれの部分（勤怠周りとか会計周りとか）を担当していた形です。
主にやったこと
といってもそんなに大げさなことはやってはいません。
まずはこれまで使っていたSFAの使用感と似たようなものにするため項目を再現。その中で、「作ったものの、もう使われていない項目」を削除したり「今後のことを考えるとあったほうがいい項目」を追加したり、というのを現場からヒアリングしつつ構築。
その後にデータの流し込みを実施。
標準機能にないものをフローで作成。
SFA移行に伴う案内や、操作マニュアルの作成。
といった具合です。
他にも細々としたことはやっていますが、大きく言うとこんな感じです。
ただし、それは今だから言えること（今だから簡単にできること）であって、当初はだいぶ苦労しました。
以下にいくつかピックアップしてみます。
苦労したこと
ここから書くことはSalesforceの導入を体験した方であれば「あるある」でしょうし、これからの人にとっても役に立つ情報かなと思います（というか、そうであってほしい）。
苦労したことでいうといくつかあるのですが、とにかくまず苦労する部分であり、それでいてそこを乗り越えれば楽しくなってくる部分というのが「Salesforceのデータ構造の理解（という表現が正しいかはわかりませんが）」かなと思います。
Salesforceでは、商談（弊社では「案件」と名前を変えてますが）、取引先、担当者、商品、etc.といった具合に、それぞれが「オブジェクト」という箱にデータとしては収まっています。そのため、商談（案件）を登録するのにも色々なところからデータをひっぱってきています。
それまで使っていたSFAでももちろん「案件」、「取引先」といったように分かれてはいたのですが、Salesforceの場合はより細く、より複雑に色々なデータが絡んでいるため、どこにどのデータが収まっているのかがわからず、最初はほんとに手探りでだいぶ苦労をしました。
特に商品については複雑で、商品の一覧としての「商品」、商品の価格のリストである「価格表」、商品と価格表を結ぶ「価格表エントリ」に分かれていますし、さらに商談に紐づくものは「商談商品」となっています。慣れてくれば別ですが、「この項目を変えたい」、「この項目を増やしたい」といったときに、どのオブジェクトをいじれば自分のやりたいことが実現できるのか、というのはとにかく色々触って慣れるまで大変な部分です。
逆に、慣れてくると、「ここを変えようと思ったらここをいじればよさそうだな」とアタリがついてくるので、すぐにやりたいことができるようになってだいぶ楽しくなってきます。
これから導入や構築をするぞ、という人にとってはここが大変でしょうけども、ここの苦労は最初にしておいたほうがよいポイントです。構築に際してはSalesforceのパートナーさんがお手伝いをしてくることがほとんどだと思いますが、丸投げにせずに、自分でやれるようにしておくほうが後々のカスタマイズを考えると確実によいでしょう。
他にもフローもだいぶ苦労をしたのですが、それは次項にて。
フロー（と役に立ちそうな事例）
Salesforceにおけるフローとは、例えば画面上のとあるボタンを押下すると何かしらの自動処理が走る、なにかデータを登録するとそれをトリガーに処理が走る、といった「処理の自動化」のことを指します。
かなり自由度が高く、色々なことを自動化することができるのですが、ノーコードとはいえすぐに習熟できるものではなく、特に私のようなプログラミングの経験がない人間からするとだいぶハードルが高く感じる機能ではあります（その分、プログラミング経験者からすると操作しやすく、自由になんでもできる便利な機能だと思います）。
いまでは簡単なものであればすぐにフローを作れるようになりましたが、ここもマスターしようと思うとだいぶ苦労するポイントだと思います。
折角なのでサンプル事例をのせておきたいと思います。ネットで探してもほぼ情報がなかったのですが、わりとニーズ自体はあるフローではないかな、と思います。
売上を把握するためのフロー
商談を管理していれば、当然ですが契約金額、契約予定日も把握できていると思います。商談Aは2023年の12月末に受注（契約）予定で、金額は1,000万円、という感じですね。
一方で、「売上」となるとこれはSalesforceの標準機能では管理できません。つまり、この商談Aの1,000万円がいつ入金されるのか、会計上はどう処理するのか、という観点ですね（商談Aの受注は12月だけど、納品は翌年の3月なので、売上は3月に1,000万、といった具合）。
営業組織であればあまりこの「売上」を意識することはなく、受注金額と契約時期を意識することのほうがほとんどだと思います。逆に、経営層は「売上」を意識し、受注金額や契約時期を意識しない場合がほとんどではないかと思います。
弊社では、この「受注金額」と「売上」の両方をSalesforce上で管理、レポートで可視化をできるようにする必要があったためそこの対応をすすめました。
Salesforceでは、売上を標準では管理できず、「スケジュール」という機能を使う必要があります。
スケジュール機能については以下のページを参照ください。
このスケジュールを活用することで、たとえばサブスク系の商品の売上を管理できるようになります（仮に、100,000円/月のサブスク商品があり、1年分を2023年12月に契約すると、受注金額は12月に1,200,000円だけど、売上的には12月に100,000円、1月に100,000円、2月に100,000円・・・となる）。
しかし、このままでは商談に紐づく商品一つ一つに手動でスケジュールを設定しなければならず、実際に商談を登録する営業メンバーからするととても手間がかかるため現実的ではないですし、漏れも確実にでて、しかもそれに気付くのも難しいです。
そこで、商談にスケジュールが必要な商品が登録されたら自動でスケジュールを設定するフローを作成しました。また、商談は日々変化をし、商談に紐づく商品が変わったり、同じ商品でも金額や数量、納期がかわることも多々あるため、特定の条件を満たした場合、既に設定されていたスケジュールを削除し、再度スケジュールを設定する、というフローも合わせて作成しています。これで営業のメンバーはスケジュールをほぼ意識することなく、それでいて売上データも管理することが可能になりました。
細かい説明はここではしませんが、このフローは小さなフローを3つと大きなフロー2つを組み合わせています（まとめて全体の数を減らすこともできると思います）。ざっくり説明すると、商談に特定の商品を追加した場合、もしくはすでに登録されている商品の特定の項目（数量や価格等）が変更された際に隠し項目にチェックをいれ（小フローの①と②）、そのチェックをトリガーに商談の中にある隠し項目にチェックをいれます（小フロー③）。このチェックをさらにトリガーとして、商談に紐づく商品のスケジュールをすべて削除し（大フロー①）、そのあとにスケジュールを設定する（大フロー②）、という構造です。
レポートで集計をする際は受注金額と売上金額とでそれぞれ別のレポートタイプを使う必要がありますが、営業メンバー向けの受注金額をベースとしたレポートと経営層向けの売上を中心としたレポートをそれぞれ作成することができるのでとても便利です。 ※本フローの作成にはパートナーさんにもお手伝いいただきました。
Salesforceを導入してみて
そろそろまとめに入りますが、Salesforceを導入してみてよかったのは、とにかく自由度が高い（その分使いこなせないとだめですが・・・）ため、ちょっとしたことを自動化したり、各種データを様々に集計したりということがかなり楽になりました。
また、当初の目的でもあった各種システムとの連携も実現できているため、データの二重入力や、csvに吐き出してからスプレッドシートで加工する、といった手間も大幅に削除できています（完全に、とはいきませんが）。
まだ本格運用を始めてから2ヶ月程度なので実際にどれだけの工数を削減できたのか、といったところまではデータとしてはとれていませんが、体感値でいえば以前に比べると様々な業務が楽になったと感じています。
今後の課題
便利さの反面として、Salesforceに詳しい人間が弊社社内にまだまだ少ないのが現状です。また、まだまだ使い倒せる機能が多くあり、改善の余地がかなり残されています。
加えてですが、システムそのものが便利にはなったものの、一方で、（管理側とは別に）使いこなせる人が少ないことも課題の一つです。便利なツールがあっても、使いこなせる人がいなければ宝の持ち腐れです。まだまだ現状では「こういうレポートがほしいんだけど作ってくれない？」という依頼がちょこちょこ来るのが現状で、それでは本質的にはあまり意味がありません。だれでも自分のほしいデータにアクセスし、レポートとして作成し、自身の業務に活用する、というところまでいって初めてSalesforce導入の真価が発揮されるのだと思います。
システム管理者としては、使い勝手や機能の改善と同時に、使いこなせる人を社内に増やしていく、というこれからの方がむしろ本番とさえいえそうです。
それではみなさまよいSalesforceライフをお楽しみください。
参考にした記事等
まずは公式のものを見るのがよいです。
スケジュールを設定するフローはこのフローをベースとして作成しています。
こちらもあると結構便利なフローです。
slackとの連携も便利です。
