Salesforce活用で意識している考え方

Hubble Advent Calendar 2023の8日目¹の記事です🎄
@kareem さんからのバトンです！

はじめに

こんにちは、健康診断で2年連続1kg増えているShogoです。² 久々のQiitaです。
2023年から現在のポジションでデータドリブンな事業開発に取り組んでいます。

• BAO（Business Analytics & Operations）を立ち上げました！
• BAO 立上げ半年の振返り

Hubbleでは普段いわゆるビジネスサイドの仕事に従事しており開発はやっていない身ですが、ちょっとしたきっかけから開発チームのアドベントカレンダーに参加する機会をもらいました。
今回は私が日々使っているSalesforceというサービスを題材に、ビジネスとエンジニアリング双方の観点が関わる話をしてみたいと思います！

RDBとしてのSalesforce

Salesforceは世界的に著名なCRM・SFAです。詳しい説明は割愛しますが、システムはRDBとしての性質を持ちます。³
Salesforceでいう「オブジェクト」はRDBでいうところの「テーブル」、「項目」は「カラム」、「レポート」は「クエリ」などとそれぞれ解釈でき、その拡張性が大きな特長の一つとなっています。

ビジネスにおける構造化データ

さて、ビジネスに関するデータも構造化ができます。たとえば「取引先の情報」と「商談で取り交わされたやり取りの情報」は性質が異なるためテーブルとして区別しつつ、取引先のIDをキーとしてリレーションを持たせる、といったイメージです。

（「Salesforce サクセスナビ」より）

それらのデータは構造化されることでより有用性が高まるため、Salesforceのようなシステムを使用する意義があります。仮に取引先との商談の情報がすべてフリーテキストで「メモ」として残っていたら数値化や分析がしづらいですし、情報の共有にも時間がかかってしまいます。⁴
（ただし別の議論として、GPTといったLLMなどの技術革新も相俟って非構造化データであっても劇的に活用が進む方向もあり、こちらも非常に興味深い。）

複眼的に取り組むべき領域

SalesforceがRDBとしての性質を持つことから、データベース設計の上では開発者的なバックグラウンドを活かすことができます。（といってもSQLの基礎的な知識があればOK）

• どういった性質の情報をどのオブジェクトに持たせるか
• 新しいオブジェクトを作る上でリレーションをどうするか

など、適切にオブジェクト・項目構成を設計できれば、分析や可視化におけるスループット・アウトプットを高められます。

そして当然、ビジネス上の要請を実現して初めて「活用」が叶う分野でもあります。
自社の事業や営業活動の特質を理解しつつ、どのような分析や可視化が効果的なのかを見定め、各部門と対話を重ねて日常のオペレーションに落とし込み、入力を励行するといった活動がなければ成り立ちません。多面的な楽しさがある領域だと感じます。

Hubbleでも絶賛活用中

Hubbleの事業開発でも「データをビジネスの武器に」という趣旨からSalesforceの活用を促進し、着実に環境は良くなってきました。一つずつ挙げれば枚挙に暇がありませんが、たとえば以下などは特に成果に直結しています。

• 商談オブジェクトの項目を工夫して、ファネル&コホート分析を可能に。ボトルネックの特定や受注金額予測に活用
• MRR管理の基盤となるカスタムオブジェクトを構築。営業・CS・経理・ファイナンスなど多部署が同じデータを参照できるように
• 自社プロダクトのデータベースと結合するためのキーを保持する運用に。データソースとしてTableau Prepに接続し、分析軸がさらに豊富に
  • Tableauについては（筆が進めば）またどこかで詳しく書けたらと思います

引き続き取り組み事業に寄与していきます！
明日は @imarm さんです！🎅

1. 平日のみの投稿なので12日ですが8日目の記事としています。 ↩

2. 身長は変わっていません。 ↩

3. 参照：Integrate.io「Salesforceのデータベースについて」 ↩

4. 特に一つの案件にさまざまなチームの人間が関わるTHE MODEL体制を敷いている当社にとっては死活問題です。 ↩