シェア
はてブ
はじめまして、株式会社estieで執行役員 VP of Products 兼 マーケットリサーチ事業本部 事業責任者を務めている久保（@takuya__kubo)です。今回、ご縁があって「もしも今プロダクトマネージャー（以降PMの表記もとります）として学びなおすとしたら」というテーマで記事を寄稿させていただくことになりました。
日ごろからさまざまなPMの方とお話しさせていただくことが多いのですが、皆さんとお話ししていると現在（日本で）活躍している方のほとんどが「気が付いたらPMになっていた」と口を揃えて仰られています。かく言う私自身も意図してなろうとしたわけではなく必要に駆られてなった一人であり、同じ穴のムジナです。
これはPMという役割や性質に依存している要素が多分に含まれていると思うのですが、ある種の生存者バイアス的な要素があり、このままではなかなか仕組み化が進まず、体系的にPMが育たない環境があると考えています。
一方、外部環境を見るとソフトウェアがあらゆる業界やサービス・事業との融合や共存が図られる中、PMという役割の需要は（その在り方は企業それぞれで求められるものは分かれるものの）益々高まる一方です。
今回の記事が、これからPMになろうとしている方、またはPMになりたて、ジュニアからミドルにステップアップしていく方（およびそれを支援しているマネージャー）の学習支援につながり、結果として世の中の需要に応えていく一助になれば幸いです。
自己紹介
経歴
- 2011年早稲田大学商学部卒業後、株式会社博展（セールスプロモーション企業）にて、営業、ディレクター、プランナー、新規事業開発を担当。
- 2013年に現株式会社リクルートに転職後、HR領域でエンタープライズのセールス、セールスマネージャー、九州拠点長、SMBの事業戦略などを担当。
- 2020年に株式会社ユアマイスターに社長室として参画し、資金調達や中期戦略立案、新規事業開発を推進。その後VP of ProductsやSaaS事業責任者として事業拡大全般をリード。
- 2022年に株式会社estieに参画し、Whole Produt構想をVP of Productsとして立案、リードし現在10個のプロダクトの横断戦略や更なるプロダクトの立ち上げを推進している。24年4月より事業責任者、6月より執行役員を担う。
経歴について
簡単にサマライズすると、ビジネス中心のキャリアを歩んできました。その多くの時間を営業として過ごしてきたこともあり、PMへの転向がやや難しいキャリアだったのではないかと自認しています。今回はその意味では「ビジネスキャリアからのPM転向」が主になることを先んじてお詫びしておきます。
一方で、その中にあるエッセンスとしては、他職種からPMへ転向していくうえでも役立つ観点があると思っておりますし、一段抽象化した目線で学びに変えていければと考えています。
では、そろそろ本題に入ろうと思います。
ここからは少し物語調で進めていきますので、気軽な気持ちでお読みください。
本題
- 自己紹介
- 本題
プロローグ
部屋に差し込む日の光がまぶしい。
「朝か」
今日は土曜日。なんだか久しぶりにすごく寝た気がする。心なしか気持ちも軽い。
寝すぎたせいか少しけだるい身体をゆっくり起こしていくと、ふと何か違和感を覚える。はっきりとはわからない。それもそのはずだ。あたりの景色は極端に悪い視力と乱視のせいでぼんやりとしか見えないのだから。しかし、見えなくてもわかるのだ。“何かがおかしい”と。眼鏡をかけた瞬間、違和感の正体にようやく気が付く。
「ここはどこだ？」
そう、自分が昨日寝たはずの場所とは違うところで目を覚ましたのだ。
「え、どうゆう状況？」
昨夜は酒を飲まずに寝たはず。知らぬ間に勝手に人の家に上がり込んだのだろうか？しかも堂々とベッドに寝て。わからない。恐る恐る立ち上がり、
「すみません…」
控えめに声を発しながら家の中を忍び足で歩いていく。
「誰もいない…か」
どうやら自分しかいないようだ。安心すると同時に余計に不安になる。そんなあいまいな気持ちを抱きながらリビングをぐるりと見まわすと見慣れたものが目に映った。
「これ、俺のトロフィー？」
リクルートでもらったトロフィーがまとめて飾ってあった。並んだクリスタルが持ち主の自己顕示欲をにじませる。よくよく部屋を見ると見慣れた持ち物がたくさんあることに気が付いた。クローゼットを覗くと自分の買った洋服がたくさんある。中には見慣れないものもあったが、どれも自分の好みにぴったりのものだった。
「ここは、もしかして俺の部屋…なのか？」
部屋の中にあるものを少しずつ確認しながらようやく状況を理解した。どうやらこの部屋は自分のものらしい。手元のスマホは指紋認証で見ることができた。いろいろ混乱と頭を抱えながらだが、今はどうやら2024年。自分の記憶ではまだ2020年のコロナ禍真っただ中だったのだが、この4年でコロナも少しずつ収束し、勤め先も株式会社estieという商業用不動産テックのスタートアップにいるらしい。
「記憶がない？」
そう、どうやらこの4年の記憶がすっぽり抜けたようだ。嘘のような本当の話が自分に降りかかり少し苦笑いをする。
「まあ、こんなこともあるか。どうにかするしかないか」
こういう時にいい意味で割り切れるのは自分の良さだ。悩んでも仕方がないことには向き合わない。問題は「これからどうするか」なのだ。
真っ先に気になったのは仕事だ。幸い某社でビジネス周りの力は鍛えられている。いくら記憶がなくなっているとはいえ、引き続き同様の仕事をしているのであれば、何とかなるだろう。
そう思いながら、今自分がどんな仕事をしているのか調べてみることにした。そうすると何やら仰々しいタイトルをつけて働いてることがわかった。
「執行役員 VP of Products マーケットリサーチ事業本部 事業責任者」
随分と長いタイトルだ。そして1つ読み方も怪しいタイトルがついている。
「ぶいぴーおぶ…ぷろだくつ…?」
タイトルの意味は全くわからない。いったいこれは何の仕事をする人なんだ…。
部屋に置いてあるPCを使い、社内wikiにも入れたことでなんとなく一緒に働いている人物たちの人柄はわかってきた。どうやら取締役の束原は根っからの「ハルキスト」らしい。きっとややこしいやつだ（が、気は合いそうだ）。とりあえず人間関係はそれっぽくできるだろう。きっといつも通りふてぶてしく振舞っていればいい（本当か？）。
しかし、問題はこの「ぶいぴーおぶぷろだくつ」だ。なんだこれは…俺はこんな役職は知らない。だれか説明を求ム。
何かこの仕事に関するヒントはないかと社内のドキュメントや本棚を漁っていると少しずつわかってきた。どうやら「ぶいぴーおぶぷろだくつ」はプロダクトの責任者のことで、自分は「プロダクトマネージャー」として働いているらしい。
「わかったような、わからないような。結局何をしたらいいんだ？」
そんなことを考えながら本棚を漁り続けていると、1冊の日記が出てきた。中に書いてある文字の癖を見ると、どうやら自分で書いたもののようだ。日記の表題を読むと「プロダクトマネジメントを習得する過程とその考察」と書かれている。その瞬間思わずつぶやいた。
「あなたが神か」
「はい」
自作自演でボケている場合ではない。とにかくこれは自分が全くわかっていない「プロダクトマネジメント」について書かれている本であることは間違いない。しかも書籍と違って実際に自分で学んだ過程を書いてあるはずだから、より実践的なのだろう。今はこれを読んで何とか学ぶしかない。幸い今は土曜の午前。今週は3連休。あと2.5日ある。
「連休明けまでにそれっぽく振舞えるいい感じの知識お願いします！！！」
そう祈りながら、そして焦りながらも少しワクワクしながら日記を開く。
プロダクトマネジメントの担い手としての心得
日記の書き出しを読んでみると、こう書いてあった。
▼プロダクトマネージャーの心得
PMはプロダクトに向き合うチームにおいて、プロダクトマネジメントを高いレベルで成立させる人物であり、自分1人でプロダクトマネジメントをするのではない。
これはどういうことだ。「プロダクトマネージャー」というぐらいだから、この職種の人物がプロダクトマネジメントを一手に担うのだと思っていたらどうやら違うらしい。
続いてこう書いてあった。
プロダクトは一人で作るものではない。セールスやカスタマサクセスと一緒に顧客の声を聴き、デザイナーとともに課題の特定や情報設計を行い、それらを実際に動くものへとエンジニアやQAなど多くの仲間とともに形作る。そしてマーケティングや再びセールスやカスタマサクセスと顧客にプロダクトを届けていく。その一連すべてがプロダクトマネジメントといえる。多くの仲間とともに実現するものだ。だから、一人ではできない。
なるほど。プロダクトマネジメントは多くの仲間とともに行うから一人ではできないのか…。
では逆にプロダクトマネージャーって何に責任を持つのか、役割がわからないな…。
そう思ったらそこに答えが書いてある。「こいつマジで神だな」と自画自賛にならない自画自賛をしながら読み進める。
プロダクトマネージャーは、チームがプロダクトマネジメントを遂行できる状態にするために、チームに足りないものを何とか埋める必要がある。これは自分一人で行うことにとどまらず、リソース獲得をしてくるなども選択肢に入る。
同時に、絶対果たさなければならない機能として「意思決定」が存在する。多くのステークホルダーがかかわるが故に、方向性が揺らぎやすいのがプロダクトマネジメントの特徴。だからこそ最後は責任をもってPMが意思決定しなければならない。
なるほど。でも意思決定できるのって楽しいし、面白そうな仕事だな。俄然興味がわいてきた。しかし、そのあとに続く文章を目にし、その考えは吹き飛んだ。
ただし、プロダクトマネージャーは「決める」という強い権限を負う代わりに、そこには「結果責任」が伴う。チームやプロダクトが成功するかどうかはPMが自分の意思決定を正しいものに変えられるかに懸かっている。生半可な気持ちでやるならばやめたほうがいい。楽しいのと同じぐらい結果が出ない期間は苦しくつらい。そしてそれは営業のように短いサイクルで成果が出るとは限らないので長期にわたることだってある。
「甘かった…」と即座に反省した。「権限がある」ということはその裏側に「責任と義務」があるということだ。関わる人全員の行く末を左右するような重要な役割なのだと理解した。同時に、記憶をなくした自分のような人間がこんなことをできるのかと不安に感じてくる。
でも、安心してほしい。もちろん誰もが一歩目は弱いPMからはじまる。そこから強くなることが求められるだけだ。良いプロダクトを作りたい、チームを支えたいという意志が何よりも大切だ。
感動で口が開いてしまった。思わず「一生ついていきます！兄貴！」と自分自身（？）であるはずの人物の文章に向かって叫んでいた。
プロダクトマネージャーとしての振る舞いを学ぶステップ
「プロダクトマネージャーとしての心得」はわかった。問題はそこからPMとしてどう振舞っていけばよいか、そのための具体的なアクションだ。
日記にはそのステップとして以下のように書いてあった。
▼ビジネス出身者がPMとしてふるまうための5つのステップ
1. PMに求められる「さまざまなモノの見方」を養う
2. PM転向プロジェクトへのチャレンジ、ビジネス経験のリフレーミング
3. プロダクトマネジメントは実践がすべて
4. 技術領域から逃げない。最大限掴み、学び続ける
5. 自分の強みを活かすプロダクトマネジメントの立脚、「自分らしく」ある
大きくステップが5つ書いてある。
「これは、結構大変そうだな…」
焦っても仕方がないが、相当な量に圧倒される。
よく見るとト書が付記してある。
ビジネス出身のPMがシニアPMに至るにあたってすべてをクリアすることが望ましいが、最低限プロダクトマネージャーとして振舞うには、まず1～3を学ぶことが望ましい。
なるほど。それであれば時間もないことだし、まずはこの3つに取り組んでいくことにしよう。
PMに求められる「さまざまなモノの見方」を養う
この章は主に最低限の知識や座学的な要素が含まれているようだ。いろんな書籍の紹介とそれに伴った押さえるべきポイントが要約されている。
▼推薦図書
・世界はシステムで動く
・ブルー・オーシャン戦略
・エンジニアリング組織論への招待
・SCRUM BOOT CAMP THE BOOK
・UXデザインの教科書
・プロダクトマネージャーのしごと
・INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
世界はシステムで動く
ビジネス出身者、特にセールスやカスタマサクセスなど顧客接点を中心とするビジネスパーソンが自分の体験からOut of boxするのに必要な考え方が書かれている。プロダクトマネジメントや事業開発といった役割への橋渡しとなる「モノの見方」を得られ、事業作りに挑むすべてのビジネス出身者にまずお勧めする書籍。
例えばあなたがセールスだとしよう。新規顧客を獲得する際にセールスは、リスト数→架電数→商談数→成約数とフェーズを直線的に考えることが多い。これは目標達成に向けたわかりやすい考え方だ。目標とする成約数から逆算すればシンプルに達成可能になっていることが多い。
しかし、実世界においては、このような直線的な状態にはならない。実世界ではこれらの「フェーズ」は相互に影響を与える因子になっている。例えば直線的にみると「商談数」を増やせば、「成約数」は線形に増えるように見えるが、これはその間の「成約率」が一定であるということを仮定している。実際には商談数が増えすぎるとその手前の「商談準備時間」が増え、「1社あたりの提案品質」が下がる可能性がある。そうすると成約率が低下し、結果として商談数の伸びに対して、成約数が増えない可能性があるのだ。
このように、それぞれの因子が相互に影響を与え合いながら、「システム（構造）」ができているという考え方が「システム思考」であり、そういった実世界の在り方に気が付き、システム思考で考えられるようになるためにこの書籍をビジネス出身者は読むべきだ。
また、プロダクトや事業というのは、まさにこういったシステム（構造）であり、プロダクトマネジメントはそのシステム（構造）を作ることが求められるため、絶対に避けては通れない道である。
ブルー・オーシャン戦略
ブルーオーシャン戦略は、（諸説あるが）ポーターの競争戦略をアップデートしたものに当たる。ポイントはそのサービスやプロダクト特有のValue Propositionを「偏った形で実現させる」というところにある。プロダクトマネジメントの、特に立ち上げ時においては、あれもこれもすべての機能や領域で最高品質のものを作ることは難しい。何かしらの優先順位をつける必要がある。そうなった際に、「自分たちのプロダクトの価値は他に比べどんなポイントで尖らせるのか」を明確に決めねばならない。その考え方や実例を学べるという点で、この書籍はビジネス出身のPM転向時に役立つと考えている。
エンジニアリング組織論への招待
タイトルはエンジニアリング組織論だが、実態はエンジニアリングと経営論の融合を図った書籍だ。「エンジニア」という言葉がいわゆるプログラミングなどのテクニカルなものを連想させてしまうが、この本は「エンジニアリングというのはエンジニアのものではなく、経営などさまざまなものに応用できる」ということを示している。もちろん一部技術的なことにも触れているが、経営や組織論的な視点で書かれていることから、ビジネス出身者がエンジニアリングや技術領域の理解をしていくうえでの橋渡しになる書籍だ。これも必読である。
SCRUM BOOT CAMP THE BOOK
シンプルに「アジャイル開発」を学ぶことのできる良書である。主人公がはじめてアジャイル開発に取り組むような物語調で書かれていることもあり、自身がどのような形で壁にぶつかるかを想像しながら読むことができる。現代の多くのプロダクト開発組織がアジャイル開発のフレームワークを使っているため、PMへの転向を考えるならば読むべきだ。
UXデザインの教科書
「UXデザイン」というややあいまいなテーマを扱った書籍である。特にビジネス出身者はプロダクトと聞くと「実際に動く機能」を想像しやすい。しかし、それは表層の話であり、「機能」の手前に「ユーザー」と「ユーザー課題」が存在している。このユーザーが機能を通じて、「どのように行動が変わるか」という行動変容を促していくのがプロダクトである。そういった基礎的な考え方や行動変容を促していくプロダクト開発のプロセスを一連で学ぶことのできる書籍である。
プロダクトマネージャーのしごと
プロダクトマネージャーというものの実像に迫った書籍であり、その苦悩やあいまいさについて率直に書かれている。現役PMが読んでみると「そうそう、本当にそういうのある」ということを頷きながら読めるぐらい無理がなく指針となるような構成になっている。そういった意味では、「PMになる前の心構え」として一度読み、PMになってしばらくしてから「立ち返る場所」としてもう一度読むのが良い。悩んだときは開いてみるとよい。その「悩み」は当然起きるものであり、「自分だけではない」と少し安心できるはずだ。
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
プロダクトマネージャーの仕事はもちろん、プロダクトマネジメントにかかわるステークホルダーや開発チームのメンバーそれぞれの役割、開発フローや仮説検証の手法など横断的に扱われた書籍。上記の『プロダクトマネージャーのしごと』が指針的なものだとすると、『INSPIRED』は「ひとつのベストプラクティス」が書かれた本だと言える。現役PMの多くの人が読んでいるため、共通言語としても役立つ。一連のフレーム理解という意味でも必読と言える。
PM転向プロジェクトへのチャレンジ、ビジネス経験のリフレーミング
課題図書は何とか休日3日間で読み切った。しかし、これ以降の2つの章はどうやら実践を通じてでしか習得できないらしい。しかも、この「PM転向プロジェクト」は本の中の自分曰くプロダクト開発に携わったことのない人物には必須の取り組みらしく、避けては通れないようだ。
しかし、今の会社で自分はプロダクト責任者として働いている。そのような中でこのプロジェクトを体験できるだろうか。そもそもPM転向プロジェクトとは何なのか。
▼PM転向プロジェクトとは
ビジネス出身者が今までのビジネス経験をリフレーミングし、プロダクトマネジメントの構造を踏まえて理解しなおすプロジェクトのこと
わかるようなわからないような。具体的に何をすることなのだろう。日記には以下のように書いてあった。
セールスやカスタマサクセスなど日常業務から、「時間軸」「対象範囲」「視座（高い視点）」を変えたプロジェクトに携わり、プロダクトマネジメントの視点を身に着ける。
具体的には、「Go To Market」のように「顧客に対して商品をどのようにデリバリーしていくか」の全体設計に携わる、「特定セグメントにおけるベストプラクティス創出」のように、点ではなく面でのサクセスモデルを構築する、「プロダクト開発へのドメインエキスパート参加」のように顧客の専門家としてプロダクト開発にかかわるなどが該当するプロジェクトだ。
最後のプロダクト開発はかなり直接的な経験だが、それ以外のものは直接的にプロダクトマネジメントにかかわらないものが多い。上記のようなプロジェクトを体験しながら、「プロダクトマネジメントのフレーム」で捉え直すことでビジネス経験をプロダクトマネジメント経験に変えることができる。
なるほど、とりあえずはここに書かれた取り組みをすればよいのか。実際、この日記の自分はどんなPM転向プロジェクトを経験したのだろうか？
かく言う自分は某社で数年間連続でシェアを落としていたプロダクトのリクーププロジェクトの経験がPM転向プロジェクトだと捉えている。それまでは、セールスマネージャーとして自分が預かる顧客の中で売上目標を達成することがミッションだったが、このプロジェクトでは「SMBマーケットのシェア逆転をするにはどういったプロダクトデリバリーに変えていくべきか」というミッションを担った。
考える範囲にプロダクトそのものは入っていなかったが、「ユーザーにとってのプロダクト価値の再定義（セールスメッセージとしてのValue Proposition）の置き換え」、「業務プロセスの変更」「デリバリー組織の最適化や組織開発」等、対象範囲は大きく広がった。
また、四半期業績の達成というところから、シェアの反転攻勢や逆転といった指標に変わったことで「時間軸」は必然長くなり、四半期で達成ということを捨ててでも、中期でシェアを獲得しなおすという長い時間軸でとらえるものになった。
そして「視座」という点では、役員へのダイレクトレポートを行うなど、このプロジェクトを進めるうえで持つべき観点やビジネス戦略上の要請を肌で感じることができた。
取り組みの詳細は省くが、結果としてそのプロジェクトは成功し、1年後に事業はリクープ、シェアは再び高まり始めた。
この当時は、これがPM転向プロジェクトであると認識していたわけではない。しかし、自身がプロダクトマネジメントを担うことになり、過去の経験を棚卸しする機会を持った時、このプロジェクトが「プロダクトをセールス起点でPMF（プロダクトマーケットフィット）しなおすプロジェクト」だったと理解した。
そのサービスは一時圧倒的な競争優位性でPMFし、10年以上にわたり高いシェアを誇っていたが、それが競合の存在により脅かされ、PMFから外れ始めていた。それを現在の顧客の要望するものやそのための業務プロセスに置き換えることでPMFし直し、もう一度プロダクトとして息を吹き返していくというものだったと捉えている。
このように自身のビジネス経験をプロダクトマネジメントの構造で捉えなおすことで、未経験だとしてもプロダクトマネージャーとしての振る舞いをはじめられる可能性がある。
「そうか、あの時の体験をもとにすればいいのか」
このプロジェクトは記憶にある。確かに自分の今までの経験の中でも一番大きなものだった。ただ、役に立つ要素はあるといってもリフレーミングが難しい。簡単に「PMFし直す経験だ」と言っても、どのようにそれを理解したらいいかがわからない。
読み続けるとこう書いてあった。
確かにリフレーミングは難しい。ただ、シンプルに考えよう。プロダクトマネジメントの本質は、「誰の（どの顧客の）、どんな課題を、どのように解決するか」だ。その上で、プロダクトマネージャーはまず、「誰の、どんな課題を解決するか」を決める必要がある。特にビジネス出身者はここで負けたらおしまいだ。開発知識はほとんどないところからスタートする。そのためにチームが迷わないように、「誰の、どんな課題を解決するか」だけは自信をもって答えられなければならない。逆に言えば、それが共感できるものであり、みんなが納得できるものであれば、周囲のステークホルダーは全力で協力してくれる。
ただし、当たり前だが「顧客が言っていた」では絶対にダメだ。だからこそPM転向プロジェクトが生きてくる。「顧客が言ったこと」は課題の断片に過ぎないことがわかるはずだ。「一人の顧客」ではなく「顧客セグメント」という集合体で見たときにどうなのか。「セグメントの中でも特に意識すべき顧客群はだれなのか」、「顧客の言葉」だけではなく業務の観察や業界自体の構造からした際に、どういった洞察を持ち得るか、そこから生み出される仮説は何なのか。
こういった思考過程をもとに「自分はこう考える」と自信を持って言える状態に至り、発する言葉にチームは共感してくれる。正解かどうかは重要ではない。大切なのは誰かではなく「自分の言葉で、誰のどんな課題を解決するか」を話せることだ。これはある種、対象範囲の話だ。
そして、時間軸は短期ではなくプロダクトや事業が継続するということを前提に、「いつ、どんな成果を得るか」という視点だ。短期的な成果を目指すのではなく、中長期と長い時間軸でどのように成果を手に入れるかを考えなければならないという話だ。
また、「負債」についても知る必要がある。プロダクトは作り続けると必ずガタが来る瞬間がある。車に5年乗ったら買い替えを検討するのと同じことだ。どこかのタイミングで車検を受けたり、修理に出したりとメンテナンスをする必要がある。これが同じように起きる。そうした際にいつどのタイミングでメンテナンスをするのか。その判断を迫られた際に、遠くを見ながら判断しなければならない。短期の業績だけを考えていたらこの視点は持てない。
最後に「視座」だ。会社や事業全体から見た際の位置づけや関係性、戦略との一貫性、事業計画やファイナンス視点など、経営や事業マネジメントの理解が不可欠になる。それも書籍による網羅的なものではなく具体的なケースをプロジェクトを通じて学ぶことで手触り感が出る。これは頭で理解するというよりその空気感を味わうことにも意味があるかもしれない。ある種の「修羅場」のような体験を通じて身につくものだ。
あとは、シンプルだがプロジェクトマネジメント経験はそのまま生きる。「いつ、どこまでに、どうプロジェクトを進めるか」これは非常に大事だ。幸い、あのプロジェクトは開発フレームワークで言うアジャイルに該当する。毎週の状況アップデートをもとにスコープとアクションを変えていった。開発チームとのやり取りも同様だ、頻度はそれぞれのチームによるが、事実をもとに方針を細かく変えたりスコープとアクションを変更していく。
少しずつわかってきた。確かにいろいろあるかもしれないが、「誰の、どんな課題を解決するか決める」「（その時々に応じた）適切な時間軸で意思決定をする」「結果を出すために複眼的な視点を駆使する」「プロジェクトマネジメントを転用する」ということを進めていけばいいらしい。
なんとなく今の自分でもやれる気がしてきたあとは日々のアクションに落としていくのみ。いったいプロダクトマネージャーは日々どんな仕事をしているのだろう
プロダクトマネジメントは実践がすべて
日記に書かれた章の通り、これはいよいよやるしかないようだ。日記には以下のように書いてあった。
▼プロダクトマネジメントは実践がすべて
これは記載の通りだが、机上の知識や体験のリフレーミングなどプロダクトマネジメントの疑似体験に近いことを進めてきた。ただ、あらゆることに当てはまるが実践の前ではそのどれもが見劣りする。これはどのプロダクトやどのチームをとっても完全に同一なものは存在しないが故に、体系的な知識やケースが当てはまりきらないことが言える。そのため、たとえ稚拙であっても実践し、何かしらのアウトプットを出し続けることが重要だ。
四の五の言わずにアウトプットを出してたたかれてみよう。打ちのめされてからがスタートだ。そのぐらいの気概がなくては職種転向などできない。さぁ、進もう。
最後がやや体育会っぽい「気合根性論」な雰囲気を感じるが共感できる部分もある。
昨夜までで最低限の知識は身に着けた。ここからはやるのみなのだ。
▼estieのプロダクトマネジメントのお作法
・estieはスクラム開発（正確にはScrumBut）を取り入れていることから、SCRUM BOOT CAMP THE BOOKに従って開発チームとともに進めていく。いわゆる朝会やセレモニーは通常通りやるのがよさそうだ
・特にPMには「プロダクト・ディスカバリー」と呼ばれる「顧客の課題発見」や「課題深化」を求められているらしく、ドメインや顧客理解が必要となる
・ユーザーがどのようにプロダクトを活用しているかのユーザーログの分析や顧客インタビューなどを先導していく必要があり、その設計やどの課題を深く掘るかはデザイナーと協働して進めることが多い
・プロダクトマネージャーの主たるアウトプットは、「ロードマップ」「バックログ」「PRD」になるようだ。これらはまだ取り組んだことがないが必要な瞬間に詳細に学ぼう
・あとは「デザイン」や「要件定義」、「実装内容」に対するレビュー（期待通りのものかのフィードバックと議論）も果たすべき役割の一つだ。これはPMだけが行うものではないが、PMも責任を持ってやらなければならない。適切なレビューの仕方がわからず、後々困りそうな気がする
ほかにもプロダクトマネージャーとして必要に応じてやるべきことはたくさんあるようだが、心を決めて新天地へ行こう。いざ出陣！
出社、そして新たな開発テーマへの挑戦
「おはようございまーす」
とりあえず出社からはじめてみる。あ、あの人は代表、あの人は営業だったな。
あたりを見回しながら何となく人を確認していく。
「くぼたく、今日から新しい開発テーマに向かうらしいじゃん。今度は何やるの？」
代表から話しかけられた。
社内のチャットを見ると、代表のことを「えいちゃん」と呼んでいるらしい。なんだか矢沢永吉っぽいが、本人は全然矢沢っぽさはない。
というか、今日から新しいテーマなのか！？まじか全然知らんぞ。本当にどうしよう。
「えいちゃんおはようー！そうなんだよ。まだ悩んでいるところ。これからチームと一緒に考えていこうと思っている」
とりあえず全力でごまかしてみた。
「お、そうなんだ。まぁ、確かにひかるんとか既にやっていきたいことありそうだもんな。よさそう。まぁ、任せるわ！なんか必要なことあったらまた教えて」
乗り切ったー…というかこんなライトな感じなんだ。プロダクトのことってめっちゃ社長とか経営陣とかも関与するのかと思ったが、どうやらかなり任せられているらしい。
ふと、日記の冒頭に書いてあったことを思い出す。
プロダクトマネージャーは「決める」という強い権限を負う代わりに、そこには「結果責任」が伴う。チームやプロダクトが成功するかどうかはPMが自分の意思決定を正しいものに変えられるかに懸かっている。
「責任重大だな、本当に」
改めて気合を入れ直して向かうことにする。
カレンダーを改めて確認すると、確かに今日はロングミーティングが入っていた。これは新しい開発テーマについて議論するためだったのか。とりあえずアジェンダや原案はないかと調べてみると先週末のうちにいくつかテーマは決めていたようだ。ナイス、記憶をなくす前の俺！
そこにはいくつかのPRDが添付されており、どれに着手するかを議論するようだ。
PRD自体も初見だったので、改めて読み直してみる。
▼PRDの構成
・Context: ユーザー背景およびビジネス背景
・Who: 誰に向けたものか
・Assumptions: プロジェクトを成り立たせる大前提の仮定
・What: 提供する価値およびImpact
・Scope: やること / やらないこと
・Concerns: 解消するべき疑問・懸念
いわゆる企画書のようなものになっている。これ自体は必ずしもPMだけが書く必要はなく、誰もが書いてよいようだ。実際に議事録に貼ってあるPRDは自分が書いたものだけではなく、エンジニアやデザイナーが書いたものもありそうだった。
estieのPRDは製品の細かい仕様までは言及していないようだ。まずは課題について深く扱い、その後製品要求定義についてはDesign Doc（機能要件などを詳細に詰めるHowを中心としたドキュメント）で詰めていくスタイルになっているらしい。
とにもかくにもこの中でどれに挑んでいくのが行くのかを決めていく必要がある。
「くぼたくさん、やりましょう」
時間みたいだ。急いで会議室に駆け込む。
「お疲れ様です！早速やっていきましょうか！」
内心ドキドキしながらスタートする。
「今日のゴールは次の開発テーマを決めていくことなのでみんなで議論していきましょう」
「提案なのですが、比較的僕が書いてきたPRDが多いので今日のファシリテーターはほかの人に譲ってもよいですか？公平に議論したいので」
と、本当は会議の回し方に自信がないのだが、誰かに任せたい一心で投げてみた。
「じゃあ、僕やりますよ」
エンジニアの一人が名乗り出てくれた。あれはテックリードのノムさんかな？
「よろしくおねがいします！」
「それぞれPRDには目を通してきたと思うので、さっそく議論から始められたらと思います。それぞれ意見はありますか？」
ここから侃々諤々議論していく。各々、気になるポイントは違うようだ。
共通しているのは実施した時のImpactの大きさだが、かなり仮説として粗いものもあるためそれが本当に確からしいのかが不安といった意見が出ている。
また、開発をしていくとしたときのソリューション案のEffort（いわゆる開発工数など）の大きさや今の既存のシステムについての負債解消をしなければならないという守りの話も含めて展開されている。
「結構議論が煮詰まってきたね。少し休憩しますか。ケーキ食べましょ」
ロングミーティングの時にデザートを差し入れするのが自分の役割のひとつらしい（笑）ので、オフィスの下で買ってきたものをみんなで食べる。
甘いものは正義。空気も少し和むというものだ。
会議再開。そろそろまとめていきたいと思った矢先、
「くぼたくさんとしては、どうしたいとかあります？」
すかさず、デザインエンジニアのひかるんからの問いが来た。
日記の言葉が頭に浮かぶ。
絶対果たさなければならない機能として「意思決定」が存在する。多くのステークホルダーがかかわるが故に、方向性が揺らぎやすいのがプロダクトマネジメントの特徴。だからこそ最後は責任をもってPMが意思決定しなければならない。
そうだよな。ここで決めるのが自分の役割だよな。
正直、出てくる話はわからないものが多かった。システムの負債解消というのが何を指すのか、それはどのぐらい緊急なものなのか。
自分が書いたPRDも一部論拠が薄い部分があるのも気になっていた（ごめん過去の俺。何も知らないから言えることってあるよな）。ただ、その中でも言葉の書きぶりや、何か自分にしか見えない熱意みたいなものが伝わるところもあり、思わず自分がやってみたいと感じるものが1つあった。
「うーん…」
「なんか、くぼたくさんめずらしく歯切れ悪いですね。いつもはもうちょっと言い切る感じなのに笑」
やばい、バレてる…。
仕方ない正直に話そう。
「負債についての緊急度やこれがどのぐらいやばいかがちゃんと理解しきれていないというところと、自分ではめっちゃやりたいと思っている案があるのだけど、やや熱意押しというか論拠が足りていないなと自分でも自覚していて、少し決めかねているって感じ。負債について理解したいので何がやばいかみたいなところをもう少し教えてもらえると助かる。あと論拠薄い中で突っ込むことについてのみんなの意見も聞きたい」
全然知識がないやばい奴だと思われるだろうか。実際そうだから仕方ないのだが。
「そういうことですね。ちょっと技術っぽい会話の仕方で分かりにくかったですよね。この負債はパフォーマンス懸念についての話をしています。具体的には検索パネル周りで、検索条件を指定してからクエリが返ってくる速度の改善に効きます。特定の動作をするとキューが詰まりやすかったりするので、そのあたりの改善をしたいなと。直近セールスチームが頑張って顧客を増やしていることもあり、利用人数が増えていくとより大変になりえるので今のうちにやったほうがいいかなと思っていまして」
ノムさんがこたえてくれた。
「なるほど、理解できた。“時間経過とともに大きくなりやすい類の問題”ってことだね。しかも検索ってうちのサービスだと主機能の1つだから改善した時のユーザー利便性も大きそう。負債解消と言いつつ、顧客にとっても相当効果が大きそうなやつだ」
クエリとかキューとかのワードは全然わからなかったのでその場で調べて補った。
ただ、すぐにわかったこともある。「ユーザー数の拡大に応じて問題が大きくなる」という話から、かなり重要なイシューだと理解できた。
問題には2種類ある。時間経過で問題の大きさが変わらないものと、時間経過とともに問題が大きくなるものだ。時間経過とともに大きくなりえるものは、なるべく早めに取り組んだほうがいい。これはPM転向プロジェクトで学んだビジネス知識だ。これなら開発経験がなくても判断できる。
「ですです。個人的には結構これが推しです」
「だとすると、これはかなり有力だなと思う。もう1つ、俺の推し案なのだけど、これどう思うかな？正直かなり仮説ベースで不安ではあるのだけど」
「あー、このプロパティマネジメント企業向けの機能ですね？確かに今までとだいぶ雰囲気違うので仮説ベースではありそうですが、面白そうですよね」
「そうなんだよね。気持ちだけはあるのだけど、まだ事実が十分じゃないような気もしている」
「そうしたらこれ検証しながら進めます？エピック2つぐらいだったらできると思うので、並行してやる感じで」
「あー...（エピック？わからないワードが出てきた...）」
すかさずググる。
（なるほど、テーマみたいな感じか。というか、一気に2つもできるのか）
「そんなのできるの？」
思わず口走ってしまった。
「この間もやっていたじゃないですか笑 あの時は3エピック同時に走らせてリソース最適になりすぎたってみんなで振り返ってみましたけど、2つまでなら十分チームのサイズ的にもフロー最適で進められると思います」
とひかるんが言う。
「そうだったね、ははは」
ひやひやする。なるほど、でも2つならいけるのか。
「でも、これ使えるかわからないものを実際に作っちゃうのってどうなのかな、後戻りしにくいような」
「それならFeature Toggleを使って、一部ユーザーにだけ出せるようにするので問題ないかと思います。とりあえず簡単にフロントで動くもの作って触ってもらったり反応もらったりしながら進めませんか？」
「おう、それじゃそうしようか！」
ノムさんの話したワードが全然わからない…と内心ヒヤヒヤしながら答える。
同時に、チームが頼もしすぎて驚いた。これが日記に書いてあった“プロダクトマネジメントはプロダクトマネージャーだけでやることではない”の意味か。
「じゃあ、今日の結論としてはこの2つを進めていきましょう。チーム構成的には3人ずつで進める感じで行きましょうか。チーム間の相互レビューはお互いにすることでもう片方のエピックが全然わからないってことはないようにしましょう」
とひかるんがまとめてくれた。ありがたい。
「あ、くぼたくさんは、この推し案を進めるにあたってもう少し事実収集お願いしていいですか？」
「あ、うん。でもどうやって？」
「え、そんなの顧客のところに行くにきまってるじゃないですか。もしかして体調悪いですか？サクセスメンバーに相談したらすぐに組めると思うのでアサインお願いしてもいいですか？僕も行きたいです」
とひかるんから心配と宿題をもらう。
「あ、ごめんごめん。ちょっとぼーっとしてたみたい。そうだよね笑。了解、相談してみるわ！」
「よろしくお願いします」
「ちょっといいですか？プロパティマネジメントのセグメント顧客に新しい機能開発のインタビュー行きたくて、直近行けるとこあります？」
AM責任者のよーすけさんに声をかけてみる。
「それだったらやわらちゃんとかが顧客多めなので、声かけてみてください。確か明後日とかに定例一件あったからそこでいけるかも」
「ありがとうございます！」
明後日？顧客ヒアリングってそんなに早く行けるものなのか？これが普通なのかな？
「やわらさん、すみません！プロパティマネジメントの顧客にインタビューしたい案件があって、同席させてもらうことできますか？」
「お、いいですよ。ちょうど明後日あるのでぜひ。とりあえず20分ぐらいでよいです？ほかにも何社か行きますか？」
「できればとりあえず触り5～10社ぐらい行きたくて」
「承知です。ここ2～3週で組んでおきますね。てか、くぼたくさんなんで敬語なんですか？普段タメ語なのとやわらちゃん呼びなのに、さん付けで気持ち悪いっす」
「あ、ごめん。なんか“さん付け”気分だったんだよ。ハハハ」
「なんすか、それ笑」
「なんでもない、気にしないで」
危うくボロが出るところだったが、何とか切り抜けた。
とにもかくにもインタビューには行けそうだ。次はインタビューに向けた準備から。
仮説を顧客接点とともにアップデートする
「お客さんとのインタビュー行けることになったよ！とりあえず明後日にまず1件」
「さすが早いですね。当日の準備はどうします？」
「自分のほうで仮説ベースになっているところに関してヒアリング項目は作っておく。まだ物はないから、基本はテキストベースかな」
「了解です。僕もできたら見せられるもの作っておきます」
見せられるものって何だろう？と思いながらインタビューシートをまとめる。
構成は以下の形だ。
▼インタビューシート
・インタビュー目的
・果たしたいゴール／検証したい仮説
・インタビュー項目
過去のものを参考に簡単なドキュメントを用意した。あとは当日聞きながら確かめていくことにしよう。
～インタビュー当日～
「本日はお時間いただきありがとうございます。後半20分で少しインタビューパートを挟ませていただくのでお願いしますね。最初は利用ログやユースケースの学習などの定常コンテンツと機能アップデートについて共有します」
「よろしくお願いします」
「……と、このような形です。新しい機能について何かご不明点ございますか？」
「大丈夫です。相変わらず機能アップデートの速度が速くて驚いています」
「とんでもないです。開発チームのおかげなので。ではここからインタビューに入らせていただきますね。プロダクト責任者の久保にバトンタッチします」
「よろしくお願いします。本日はプロパティマネジメント業務を現在のサービスにとじず、より効率的にする機能開発を検討しておりまして、業務の実態とお困りごとをお伺いしたく思っています」
「業務の中でも○○あたりについて、今どのように進められているか教えていただくことは可能ですか？」
このあたりの質問は、営業時代にもさんざんやってきているから得意だ。課題を直接聞くことよりも、業務の実態を聞くことが大切。業界の一般的な業務プロセスはあるが、各社で特徴があったりする。その差分を明らかにすることを目的として、問題が発生しやすい箇所や困っていそうなところを浮き彫りにしていく。
「なるほど。その中でご不満やお困りごとはありますか？」
「うーん、どうだろう。表面的には困っていないかな」
「なるほど、結構パーフェクトな業務の流れになっていらっしゃる感じですね」
「いや、完璧ってことはないですね。ああ、それで言うと目的が違うけど結局は同じようなExcelを何個も作っているというのはあるかもしれません」
「（きた！）」
足元の業務に慣れていると、咄嗟に聞かれても深く考えずに「困っていない」という言葉が出るのはよくあることだ。そこに対してもう少し投げかけると、「本来困っていること」が顔を覗かせる。
こういった形で何ストロークかしているうちに、自分たちの仮説の1つである、「ドキュメントを複数作ってしまう」にフィットするようなお困りごとが見えてきた。
「なるほど、お話ありがとうございます。お聞きできたお困りごとに対して解決できないか引き続き調査と開発検討していきたいと思います」
話を終えようとしたその時、
「ちなみに、お困りごとってこのような形で解決できませんか？」
ひかるんが、口火を切り手元のPCで簡単なデモをはじめた。
「おお、それは楽になりそうです。この機能があればいちいち作り直さなくていいかも」
「ありがとうございます。まだこちらは手元で触っていただくことはできないのですが、できたらまたご案内させてください」
まさか、もうできているとは…お客さんと一緒に唖然としながらデモを見ていた
「ひかるん、この2日でやってたの？」
「あれはFigmaで簡単に作っただけですけどね、イメージこんな感じかなと。でもユーザーの業務の流れ的にちょっと思ったのと違う部分があったので修正は必要そうです」
「それは思った。PRDの業務の流れと違うところがあったよね。これがこの会社さん特有なのかセグメント自体で異なるのかは調査が必要かも」
「ですね。引き続き聞いていきましょう」
プロダクト開発とはこれほどまでに早く進んでいくのか。
自分の知らない領域とはいえついていくのに必死だ。
ここから複数の企業にヒアリングを行い、事実収集を進めたことで仮説の確かな部分と誤っていた部分が見えてきた。ただ、方向性は合致しており、実際に顧客に触っていただくフェーズに進めることにした。
検証指標を決め、プロトタイプで顧客の反応を見る
「さて、方針としては見えてきたこともあるので、そろそろプロトタイプの実装をしていきたいと思う。最低限価値検証できる範囲で作っていきましょう」
「くぼたくさん、その前にいいですか？これって検証指標って何にしますか？」
検証指標、だと？確かに考えていなかった。顧客課題を解決するということに集中していたのでとにかく使ってもらえばいいと考えてしまっていた。
「プロパティマネジメントのユーザーが便利になればいいというところからスタートしていたから、やっぱりそのセグメントの利用率かな」
「まあ、それはそうかもしれませんが、もう少しアウトカムに近いのがいいですね。あとビジネス的にはどうなったら成功かのビジネス指標も欲しいかも」
なるほど、みんなはこれがちゃんと自社の事業にとっても価値があるのかを気にしているらしい。
何がいいか…。
「どうしようかなー。今回はあくまで一部だけどプロパティマネジメントの業務を機能に乗せるから、ユーザー数は増えるかも」
「あ、それよさそうですね。ユーザー数が増えたらその分アップセルもしやすい」
「そうしたら、“ユーザーアカウント利用数の増加”をKey Resultとして考えて進めようか」
「よさそう。やっていき！」
ここから怒涛の開発がスタートした。今回は最低限の機能開発に収める予定だが、いち早く顧客に届けるために締め切りを設定し、「2週後の顧客訪問時にデモをする」という目標で一気に進めることになった。
毎日、朝会と夕会をしながら、進捗の確認やタスクの整理、優先度の判断などを行っていった。取り組む中でわかったのは、タスクには並列で進められるものと直列で進めねばならないもの（依存関係があるもの）があるということ、「最低限はここまで」とスコープを決めたものの、期限がある場合は、何を捨てるかを都度判断しなければならないということ。
この判断は慣れていなくて本当に骨が折れた。
捨てていいものの判断がつかない。あくまでも要素とその場でユーザーが使うということを考えた時のことを考え、要らないものを考えていった。
例えば入力内容の削除や編集機能は手を付けないことにした。とりあえずまず使うということを考えると間違った内容の編集などは後回しでいい。そもそもここにインプットしたものを使ってもらえるかのほうが大事だ。
そうやって、わからないなりにとにかく決めることでプロトタイプ開発を進めていった。
そして、いざ当日。
最後の追い込みもあり、みんな肩で息をしながら顧客訪問の時間を迎えた。
疲れも見えるのでエンジニア陣はリモートで入りながら顧客反応を見てもらう。
実際にユーザーに触ってもらった際の反応は…。
「これ、いいですね。使いやすい。今まで作っていたExcel不要かも」
最初にインタビューにお伺いしたお客様に当てたところ良い反応が返ってきた。
「でもこっちの機能は使わないかもです。あんまりこういう風に管理してもうまくいく気がしない。現場の営業担当が手元でやりたいと思ってしまうので」
中には実現しきれないものもあった。
自分がより肝だと考えていた機能は意外にも反応が悪い。すべてが思い通りにいくわけではないが、悔しい反応だった。
「提供機能の3つのうち2つは勝ったけど、1つは負けました！」
顧客デモの結果をチームで振り返っていった。
もしかしたら途中で開発をやめる判断にした機能があってようやく利便性を感じていただけるものになっていたかもしれない。そういう意味で不完全な検証だったかもという意見が出た。
これは自分のプロダクトマネージャーとしての判断のミスだ。自分が未熟なあまりにみんなに迷惑をかけてしまった。
「これが結果責任を負うということか」
まだ未熟な自分がいっぱしに悔しがっているのもおかしな話ではあるのだが。
チームで話し合った結果、いったん評価の高い2つの機能について深掘りをすることにした。1社目で得たフィードバックをもとにブラッシュアップをしていく。そこから10社ほどに当てて検証を進めていった。
結果、ユーザーの利用反応は10社中6社で良好、また、その6社がいずれもこの機能の利用のためにアカウント利用数を増加したい意向を示してくれた。
「これは、よさそうだ！」
事前に設定した指標をクリアし、いよいよ本格的に全ユーザーへ提供するための機能開発に進んでいく。
「ここまでくれば、もうあとは完成させるだけだ。余裕だろう」そう考えていた自分の甘さを知ることになる。
本開発に進み、品質の基準が変わる
全顧客にリリースしていく場合、今までデモ用と落としていた必要機能を実装していくことになる。同時に本格的なリリースを意図した際の品質水準にする必要があるとのことで結構なプロトタイプの倍近く期間がかかるということだった。
「プロトタイプでおおむね動いていたし、2週間もあればいけるだろう」と思っていたが、意外と期間がかかるようだ。
とはいえ開発は順調に進んでいるかのように見えた。
基本的には目標日に合わせて順番を決めていったが、スケジュール通りに終わる予想だ。
そしていざリリース日、自分の想像の甘さに気づいた。
機能をリリースしました！とリリース情報を社内全体に伝えたところ、サクセスメンバーやセールスメンバーから問い合わせが殺到。
「この機能って何でしたっけ？」
「お客さんにどう案内します？」
「触ってみたけど、この辺動かないの大丈夫？」
やばい、何が起きているのか…。
「くぼたくさん、デモ会を実施するなど、サクセスやセールスへの接続していました？」
「口頭では伝えていたのだけど、伝わりきっていなかったみたいだ」
「なるほど、ちゃんと確認していなかった僕らも悪いけど頼みますよ！さすがに大きめの機能アップデートだし、社内のデモ会とかきちんと接続しないとみんな混乱しますって...」
「ごめん、これは俺のミスだ...」
「サクセスメンバーは結構ドメインが深いのもあるから、僕らが考え切れていなかった触り方してますね。思ったより非正常系の検証が甘かったかも。どうします？一度リバートします？」
（非正常系？リバート？やばい、混乱している。とにかく調べて答えないと）
いったん心を落ち着け、ググりながら回答する。
「そうだね、いったんリリースしてしまったが戻そう。一度社内のフィードバックを集めて修正してからリリースしなおす形にしましょう」
「承知です。Hot Fixとしてすぐに対応します」
（Hot Fixも調べないと…）
その後、一度機能リリースを取りやめ、改めて開発チームとオペレーションチームで協働デモとQA会をすることにした。
「マジで焦りましたよ！くぼたくさん事前にちゃんと教えてください」
「ごめん、一度説明したので問題ないと思っていた」
「何のために作ったのか、誰がこれを利用したらうれしいのか、もっとちゃんと伝えてほしいです。私たちも作ってくれたものをきちんと顧客に届けたいからきちんと知りたい」
サクセス担当のみつきが言う。
ぐうの音も出ない。日記に書いてあった一文が頭を巡っていく。
プロダクトはひとりで作るものではない。セールスやカスタマサクセスと一緒に顧客の声を聴き、デザイナーとともに課題の特定や情報設計を行い、それらを実際に動くものへとエンジニアやQAなど多くの仲間とともに形作る。そしてマーケティングや再びセールスやカスタマサクセスと顧客にプロダクトを届けていく。その一連すべてがプロダクトマネジメントといえる
全然、プロダクトマネジメントできていないじゃん。そう思いながら、ただただお詫びするしかなかった。
「本当にごめんなさい。これは自分の進め方が悪かったです。今後このプロセスはきちんと改めます。そのうえで、今日この場にみんなに集まってもらったので、ぜひお客さんに届ける品質まで引き上げて、再度リリースしきりたい。よろしくお願いします」
ミーティング内では開発背景、課題、価値、顧客の反応、そして主たる機能を説明し、全員で利用しながら使いにくい点や使いやすい点、顧客に届ける際の注意点や顧客へのデリバリー方法などを議論していった。
そうして、たくさんのフィードバックの中からリリースまでに絶対にクリアする開発トピックと、顧客デリバリーまでのステップについて決めていった。
開発トピックが決まった以上、開発チームがメインで進めればうまくいく。自分はセールスとカスタマサクセスがデリバリーする際のセールストークや資料の作成を手伝うことにした。ビジネス経験をバックグラウンドにしていることもあり、ここで貢献するのが一番リリース速度を速められると考えたからだ。
「こういうことだよな」
プロダクトマネージャーは、チームがプロダクトマネジメントを遂行できる状態にするために、チームに足りないものを何とか埋める必要がある。これは自分一人で行うことにとどまらず、リソース獲得をしてくるなども選択肢に入る
日記に書いてあったことを思い出す。
準備は着々と進んでいった。
そしてリバートしてから1週間後、正式リリースを果たした。
リリースがすべてのはじまり
リリース後、一斉にサクセスチームが顧客へと機能案内を実施してくれた。
しばらくして利用状況が見えてくる。検証時には、10社中6社から好反応だったものの、本リリース後は全体顧客の30％程度にとってプラスという結果だった。利用ユーザーの中でプロパティマネジメント業務を持つ会社ばかりではないことがわかっていたので、全体に案内した際に利用率が下がることは想定内だったが、思った以上に低かった。
これまでの機能と異なり、利用開始時点でデータのインプットも必要だったことから、利用開始に至るまでのハードルが高かったことも要因らしい。
一方、利用顧客の中でアカウントを増やしてくれるユーザーが生まれ、ユーザー価値とビジネスインパクトがあったことは不幸中の幸いだった。とはいえ手放しで喜べる結果ではない。
「なかなか難しいな…」
スクラムのミーティングでぼそっと口にすると、すかさずひかるんが言う。
「リリースして終わりじゃないですから。まだ始まったばかりですよ。まだまだ改善の余地があるから頑張りましょう。くぼたくさんが魂込めてた案件じゃないですか」
頼もしさを感じるとともに「ハッ」とさせられる。
チームやプロダクトが成功するかどうかはPMが自分の意思決定を正しいものに変えられるかに懸かっている。
またも日記の一文が頭をよぎる。
はじめてのリリースで完全に成功に至ろうというのは都合がよすぎた。
意思決定したものを、正しいものに変えられるかどうかはこれからの自分次第。ここがようやくスタートラインなのだ。
「たぶん日記を書いた自分も、こんな瞬間を何回もくぐってきたんだろうな」
きっと、この開発サイクルを何度も何度も繰り返した先にようやく一人前のPMとしてふるまえるようになるはずだ。
プロダクトマネジメントは実践がすべて
今日この日を起点として、ひたすら実践と学びを繰り返していくしかないんだ。
エピローグ
～3か月後～
「ようやく目標まで来たね！本当にお疲れ様でした！来週あたり打ち上げしましょう！」
リリース後、何度も顧客ヒアリングとアップデートを重ね、チーム全体で侃々諤々議論しながら、少しずつ改善を進めていき、とうとう期待する利用水準へ到達した。
「本当にあっという間の3カ月だった…」
自分自身もプロダクトマネージャーとしてのふるまいが板についてきたように思う。
学ぶべきことはたくさんあるが、一歩一歩進めている。
オフィスから出ようとしたタイミングで、えいちゃんに声をかけられた。
「くぼたくお疲れー！調子どう？直近のやつ、うまくいってる？」
「今週ようやく目標到達した！チームのおかげで何とかできたわ」
「よかった。なんか夢中になってやっているから『よさそう』って思ってたｗ ここ数カ月はなんかVPoPってよりは、がむしゃらにイチPMとしてやっている感じが結構好きだったかも」
「おお、ありがとう！そう言ってもらえてよかった」
「でも、そろそろWhole Product構想のアップデートとかプロダクト戦略の話したいから、また話そうぜ。お疲れー！」
そう言って、さらっと宿題を投げて帰っていった。
「Whole Product構想のアップデート…プロダクト戦略…」
一難去ってまた一難。
ようやくイチプロダクトマネージャーとして動けるようになってきたというのに、今度はVPoPとしての振る舞いを身につけなければならないらしい。
VPoPとしてのふるまいは現時点ではさっぱりわからない。
でも、悩んでいても仕方ないのだ。プロダクトマネジメントを一から学んだように学習と実践を繰り返していくしかない。
さて、帰ってまた日記を読みなおそう。きっと“自分”も一度は悩みながら実践したはずなのだから。
そして、不安にならなくていい。プロダクトマネジメントはひとりでやるものではないのだから。
仲間と共ににいいものにしていこう。
結びに
ここまでお読みいただき、ありがとうございました！
「テック転生」ということで本当に転生した時にどのように壁に当たりながら実現していくのかを表現するためにあえてストーリー調で書かせていただきました。（その分相当な分量になり、読むのが大変になってしまったかと思いますが…）
プロダクトマネジメントは人とのコミュニケーションがさまざまに発生していく仕事になります。そのため学び直すとしても、書籍やセミナーのようなものだけではどうしても不十分であり、「実践とその壁を乗り越える」ということが必要だなと考え、この形式をとりました。
おそらく僕自身は「転生したとしても、きれいに学び直すことはできない」と考えているのだと思います。逆に言えば「きれいじゃなくていい」ということです。
失敗をしましょう。恥をかきましょう。その中で学び、強くなっていくのがプロダクトマネージャーだと思います。
「この企画の趣旨に合っていないのでは？」という声が聞こえてきそうですが、「意思決定」と「結果責任を果たす」というのはそういうことではないかと思います。
究極、プロダクトマネージャーに一番必要なものは「批判や変化、アップデートを恐れない」ということなのかもしれません。形だけのスキルや定型のプロセスを身に着けるのではなく（もちろんスキルは大事です）、意志を形にしていく自分自身の器自体を大きくしていくことが求められるのだと思います。
それでは、最後までお付き合いいただきありがとうございました。
本記事で書ききれなかったことは、また機会があれば続編として書いていきたいと思います。
もし本記事についての疑問やそれ以外でも気になることがあれば、X（旧Twitter）のDM等でぜひご連絡ください。それでは、また逢う日まで！
