👏

さよならぼくたちのHubSpot ~弊社での開発事例~ | Offers Tech Blog

2022/12/19に公開約5,100字

はじめに

こんにちは!
Offers を運営している株式会社 overflow の磯崎です。

弊社では HubSpot を使用しています。
我々開発チームでは、この HubSpot 上のデータリソースの取得や操作をし、社内業務の効率化を図る対応をしていくケースが多々有りました。

直近、商談管理を Salesforce に移行しており、開発チームとしてはお別れのタイミングになりますが、節目としてこの文章を書いています。
色々魔改造を試みて記憶から吹っ飛んでいる対応もありますが、かれこれ2年ほど HubSpot とお付き合いさせていただいた中での実例をご紹介させていただきます。

HubSpotとは?

CRM(Customer Relationship Management = 顧客関係管理)を中心に、企業のインバウンドマーケティングのプラットフォームです。

導入ハードルも決して高くなく、LP や問い合わせ form 作成や営業支援の機能などは任意に追加していくことで使用できます。

顧客データなどは比較的早い段階で設計をし、収集をしておかないと後々それをお掃除するのは非常に苦痛を伴う作業になってくる事が予想されます。
HubSpot は比較的早い段階でデータを収集・集約しておくために導入するツールとしても適しています。
とりあえずデータを CRM に放り込んでおくだけでも、価値があるかと思います。

CRMで使用するデータ

HubSpot を用いての実装をしていくにあたって、まずはどんなデータが存在するかを確認する必要があります。
HubSpot を取り扱っていこうとした場合は、まずこの 3 つだけ覚えておけば大丈夫です。

Company(企業)

企業データです。会社名や電話番号などがこちらに入ります。
企業ドメインを一意の key として、HubSpot では取り扱っています。

Contact(企業担当者)

企業の担当者データです。名前や email などが入ります。
こちらは、email を一意の key として取り扱っています。

Deal(取引)

各企業との取引のデータで、取引のステータスや取引先企業、担当者などがこちらに入っています。

APIを使用する

公式の docs に全てサンプルリクエスト付きでわかりやすく書いてありますので、僕が特筆すべきことはありません。
https://developers.hubspot.jp/docs/api/overview

Node.js, PHP, Ruby, Python 用のクライアントライブラリも用意されているので、対応する言語がある場合はさっと使い始めることができますね。

CRM 上のデータ操作する場合は、上述した Company, Contact, Deal を中心にデータを触っていくので後はドキュメントとにらめっこしていれば必要な操作が行えるかと思います。

webhookを使用する

これも公式に非常にわかりやすい説明がありますので、僕が追加で書くことはありません。
https://developers.hubspot.jp/docs/api/webhooks

管理画面上、API どちらでも簡単に webhook の管理が行えます。

弊社での活用事例

今まで色々と開発をしてきましたが、組織のフェーズに合わせて消え去ったものも存在します。
そんな中、結果的にこの 2 年間で現在も生き残っている HubSpot を絡めた開発事例をご紹介します。

クラウドサインの下書き作成

Hubspot の商談をベースに、クラウドサイン の下書きを作成できる機能です。
HubSpot の webhook と API、クラウドサインの API を組み合わせて実装されています。
毎回、契約書を人の手によって作成するのは時間が取られますし、ヒューマンエラーを引き起こす可能性もあります。
なので、これを自動化して、人々の負担を減らして時間を作っていこうという想いでこちらは実装されました。

具体的な処理の流れとしては以下です。

  • HubSpot 商談に情報を入れる
  • 特定の取引ステージに移動
  • 取引ステージ移動で webhook 発火
  • それを受けたサービスがデータの保存とクラウドサイン下書き作成
  • Slack に完了通知

処理としては単純ですが、
「どのように HubSpot のデータを設計し、システムに取り込むか」
「データのバリデーションはどこでどのように行うのか」
「作成失敗時の通知内容、通知先はどうするか」
のような事を考慮しなければなりません。

結果的に契約書の作成担当者の負担軽減と HubSpot 上の取引情報をベースとした契約書作成によりヒューマンエラー発生率低下に貢献しました。

Slackチャンネルの開設

こちらも、HubSpot の商談をベースに Slack チャンネルを解説し、関係者を招待する機能です。
HubSpot の webhook と API、Slack の API を組み合わせて実装されています
弊社では契約プランに応じて、専用の Slack channel を作成し、サポートさせていただくケースがあります。
毎回人がチャンネルを作成し、必要な方々を招待し..とアクションしていくのはそこそこ工数がかかります。
なので、これを HubSpot のデータを元に自動で作成するようなものが実装されました。

具体的な処理の流れとしては以下でシンプルです。

  • 特定のプロパティの更新
  • プロパティ更新で webhook 発火
  • それを受けたサービスが Slack チャンネル作成と関係者の招待をする
  • Slack に完了通知

こちらも結果的に Slack チャンネルを作成し、関係者を招待するという作業の負担をほぼ無くすことに成功しました。

2年超 運用していて見えた課題

色々な物を作っては壊してきた(遺跡と化しているものも含む)この2年間で運用していて「困ったなあ~」と思った点です。

プロパティ・ワークフローが乱立し、誰も手を付けられない状態になる

これは HubSpot の問題というよりも、Owner を立ててしっかりルールの元制御せよということですね。
HubSpot は誰でも簡単に触れるというところが良い面ではあるのですが、裏を返せば権限さえあれば誰でも簡単に触れてしまうということです。
弊社 HubSpot 導入時は人の入れ替え等もあり、Owner が定まっていない状況でした。
そのような状況下で何が起こるかというと、色々な人の思惑によりプロパティが乱立し、どんな副作用がありどこで使われているかもわからないワークフローが爆誕しつづけるというような状況になり得ます。

きちんと Owner を立てた上でプロパティは設計をし、ワークフローに関しては本当に必要なものなのか、ワークフローでやるべきことなのかをしっかりと考えていった上で追加していくべきでした。
特にワークフローが動いていて、他で webhook 起点に処理を動かしていた場合、巨大なハウルの動く城が完成するので注意です。
とあるワークフローでとあるプロパティを更新して、それを起点に webhook 発火...のように影響範囲が広がってしまうと非常に恐ろしくなっていきます。

ワークフロー上ではプロパティを更新しない、それ単体で完結する簡単な処理に留める
などのルールの元で追加・編集をしていき、余裕があればレビューを挟むのも良いかと思います。

色々と開発を進め、開発チームの持ち物が増えることによる保守コストの増大と柔軟性の低下

これも HubSpot の直接的な課題ではないですが、HubSpot で公式に連携可能なツール以外のものと連携したい時は自前で作っていく必要が出てきますね。
本来セールスチームで握っている商談データをベースになんらかの処理をしており、それを作り込めば作り込むほど当然のごとく保守コストが増していきます。
売り方やプラン、初回のサポートなど、各チームが最高の体験にできるように試行錯誤をしていった結果、実際に作り上げたフローから外れるケース、または外したいケースが発生してきます。
そういったイレギュラーケースは全て開発チームが絡んでいくことになります。

理想形は、開発チームがほぼ介在せず、HubSpot を使用するメンバーが一定の制約のもとに柔軟に操作でき、システム化による負担軽減の恩恵を受けることができるような状態です。

本番を模倣したsandbox環境が簡単に立ち上がらない

開発時に困りました。
本番環境同様の、プロパティ・ワークフローを保持した本番コピーversion を作成して、開発の検証用として使用したいケースが多々有りました。
実際の動作確認があまりにも本番とはかけ離れている環境で行われていた場合、不安でさくっとリリースすることは難しいです。

また、大切なデータを扱っているサービスのため実データの入った本番に対してのアクセス権は慎重にならざるを得ません。

自由自在にぶっ壊してもいい検証環境をボタンポチーで作れたらいいのになとずっと思ってました。

最終的に、Sandbox 環境は管理画面から作れるので、API を使用してその Sandbox と本番の Workspace を同期するようなスクリプトを書くことで本番環境だいたい模倣に成功しました。

これを作ったことによって、HubSpot を絡めたローカルでの開発がとても捗るようになりました。

これからの展望

直近、色々な理由により、HubSpot での商談管理を Salesforce に移行しました。

なので今後は Hubspot ではなく、Salesforce と絡めた開発をしていくことになるのですが、HubSpot での運用時の反映を踏まえ、開発チームがゴリゴリと入り込んではいかないような方針で開発を進めています。
基本的に Salesforce 上でコードを書かずに実現できるものは全て使っていき、なるべくプロダクト開発チームで保守しなくても良いような形で、上述した契約書の自動作成や Slack チャンネルの開設等を実現していこうと考えています。

開発にバインドされすぎないことで、セールスチームも自分たちのルールの元で、その時の状況に合わせて商談をベースとした契約書作成などの各アクションを行うことができ、開発チーム全体としても保守コストがかからないのでより他の事に捻出できる時間が増えて全員幸せになります。

HubSpotへの感謝

いきなり導入が決まり右も左もわからない状態から導入→運用をしてきましたが、ドキュメントや管理画面の操作がわかりやすく、担当者様に問い合わせさせていただいた時もこちらのやりたいことを汲み取っていただきながら手助けをいただきました。
魔改造を試みての強引な実装、乱立したワークフローの整備、ワークフローの無限ループによる Slack メッセージ大量誤爆など思い返すと色々な思い出があります。

フェーズも変わってきて、開発チームとしては深く関わることはなくなっていきますが、また機会があれば触っていきたいです。
ありがとうございました。

エンジニア採用強化中

株式会社 overflow では Offers の開発メンバーを大募集中です。正社員はもちろん、副業でのジョインも歓迎です。とりあえず話を聞いてみたい!という方には カジュアル面談 がオススメです。

https://jobs.overflow.co.jp

Discussion

ログインするとコメントできます