エンジニアがPMとして働き始めて感じた足りなかったスキルを振り返る

株式会社YOJO Technologies」から「PharmaX株式会社」へ社名変更いたしました。この記事は社名変更前にリリースしたものになります。

この記事は"プロダクトマネージャー Advent Calendar 2021"の1日目の記事です。

自己紹介

2019年12月からYOJO Technologiesで加藤智之（@tomo_k09）と申します。

私はもともと薬剤師をやっていたのですが、趣味でプログラミングをやっていたところ代表の辻（@YusukeZ2）からお誘いいただき、2019年12月からYOJOでエンジニアとして働き始めました。

弊社は2018年12月に創業したスタートアップで、「患者満足度世界一の医療機関になる」というミッションを実現すべく、LINEで医療相談や医薬品購入・服薬フォローなどを一気通貫で提供するオンライン薬局『YOJO』を提供しています。

私は主にサーバーサイド（Ruby）を担当しており、LINE botや薬剤師が患者さんとメッセージのやりとりをするための管理者画面の開発に携わっていたのですが、新規事業のPMをやらせてもらえる機会があったので、振り返りも兼ねてPMをやってみて感じた「ここ足りてなかったなぁ」というスキルや、エンジニアがPMをやることの利点などについて書き連ねていこうと思います。

エンジニアからPMへのキャリアをこれから歩もうとされている方に少しでもお役に立てれば嬉しいです。

圧倒的に足りなかったスキル

・仮説を立ててそれをどうやって検証すべきかを考える戦略的な思考力が全然足りていなかった

PMはミニCEOとも言われています。エンジニアはHowの部分を担当するのである程度やることが明確になっていることが多いですが、PMはゼロから何をするべきか考えることが仕事なので、自分が何をしなきゃいけないのかから考えなければなりません。

私の場合は「どんな仮説検証をしなきゃいけないのか」という最初の段階からつまずいてしまいました。なぜつまずいたかというと、本来知っておかなければいけないことをちゃんと把握していなかったことが大きな原因なのではないかなと思っています。

例えば、市場規模を知らないとこの事業がどれくらいの売り上げを見込めるのか分からないし、財務状況をちゃんと理解していないとこの事業の肝となる部分はどこになのかも分かりません。何も分からないから、どんな仮説を立てれば良いかもよく分からないという"分からない地獄"に陥るわけです。

幸いにも周りの皆さんが優しかったので、サポートを受けながら何を仮説検証するのかなどの合意形成を取って走り出すことはできましたが、エンジニアとして働くにしてもビジネス理解が深くないと良いプロダクトを作れるわけがないので、今までの自分のビジネスへの認識の甘さにただただ反省しっぱなしでした。

・PMの自分とエンジニアの自分をちゃんと分けて考えることができなかった

例えばイケてるプロダクトを作る上で重要なAという機能があって、この機能の実装コストが高かったとしましょう。

このとき、PMとしての自分よりもエンジニアとしての自分が強く出てしまうと、それがイケてるプロダクトを作る上で重要な機能だったとしても、エンジニアリングの知識があるがゆえに「この機能は実装するのにかなり工数がかかりそうだぞ...」などとネガティブに考えてしまいがちです。

エンジニアがPMをやることは技術的な論点や開発工数をすぐに把握できるというメリットがあります。しかしプロダクトを作る初期段階から実装コストのことを考えすぎてしまうと、いくらプロダクトのコンセプトが良かったとしてもプロダクトの可能性を潰しかねません。

こういう考えに陥ってしまうのは、エンジニア出身のPMがやりがちなのではないでしょうか。

PMの役割は「プロダクトを成功に導くこと」です。エンジニア出身のPMは「PMの自分」と「エンジニアの自分」という2つの人格が自分の中にはいて今はどちらの立場で考えているのかを常に意識し、「自分の最も重要な仕事はプロダクトを成功に導くことなのだ」ということを強く自覚する必要があるなと思いました。

（なんで人格の切り分けができなかったんだろうと考えながら記事を書いていたんだけど、自分の中でどの仕事が自分にとって最も重要なのか明確に順位をつけられていなかったからだろうなぁと思った。）

・1つ1つの意思決定のスピードが遅すぎた

新規事業は仮説検証のサイクルを素早く回していかないとなかなか立ち上がりません。「次はどんな施策をやろうかな〜」と呑気に考えていると一生結果が出ないわけです。

正直、今まで自分の意思決定スピードがとんでもなく遅いという自覚があまりなかったのですが、自分の意思決定スピードってめちゃくちゃ遅いんだなと思わされたエピソードがありました。

事業部長の倉内さん（@Peeeee_ter）と次やる施策についてお話ししていた時のことです。

私が「次の施策はxxxをやろうと思っているのですが、今日中に本当にこれをやるか意思決定したいと思います」と伝えたところ、「いや加藤さん、この意思決定は1時間くらいでやらないとダメでっせ」というフィードバックをくれました。

倉内さんは元マッキンゼーのコンサルなのですが、僕はこの時「ああ、これがグローバルスタンダードの意思決定なのか...!!ぐぬぬ....!!」と思い知らされたわけです。

とは言え、「意思決定のスピードを早くしよう」と意識するだけで意思決定のスピードが速くなるであれば苦労はしません。

そんな時は「この意思決定は後戻りできるかどうか」基準で考えるのがおすすめです（取締役の上野さん（@ueeeeniki）からアドバイスをもらいました）。

何も考えずにGOするのはさすがにまずいですが、ある程度検討して後戻りできるのであればとりあえず実行してみる。

こういうフットワークの軽さは初期検証の段階ではとても重要だなと身に沁みて感じました。仮に失敗したとしても得られる知見がたくさんあるので。

いま振り返ると何かしら施策をやるのなら失敗したくないという思いが強すぎたのも、意思決定が遅くなってしまった原因の1つだったかもしれません。失敗は「こっちの道は間違いだったんだ」と分かるとても大切な発見だと思うのでもっと前向きに失敗を捉えるべきだったなぁと。

エンジニアがPMをやる利点

ここまでエンジニアをやった反省点を書き連ねてきましたが、エンジニアがPMをやることの利点もなんとなく見えてきた気がするので自分の考えを書いておきます。

・技術的な難しさ・工数を加味して、迅速に優先度を決めることができる

エンジニア出身のPMが増えていますが、その理由はプロダクトをグロースさせていく上で、エンジニアリングの知識が必要になるケースが増えてたことが挙げられると思います。

例えば、現代のプロダクトはライフサイクルがとても短くなっています。そのため、技術的な難しさ・工数を加味した上ですばやく優先度を決めて施策を打ち、プロダクトを成長させていくスキルが重要視された結果、エンジニアがPMをやる機会が増えたんじゃないかなと。

実際、PMとしてデザイナーさんとお話ししながらこういうプロダクトの設計をしていた時も、「ここの部分は技術的に難しそうだから、こういうふうに実装したら良さそうだな」と思う場面がたくさんありました。こういうスキルを強みにできるのはエンジニア出身のPMならではないかなと思います（自分はまだまだですが）。

・ビジネスへの理解が深まりエンジニアとしての視野が広がる

YOJOのエンジニアチームは、ビジネス上の戦略や、仕様・UXについてかなり上段の議論から入っていくので、他社のエンジニアチームと比べてビジネスへの理解が深く求められているんじゃないかなと思います。

今回PMとしてOKRの設定から始めたのですが、「何をこの四半期でどんな仮説検証をするべきだろう？」、財務をいじりつつ「この数字がサービスの肝になってくるのだな」と試行錯誤しながら、いつもより上段のところからサービスを作る経験ができたのは自分にとってとても貴重な経験になりました。

例えば、現在の財務状況を把握していれば自分が作っている機能は財務のどこにインパクトがあるのかが分かるようになるので、「財務のこの数字を良くしたいのであれば、もっとこうした方が良いんじゃない？」というエンジニア視点の意見をもっと出せるようになるはずです。

こういう考えをできるエンジニアが本当に価値のあるプロダクトを作れるんじゃないかなと。

エンジニアの中には"ビジネスサイド"と"自分たち"を分けて考える方もいらっしゃいますが、自分たちもビジネスを作っているんだという意識を持つ上でPMの経験をできてとても良かったと感じました。

終わりに

かなりざっくりですが、PMをやって感じたことを振り返ってみました。エンジニアからPMへのキャリアを考えている方の参考になれば幸いです。

私もプロダクトマネージャー Advent Calendar 2021の参加者の皆さんからたくさん学んで、次に活かしたいと思います。