マーケターにもプロジェクトマネジメントの視点が必要――PMBOK を学ぶ

Dynamics 365 とAdobe Marketo Engageを導入しているユーザーの分科会「DKETO」。今回は2024 Japan Adobe Advocatesの日本ビジネスシステムズ株式会社 三田村国樹氏をスピーカーに迎え、「マーケティングにプロジェクトマネジメントの手法を取り入れながら、CRMとうまく付き合う方法」について語っていただきました。本イベントの模様をお届けします。

マーケターの仕事はプロジェクト型？

「プロジェクトマネジメントなんて、自分の仕事には無縁のものだ」と思っているマーケターの方も少なくないのでは？ しかし、三田村氏は「マーケターの仕事とプロジェクトマネジメントは、とても親和性が高い」と言います。

なぜ三田村氏は、そう考えるようになったのでしょうか。ヒントは三田村氏の歩んできたキャリアにありました。

インサイドセールスとしてスタートした三田村氏は、2017年に日本ビジネスシステムズ（以下、JBS）に入社。CRMエンジニアとしてDynamics 365の導入支援に携わった後、プロジェクトマネージャーに就任。それから3年前にマーケティング部に異動し、MOps（マーケティングオペレーションズ）を担当することに。今は、さらにその範囲を広げ、RevOps（レベニューオペレーションズ）に取り組んでおられます。

「そもそもプロジェクトの定義には何があるのか、皆さんご存じですか」と問いを投げかけた三田村氏。すると参加者から、「『ゴール』と『プロセス』？」「期間が決まっているものは『プロジェクト』、そうでないものは『タスク』だと判断しています」という答えが返ってきました。

「さすが、すごいです。ほぼ正解！ やはり皆さんは無意識のうちに、日頃からプロジェクトマネジメントをされているのではないでしょうか」と述べた三田村氏は、「PMI（プロジェクトマネジメント協会）では、プロジェクトの定義として、次の2つの特徴を挙げています」と紹介しました。

＜プロジェクトの定義＞

・有期性…期間の定めがある、始まりと終わりが明確。

・独自の創造…プロダクト/サービス開発、目的が明確。

逆に、目的やKPIはあっても期間が決まっていなければ、プロジェクトではなく「定常業務」になります。「そう考えると、『MOps系の施策』『イベント/ウェビナー』『システム導入』など、マーケターのほとんどの仕事は、期限があり、明確に新しい価値が生み出されることから、プロジェクト型だと言えます」と語ります。

次に、プロジェクトマネジメントの知識体系「PMBOK（Project Management Body of Knowledge）」をマーケターが学ぶ優位性について、話を進めました。

PMBOKでプロジェクトを成功に導く

改めてPMBOK（ピンボック）とは、PMIが発行する、プロジェクトマネジメントに関する標準的な知識を体系化したガイドラインです。PMIが提供する世界的に認められたプロジェクトマネジメントの資格「PMP（Project Management Professional）」の試験対策に使われる他、JBSでは現場のプロジェクト管理でもPMBOKが活用されていると言います。

PMBOKでは、プロジェクトは次の5つのフェーズから成り立つとされています。

・立ち上げ…プロジェクトの目的や目標を明確にして、実施の可否を判断するフェーズ。

・計画…スコープ/スケジュール/コストなどを検討して、プロジェクトの進め方を決定するフェーズ。

・実行…計画に基づいてプロジェクトを進めるフェーズ。

・監視/管理…進捗を監視しながら、計画と実行のズレを調整するフェーズ。

・終結…プロジェクトを完了して成果物を引き渡すフェーズ。プロジェクトの振り返りを行うとともに、プロジェクトで得た知見を後世に引き継ぐ。

そんなPMBOKから、三田村氏はクイズを出題しました。

Q. では次のうち、一番失敗の可能性が高いフェーズはどれでしょうか？

参加者からは「計画？」「実行？」という答えが出てきましたが、実はどちらも不正解。「確かに実際のプロジェクトでは、計画や実行でつまずきやすいので間違いがちなのですが、正解は 『立ち上げ』 です」（三田村氏）。

どうして立ち上げが一番失敗しやすいのでしょうか。参加者の頭の中に「？」が残る中、次のクイズに入っていきます。

Q. そんな立ち上げフェーズで登場する「知識エリア（プロジェクトの成功に必要なスキルやプロセス）」は、次の10個のうち、どれでしょうか。2つ答えてください。

統合管理、品質管理、スコープ管理、要員管理、調達管理、スケジュール管理、コミュニケーション管理、ステークホルダー管理、コスト管理、リスク管理

正解は、「統合管理」 と 「ステークホルダー管理」 です。「我々マーケターは何かしらの施策をする際に、いきなりスケジュールを引いてしまいがちではありませんか？ しかし、PMBOKでは、立ち上げフェーズで、『統合管理＝プロジェクト憲章（正式な承認を得るための文書）の作成』や『ステークホルダー管理＝ステークホルダーの特定』をおろそかにしてはダメですよ、と書いてあるんです」と語る三田村氏。つまり、「統合管理」と「ステークホルダー管理」が、プロジェクトの成否を分けるカギとなるわけです。

「特にDynamics 365の導入企業では、次のような理由によって“大ステークホルダー祭り”になりがちだからこそ、立ち上げフェーズでのステークホルダー管理が非常に重要だ」と強調しました。

＜Dynamics 365は大企業に選ばれがち→社員数/登場人物が多い＞

Microsoft 365導入済みの大企業が、ワンプラットフォームの実現や、併用によるコストメリットをもくろんで導入することが多い。

＜“うちは独特”がありがち→伝統が分かる人たちを召喚せざるを得ない＞

Dynamics 365を導入する企業は、ビジネスモデルや関係企業が複雑で、JTC（Japanese Traditional Company）ならではの文化や伝統が多い。

＜結果、カスタムしがち→業務/情シスのオールスター勢ぞろい＞

「SaaS標準に合わせるべきだ」と頭で分かっていても、結局、業務プロセスを変えられず、要件を優先することになり、カスタマイズが多くなってしまう。

RACIチャートで始めるステークホルダー管理

では、具体的にどのようにステークホルダー管理をすれば良いのでしょうか。

三田村氏は、「特に正解はないけれど、大切なのは『ステークホルダー登録簿』としてドキュメントで残して可視化すること。プロジェクトのキックオフで『ステークホルダーは、こちらで合っていますか？』と確認するのが重要です」と語り、オススメの管理法として「RACIチャート」を紹介しました。

RACIチャートでは、横軸にステークホルダーをバイネームで書き出し、縦軸にプロジェクト内のアクティビティを並べます。そして、それぞれのアクティビティにおいて、誰が何の役割を果たすのかを明確にしていくのです。

RACIチャートの作成ルールは、「A（説明責任者）はアクティビティごとに1人ずつしか設定しないこと」だけ。これにより、何かトラブルが起きた際に、責任の押し付け合いを防ぐことができます。

ステークホルダーの特定および管理表を作成することで、何が見えてくるのでしょうか。三田村氏は、次の4つのパターンについて、解決策を提示しました。

1. 役者が多すぎる

ステークホルダーを書き出してみると、あまりに多すぎて困ってしまうパターンです。役者が多すぎると、「どこまで巻き込めばいいのか分からない」「意見がまとまらない」「後でちゃぶ台返しをくらう」なんてことも。アジャイル開発では 「ピザ2枚ルール（Two Pizza Rule）」 と言われ、「チームの規模はピザ2枚を分け合える人数（約6〜8人）が最適なチームサイズである」とされています。「経験上、10人前後が限界。プロジェクト全体で30人いたとしても、このフェーズでは多くてもこの10人といった形で、意図的に絞り込むのも大切だと思います」（三田村氏）。

2. 役者が足りない

逆に、役者が少なすぎて困ってしまうパターンです。役者が少なすぎると、「チームで解決できないことが増える」「後ろ盾が少ない」「後で不平不満が出る」といったことが起こりがち。そんなときは、専門家への相談や、キーパーソンに「相談役として入ってもらいたい」とお願いするなど、立ち上げの段階で役者の頭数をそろえておくと良いそうです。

3. 役割が不明瞭

三田村氏がこれまでプロジェクトを立ち上げてきた中で、一番多かったのがこのパターンだと言います。「キックオフでそれぞれの役割を提示すると、『それは私じゃない』なんて言われます。でも、いなければ進まないので、『じゃあ誰ですか』という話をするしかない。経験上、スケジュールと役割/体制は、最も齟齬が起きやすいところなので、キックオフで握っておくことは、とても重要です」（三田村氏）。

4. 座組の不足

PMBOKでは、次のフェーズに進むときには「フェーズゲート」を設けて、このまま進めるか、変更が必要か、はたまた中止すべきか、といった判断を仰ぎ、ステークホルダーの承認を得ることが推奨されています。そのため、ステークホルダーの管理表を作成する際に、「このフェーズゲートを通過するためには、あの人に承認を得るための会議体を設定しておくべきだ」といった観点で、座組の不足がないか、頻度や手法を決めておくようにしましょう。

「特にCRMが絡むマーケ施策は、ステークホルダーが多くなりがち です。頭の中でやってみるだけでも難しさを感じられると思うので、一度、施策を実行する前に、取り組んでみてもらえたらと思います」と語り、三田村氏は発表を終えました。

最後に、参加者から寄せられた感想を、いくつか抜粋してご紹介します。

「私はもともとエンジニアで、1か月前にマーケに転籍してきたばかりなのですが、過去のプロジェクトを振り返ると、うまくいったものは確かに、PMがステークホルダーの中で誰が意思決定者なのかを明確に決めてくれていたと思い出しました。また、マーケの仕事もプロジェクトとして捉えることができるというのは、自分的にすごくしっくりきたので、これからプロジェクトマネジメントを意識しながら仕事を進めていきたいと思いました」

「Adobe Marketo Engageのプロジェクトがもうすぐ終わりそうなのですが、今日の内容を意識していれば、もっと早くスムーズに進められただろうなと。『これは誰に確認しないといけないのか』というのを走りながら考えて調整していたのがすごく大変だったので、間違いなく“立ち上げ”で失敗していたなと思います」

「マーケターを長く続けていると、施策を回すのも手慣れてくるんですよね。次に何をすれば良いのか分かっているがゆえに、ステークホルダー管理を蔑ろにしてしまいがち。突然、『自分にも意見を言わせろ』みたいな人が出てきて、大炎上したことがあります。企画を立てる際には、作業内容やスケジュールだけではなく、体制図もちゃんと用意しなければならなかったんだなと、すごく腹落ちしました」

イベントの最後にはネットワーキングを行い、またJBSの社員食堂「Lucy’s CAFE & DINING」にて希望者のみの懇親会も実施。似たような悩みを持つ仲間同士で熱い議論を交わしながら、交流を深めました。