BizOps実践論 -事業会社におけるデータ活用5選-
もしかしたら2022年は日本のスタートアップにおけるBizOps元年だったのかもしれません。
多くのスタートアップでBizOpsチームが生まれました。これを書いている2023年8月時点までに、LayerX、マネーフォワード、リンクアンドモチベーション、ログラス、アルプ、Chatwork、ソーシャルインテリア、ナレッジワーク、アカツキ、Azoop、サイバーセキュリティクラウド、PoliPoli、Rehab for JAPANで求人が出ていたことを確認しています。
前回のnoteを書いた2022年5月時点では、どう探しても国内には3社程度しか見つからなかったのですから、この1年で急激に増えたのかと思います。
きちんと機能すれば非常に重要な役割を果たすBizOps。とはいえ実際は、次々と現れる課題に翻弄されながら右往左往したり、三歩進んで二歩下がるような思いで少しずつ体制整備しているのが現実かもしれません。
今回のnoteでは、僕たちがBizOpsチームを立ち上げてからの16ヶ月間で進歩したことのうち、もしもう一回BizOpsの立ち上げをするとしても取り組むであろうことを5つ共有したいと思います。
結果的に、組織の状況に依存して個別性の高いよろず屋業務ではなく、汎用性の高いデータ活用・テクノロジー活用に関する話が中心になります。
これからBizOpsチームを設置しようと思う方や、今まさにBizOps業務に従事している方にとって、なにかしらヒントになれば幸いです。
1箇所に情報を集める『Data Platform』
BizOpsが担う役割で大きなことの1つは、4大経営資源である「ヒト・モノ・カネ・情報」の中の「情報」資源の活用を司ることだと思っています。そのためにも、情報（データ）を蓄積する業務システムの整備は重要です。
当時のhacomonoは、情報がさまざまなシステムに散在していました。アカウントプランや議事録はNotionに。商談情報はSalesforceに。見積や請求情報はMisocaに。売上情報はスプレッドシートに。入金情報はfreeeに。と。
共通の企業IDや取引IDがあるわけでもなく、人の手でそれらのシステム間のデータを転記・同期していました。これではデータの利活用はおろか、事務スタッフの業務負荷も高まるばかりですし、いつ請求ミスが起きてもおかしくありませんでした。
幸いSalesforceが導入されていたので、「All Data in Salesforce」な状態を目指してQTC（Quote to Cash）に関する情報をSalesforceプラットフォーム上に一元化していくことにしました。
この中でも特にインパクトが大きかったのが販売管理システムです。当時のSalesforceには月次の請求総額は入っていましたが内訳が入っていなく、どの顧客にどのオプション商材を取引しているのかがデータベース化されていませんでした。
そのため「◯◯オプションは、◯◯な規模・業種によく導入されている」とか「営業の◯◯は、提案における◯◯オプションの販売率が◯◯％」とかの戦況把握をするのが容易ではなく、営業の肌感覚以上の情報を集めるのが困難でした。
この課題に対して、Salesforceプラットフォームの上で動くSoascを導入したことは大きな変化がありました。請求総額のみならず、販売した商品の数量・単価・明細・割引率のすべてがSalesforceプラットフォームに格納されるようになったので、Salesforceレポートだけでも多様な戦況把握ができるようになりました。
一方で販売管理システムの導入・リプレイスは極めて難易度の高いシステム導入の1つだと思います。商談管理システムや、MA、IP電話、オンライン会議システムなど、営業が使うSaaSシステムはたくさんあり、これらの導入を手掛けたことのある人は少なくないかもしれませんが、販売管理システムは異質の難易度です。
会計システムとも接続しなければならず、経理との連携が欠かせません。売上計上・締めの概念や、月次決算との業務連動、承認フローの整備や、レコードロックの権限管理などの要件に加え、求められる正確さも異なります。
営業企画系のメンバーだけで取り組むことなく、販売管理システムや経理業務に明るい導入ベンダーや情シスと一緒に、それなりの予算と体制で臨むのが安全だと思います。
※事例紹介いただきました：https://www.opro.net/customer/hacomono.html
大きな移行負荷はかかりましたが、早期に取引情報を1箇所に集めるData Platformを作れたことはリターンの大きい取り組みでした。そのあとのデータ活用を大きく進歩させることに繋がっています。
1箇所で戦況把握できる『Analytics Platform』
2つ目は、データで「戦況把握」をするためのプラットフォームです。主に経営陣向けに作った、事業の戦況を俯瞰的に把握するためのものです。
例えば当時、月次売上の予実情報はSalesforceダッシュボードで可視化していました。が、あくまで月末時点に達成しているべき数字に対する進捗の可視化しかできていませんでした。「今月目標300に対して現在100です」のような。
なので、当然ながら月初・月中は未達な数字になります。「このままのペースで進捗したら月末どうなるか？」という近未来予測に直接応えるものではありませんでした。
加えて情報の散在も課題でした。「受注状況はあのSalesforceダッシュボード」「リード獲得は別のダッシュボード」「NRRは別のシート」「チャーンレートは、、、」と別々のファイルやURLになっていました。
毎日のようにその数字と向き合っている現場はそれでいいのですが、全体を網羅的に俯瞰したい経営陣にとっては次々と移り変わる状況にスピーディに対応するためにも「あのデータどこにあったっけ？」という状況は避けたいものです。
そこで、経営陣が戦況把握をするために、見たいデータを1箇所に集める経営データ基盤の構築を行いました。現場も含めて同じデータを見るようにしたかったので、無料で使えるLooker Studioで構築しています。1つのURLに複数のグラフを入れているので、1つのURLだけブックマークしておけばデータを探すのに迷うことはありません。
日次のMRR予実は、COOが毎週キャプチャを取り、週次定例MTGで全社共有しています。
フォーキャストのグラフは絞り込みができるので、集計期間を変えたり、特定の部署に絞り込んだり、特定の営業担当だけに絞り込んだりもできて、誰がどのくらいの達成率になりそうかの見通しがわかります。右半分の明細からSalesforceの該当商談にワンクリックで飛ぶこともできるので現場の案件管理にも。
この他にも、リード獲得の予実や、NRR推移、チャーンレート推移、顧客満足度の推移や内訳などもここに集約。
データソースは、Salesforceの商談データと、スプレッドシート上の予算データです。以前のnoteでも紹介した『Data Connector for Salesforce』が活躍しています。
クエリを書いたりコードを書いたりすることなくノーコードで作れて、かつ無償で使えるLooker Studioはお気に入りなツールの1つです。
※ちなみにこのBIを、「BI」とか「Looker Studio」と呼ぶのは味気ないので、フィットネスを楽しむ生活者が使う体組成計としてメジャーなタニタ社の「インナースキャン」になぞらえて「hacomono Scan」と名付けたのですが、浸透度はイマイチでした。。
これにより、経営会議で毎週クイックな戦況把握をすることができ、気になることがあればすぐに現場部門に確認が取れるようなスピーディな経営ができるようになりました。
1箇所で顧客の詳細がわかる『CDP』
CDPとは「Customer Data Platform」の略称で、顧客データを一元化する基盤のことです。CDPパッケージを提供するベンダーはTreasure Dataなどが有名ですね。
hacomonoでも、顧客データを一箇所に統合することが望まれていました。
・顧客の属性情報：企業名・業種・規模など
・顧客の取引情報：契約オプション・金額・利用期間など
・顧客の窓口情報：営業担当・CS担当・先方の連絡先など
・顧客の利用情報：hacomono製品上の付与ライセンス・設定情報など
・顧客の運営情報：顧客が運営する店舗の名前・住所など
などなど。
当時、顧客からの問い合わせがあった際などに、Salesforceにアクセスできない開発やサポートメンバーが簡単にこれらの情報をすぐに探し当てられないことが課題でした。こういうケースではhacomono Scanのような集計データというより、1社1社の関連情報が1箇所でわかる「顧客台帳」が必要です。
統一された顧客IDがあれば突合は簡単なのですが、そんな都合の良いことはありません。取引に関するデータはSalesforceに一元化されていますが、サポートに関する情報、ID発行に関する情報、製品利用に関する情報はSalesforce以外で行われているものも多く、それらを集約していくことが必要でした。
大ナタを振るう覚悟でやるならば、全てのオペレーションをイチから整備しなおして、用いる業務システムやデータ形式・顧客IDの振り方から再設計する案もあります。が、変化の大きいスタートアップでそんな大プロジェクトをやっても1年経たずに実情に合わなくなるのがオチです。何より顧客台帳作りのためだけにいろいろな関係部署のオペレーション変革に介入するのはあまりにハイカロリーでした。
なのでまずは第一弾として、既存のオペレーションをできるだけ変えずにクイックに作る形式を取りました。いろいろなファイルに散らばった顧客情報に、統一されたIDを振り直していく地道な作業と、今後統一されたIDが振られ続けるよう現実的で実効性のあるオペレーション整備をこつこつと実施していきました。
当初、CTOから依頼を受けたときに、全社の顧客マスタになるものなので「CDP」と大層な名前をつけてプロジェクトを開始しましたが、実際のアウトプットはスプレッドシートです。様々なデータソースからリアルタイムに情報が更新されていく顧客台帳として、開発でもサポートでも誰でも見れるという要件を満たすのはスプレッドシートが最適でした。ツール代もかからないですし。
・Salesforceのデータ：Data Connector for Salesforceで取得
・他のスプレッドシートのデータ：importrange関数で取得
・BigQueryのデータ：Google純正のデータコネクタで取得
どれもほぼリアルタイムでデータ連携できるので、日次以上の更新頻度で最新情報が集約されています。共通IDを振ったのでデータの連結は単純なvlookup関数で。
ちょこちょこと追加されるCDPの改修要件もメンバー主体でアップデートができていますし、構築後のカスタマイズに必要なスキルレベルが低く済むのは変化の激しいスタートアップのインフラにおいてはとても重要です。
使う側にして見ても、いつものスプレッドシートのインターフェイスで検索したり、オートフィルタで絞り込んだりと、使われやすくて持続可能なCDPができあがりました。
ちなみにこちらは「CDP」の略称で社内にすぐに浸透しました。「◯◯な情報を見たいんだけど、、、」「◯◯な顧客を抽出したいんだけど、、、」などの様々な依頼に対して「それ、CDPから探すといいですよ」と解決策となることができ、当初の想定以上にいろいろなケースで使われています。
これにより、Salesforceにアクセスできない社員でも、いつでも顧客に関する必要な情報に1つのファイルからアクセスできる状況を作ることができ、情報を誰かに聞く手間や調べる手間なく、クイックに業務を進められるようになりました。
営業の事務を最小化する『Data Automation』
僕は業務システム構築は好きなのですが、日々のデータ入力はあまり好きではありません。自分が営業をやってた時も、商談ごとの商談メモの記入や日報、週報の記入などは、どちらかというとめんどくさいと感じていました。
その中でも特に嫌いだった事は、取引先登録申請や見積作成などの反復作業です。商談メモは残しておくと後で自分でも思い出せるので「しかたないやるか」という感覚だったのですが、こういった純粋な事務作業はできるだけなくしたかったです。
1年に1回しかやらないような手続きであれば多少複雑になっていても影響は少ないのですが、毎日のように行うプロセスだとそれが数分でも数十秒でも大きな時間の浪費になりますので、ここを効率化できる事は大きなインパクトがあります。
hacomonoの営業においては、特に見積書の作成が毎日のように繰り返し行うめんどうな事務作業の1つでした。
しかもこの見積書の作成については、割ときっちりした販売管理システムを入れてしまった影響で、より営業の事務作業を増やしてしまっている状況がありました。BizOpsの取り組みによって事務作業が増えてしまっていたのです。
移行前のシステムは、ほぼExcelに記入するように金額や単価・明細を枠に書けばPDF出力できるものだったので、使いやすさという意味では抜群でした。それに比べると移行後は、きちんとデータベースとして入力をしないと出力ができないものだったためどうしても事務作業が増えてしまいます。
毎日それを使う営業としては退化しているように見え、システムを入れ替えた直後には使いにくいと言う不満が山のように出てしまっていました。人によっては「元に戻してほしい」という声までも。
データ活用をするために、それが実現できる業務システムとオペレーションを構築することも重要ですが、日々お客様に価値を提供する営業が事務作業に時間を取られることなく、顧客対応に十分な時間を避けるようにすることも同等に重要です。両方実現しなければなりません。
ここへの対応策はいくつかに集約されます。
１）システム変更の必要性を説いて、必要な業務であると理解いただく
２）営業アシスタントや営業事務を雇い、事務作業を代行してもらう
３）自動化テクノロジーによって、できるだけノンコア作業を圧縮する
最終手段は1や2ですが、できる限り抗おうと、3)にチャレンジしました。
そうしてできた成果物の1つが、見積書を1クリックで作れる「ハコロボ」機能です。
ステキな機能つくりました。
— 上村篤嗣 / BizOps構築屋 (@Kam_ats) June 2, 2023
見積書を１クリックで作れる「ハコロボ」機能。
見積書を作るときは、取引条件、契約期間、品目明細、、など入力箇所がたくさん。けれどSaaSならだいたい数パターンに集約される。
忙しい営業が毎回数分かかってた作業が、たった５秒になりました。#BizOps #Salesforce pic.twitter.com/VvCBuIybPq
質の高い自動化になるよう工夫した点が2つあります。
①説明レスの追求
1つ目は説明不要で使えることを目指したことです。どうしても業務システムにおいては入力マニュアルを別途作らないとわからない・伝わらないということは多いです。それらに対処するためにヘルプメニューやヘルプテキストなどの機能を活用することもできますが、本質的には「説明しなくても使える」状態を目指したいと思いました。
今回のハコロボで言うと、
ａ）ハコロボが使える商談にしか表示させない
対応できる商談は当初は新規商談のみで、既存のアップセル・クロスセル商談には対応していません。なので誤作動させることがないよう新規商談以外では表示しないようライトニングコンポーネントを動的表示する設定をしています。
ｂ）入力項目は必要最小限に
例えば見積日、見積作成者、期間などは入力する項目を省いています。元の販売システムにはこれらを全て指定・変更できるきめ細やかな機能がありますが、これらは状況からほぼ一意に決まるので入力させるだけ無駄でした。
なのでハコロボでは必要最小限の項目だけを入力する形式にしています。自動的に初期値設定もするので99%のケースではテンプレートを選んでボタンを押すだけ。極稀なケースで請求開始日や見積名を更新してもらい、もっと稀なケースでこれ以上の項目をカスタムしたい場合は一度作成したあとに編集してもらう形式としました。
ｃ）対話型のウィザード形式に
フローの源流であるウィザード形式にならって、チャットボットなどと同様に何を入力・更新して欲しいのかがわかりやすいように項目ラベルを質問形式にしています。
対話感が出るようにハコロボのキャラクターも生成AIで作成し、2種類のポーズを表示させました。不思議なもので名前とキャラクターがあるだけでユーザ側も管理者側も愛着が倍増します。かわいいは正義なのですね。
②ユーザサイドで見積書テンプレートを増減できる
ハコロボはSalesforceのフロー機能で作られていまして中身はそれなりに複雑です。販売管理システム内のテーブル構造・カラム構造に熟知し、フローに詳しくないととてもじゃないけどメンテナンスはできません。
一方で、見積書のテンプレートは今後の商品ラインナップの拡充に伴ってどんどん変化していくことが予見されていました。そのたびにこれを改修するのはあまりに手間なのでやりたくありません。
見積書のパターンをハードコーディングしてしまったらすぐに使い物にならなくなることは目に見えていました。営業事務などのSalesforceの設定画面を触らないユーザでも見積書テンプレートの増減できることが必要でした。
そこで、以前に作ったフローのアイデアを転用して、ハコロボは「特定の商談レコードに作られた見積書データをコピーする」という作り方にしています。
こうすることで、参照先となる商談レコードに見積書を登録したり非有効化するだけでテンプレートを増減させることができます。フローに手を入れることなく対応範囲を追加することができます。当初は3つだけだったテンプレートも今は10種類まで現場がセルフで拡張してくれています。
このハコロボは、とてもスムーズに営業に浸透していきました。次のレポートの通り、リリースして2週間程度で80%以上の見積書がハコロボから作られるようになりました。
これまでも入力インターフェースを改造する事には多く取り組んできましたが、「ユーザにとって便利なものは放っておいてもすぐに浸透する」という原則を改めて確認できた取り組みになりました。
こういった取り組みを通じて、現場の営業に「BizOpsは自分たちの業務を楽にしてくれる存在」だと思っていただく事は非常に重要だと思っています。
僕たちは経営の意思決定に貢献することも必要ですし、それと同時に現場からの信頼も得なくてはなりません。データ活用のための業務システム改修や入力オペレーションの変更は、時に現場の事務負担を増やすことも少なくありません。
そのトレードオフに対して、会社が決めたんだからやってくださいと強権発動するやり方もなくは無いですがあまりスマートではありません。BizOpsのテクノロジー活用を通じて、現場の事務作業が楽になり、かつデータがきれいに入力されることによって経営のデータ活用も進む。そんな現場と経営の三位一体での変革ができると持続的に協力してもらえる信頼関係が築けて良いと思っています。
※過去にも事務作業の自動化には多く取り組んだので参考までに
顧客起点で前工程を最適化する『Demand Chain Management』
マーケティング部門と営業部門には深い溝があると言われます。
B2Bマーケティングの権威であるシンフォニーマーケティング社の庭山先生は、繰り返し以下のように述べています。
"世界の共通言語になっているのは「セールスイズハンター」という言葉です。営業は基本的に鉄砲を担いだ猟師のようなマインドセットを持っており、動く獲物にしか反応しない、つまり3～6カ月以内に大型案件を受注できる対象にのみ集中力を発揮できる、という比喩です。
その反対語として「マーケターイズファーマー」という言葉もあります。マーケティングは猟師ではなく農民のようなマインドセットを持っていますから、荒れ地を耕して畝（うね）を作り、土地や気候に合った種をまき、2年も3年も肥料をまいたり、雑草を抜いたりして育て続けることができるのです。"
目の前の受注を追いかけ、ニーズが顕在化しているリードを欲しがる営業と、将来の見込み客を育むためにせっせとコンテンツを作りハウスリストを増やすマーケティングとはそもそも目的意識が違うのだと。確かにこれは真実なように思います。
一方、こういった中長期を見据えたB2Bマーケティングに専念できている組織は決して多くないように思います。多くの組織では、すぐ商談につながる顕在リードの獲得が強く期待され、営業の新規受注にどれだけ貢献したかで評価されることが多いのではないでしょうか。
本当は、中長期的な見込み客の個人情報獲得や、そこに対するコンテンツ発信を通じた良い製品認知の形成、そして製品自体のSTP戦略にまで踏み込めると良いのですが、まずは目の前の顕在リード獲得が十分できていないと、これらの本質的な取り組みに着手できないのもまた現実的に直面する真実かと思います。
さてそうなると、マーケターは「ファーマー」なスタンスに安住していてはうまくいきません。「ハンター」のセールスと共に狩りにいくスタンスも持ち合わせて両立する必要があります。
さて、ハンターと共にプロジェクトに取り組むからにはハンターの視点を理解しなければなりません。
その1つに、リードは等価ではないことを知る必要があります。リードにはニーズの濃淡があります。ニーズが顕在化していてこちらから何も働きかけなくても、先方から商談を希望するようなリードもいます。一方で製品には一切の興味関心もニーズもなく、ただ展示会でノベルティ欲しさに名刺交換したり、お役立ちコンテンツとしてのホワイトペーパーをダウンロードしただけのリードもいます。
「ハンター」な営業からしたら当然これらは等価ではありません。なのですが、KPI設計上、これらを等価なMQLとして捉え、MQL数の最大化を追うマーケティング組織は未だに多いように思っています。
特に、MQLをKPIとして広告代理店を活用すると十中八九「薄いリード」の獲得に予算を集中投下されます。顕在ニーズを持つリードの獲得は難しく、そうでないリードをホワイトペーパーなどのコンテンツで集客することは相対的に簡単で、CPAも大きく抑えることができます。
こうして少しずつずれた目的意識とKPI設計で、営業とマーケティング、そして広告代理店の溝が深まっていくように思います。
少し前のhacomonoもそういった状況に陥っていました。マーケティング部門はリード目標こそ達成していましたが、商談生成目標はショートが続いていました。代理店のマネジメントが甘く、代理店はホワイトペーパーや事例コンテンツなどに誘導するキャンペーンに広告予算を割いていました。
これをBizOpsという間接部門から変革しなければなりません。取り組んだのはB2Bマーケティング版の『Demand Chain Management』とも呼ぶべきリードトレーサビリティの確保と、後工程への遷移実績をもとにした新たな成果指標の作成です。
①リードトレーサビリティの確保
商談化につながるリード獲得にリソースを寄せるためには、どのチャネル・コンテンツで流入したリードがどれだけ商談化につながったのかを正確に把握することから始まります。
具体的には、どのチャネルかの識別には広告に付与した5つのURLパラメータまで（utm_sourceとかutm_campaignとかの）。コンテンツはコンテンツごとにSalesforceのキャンペーンIDを分けて管理。この情報をすべてのリードに付与し、商談にも付与することでトレーサビリティを高めるインフラを整備しました。
※URLパラメータの取得・Salesforce連携の技術は複雑なので説明は割愛しますが、この過去記事の 3a.3bと、リンコム土屋さんのCookie経由移送を組み合わせて実現させています。
これにより、どのチャネル・コンテンツから生成されたリードがその後どれだけ商談化したのか・受注したのかが正確に集計できるようになりました。これがあると次の段階に進めます。
②後工程への遷移実績をもとにした新たな成果指標の作成
過去データを元に集計するといくつかの傾向が明らかになります。後工程の商談化率に大きく影響を与えるのは、チャネルではなくコンテンツです。コンテンツを商談化率を元にクラスタリングしてカテゴリ分類を作ります。
そしてそのカテゴリごとに「推定商談化率」を設定します。過去の実績からはじき出される商談生成の期待値です。例えば問い合わせ系カテゴリであれば60%、ホワイトペーパー系カテゴリであれば5%といった具合です。hacomonoでは12種類のカテゴリが設定されています。
そしてこれをSalesforce内で自動計算されるように設定します。MQLかどうかの判定、重複リードでないかの判定、どのチャネル・コンテンツかの判定をしてキャンペーンメンバーに「推定商談化率」を付与します。商談化しやすいリードは高く、商談化しにくいリードは低くなります。これが営業やインサイドと共通のハンター視点でのKPIになります。
Google広告などの設定にもコンバージョン値を使用すれば重み付けを反映することができます。そうすることで広告代理店との目線も揃いますし、Google広告などのプラットフォームの機械学習にも重み付けの方針を学習させることができます。
Demand Chain Managementの効果は大きかったです。商談に繋がりやすい施策はなんなのかの目線が揃い、営業とインサイド、そしてマーケティングと外部の広告代理店も含めて1つの目標を追うことができるようになったことで、月間の生成商談数がほんの2ヶ月で128%になりました。
その後も現場主導で改善を重ねて生成商談数を増やし続けてくれています。部門単位での顧客となる後工程部門からのフィードバックをリアルタイムに反映できる仕組みにしたことで、顧客起点で業務を最適化する体制ができたことは大きな組織上の強みになりました。
BizOpsは事業会社の中からデータ活用を牽引する存在へ
DXの界隈で何度も引用されている話ですが、米国と日本ではIT人材がいる会社が違います。米国ではユーザ企業の中に大半の人材が。日本ではSIerと呼ばれるような支援会社の中に大半の人材がいます。
内部に充分なIT人材がいないとデータ活用は進みません。組織にノウハウも溜まらないですし、それを指揮する指揮官のリテラシーも上がりません。リテラシーの低い事業会社は外部のIT企業を上手に使うこともできず悪循環が続きます。
一方で、最近のSaaS・PaaS製品の広がりや、ローコード・ノーコードエンジニアリングによるITの民主化により、基本的な業務システム開発とデータ活用の敷居はぐっと下がっています。PaaS各社も自らの製品を活用してもらうために、無料のe-learningコンテンツや資格取得制度の設置などIT活用を学べる環境が整ってきています。
その結果、SalesforceのTrailblazersに代表されるような、プログラミングはできないながらも、組織の基幹となるような業務システムを自ら開発・改修する非エンジニア人材が増えてきています。ITの内製化に向けたこの流れはしばらく続くと思っています。
情報があれば、会社が大きくなって組織が複雑になっても正確でスピーディな戦況把握ができます。情報があれば、原因と結果の因果関係を捉え、より効果的な判断をクイックに下すことができます。
4大経営資源の中の「情報」を上手に活用した先には、どんな環境変化にもしなやかに対応する、クオリティの高い意思決定ができる組織が作れると思っています。
BizOpsがそういった事業会社のデータ活用プロジェクトの牽引役となれれば、この組織は一過性のバズワードで終わることもなく、持続的に事業会社で必要とされ、多くの優秀な人材が集まって来てくれる役割になると思います。
僕も、この役割に従事して日々のように四苦八苦する1人として、各社での取り組みが適切に流通し、総体として日本企業のデータ活用力が高まっていったらいいなと願っています。