こんにちは！
dely, Inc.でプロダクトマネージャー兼開発部ジェネラルマネージャーをしている奥原 (@okutaku0507) といいます。この記事はdely Advent Calendar 2018の2日目の投稿です。
先日は、弊社のAndroidエンジニアでマネージャーを勤めている梅森から「AWS CodeBuild+AWS SAM（Lambda）+Slackで最高なAndroid CI環境を作る」というタイトルで投稿がありました。梅森はDroidKaigi 2019にも登壇する予定です。
弊社が運営しているレシピ動画サービスのkurashiruはよく知っているけど、開発チームは何しているのかわからないという方に、少しでも弊社の開発部のことを知っていただければ幸いです。もし、同職種や弊社に興味を持ってくれた方がいましたら、僕のtwitterのDMでも良いので、連絡していただけたら嬉しいです。
1. はじめに
僕はdely, Inc.に入社した2016年から元々はずっとサーバーサイド (Ruby on Rails) のエンジニアをしていました。そして、今年 (2018年) の5月ごろからプロダクトマネージャーになり、ゴリゴリと施策などを回しています。
良くも悪くも、急成長するベンチャーではあらゆる役職がそもそも存在していなかったり、ほいほい空いたりします。奇しくも、弊社にはプロダクトマネージャーという役職は存在していませんでした。CTOがその業務を担っていた状態でした。しかしながら、CTOは執行役員も勤めているので、組織のことや技術的な視点から会社の未来を創造しなければなりません。プロダクトのことを常に考えるにはキャパがオーバーしてしまいます。そのため、プロダクトマネージャーの登用は急務でした。されど、kurashiru規模のプロダクトマネージャーを外から採用するにはかなりのハードルがあり、採用は暗礁に乗り上げていました。そこで、僕が言われた言葉は、、、
「おっくー、明日からプロダクトマネージャーで！」
そう、これが僕が未経験ながらプロダクトマネージャーのとてつもなく重い門を叩くことになった転機でした。なぜ、僕がプロダクトマネージャーになろうと思ったのか、今後のキャリアや成長に関する考えは後述しますので、もし同じようなキャリアに悩んでいる方がいれば、少しでも参考になれば幸いです。
2. プロダクトマネージャーとは
日本でも当たり前になったプロダクトマネージャーですが、会社、組織、プロダクトにいよって、本当に様々なことをする役職です。ですが、その本質をざっくり定義すると「プロダクトの成長に責任を持つ人」だと想っています。
残念なことに有料の記事ですが、この記事はわかりやすく書かれていて、とっかかりやすかったです (ステマではありません...) 。
この記事にもあるようにプロダクトマネージャーには「ミニCEO」としての責務があると思っています。ちょっと表現が強いですが、えふしんさん (@fshin2000) のツイートも核心をついていると思っています。
プロダクトマネージャになりたい人、ミニCEOとしての期待だから労働時間はチーム連携に必要な分を除くと短いとか会社来ないとかは割とどうでもよくて、それより24時間のマインドシェアを捧げられる人じゃないと多分無理です。マインドシェアはいくら獲得してもブラックとは言われないですね。
— えふしん@12/1 WebSig24/7登壇！ (@fshin2000) November 6, 2018
以下の記事の中でYamottyさん (@yamotty3) がおっしゃること、そのままだと思います。
PMの役割や必要なスキルは、会社やチームによって全然違います。10Xであれば、僕以外のメンバーは全員エンジニアなので、僕は社長業に加えてPMとして、デザインや顧客開発を含むエンジニアリング以外のプロダクトに関する全ての仕事をやります。逆に、あらゆる職種が揃っている会社なら、PMは調整力や巻き込み力のほうが重要かもしれません。
また、以下の記事にあるように、メルカリのように同じプロダクトを触っていたとしても一つの領域をまるっと任せるというスタイルもあります。
では、dely, Inc.ではどのような業務をプロダクトマネージャーがこなしているのかというと、「何でも屋」という役割が大きいです。ざっくりプロダクトマネージャーとして僕がこなしていることを箇条書きで書きます。
- ユーザーインタビューやデータ分析を通して、解決すべき課題を特定する
- ユーザー、ビジネス、グロース、デザインの課題に対して解決策を発案する
- 課題とそれに対する解決策をプロダクトに反映させるために開発プロセスを回すファシリテートをする
- カスタマーサクセスを行う
- コードを書く
- KPIの報告を行う
- ドキュメントおじさんとなって開発仕様書を書く
- 部署間調整を通して優先度付けを行う
- 意思決定の説明を行い、チームから納得を得る
- エンジニア/デザイナーの採用を行う
- twitterでエゴサする
- etc...
そんなこんなを行なっていると、一瞬で太陽が沈みます。
前述した、Yamottyさんの記事の引用にもあるように、dely, Inc.では人は全く足りてませんが、あらゆる職種が最低一人は揃っていて、部署が存在します。10人も満たない組織で、一人一人が全ての領域の細部まで把握して意思決定して行動していく像とは、現実的には異なっています。そのため、限られた開発リソースの中、部署間の調整を行い、部署横断的な視点を持って、今会社にとって何をすべきかを考えて優先度を決定し、仲間の納得を得てチームをドライブさせていく力が求められています。
僕は元々はサーバーサイドのエンジニアであるため、現時点ではエンジニアリングの領域に強みを持っています。そのため、直近で行なっている僕の仕事としては、不確実性に向き合う組織を創り上げて、リーンなプロダクト開発フローを確立していくことが挙げられます。
リーンなプロダクト開発について、メルペイのプロダクトマネージャーをされている川嶋さん (@tsumujikaze) が書かれたnoteがとても参考になります。
今では、このリーンなプロダクト開発も軌道にのってきて不確実性に向き合う強いチームになったと思っています。このリーンなプロダクト開発をどのように弊社で実践しているのかをAWS Dev Day 2018で登壇させていただく機会に恵まれたので、その時の資料を掲載しておきます。
3. 「明日からプロダクトマネージャー」と言われたら
ここまできて本題について書きたいと思います。エンジニアから経験もしたことないプロダクトマネージャーになった僕のケースですので、ツッコミどころ満載かと思いますが、そこらへんはご容赦していただければ幸いです。
組織文化にもよりますが、dely, Inc.では様々な役職をぽーんっと任せることがよくあります。僕が任されたプロダクトマネージャーもそんな感じで渡ってきました。そして、 前述しましたが、弊社にはプロダクトマネージャーがいませんでしたので、実質的に引き継ぎなどはありませんでした。
3.1 形から入る
そのため、僕がまず着手したのは「プロダクトマネージャーとは？」を調査し、自分の中のプロダクトマネージャー像を確立させることでした。
まずは、ググりまくりました。「プロダクトマネージャー とは」と。そして、様々な記事や先駆者の言動を見ていく中で、プロダクトマネージャーは総称であり、今では当たり前だと思っていますが、様々な形態があることがわかりました。つまり、プロダクトマネージャーとは、プロダクトの成功に責任を持ち、なんでもやる役職だということがわかりました。なので、弊社のkurashiruというサービスのプロダクトマネージャーは自分で形成していくしかなかったのです。誰も正解を教えてはくれません。「さて、困ったぞ。何をすればいいんだ。」という状態でした。
3.2 整理する
何をすればいいのかわからないというというカオスな状態だったので、まずは整理が必要だと思いました。具体的には、プロダクト開発に直接的に関わっている部署、弊社でいうとタイアップ広告事業部、マーケティング部、ブランド部 (ブランド醸成に関わり、主にコンテンツの制作を行なっている)、そして開発部として、プロダクトに変更を加える施策として何を考えているのか、ヒアリングすることから始めました。
元々、サーバーサイドエンジニアとして様々なデータを扱っていたり、管理サイトの構築などを通して他部署とのコミュニケーションがあったので、部署間でどのような施策を考えているのかは肌感はありましたが、さらに具体的に聞くことで、工数見積もりやそれぞれの部署でのプライオリティの高さなどを聞くことで、施策の解像度を高めていきました。
3.3 優先度を決める
全ての部署が一つのプロダクトを良くしようと動いていたとしても、基本的には開発リソースは一つで、ほとんどの場合それもパツパツだと思います。その中で、何をすべきかを考えることは容易ではないし、その意思決定はその時の気分に左右されることなく、再現性がなければなりません。
そのために、執行役員でCTOである大竹 (@EntreGulss) にBizサイドの諸々をコーチングしてもらう時間を設けてもらいました。プロダクトの行く末を左右するプロダクトマネージャーには会社のほぼ全ての情報を頭にインプットしておく必要があります。そのため、経営層の考えを聞くことは不可欠でした。
各部署の責任者であるジェネラルマネージャーは部署間で情報を共有できていたとしても、プロダクトに変更を加える必要がある各部署の大小ある施策の全て頭に入れておくことは難しいと思います。そのため、プロダクトマネージャーは全ての情報を自分に集積し、今会社にとって解決しなければならない課題は何かを決定しなければなりません。各部署で優先度が高い施策であっても、それがプロダクトにすぐに反映できるとは限りません。その優先度を決めた背景をロジカルに説明する責任も同時にプロダクトマネージャーが負っているわけです。
3.4 実行する
なぜ、今その施策をするのか。施策のwhyを開発に関わる全ての人が知っていることはとても重要です。納得感を持って開発できるかが施策の良し悪しを左右することもあると考えています。その責任もプロダクトマネージャーにはあります。そのためには、ドキュメンテーション能力が不可欠です。僕は、ここで自分の意思決定を言語化することにとても苦戦しました。あらゆることを総合して考えて意思決定を行なっているので、それらを順序立てて、全ての人に理解してもらえる粒度で言葉に落とすことはとても難しいです。そのため、自分のドキュメントで納得していなさそうなメンバーが入れば席まで行って、納得してもらえるまで議論することもありました。
そして、実際の開発では今まで実装段階ではアジャイルを取り入れていたものの、要件定義をウォーターフォールで行なっていたがために、課題はあっていても解決策が間違っているということが度々あり、それが開発での課題となっていました。要件定義もアジャイルで行おうという、前述したリーンな開発プロセスの定着にメンバーとともに注力しました。要件定義フェーズでは、最初は細部まで介入して、それらが上手く回るようにフローの改善を行なったりしていました。
そして、部署間で実行する施策や全社規模で注力する機能については、スケジュールを常に更新、可視化し、ステークホルダーには通知するなどを行い、部署間の摩擦や間違ったものを作ってしまうようなリスクを減らすことも行いました。
3.5 プレイヤーから離れる
自分がプレイヤーから離れる、これが一番難しかったことです。最近では新卒からプロダクトマネージャーを任せるケースやプロダクトマネージャーが一般化したことで転職するケースもあると思います。しかしながら、内部からエンジニアあるいはデザイナーからプロダクトマネージャーになるケースが多いのではないでしょうか。その時に、しっかりと自分のプレイヤーとしての業務を引き継ぐ時間があれば良いのですが、弊社のようにいきなりプロダクトマネージャーを任されるケースでは、そうはいきませんでした。
僕の場合は、サーバーサイドを書きながらプロダクトマネージャーとしての業務を遂行する必要があります。自分がコードを書くことが好きで、開発リソースがパツパツ且つやりたいことがたくさんある中でついつい自分を戦力としてカウントして、様々なことをこなしてしまいがちでした。しかしそれではどっちつかずになってしまい、自分もキャパオーバーになりかけていました。心を鬼にして、自分がプレイヤーから離れる決断をしなければなりませんでした。幸いなことに、弊社サーバーサイドチームは少数ながら精鋭が集まっており、徐々に自分が担当するタスクを減らしていくことで、フェードアウトすることができました。
4. プロダクトマネージャーとして大切なこと
半年間という短い期間ながら、プロダクトマネージャーを経験していて、大切だと思った考えをお伝えしたいと思います。
4.1 執着し、諦めない
前述した、えふしんさんのツイートにもあるように、プロダクトマネージャーには24時間のマインドシェアをプロダクトに費やすことができるかが資質なのではと思います。費やすという表現も適切ではなくて、気がついたらプロダクトのことを考えていたくらいがちょうどいいと思います。自分でサービスを立ち上げたことがある人なら思い当たる節があるのではないでしょうか。気がつけば、自分のサービスを使ってもらうにはどうすればいいのかを考えていたということがあるはずです。
そして、プロダクトは順調な時ばかりではありません。長く苦しい時期に差し掛かる時もあります。苦しい時でもプロダクトに寄り添い、更なる成長ができることを諦めない。頭がちぎれるまで考える。時には自分も泥臭いことをする。そんな諦めの悪さも必要だと思っています。
4.2 自分の枠組みだけで考えない
つい自分の枠組みで考えてしまうことがあります。例えば、どうやればDAUをあげることができるかという課題に対して、開発側で考えたら、リテンションを上げるための施策を考えてしまいがちです。それ自体は間違いではないのですが、その答えはプロダクト開発の外にあるかも知れません。もしかしたら、リアルイベントを開催したら思わぬ盛況ぶりで、SNSでバイラルしまくり結果として、自分のプロダクトをグロースさせることができるかも知れません。つまり、DAUを上げるためにはプロダクト変更はいらずに、マーケの施策で解決できるかも知れません。そうなると、マーケティング的な視点など自分の枠組みの外で考えることも必要になるわけです。
そのためには、常に社内外でアンテナを高く貼り、様々なサービスの施策をみて自分たちのプロダクトにローカライズさせるとどうなるかを考えておく必要があります。ふとした瞬間に自分の頭の中に一つ一つのピースがぴったりと繋がることもあるのです。
4.3 逆算思考
それはちゃんと目標から逆算して考えているのか、と自分に常に問うことは大切です。スマートニュースのプロダクトマネージャー をされている前田さんの記事から引用します。
また、大きなジャンプを生むために、目標は逆算で設定しています。
「1年後にユーザーあたり収益を3倍にする」といった厳しい目標を立てて、そこから逆算して考えるということを日々行う。これは、非常に重要な状況設定だと思います。
この記事にあるように、例えば1年後にユーザーあたりの収益を3倍にするという目標を立てたとします。この値は事業計画から引っ張ってくるのでいいと思います。今の実際の成長率を厳しめにみて、成長曲線を引いた時に、1年後には収益は2倍にもいかないことがわかったとします。そうすると、このままやっていては目標が達成できないことに気が付くわけです。そうすると、違う手を考えなければなりません。その中で思わぬ手が思いつき、一気にグロースさせることができることもあります。
4.4 解決すべき課題設定で全てが決まる
今僕らが全力を掛けてでも解決すべき課題は何であるかを考えることがプロダクトマネージャーの本質だとも思っています。その施策が成功し、プロダクトを大きくグロースあるいは改善させることができるかは課題を設定した時点で決まっていることもあります。そのため、ユーザーあるいはビジネスにおける課題を発見し、それらに優先順位をつけて解決していく、そこにプロダクトマネージャーの手腕が問われていると思います。
4.5 難しい課題にフォーカスする
エンジニアあるいはデザイナーのリソースはとてつもなく貴重です。プロダクトには大小様々な問題があります。改善リストを作りちょっと運用しただけでも、かなりの数の解決しなければならない課題が見つかることでしょう。その時によく思い出すメタファーは、以下の記事にある瓶と石と砂とコーヒーです。
この記事で言っていることはプロダクト開発にも適応されます。瓶の中に、最初から砂を詰めていると、肝心な時にそれらに邪魔されて石を詰めることができなくなってしまいます。プロダクト開発においても、目先の小さい施策に気を取られてしまっては、本当に僕らが解くべき、難しく大きな課題を解けないまま時間だけが過ぎてしまうのです。小さい機能でも、アプリはリリースされたら取り返しがつかない場合が多いので、隅々までチェックすると思います。結果として、大小関わらず一つの機能をリリースするには、ある程度の工数がかかるわけです。その中で、解くべき大きな課題に対して全力で取り組む、このマインドを持っておくことが大切だと感じています。
5. プロダクトマネージャーになろうと思った理由
なぜ、プログラムを書くことが大好きな僕がプロダクトマネージャーになろうと思ったかを簡単に書いておきます。
僕自身のエンジニアになろうと思った理由が「テクノロジーを通して世の中を幸せにしたい」という人生の目標があるからです。その中で、自分はプログラムを書くことにハマっただけで、それは手段に過ぎないと思っています。世の中を幸せにするプロダクトを自分の手で創っていくためには、一人のエンジニアとしては限界があると思っていたし、意思決定をしていくためには自分のレイヤーを上げていくしかないと考えていました。そのための選択として、一番良いと思ったのがプロダクトマネージャーになることでした。
6. 最後に
「明日からプロダクトマネージャー」と言われた自分の経験を通して、弊社のプロダクトマネージャーの役割やマインドセットについて紹介しました。いかがでしたか。
プロダクトマネージャーは何でも屋であるが故に、大変な場面も多々あります。しかしながら、世の中をより良くしていく実感は強く、やりがいのある役職だと思っています。
弊社では、ユーザーあるいはビジネスの課題に対して成果に執着していけるプロダクトマネージャーを募集しています。これからさらに、弊社と弊社が運営しているプロダクトはどれも面白くなると自負しています。プロダクトマネージャー以外の役職でも、もし興味があれば、僕のtwitterアカウントでも何でもいいので、声をかけていただけると幸いです。是非お茶でもしましょう。
明日は、弊社の機械学習エンジニアの辻より自身が使っているNixOSの話が書かれると思います。是非、お楽しみにしていてください。
