PMのキャリアはいかに始まるか
この記事は、僕自身のプロダクトマネージャーとしてのキャリアがどうやって始まったのかを綴ったエッセイだ。
経験を出汁にして創造をすることは、「創造行為の終着駅」と藤子・F・不二雄先生も語っていらっしゃるようだが、まさにその通りだと思う。
人はゼロからストーリーを作ろうとする時に「思い出の冷蔵庫」を開けてしまう。自分が人生で経験して、「冷蔵保存」しているものを漫画として消化しようとするのです。 それを由（よし）とする人もいますが、私はそれを創造行為の終着駅だと考えています。家の冷蔵庫を開けてご覧なさい。ロブスターがありますか？多種多様なハーブ類がありますか？ 近所のスーパーで買ってきた肉、野菜、チーズ、牛乳・・・どの家の冷蔵庫も然して変わりません。 By 藤子・F・不二雄
本文は「終着駅的」であることに加え、9,000字以上に渡るダラダラと長い文章で、残念なほどにまとまりもない。
殆どがsmarbyという、僕が創業から2.5年を共にしたスタートアップでの経験に関する記述になっている。興味のない方はここでブラウザを閉じることをオススメする。
文末にこの記事から1.5年が経過した時点（2018年6月)の振り返りと心境の変化をまとめている。
0 / わたしの近況
2016年10月31日、創業から約2年と半年、本当になにもないところから育ててきたsmarby（スマービー）がSTRIPE INTERNATIONALグループの末席に加えていただくことになった。そして時を同じくして僕はsmarbyを辞めた。今はフリマアプリを提供するメルカリでプロダクトを創っている。
※さらに2018年6月現在、9ヶ月在職したメルカルを辞め、今は10Xという会社を創業してタベリーというプロダクトを創っています。発明を目指す会社です。 2016年の初めから本腰を入れ始めたブログ執筆は、ありがたいことに多い時には万を超えるような人に見てもらうこともある。だからこそ、僕自身の身上話より、「プロダクトマネージャー」「スタートアップ関係者」にとって意味のある文章になればと思い書いてきた。
僕（ら）の身の上話など、誰の役にもたたないだろうと思っていたからだ。今もそう思う。が、今回だけは少しだけお付き合い頂きたい。
1 / プロダクトマネジメントは「死にたい」
smarbyはママというユーザーに特化した子供服ECサイト&アプリとして2014年の11月末にスタートした。商品の掲載時間が1weekと短いことを除いては普通のECと変わらない。しかしシンプルな機能にもかかわらず、以下のような理由からリリースまで超難産だった。
- そもそも決済、物流、お問い合わせ対応など最低限必要な機能が多い（ECの性質）
- 創業メンバーにプロダクトを創った経験を持つ人がいない
- 最新仕様が変わるのでの伝達コストが高い
- 結果「優先度」があやふやになったりする
- （リリース後の）運用負荷が想像以上に高い 着手からリリースまでに半年以上の時間を経て生み出されたプロダクトは、初日に想定の1/50程度の売上（数万円）をこしらえ、創業メンバー全員に死にたい気持ちをプレゼントしてくれた。
リリース前、僕は悪手・奇手を絡めて3000人の事前ユーザーを獲得することに忙しくほとんどプロダクト開発に関わっていなかった。ただ初日の売上とユーザーの動きを見て、このままでは死ぬということだけ理解した。
創業時のメンバーの経歴だけ見るときれいだったが、僕を筆頭に誰ひとりとしてプロダクトがつくれる人材ではなかったことをここに保証したい。また、読んでおわかりの通り、この時のsmarbyにプロダクトマネジメントなんて存在しない。ただ「死にたい」と思えるほどの現実と対面した時の、暗雲とした重い空気が、プロダクトマネジメント（プロダクトを前にすすめる力）だった。
2 / プロダクトマネジメントは「苦い」
初日にしょっぱい売上を目の当たりした後、一切の余裕を無くした僕は各方面からどんな手を打つべきかとにかく探った。はじめにしたのはFacebook広告に金を突っ込んでユーザーを買ってくることだった。事業計画時には「CPOが…」「LTVが…」と綺麗事を並べたが、それらはすべてクソだと悟った。人が来なければ終わる。そう思って僕はFacebookに資金を投下した。
結論、広告もクソだった。というか運用者の僕がクソだった。
焦燥からKPIを定点観測するという概念が吹き飛んでいたため、初日に平常値だったCPAが3日後に10倍になっていたことに気づけなかった。
命の灯でもある資金で、よそ見しながらキャンプファイヤーをしていたこの時の自分にドロップキックしてやりたい。
数百万円を溶かしたところで過ちを知った。その日を境に1分毎にダッシュボードを更新してCPAをモニタリングしながら命の灯（資金）を燃やす日が数週間続いたが、見るに見かねたエンジニアがスクリプトを書いてくれたため、Slackから自動でCPAを把握できるようになった。
他にもECの要である商材（MD）から打てる手を探った。
立ち上がったばかりの売上数万のプロダクトに商材を掲載したいと思う取引先はなかなか無く、毎日数百のメールを爆撃し、アポをこぎつけてはで商材を引っ張ることで凌ぐ日々だった。幸い、経歴のおかげで幾つかのお取引先が広がったこともある。そういうパートナーに対して「思ったより売れなかった、smarbyには裏切られた」と思われるのが何より怖かった。今でこそ話せるが、なけなしの給料で、みんなで自社商品買いに勤しんだこともある。
MDのなかで一つの成功体験がある。リリースしてから間もなく迎える年末年始のピークに合わせ、売れ残ったバラバラの商品をコーディネートセット（福袋）に組みなおして販売した。これがヒットし、売り切れが相次いだのである。
- 商材の価値を高める（揃う、安い、わかりやすい）
- しっかり情報発信する（自社メディアでママライターに扮装し記事で訴求した）
- Facebook広告で2を拡散（関心層拡大）
この3つの力で、smarbyは初めて見るに耐える月次売上を記録した（ただし、まだまだ微小）。この瞬間が本当の0→1を感じたときでもあり、 ECのプロダクトは「狭義でのプロダクト（Webサイト&アプリ）」「MD」「マーケティング」の三位一体なのだ！
と理解して鼻を長くしたものだった。もちろんすぐに折られるわけだが。
リリースから3ヶ月、smarbyはやっと「自分たちの売り方」を学習しつつあった。なおこの3ヶ月間、プロダクトのソースコードにはほぼ一切の変更を加えていない。かのエンジニアは僕らがMD情報をデータベースへ手入力しなくて済むよう、自動入力用のスクリプトを書いたり、ECで扱う大量の画像を軽量化するスクリプトを書いたり、サーバー監視で一杯一杯だった。それでも事業は前に進めることができる。プロダクトをマネジメントする方法は、ソースコードを修正することが唯一の手段ではないのである。
- 社長は僕が金を溶かしてばかりいるので、追加の資金を集める必要があった。
- エンジニアは1ヶ月に1度しか家に帰らない生活をしていた。
- 共同創業者はみんなのストレスを中和するマスコットだった。
- 僕は2時に寝て、息子の夜泣きで3時に起きる生活だった。
どれだけ夜が遅くなろうとも、僕は毎日きっかり10時に三軒茶屋にあったワンルームのオフィスに行くとエンジニアを起こして、一緒にファミマのコーヒーを買いに行く生活だった。リリース直後、台風のように過ぎた時期のプロダクトマネジメントの味は「苦かった」。
3 / プロダクトマネジメントは「焦れる」
「自分たちの売り方」を学習し、エンジニアとタッグを組んでオペレーションを効率化できるようになってきたことで、smarbyは初めて「未来に向けた次の一手」を考える体力を手にした。機能に修正を加えたり、機能追加をしたり、新しいプロダクトを検討したり、など。
やっとプロダクトっぽい話であるが、この時点で創業1年とか、そんな時期の話だ。1年もの間、俗に言うきれいなプロダクトマネジメントなんてなかった。当然アジャイルの「ア」の字も出てこなかった。
少しずつ運用が小慣れて売上も立ち始めた頃、更に売上を伸ばすために例えば以下のような「機能開発」を検討していた。
- 新たな決済方法の導入
- PCサイトのリリース（smarbyはモバイル専用で、現在進行系）
- Androidアプリ（当初はiOSのみだった。ちなみにAndroidは創業から丸2年経過するまでリリースされなかった）
- 会員向けメルマガの自動配信システム
- Wordpressで運営していたオウンドメディアの自社開発 振り返ると、これが僕のプロダクトマネージャーとして初めての仕事だったとも言える。
- プロダクトの課題を定義し、
- 工数とにらめっこしながら順番を付け、
- 「やりたいこと」を定義し
- 周囲の納得を得るコミュニケーションを行い
- リリースまで伴走する 荒削りではあるが、こうやって少しずつプロダクト自体に変化をもたらした。しかしその過程は、思ったようなスピードが出ず、焦れて、意見がぶつかることは日常だった。
smarbyのバックエンドはリリース時から幾つかの穴があったため、「買えない」「落ちる」「重い」などユーザーからのお問合わせとHotfix（緊急なイシュー）が日々飛び込んでくるような状況だった。当然Hotfixが生じたタイミングで、エンジニアの優先度はHotfixが1番となる。ところが、Hotfixを解く傍らで機能開発が進まない理由が、当時の僕には本当にわからなかった。すべての開発タスクは直列でないといけない、という当たり前の事実を、エンジニアを除いて誰一人理解していなかったのである。
- 「XX日までに完成する予定だった機能がリリースできない」
- 「何度も話題にしているはずなのに一向に着手してくれない」
- 「進捗がわからない」 エンジニアという「クリエイター」の気持ちを理解できない未熟なプロダクトマネージャーだった僕は、上記のようなコメントを毎日のようにしていた気がする。今思うとゾッとする。
幸いにも、この頃僕とエンジニアの彼は朝昼晩と全ての食事をほとんど一緒に過ごした。酒が飲めず、人となかなかパーソナルな関係を築くことが難しい僕にとって、この機会はとても貴重だった。仕事で産まれた「棘」は朝飯のパンをかじっている時にほぐれていた。
そして、本質的に「開発がわからない」という問題を解決したのは新たにジョインした別のエンジニアだった。彼は僕に、
- 「エンジニアは何を大事にしているか ― プログラマー三大美徳」
- 「開発を行うにはどういう環境が必要なのか ― 静かに、自由に、好きな時間に働かせろ」
- 「一般的な開発フローはどうなっているか」 など基礎的な情報（や、情報源）を提供してくれた。これをきっかけに積極的に技術書を読み、terminalやgitを使い始め、エンジニアの言語を理解しようとした。
彼から勧められてはじめて読んだ本は「UNIXという考え方」だった。
クリエイターの気持ちを少しずつ理解できる様になると、プログラミングを通じて「ものづくり」をするプロセス自体が尊く楽しいものだと思えるようになった。そしてプロセスにおける僕自身の行動指針を醸成していった。例えば以下の様なものだ。
- 「創らずに解決」が最上の手段。
- ビジョンを示す。なぜそのプログラムを書く必要があるのか。あなたがそのプログラムを書くことにかける時間はどのようなリターンをもたらすのか。
- ソースコードへのコミットは自分にはできない。如何にエンジニアがプログラムに集中できるようなパスを送るかに集中する。
- コントロールをエンジニアに渡したら、任せきる。
- Hotfixが飛び込んできたり、ユーザーの状況によって必要な機能の優先度はコロコロと変わる。テンポよく、そして誤解を招かぬよう、「Backlog（タスク）」の優先度を決めていく。
- エンジニアの手が止まる時間を最小化するよう、即レス・クリアな仕様・誤解のない言葉遣い。 こういった行動指針の多くは、例えば「リーン・スタートアップ」や「アジャイルサムライ」などのプロダクト開発のTipsを記す多くの書籍で当たり前のように書かれている。しかし僕はそれらの本を通じてこういった指針を理解したわけではなかった。
エンジニアと実際にプロダクトを創り、理想と現実・運用と開発の間で揺れ、精神を焦らし、時に喧嘩をしながら、一つずつ学んだものだ。
例えばSlack（チャットツール）で開発仕様についての情報を伝える際、口頭で話すような簡易・省略形の言葉で書くことを僕はしない。多少書き手の手間が嵩んだとしても、正確な言葉を使う。わずかなミスリードで大きな事故を招いた経験があるからだ。「もうすこしだけ丁寧に書けば避けられた事故」を繰り返さずに済んでいるのは、いろんな地雷を踏んだおかげかもしれない。
4 / プロダクトマネジメントは「Saying NO」
プロダクト・ビジネスを前に進める手段（= プロダクトマネジメント）はチームの状況によって最適解が目まぐるしく変わる。それはサッカーやラグビーのようなものだ。新しいエンジニアが加わったり、業務委託やフルリモートのメンバーが加わったり、チームの布陣と個々のプロパティによって大きな影響を受ける。
smarbyは、焦燥を抱えながらもきちんとマイルストーンに合わせて成長を続けていた。4人でスタートした会社は1.5年で30人を超え、取引先やユーザー、そして株主などステークホルダーは増加の一途を辿った。当然プロダクトに対して良く言えば「自由な」、悪く言えば「勝手な」意見が大量に集まるようになる。
次の僕の大きな役割は、それらの殆どに「NO」を言うことであった。誰かの意見に対し「NO」を言うことはそれほど難しいことではない。しかし「NO」を言い続けることはなかなかタフなゲームだということは余り知られていないように思う。
- 〜は簡単に実装できるでしょ？
- 競合にはあの機能がついている
- ユーザーのAさん、投資家のBさんがあの機能は付けないの、と言っている。 これらの僕に投げかけられるコメントは一見妥当であるように見えて、実は違う。プロダクト、そしてプロダクトを創るチームにとって考えるべきは「今、われわれのユーザーにとって本当に必要がどうか」という一点のみだった。
特定の誰かが満足する機能が大事ではない、とは言わない。しかし来月もユーザーの満足するような体験を届け、売上を2倍に、一年後に10倍にすることがECである僕らにとって最重要命題であり続けた。
売上に責任を持つ身として、全ての意見に耳を傾けたり、懇切丁寧な説明を加えることは難しかった。
「NO」を言い続けるために役に立ったことが3つある。1つは運動でストレスを消し去ること。もう1つは以下のIntercomという顧客マネジメントツールを提供するスタートアップのブログ記事。この記事を読むたびに、奮い立った。
最後の1つは、今のプロダクトがどんな状況で、いつまでに何を成し遂げなくてはいけないのか。僕の目線から思ったことを社内のドキュメンツールに投稿することだった。また時にはこのブログにもすこしマイルドな形で投稿した。大した推敲もせずに書きなぐる程度だったかもしれないが、意思決定のプロセスを最低限共有することで、「なぜYamottyはNOを言うのか」を理解してもらう助けになったように思う。テキストの力は偉大だ。
5 / プロダクトマネジメントは「楽しい」
プロダクトや会社に対して行う意思決定が正しいかどうかは誰にもわからない。ただ結果は必ず現れる。プロダクトマネージャーという役割の評価は、各施策・意思決定の積み重ねによってプロダクトが理想とする状態へ近づけることができたか？で大まかに測ることができる。
しかしこういった個々の施策評価に傾倒するのを僕は危険だと思っている。本当の役割は、そもそも理想ってなんだっけ？というプロダクトのビジョンを描ききる力にあると思っている。
- いつまでに
- どんなコアバリューを提供し
- どんな人に、どのくらい使われるのか この3つの要素に答えるビジョンを描くこと。そしてそこに人を巻き込むこと。この2つのほうが、「Saying NO」をし続けるより、ずっと胃が痛くなるハードワークだ。ただこれほど楽しい機会も無い。そう、プロダクトマネージャーは楽しい。
6 / プロダクトマネジメントは「千差万別」
これまでの僕の話は「スタートアップのプロダクトマネジメント」についてだ。しかし、このケースはある程度規模のある企業のそれとは質的に異なるかもしれない。スタートアップにおいてプロダクトマネジメントは会社の死活をそのまま握ることになるからだ。
また「起業家」ではなく、「プロダクトマネージャー」という存在のキャリアを突き詰めると、「自分の意志の通ったプロダクトを創る」ことの難しさがある。企業務めのプロダクトマネージャーにとって、自分以外の誰かのアイデアでプロダクトがキックオフすることは稀ではないだろう。他人のアイデアをどれだけ自分のコンテクストで消化し、自分の意志を通わせたプロダクトを創っていけるか。それもスタートアップを始めるのと同じくらい大きなチャレンジだと思う。
プロダクトマネジメントは、それ自体が目的化してはいけない手段である。プロダクトを通じてどんな世界を創りたいのか。その目的のためにとれる手段は、仕事やプライベートの環境・スキル・コンディションによってまちまちなはずだ。
僕は自分以外のプロダクトマネージャーの話を聴くのは好きだ。だが参考にすることは殆ど無い。自分に当てはまることなど殆どないから。どうせなら、道の進み方は自分で考えて決めたい。
7 / さいごに
「プロダクトマネージャーのキャリアをどうやって始めればよいか？」 「どうやってプロダクトマネージャーを育てればよいか？」 手探りでやってきた僕のような人間にもこんな質問が寄せられるようになった。そしてこの記事はその問へのアンサーでもある。
一言で言えば、「必要に迫られたことをやってきただけ。」ということになる。赤の他人に「Facebook広告で莫大な予算を溶かす」などのクソ経験を再現させたところで、良いプロダクトマネージャーを育てられる気がしない。逆説的だが、プロダクトマネージャーとは再現性のある仕組みで育てられるものではないのかもしれない。
エンジニアをしていたら、周囲から頼られるハブとなりプロダクトマネージャーになる人もいるかもしれないし、カスタマーサポートとしてユーザーに尽くしていたら、ユーザーへのもっとも深い理解と愛情が育まれ、プロダクトマネージャーへ転身する人もいるかもしれない。
そういう人たちに、「大丈夫、僕も適当に歩んでこうなりました」と背中を押せる記事になれば、一筆の価値があったものだと思う。
8 / この記事を1.5年後に振り返る（2018年6月）
あらためて振り返ってみると、プロダクトマネージャーへのキャリアパスに一切の普遍性がないこと。そして、僕が多くの失敗を犯して来たことが蘇ってきてなんとも言えない気持ちになる。
実はsmarbyを始める前、僕がプロダクトマネージャーを目指すきっかけを与えてくれた人物がいた。現Niantic, Inc. VP of Product の河合さんという方で、当時はGoogle Mapなどを統括するGoogle GEOチームのプロダクトマネージャーをしていた。
彼との出会いはsmarbyを始める前に務めていた東北復興支援のNPO。たまたま仙台出身だった河合さんが、我々のファンドレイズに乗っかてくれ、大きなお金を任せてくれて、仕事を一緒にさせていただいた。当時限界区域であった福島の浪江町にストリートビューを走らせたり、東北の事業者とトウキョウのプロをマッチングするクラウドソーシングを立ち上げたりと、ずいぶんと自由にやらせていただいた。
（以下のツイートは久し振りに河合さんとお会いしたときのもの）
「ユーザーのペインにあらゆる手段をつかって向き合い続けること」「同じ場所にとどまることをNGとし、10xをめざすこと」など僕の行動の指針は彼から学んだはずだったが、実はsmarbyをはじめる際にこういった指針を徹底できていたかというと、NOだった。smarbyでの失敗や成功体験を経て、やっといま手に馴染むようになったと感じている。
プロダクトマネジメントの知識も近年ではかなりが体系化されつつある。しかしそれを本当に使いこなせる人材はごく僅かだ。リスクをとり、ポジションをとり、実際にプロダクトをハンドメイドする経験の中でしか培われないものがやはり存在する。
smarbyのあと「本当の発明がどうやって生み出すべきか」について自分なりの答えを見つけたかった。そのためにうってつけの環境として選んだのがメルカリだった。メルカリはすごい。素晴らしい成長率と、安定した職場環境、待遇が揃っている。しかし、「本当の発明」を自分で目指したいと思った時、僕にとっては10Xを創業することのほうがずっと近道だと思えた。
つまるところ、発明は「チャレンジした人だけ」の特権だと気づいた。プロダクトにチャレンジしない限り、プロダクトマネジメントの知識が手になじまないのと同じように。
僕の今の目標は、死ぬまで「人が欲しがるものをつくる」にアタックし続けることだ。そのスタートがsmarbyであったことは疑いようもない。