地味プロダクトロードマップのススメ
地味PM Advent Calendar 2022 1日目のエントリーです。
2022 とつけてますが、今年が初の試みです。どきどき。
思いつきで note を書き、思いつきでイベントを企画し、思いつきで声をかけてみたら、たくさんの方に集まっていただきました。ありがとうございます。
もうそろそろ2022年も終わりですね！年の瀬の風物詩、地味PMアドベントカレンダーをやってみたいと思っています！（初だけど）
— 永嶋 広樹 / NAGASHIMA Hiroki (@_nagacy) November 3, 2022
今年の締めくくりに、ブログを書いてみませんか？
ご興味ある方、ぜひ乗っかってもらえたら嬉しいです〜！https://t.co/jF7Jv6pB10 https://t.co/JO3Jkq3JpH
さっそくですので、言い出しっぺらしく、先陣を切ってみました。こんにちは、永嶋です。STORES（旧hey（旧Coiney））に入社して 4年半 になります。
https://adventar.org/calendars/7528
今日、持ってきたテーマは「プロダクトロードマップ」×「地味PM」です。
では、いってみましょう！
プロダクトロードマップ作りは難しい
まずはじめに、私の失敗談をします。
私が今でいうところのプロダクトマネージャーのような仕事をするようになったのは、前職入社時のこと。当時は「開発ディレクター」と呼ばれていました。いまから7年ほど前のことです。
先に私の経歴をお話ししますと、新卒で大規模SIerに入りまして、7年ほどエンジニアからプロジェクトマネジメントを行っていました。そこから小規模SIerに入り4年間、プロジェクトマネジメント以外にもEC運用（R/Sだったのでシステム構築も広告もSNSも倉庫もなんでも）やったり、クライアントの新規事業部署にべったり入り浸って複数の事業（WEBもリアルも）立ち上げ手伝ったり、なぜかUXコンサルみたいなことやったりしていました。
当時の私はまだ若かったので「大規模の堅いシステム開発から、小規模のシステム開発＆運用、新規事業の立ち上げまで、なんでもできる」と過信していました。（今の私は「プロダクト作れる？」て聞かれたら被せ気味に「難しい」と答えるでしょう）
で、そのあと入った前職。
そのときすでに齢30をちょっと超えており、世間的に見ればベテランに分類される年齢だったと思いますし、「なんでもできるんでしょ？」と、ある程度期待されていた（はず・・・）と思うので、とあるプロダクト組織のリーダーになり、ロードマップ作りを任されます。
2015年当時、少なくとも国内にはプロダクトマネジメントなんて言葉は浸透してなかったように思いますし、ネット上にノウハウも転がってはいませんでした。なんとか自己流でやってみるしかありません。
各所にヒアリングして回りましたし、
VOCもたくさん目を通しましたし、
営業チームからの要望は取り込んだし、
取捨選択はしていたつもりだし、
開発チームのリソースやプロダクトの状況も考慮したし、
クリティカルパスも意識していたし、
実現したらプロダクトは着実に進化する、と思えるものでした。
みんなのやりたいことを聞き、整理して、可視化しました。
それでも、評判はイマイチでした。
「あいつにはプロダクトロードマップは作れない」
とまで言われることもあったように思います。
今思い出しても非常に苦い思い出です。
プロダクトロードマップ作りは誰もがする仕事ではない
ところで、みなさんは日々、プロダクトロードマップ、作ってますか？
立場によって「あたりまえじゃん」という人と「作ったことはない」という人がいるかと思います。
あなたがプロダクトマネージャーであれば、おそらく以下のような環境で仕事をされているのではないかとおもいます。
綺麗にツリー化された組織
カオス組織の一人PM
組織化はされているが、なんでも屋さん
実質PMのようなことをしているがPMではない
そのとき、ツリー組織の下部・一人PM・なんでも屋さん・実質PMの方々は、プロダクトロードマップは自分で作るものではない、と考えている人も多いのではないでしょうか。
地味プロダクトロードマップって？
いきなりですが、上の
プロダクトロードマップ作りは難しい
プロダクトロードマップ作りは誰もがする仕事ではない
これを、二つとも否定してみます。
プロダクトロードマップ作りは誰もが行うべき仕事で、難しくありません
そもそもプロダクトロードマップとはなんでしょうか？
プロダクトロードマップとは、平たくいうと、プロダクトの現状とこれからを表し 自分と他者とコミュニケーションするためのツール だと考えています。
前述のどのタイプのPMにおいても、日々仕事を進める上で他者と関わらないPMはいないですよね？
開発チーム向けロードマップ
営業向けロードマップ
経営層向けロードマップ
外部向けロードマップ
etc…
「他者」と対面する上で、それぞれ目的や階層が違う、それぞれの持ち場の人が作成する必要があります。
全体のロードマップに対して、こうした、それぞれの持ち場の人が作る必要のあるロードマップをここでは 「地味プロダクトロードマップ」 と呼んでみます。
一般的なプロダクトロードマップの作り方については、私が語れることはありません。ビジネスフレームワークを駆使して、外部から内部、上流から下流、抽象から具体、長期から短期へと、トップダウンに落とし込んでいくのがセオリーになるかなと思います。難しいですよね。知識と経験が要求されます。
でも、今日お話しするのは 「地味プロダクトロードマップ」について です。
これは、決して難しくありません。
地味プロダクトロードマップの作り方
今日考えた言葉なので、作り方もなにも、作るものについての定義もありませんが、ひとつ、大切なポイントがあるかなと思っています。
それは、 受け取り手の目的に叶ったものとなっているかどうか 、です。
ロードマップにはいろんな種類があると書きました。それぞれ、想定読者がいると思います。その読者が欲しがっている情報、受け取った後に最大のアウトプットが出せる情報を載せてあげるのがよいと思います。
「何を、どういう順番で作るのか」というのは、全てに共通するあたりまえのものだと思いますので、これは特筆すべきことはありません。
開発チーム向けであれば、必要なことはなぜそれをするのか、それをすることで誰のどんな課題を解くことができるのか、どういう状態に顧客を連れていくことができるのか、を強いメッセージ、ストーリーとして可視化する必要があります。開発チームは、解決のプロです。事細かに次は何をやって、という情報よりは、「どうなりたいのか」を強く動機づけてあげることで、プロダクトマネージャーだけでは考えられなかった、さまざまなアイディアが出てくるでしょう。いまあなたが抱えているのがどんな地味なタスクの集合体でもかまいません。それらにテーマを与え、メッセージとストーリーを整える工夫をしてみてください。具体→抽象→具体と、一回ボトムアップに作るのが難易度低くオススメです。
営業向けであれば、上記に加え、要望リストに対するなぜやらないのかの理由、中長期の計画や代替案なども示してあげる必要があると思います。なぜならば、彼らの先にはお客さんがいます。彼らはプロダクトが未熟な状態で日々提案をしたり、要望を受けなければいけないのです。プロダクトができるならば、彼らはある程度強気に提案ができるでしょう。プロダクトができないのであれば、それをちゃんと理解し、代替案を提案するでしょう。営業からすると、プロダクトはいい意味でただの手段で、ただ、お客さんのビジネスを成功させてあげたいのです。
経営層向けであれば、細かな情報はいりません。何何機能を作るのが難しくて結構大変だとか、あれをするには技術的負債があってしんどいとか、RPC1000回も呼んでないとか、そういう情報はいりません。経営判断に足りる、シンプルなメッセージと、事業計画にきちんとミートできるのか、できないなら、打ち手をどうするのか（たとえば、人を増やしたら達成できるのか、作る以外の選択肢も考えるのか、なんなら撤退も視野にいれるのか）を考えられる材料を揃える必要があります。
外部向けであれば、なんでしょうね。私はあまりやったことはないので多くを語れない前提なのですが、過去に Salesforce のイベントにお客さんとして参加して、生でロードマップを語るマーク・ベニオフ氏の話を聞いた時に、単純にワクワクしました。「このプロダクトは良いプロダクトだ」と確信しました。外部向けは、顧客に夢と安心を与えられることが重要なのかもしれません。
ところで、冒頭の私の失敗談ですが、答え合わせとしては、上司は私に「経営層向けプロダクトロードマップ」を求めていたのです。なぜならば、その上司が次に行いたいのは人員計画だったからです。当時それがわからなかった私は、与えられたメンバーでできる範囲の「開発者向けプロダクトロードマップモドキ」を作ってしまっていたのです（実際には開発者向けプロダクトロードマップとしても足りていなかった）これでは、「あいつには作れない」と言われても仕方がないですね。
まとめ
プロダクトマネージャーは日々「意思決定」をする仕事だ、「孤独」な仕事だ、などと言われることがありますが、少し誤解を招きそうな表現だなと思うことがあります。
もちろん、最終的に誰も決められないことを「私が責任を取る、これでやろう！」と決めることもあるかと思いますが、基本的には、客観的な材料で９割の意思決定は誰でも行えるはずです。意思決定をするための材料を集め、可視化することが重要です。意思決定は思いつきではありません。
これは前職で教えてもらったことですが、意思決定は決定事項そのものよりも「決定された背景」を残しておくことが最も重要です。決定事項は、環境の変化に合わせて変化させてもよい（むしろ順応しなければならない）と思いますが、背景は揺るがない（むしろこれがないと変化できない）からです。また、大きなプロジェクトになればなるほど、後からメンバーがが増えていきます。偉い人も首をツッコんできます。知らない謎のおじさんも入ってきます。その際、余計なところで議論を再燃させない必要があります。そのために「決定された背景」が最も大事です。
また、孤独であるというのは、一人でやってしまおうとしているからだと考えています。プロダクトマネージャーはただのアイコンです。実際には社内外の優秀な専門家の知見をうまく巻き込み、練り上げるのが大事です。そのためには、そもそも一人では実現ができないのです。孤独とか言ってるヒマはありません。
プロダクトロードマップは、コミュニケーションツールです。ぜひ、普段はその機会がないPMの方も、自分にとっての他者とは？を意識して、日々のコミュニケーションをなめらかにする地味プロダクトロードマップを育ててみてください。
おしまい。
明日以降のエントリーも楽しみです！
メリークリスマス！
この記事が気に入ったらサポートをしてみませんか？