【b→dash #03 】これだけはやっちゃだめ、b→dashの利用が遅れる３大パターン

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

第3回は、晴れてb→dashの導入が決まった企業様に向け『これだけはやっちゃだめ b→dashの利用が遅れる３大パターン』をテーマにお届けします。最後におまけ資料もありますので、ぜひ最後までご覧ください。

b→dashの利用が遅れてしまうパターンを解説するにあたり、プロジェクトマネジメントと単なるタスク管理の違いを見ていきましょう。

b→dashに限らず、CDPやMAの導入はプロジェクト形式で行われます。プロジェクトとは、一定期間のうちに明確な目標や成果物を達成するために計画的に実行される、一連の活動を指します。プロジェクトマネジメントにおいてよく用いられるのは、QCD（Quality：成果物の質、Cost：費用、Delivery：納期）のフレームワークです。プロジェクトマネージャーは、QCDをコントロールしながら目的の達成を目指します。

しかしながら、多くのb→dash導入推進者は「タスク管理」する人、に終始してしまい、プロジェクトマネジメントをできていないのが実情です。本来、導入推進者はタスクの管理に留まらず、プロジェクト全体の戦略的な計画やリソースの最適化、リスク管理、効果的なコミュニケーション、チームのモチベーション管理など、多岐にわたる役割を担う必要があります。

但し、これは個人の問題というよりは組織全体の問題であり、組織文化やチーム編成、教育と訓練の不足など根深い問題です。普段プロジェクトマネジメントをしたことがない人や、プロジェクトマネジメントを体系的に学習していない人に、いきなりプロジェクトマネージャーをやれと言っても無理な話です。

b→dashの利用が遅れてしまう根本的な原因としては、この『プロジェクトマネジメントスキルの欠如』が挙げられます。それでは、プロジェクトマネジメントスキルの欠如が一体どういった結果に繋がってしまうのかを見ていきましょう。

まずは、『上司や経営陣が描いた壮大な物語を、現実に落とし込めない』というパターンです。とかく、流行り（はやり）に流されやすい経営者や上司は、CDPやMAに大きすぎる夢を描いてしまいます。
・売上が劇的に向上し、顧客満足度も一気に高まると期待する。
・データが自動的に分析され、最適なマーケティング戦略が提案されると考える。
・すべての顧客データが一元化され、完全な顧客像が描けると信じる。
・導入コストは一度の投資で済み、その後は低コストで運用できると考える。
・組織全体が簡単にデータドリブンな意思決定に移行できると期待する。
などです。

このような夢物語は、一朝一夕で実現できるものではありません。今や有料会員数は世界で2億人超を誇る、エンターテインメント界の雄「Netflix」も創業は25年以上前の1997年で、これまで４度のDX*を経て、今の地位を築くに至りました。

DXという言葉の起源は、スウェーデンのウメオ大学の教授であるエリック・ストルターマン氏が「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」と提唱した、2004年に遡ります。そして、日本においてDXという言葉が世に広まりだしたのは、2018年に経済産業省がDXレポートを発信したことがきっかけとされています。
*DX：デジタルトランスフォーメーションとは、デジタルテクノロジーを使用してビジネスプロセス・文化・顧客体験を新たに創造し、変わり続けるビジネスや市場の要求を満たすための一連のプロセスを指す

このような長年にわたる世界的な歩みを一朝一夕で叶えられるわけもありません。従って、b→dash導入推進者は上司・経営陣の期待値を適切にコントロールしながら、現実的な歩みを一歩一歩進める必要があります。

２つ目のパターンは、前述のパターンの真逆です。本来は、自社が抱える全社的な経営課題を解決するためのものであったb→dashプロジェクトが、『いつの間にかその導入目的が忘れ去られ、短期的な売上向上・コスト削減プロジェクトに成り下がってしまう』というパターンです。

私が過去の職場で担当させていただいたクライアント様について触れさせていただきます。本プロジェクト自体が引継案件かつ前任者が急に離任してしまったこともあり、引継し立てのころはクライアントの御用聞きに終始してしまい、プロジェクトの目的にまで思い及ぶことができていませんでした。そんなある時、クライアント先の担当者様の上司の方が定例会議に急に現れ、「導入目的であるｘｘｘは今どうなっているのか」とおっしゃいました。私にとってはまさに青天の霹靂（せいてんのへきれき）でした。「え、そうだったの？」という感じです。そのような話はこれまで先方担当者様からは一切出てきませんでした。

結果、このプロジェクトは大揉めに揉めてしまいました。担当者様だけのせいではまったくなく、私の至らなさを思い知ったとても苦い経験となりました（ご迷惑をおかけした皆様、本当に申し訳ございませんでした）。

このように、経営陣が描いていた目的が現場に浸透しておらず、支援会社内でも十分な引継がされていないようなケースにおいては、導入目的が忘れられてしまうという現象が往々（おうおう）にして起きえます。その結果、プロジェクトは振り出しに戻るならまだいいですが、最悪の場合はプロジェクト自体が立ち消えになってしまいます。

最後は、『担当者の方ががんばりすぎてしまう』パターンです。どういうことかというと、担当者の方が一人でタスクを抱え込んでしまい、適切に社内の人を巻き込めていないパターンです。

冒頭にお伝えした通り、プロジェクトマネジメントには、全体の戦略的な計画やリソースの最適化、リスク管理、効果的なコミュニケーションなどが含まれます。すべてのタスクを自分自身で行う必要はなく、情報システム部の方や代理店、ベンダー等を巻き込んでプロジェクトを進行する必要があります。プロジェクトマネージャーの仕事は、「プロジェクトを進めること」なのです。

一方で、ハイスキル過ぎる担当者の方の場合も注意が必要です。何でも自分でできてしまうがゆえに、タスクの管理・実行や要件・仕様の理解、意思決定などがすべて担当者の方に集中してしまい、何を進めるにしてもその方を経由しなければ何も進まなくなってしまう状態になってしまうことがあります。プロジェクトオーナー自身が、最前線の担当者に立ってしまっている場合（リソースやスキルなどの都合により）には起こりがちな問題です。

また別の機会にもお伝えさせていただきますが、このようにb→dashの推進が属人化してしまうと、問題が起きるのは導入時だけではありません。運用フェーズに移行したのちも、このように属人化してしまったままの場合、担当者の方の退職や異動によってプロジェクトの進行が途切れてしまうこともありえます。従って、b→dashの推進にはリーダーが必要ではありますが、属人的ではなく組織的に推進していくことが肝要となります。

いかがでしたでしょうか？全12回の連載のうち、今回は『これだけはやっちゃだめ b→dashの利用が遅れる３大パターン』というテーマでお伝えさせていただきました。b→dashに限らずテクノロジーの導入にはプロジェクトマネジメントスキルも求められます。社内に適任者がいない、育てたい人材はいるが１人に任せきりになるのは万が一何かあった時に不安、と感じていらっしゃる方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。

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

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