【b→dash #04】ここで差がでる、b→dash担当者に必要な心構え３選

b→dashの導入・運用に対してお悩みをお持ちの  マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。

第4回は、b→dashの導入担当者を任された方に向け『ここで差が出る b→dash担当者に必要な心構え３選』をテーマにお届けします。最後におまけ資料もありますので、ぜひ最後までご覧ください。

b→dash担当者に必要な心構えを解説するにあたり、少し話は逸れて（それて）しまいますが『スタートアップにおける仮説検証』について触れておこうと思います。

スタートアップや新規事業開発の営みを端的に表現すると、「顧客が抱える未だ解決されていない課題に対し、最適なソリューションは何か、そのソリューションをサービス・プロダクトに昇華（しょうか）し、そのサービス・プロダクトを持続発展的に成長させていく最適なプロセスは何か、を問い続ける営み」だと私は考えています。

この最適なソリューションや最適なプロセスを問い続ける営みを、『仮説検証』と言います。『仮説』とは「～だろう」という現状考えうる最も確からしい仮の答え（自身の考え）です。「顧客が抱える課題を解決する最適なソリューションは、～だろう」「このソリューションを持続発展的に成長させるための最適なプロセスは、～だろう」という仮の答えです。スタートアップや新規事業開発は、この仮説が正しいことを証明する（あるいは間違っていることを証明する）必要があり、そのために『仮説検証』を行います。

スタートアップにおける仮説検証には、以下の４つのフェーズがあると言われています。
１．CPF（Customer Problem Fit）：顧客が抱えている課題は何か
２．PSF（Problem Solution Fit）：最適なソリューション（解決策）は何か
３．SPF（Solution Product Fit）：解決策としてどのようなサービス・プロダクトが最適か
４．PMF（Product Market Fit）：サービス・プロダクトを市場にどのように適合させるか

これらの仮説検証を進める上で、創業者・起業家・新規事業担当者は、心の底から解決したいと思える顧客の課題を選定し、顧客を深く理解し、失敗を恐れず失敗から学習し続けなければなりません。

それでは、これらの姿勢を参考に、b→dash担当者に必要な心構えを見ていきましょう。

注：本パラグラフでは基本的に、ベンダー・代理店の立場で解説していきます。もしくはプロジェクトオーナーである上司や経営陣の方の立場からの解説です。

まず、b→dash担当者に必要な心構えのその１は、『意思を持つこと』です。

稀にですが、まったく自分の意思がない担当者の方がいらっしゃいます。b→dashの導入も経営陣が決めただけ、自分は忙しい、言われたことはやるがそれ以上のことはしない、というような考え方の方です。こういう方の口癖は「どうしたらいいですか？」です。そこに意思はなく、ベンダーや代理店の方からの提案を待つ、完全に受け身の姿勢です。

こういった「意思のない担当者」にb→dashの推進を任せた場合、十中八九b→dashで成果は出ないため、b→dashは解約になり、投下した利用料（コスト）が無駄になります。今すぐ担当者を変えるか、プロジェクトオーナー自らがコミット*すべきです。
*コミット（コミットメント）：積極的にかかわること、責任をもつこと

プロジェクトが進まない、思うように成果が出なかった場合、100%ベンダーや代理店に責任を押し付けます。とは言え、ベンダーや代理店もプロである以上、担当者の方がボトルネックとなってプロジェクトが進まない場合は、プロジェクトオーナーを引きずりだしたり、短期的にはタスクを巻き取ったりしながら何とかプロジェクトを進める必要があります。

次に、b→dash担当者に必要な心構えその２は、『アジャイルの思想を持つこと』です。

アジャイル（agile）とは直訳すると「素早い」「機敏な」「頭の回転が早い」という意味です。もともとは「アジャイル開発」というソフトウェア等の開発手法の１つで、『計画→設計→実装→テスト』といった開発工程を機能単位（例えば、b→dashというプロダクト全体ではなく、メール配信という機能単位での開発）の小さいサイクルで繰り返すのが最大の特徴です。

対比されるのがウォーターフォール（日本語で直訳すると「滝」を表す）という開発手法です。古典的な開発モデルであり、まず始めにプロダクト全体の仕様や計画を入念に策定し、長ければ数年単位で『計画→設計→実装→テスト』といった開発工程を滝のように、上流から下流へ後戻りすることなく水が流れていくように、プロジェクトが進められます。

現代において、この「アジャイル」という考え方は、経営にも取り入れられ、「アジャイル経営」という言葉も生まれています。b→dash担当者になぜこの「アジャイルの思想」が必要かというと、SaaS（サース）*の本来の在り方だからです。
*SaaS（Software as a Service）：基本的にはインターネットに接続するだけで、どこからでも利用可能なソフトウェアサービスの総称

SaaSやアジャイル開発が生まれた背景には、従来のオンプレミス*型のシステムやウォーターフォール型の開発では、時代の変化についていけなくなったことが挙げられます。
*オンプレミス：システムの稼働やインフラの構築に必要となるサーバーやネットワーク機器、あるいはソフトウェアなどを自社で保有し運用するシステムの利用形態

早すぎる時代の変化には柔軟に対応していく必要があります。そのため、b→dashの担当者においても、大目的である当初の導入目的は忘れてはいけませんが、それに縛られ続けてもいけません。時には朝令暮改（ちょうれいぼかい）も必要であることを胸に留めておく必要があるのです。失敗を恐れず、日々改善し続ける姿勢が重要となります。

最後は、『テクノロジーに興味を持ち、学び続ける姿勢を持つこと』です。

b→dashの究極的な思想は「誰でもデータ構築」ができることです。従来のCDP・MAツールにおけるデータ構築は、エンジニアが行うものでした。そのため、マーケターが必要なタイミングで必要なデータを得ることができず、多くの工数や費用が無駄になってしまっていました。一方で、b→dashであれば「ノーコードで誰でもデータ構築」をすることができます。

とはいえ、まったくデータベースの知識のない非エンジニアマーケターの方がいきなり自由自在に使いこなせる代物でもありません。※そのために、業界業種ごとにベストプラクティスを集めたデータセットが予め用意されています。

繰り返しになりますが、現在はVUCA（ブーカ）*の時代と言われ変化の激しい時代です。そのような環境においては、学習し続ける姿勢、変化に適応し続ける姿勢が求められると同時に、いち早くその変化に適応できた企業、マーケターに勝機が訪れます。その意味において、誰でもいつでもデータの再構築が可能なb→dashはVUCAの時代に適したツールであると言えます。
*VUCA：Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）という4つの単語の頭文字をとった言葉で、目まぐるしく変転する予測困難な状況

100%自由自在にb→dashでデータ構築ができるようになる必要は、必ずしもありません。しかし、何もわからないままでは、b→dashで何ができるかもわかりません。無知の無知という言葉があるように、何がわからないかもわからないままではb→dashを使いこなすことはできません。私ももともとは毎日自転車で長野の大地を営業している証券マンでした。最初はとても苦労しましたが、今では多くのクライアントをご支援するに至っています。一歩一歩学んでいきましょう。

いかがでしたでしょうか？全12回の連載のうち、今回は『ここで差が出る b→dash担当者に必要な心構え３選』というテーマでお伝えさせていただきました。もし少しでも「自分には足りてなかったな...」と思い当たる方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。


最後までご覧いただきありがとうございました。

「問題はわかったけど、じゃあどうしたらいいの？」と思われたかと思います。続きが気になる方は以下の資料で「明日から使える３つのアクション」を解説しています。ご興味を持っていただけた方は、ぜひお気軽に資料請求をしてみてください（しつこい営業は一切行いません。※同業他社の方からの資料請求はお断りしておりますので予めご了承ください）。