ドメイン特化型Full-Stack Data Platformで挑む「人を動かすダッシュボード」 - CTOが語るSALESCORE その2
こんにちは。SALESCORE株式会社CTOの成澤です。
このシリーズでは、資金調達のリリースにあわせてSALESCOREにまつわる様々なトピックをお話ししています。
第二回となる今回の記事ではSALESCOREの「ドメイン特化型Full-Stack Data Platform」という開発コンセプトに焦点をあててお話しします！
※第一回の記事はこちらから！
「多機能」ではなく「複数のニーズに応える単機能」を開発する
第一回では「セールスイネーブルメントのプロダクト開発は難しい」「その理由は多機能性とカスタマイズ性が求められるから」とお話ししました。SALESCOREはこの難しさに対して、いくつかのコンセプトで挑んでいます。ここではその一つについてお話します。
創業当初（旧社名は株式会社Buff）、初めて作ったサービス「Buff Sales」のコア機能は「Salesforceのレポートと同期して、ユーザーごとに今月の各種KPIと目標が見れること」 でした。
今思うと信じられないほどシンプルな機能でしたが、この機能が営業組織に刺さり、数社に有料でサービス提供を開始しました。
※ちなみに、他3種類ほどの機能の開発や要件整理も含めて、エンジニア一人で全行程を2週間で作ってリリースしました！この辺の話はまた別の機会で。
そして時は流れ、MVPとして開発したBuff Salesに対して様々な要望が挙げられます。
部署別 / 経路別 / etc…でも集計したい
数値をクリックしたらドリルダウンして、詳細が見れるようにしたい
詳細からSalesforceレコードを編集したい
Hubspotとも連携したい
etc…
それぞれを「機能」として開発することは可能でした。
しかし、この調子で「経路別で表示する機能」「先々月で絞り込む機能」のような機能を増やしていくと、コードベースが複雑化し手がつかなくなることは目に見えていました。
「多機能」なサービスを開発するのは、常に難しい開発です。
一定期間を経てMVP検証を終え「ダッシュボードに特化したサービスにしよう」という事業の意思決定が行われた時、同時に開発としては「任意のデータソースに対して、任意のクエリを発行し、任意の形で表示できる機能」という”単一”の機能を作るという意思決定をしました。
なんだかトンチのように聞こえるかもしれませんが、ソフトウェア開発において「多機能」なのか「単機能で複数ニーズに応える」のかは全く違います。
例えば「1+1を計算する機能」を愚直に開発すると「1+2を計算する機能」はまた新しく開発しなければなりません。同様の機能を100個作った後に「やっぱり掛け算もできるようにしておいて」と言われると、修正には多大なコストがかかります。
優秀なエンジニアであれば、この場合は「X+Yを計算する機能」を作り、単一の機能で複数のニーズに応えようとするでしょう。
この実現には高度な抽象化の力と実装力が必要になりますが、これこそがソフトウェアエンジニアの腕の見せ所でしょう。
「1+1をする機能ではなく、X+Yをする機能を開発する」
これがSALESCOREの重要な開発コンセプトの1つです。
「ドメイン特化型Full-Stack Data Platform」としてのSALESCORE
さて「任意の分析ができる機能」と言ったはいいものの、実際にはどう作ればいいのでしょうか？
ここまでは「セールスイネーブルメントのためのSALESCORE」の文脈で話してきましたが「データプラットフォームとしてのSALESCORE」に少し軸足をずらしつつお話ししましょう。
新しいSALESCOREで必要とされることを整理すると、以下の機能が必要だということが分かりました。
外部データソース（Salesforceなど）からデータを抽出
抽出したデータをデータストアに格納・加工
格納したデータを任意の形式で表示
ユーザー操作に合わせて外部データソースに書き込み
アプリケーション開発を主業務とするWebエンジニアにはパッとこないかもしれませんが、この流れはデータ基盤構築の際にお馴染みの「ELT」「DWH」「BI」「Reverse-ETL」といった技術スタックそのものになります。
サービスリニューアルに辺り、これらの既存技術スタックを丁寧にリサーチし、手応えを得た結果、SALESCOREは「ELT」「DWH」「BI」「Reverse-ETL」の各機能を、シームレスかつフルマネージドに扱える、営業ドメイン特化型のFull-Stack Data Platformであると開発コンセプトを定義し、この方針で開発していくことにしました。
リニューアル後のSALESCOREでは、各レイヤーで最新の技術スタックと同等の機能を、分かりやすいUIで使うことができるようになりました。
（…などなど、ここでは語りきれないたくさんの機能があるので、気になった方はぜひお気軽にご連絡ください！）
ELTなどそれぞれ1サービスでも成り立つような機能を全てまとめて開発するという意思決定はなかなかハードなものでしたが「既存サービスでは実現できない理想を実現するため」「営業ドメインに特化することで難易度が大幅に下げられる」という理由でこの方向性としました。
この「理想」について、次段落でもう少し詳しくお話ししましょう。
人を動かすダッシュボードを作る
私が大好きな本である「戦略を、実行できる組織、できない組織。」の一節に以下があります。
「ストリートバスケはスコアボードを入れると途端に白熱する」
スコアボードがなく今の得点が分からないストリートバスケでは、あと1分しかないという時に「あと1分で6点決めて絶対に勝つ！」なんて思いは生まれません。「スコアボードにスコアが反映されるのは1時間後です」と言われてもまた同じでしょう。
バスケットボールでのスコアボードはまさしく「人を動かすスコアボード」だと言えます。
さて、データの可視化の重要性が叫ばれ、BIツールの利用が当たり前の時代となりましたが、果たして可視化したデータは人を動かしているでしょうか？
分析担当者がSQLを何十行も書いて頑張って作ったレポートが、誰にも見られなかったり、5秒眺めて終わりくらいになっていないでしょうか？
データの価値は、データを活用し日々のアクションが変わることで初めて生まれるものであり、このような状況になっては意味がないと考えます。
SALESCOREは「人を動かすダッシュボード」という考え方をとても大事にしており、SALESCOREを上手く活用していただいているお客様の多くは、朝会・夕会でSALESCOREのダッシュボードを確認し、各種KPIをチェックし、それをベースに議論を行ったりその日のアクションを変えるという運用をしてもらっています。
「数値で管理される」というと「ノルマが厳しい」のようなネガティブな印象が付きまとうかもしれませんが、弊社内や導入先の声を聞いていると「大変だったけど達成できて嬉しい」「未達だと悔しい」のような、まさしく部活でバスケをやってるような感想をよく聞きます。
これができるのは、営業特化のダッシュボードで日常的に見たいデータをリアルタイムに見れるためであり、そして必要があればその場で非技術者がレポート条件を変更できるからです。
追加で見たいデータがあるときに「分析チームに依頼してELTしてもらってSQL書いてもらって…」などをやっていては意思決定が遅れに遅れ、意欲も下がってしまいます。分析結果を一番欲しているのは、分析結果を欲しているその当人であり、であれば当人がその場でリアルタイムに分析をできるべきです。
そして開発者の視点では、これらの実現のためには「ELT」「DWH」「BI」「Reverse-ETL」の各機能を、シームレスかつフルマネージドに扱える、ドメイン特化型のFull-Stack Data Platformが必要でした。
例えばELT・DWH・BIが統合されているからこそ、ユーザーがそれぞれを別で運用したり小難しい連携設定をする必要がなくなり、非技術者でも手軽に導入できます。
またELT連携先ソースのメタデータ（和名、参照、選択肢、メタ属性など）をBIレイヤーで使って快適なユーザー体験を実現できるのも、この構成ならではの利点です。
更に言えば「分析結果を見て元データが間違ってたらその場で修正する」なんてこともできるのは、データ界隈でも唯一無二なサービスですね。
（……などなど、ここでは語りきれない本当にたくさんの機能があるので、気になった方はぜひお気軽にご連絡ください！）
長くなってしまったのでまとめると、SALESCOREは「人を動かすダッシュボード」という理想を実現するために、営業に特化したダッシュボード・非技術者でも触れる設定画面を提供しており、これらを支える技術基盤としてドメイン特化型Full-Stack Data Platformを開発しています。
おわりに - 「データの民主化」は本当に達成されているのか？
前回の記事では「セールスイネーブルメント」の文脈からSALESCOREを紹介しましたが、この記事では「データ」の文脈でのSALESCOREを紹介しました。いかがでしょうか？
近年のモダンデータスタックの潮流を初めとして、データ界隈も技術の進歩により良い時代が来ているなと感じているのですが、やや気になるところもあります。
それはこれらの技術スタックはあくまで技術者向けであり、非技術者が触るようなものではないことです。
高度に技術的なことをしようとする時に技術者の手が必要になるのは当然ですが、簡単なことは非技術者でもできる世の中になって欲しいですし、それが出来てこそ本当の意味での「データの民主化」だと考えます。
SALESCOREではこういった思いから、最低限のデータリテラシーを持つ人であれば、モダンデータスタックの恩恵を受けつつ、それなりに高度なデータ集計が便利に行えるように設計されています。
…とは言いつつも、まだまだ理想には遠く、開発したいことは山積みです。
ここまで戦略的に一人での開発をしてきましたが、そろそろフェイズの切り替わりを感じており、開発チームを作っていこうとしています。
「営業の現場のスコアボード」「人を動かすダッシュボード」を一緒に作って見たい方、ぜひお気軽にお声がけください！採用ページは以下より。
Appendix
長すぎて本文にいれられなかった文章をこちらに書いておきます（興味ある人だけお読みください！）
（当初この3倍の量の文章を書いていたが「長すぎ」というFBにより削った）
モダンデータスタック
モダンデータスタックとは、一昔前のデータ関連サービスと比べて、より現代的なコンセプトを提案しているサービス・ソフトウェア・方法論を指す言葉です。
モダンデータスタックについては、廣瀬さんのこちらの記事が名文なので是非ご一読ください。
最近のこちらのpodcastも面白かったのでぜひ！
dbt
モダンデータスタックについてほんの一例にはなりますが、例えばdbtを使うとデータパイプラインをSQLにより宣言的に定義し、マクロによりモジュール化しつつ、テスト、CI、バージョン管理やPRレビューなどのモダンな開発手法を使って開発できるようになっています。
モダンなソフトウェア開発の手法がデータ界隈でも取り入れられ始めているのが面白いな〜と思ったので、データ界隈に縁のないソフトウェアエンジニアの方も、ぜひ触ってみてください！
また別の視点で面白いのは、dbt上で動く「パッケージ」もOSSで公開されていることです。
諸々と便利なパッケージがありますが、例えば「SalesforceをELTした時に使えるパッケージ」もFivetranにより公開されており、これを使うと複雑な計算を行った各種テーブルが生成され、あとはそのテーブルをSELECTするだけで手軽にレポートを生成できます。
ソフトウェア開発者がOSSのモジュールを使って開発するように、分析エンジニアもモジュールを組み合わせて手軽に分析を行う未来が来るかもしれません（SALESCOREでもそれをやりたいと思っています）。
Operational AnalyticsとReverse-ETL
Reverse-ETLサービスを提供するCensusはOperational Analyticsという考え方を提唱しています。個人的な解釈も含めて説明すればこんな考え方です。
「BIツールで頑張って分析レポートを作っても、他のメンバー（営業担当etc）はどうせ誰も見てくれないんだから、営業担当が普段使うツール（Salesforce）に分析結果を書き戻して目に入るようにしよう。そして営業担当の運用に乗るようにしよう」
手段は違いますが、SALESCOREと似たコンセプトだなあと感じています。
データの「活用」をいかに行うか、注目が集まっていると言える事例でしょう。
Reverse-ETLサービスを使うと、各種サービスデータとDWHのデータを相互に同期することができ、データの流動性が高まり、従来の「データがある場所で分析をする」ではなく「分析結果を見たい場所で見る」というデータ体験を得られるように思います。
SALESCOREの活用事例
活用事例については、ぜひこちらをご覧ください！
５か月連続で売り上げ目標達成！営業進捗確認が容易になり、営業組織全体の数字への意識が向上！ - 導入事例 | 株式会社Buff
【深堀記事】YOUTRUSTが2ヶ月でリードタイム半分、受注率6pt向上した方法を聞いてみた - 導入事例 | 株式会社Buff
まさしくSALESCOREが「人を動かすダッシュボード」になっていることが実感できる例かと思います。
この記事が気に入ったらサポートをしてみませんか？