シェア
はてブ
2020年11月26日（木）ファインディが主催するエンジニア向けイベント「【エンジニア職種徹底分析〜PdM入門編〜】スマニューたいろーさん×クラシル奥原さんが語る、エンジニアからのキャリアチェンジ」がオンライン上にて開催されました。
先日、”プロダクトマネージャーカンファレンス2020”も開催され、職種としてのキャリアが認知されつつあるプロダクトマネージャー（以下、PdM）。しかし、ビジネス側からPdMになるケースが一般的で、「エンジニアからPdM」というキャリアを選ぶ方はまだそれほど多くはないのが現状です。本イベントではスマートニュース株式会社のたいろーさん、dely株式会社（クラシル）の奥原拓也さんをお呼びして、PdMというキャリアについて語っていただきました。具体的な業務内容から裏話まで展開されたトーク内容をお届けします。
- 登壇者プロフィール
- エンジニア出身だから活きる、PdMという仕事
- 一粒で二度、三度美味しい形に。一つの課題で複数解決される「ツボ」を定義できるのが「イケてるPdM」
- 失敗経験さえも「勲章」になる。何でもありなPdMのキャリア
登壇者プロフィール
たいろー(スマートニュース株式会社) (@tairo)
現在はスマートニュースのTechnical PM 元メルカリHead of Data/AI Search Engineering Manager 自分自身の転職経験（8社目）から得られたノウハウや気づきを発信。 エンジニアの転職事情やビジネス系から開発系へのキャリアチェンジ、IT業界とユニコーン企業について書いてます。 新卒リクルートで人事/法人営業 →ベンチャーでマーケティング職 →HR系スタートアップCEO →ビズリーチ 検索エンジニア →メルカリ Engineering Director →スマートニュース Technical PM
エンジニアやPdMを目指す人向けのブログやボイスメディアを発信中。
奥原拓也(dely株式会社・クラシル)( @okutaku0507)
大学からプログラミングを始め、受託会社でのアルバイトでコーディング技術を磨く。大学院では生物化学を専攻し、大腸菌を研究。在学中にdely株式会社から声がかかり、2016年9月にジョイン。サーバーサイドのリードエンジニアを経験した後、クラシル全体のプロダクトマネージャー、開発部の部長を経て、現在は2019年に立ち上げた新規事業（クラシルチラシ）のプロダクト責任者を担当。
■モデレーター
山田裕一朗(ファインディ株式会社)(@yuichiro826)
同志社大学経済学部卒業後、三菱重工業、ボストン コンサルティング グループを経て2010年、創業期のレアジョブ入社。 レアジョブでは執行役員として人事、マーケティング、ブラジル事業、三井物産との資本業務提携等を担当。 その後、ファインディ株式会社を創業。求人票の解析とアルゴリズムづくりが趣味。
エンジニア出身だから活きる、PdMという仕事
──本日はよろしくお願いします！まずはPdMの仕事についての話から、スタートできればと思います。お二人が考えるPdMの定義とはなんでしょうか？
たいろーさん：僕の定義では「製品開発責任者」です。「よりよい製品＝プロダクトとは何か」を定義して、サービスそのものを０から立ち上げたり、既に立ち上がっているものを洗練させたり、より多くの人に届けたり、ビジネスとして成立する段階まで責任を持って推進したり。会社やサービスのフェーズによって違ってくるのですが、基本的には製品に責任を持ってる人だと思います。
奥原さん：僕は「プロダクトの成功に責任を持っている人」という捉え方をしています。僕の中での定義でいうと、エンジニア、マーケティング、ビジネスサイド、セールスの人といった、プロダクト開発の枠組みにいる人の間の動きをする人がPdMの役割かなと思っています。専門性が高い人たちが、より良く動けるように、サポート・意思決定をしていく人と捉えていますね。
── PdMとして活躍するには、どんなスキルが必要なのでしょうか？
たいろーさん：エンジニアリング能力そのものよりも、PdMはエンジニアと一緒に仕事をして成果を出す仕事なので、まずは彼らから信頼を得る必要があります。エンジニアが分かる言葉でコミュニケーションができたり、大規模トラフィックの捌き方や、システムの振る舞いも理解していると、エンジニアからの信頼を得やすいでしょうし、一つの目的に向かってチームとして協働しやすいですね。エンジニアリング経験が大事というのは、そういう意味です。
奥原さん：PdMとして、サーバーがさばけるかどうかの判断や、数ある仕様を把握していることが求められます。技術を自分の中で翻訳して、経営層の人たちに説明することができないとスピードが出ないので、コミュニケーションがスムーズにできる重要性を感じます。
組織やプロダクトのフェーズによっても、求められるスキルは変わるように思います。例えば、20~30人の組織のようなアーリーなフェーズですと、より早く・正確に機能を出せる方がいい。PdMを兼務しながら、ぐいぐい推進していける人の方が、成果に結び付きやすくなると思います。弊社delyのような140~150人程の規模になると、ステークホルダーが多くなります。誰がどんな役割を担って、どういうステークホルダーに対して、どういう調整が必要なのかを判断するためには、別のスキルセットが必要なんです。どんどん開発していくフェーズとは違って、ユーザーに価値あるものを届けていくための、サービス設計が大事になってくる。ここまでくると、仕様を理解していて、エンジニアとのコミュニケーションパスをスムーズに進めることができるスキルが活きるのではないでしょうか。
── ありがとうございます。開発サイクルを早める上で、エンジニアの知見が活きた！と感じた瞬間はありましたか？
奥原さん：仕様策定は進めやすいですね。何かを意思決定しながら開発を進める際に、毎回「これエンジニアに聞いてみますね」と持ち帰ると、時間の確保が難しい人などはその場にいないと話が進みません。仕様を決めるだけで、1~2週間かかるという話も聞いたことがあります。素早く判断して意思決定ができるのは、エンジニア出身だからこその価値なのかな。
たいろーさん：メルカリに入社した当時は、むしろエンジニアの知見を使い過ぎましたね(笑)。検索OSSのSolr*のスキーマ定義やAnalyzerの設定など、どこにどのような言語処理を入れて、どうカスタマイズすればいいのか具体的に全部僕が書いて、エンジニアはそれらを自分たちでそのままコピペするだけでいい状態にしていました。当時、バックエンドエンジニアはチームに何人かいましたが、検索技術に明るいエンジニアはいなくて。僕は以前検索エンジニアとして検索システムをみてきたし、アルゴリズムの改善をしていたので、すごい勢いでアイデアが湧いてきて。「次これやるぞ、次はこれだ」って超高速で開発チケットをどんどんつくって、エンジニアが盛り上がるみたいな時期がありました。ただ、それだと僕への業務依存度が高くなるので徐々にやらなくなりましたね。
*Solr：Apache Solr(アパッチソーラー)。Javaベースのオープンソース全文検索エンジン。
──会社のフェーズやポジション次第で変わると思うのですが、関わる工程の裁量はどのように決まるのでしょうか？
たいろーさん：PdMが何かを生み出していく道筋は、会社のOKR*に沿ったオフィシャルな開発の進め方だけじゃない、非公式なルートもあると思います。メルカリ時代、公式のOKRにはない勝手なプロジェクトをエンジニアと進めていました。彼が個人的に興味があることを社内に共有していて、非常に面白かったんです。でも、OKRと上手く紐付けられる人がいないから評価されない。僕はこれに目をつけて社内向けのデモページを作ってもらいました。それが後にプロダクトのトップの目に止まって、「これ、新機能としてやってみようか！」と日の目を見ることになりました。こういうケースってあるんですよね。
*OKR：Objectives and Key Results(目標と主要な結果)の略称。目標の設定・管理方法の一つ
奥原さん：タスクを分解すると、これだけでいいのか？みたいな話は必ずあって。要件定義をすると、細かいものが発生しますし、OKRに全てを紐づけるのは難しいので、こっそり進めるの分かりますね...。
たいろーさん：クラシルに表示される「何人分」の数字、1人分とか4人分とかに変えたら、勝手に各調味料の分量とか変わってほしいな...(笑)
奥原さん：それは、「献立機能」だと反映されるんです(笑)。ユーザーならではの視点をありがとうございます。
一粒で二度、三度美味しい形に。一つの課題で複数解決される「ツボ」を定義できるのが「イケてるPdM」
──経営陣とも近い距離で仕事をすることもあるPdMは、どんな苦労に直面するのでしょうか？
奥原さん：抽象と具体の行き来に苦労することがあります。エンジニア出身のPdMは、仕様の話から、コードレベルに落とし込んでいく具体的な話に強みがありますが、時に経営陣から概念的な「こうやっていくぞ」という方針を伝えられることもあります。抽象的な話をPdMが理解した上で、実装に移すためのメンバーとのやり取りは「使う脳が違う」感覚で、今も苦労しています。
たいろーさん：PdMが直面しやすいケースは、技術的負債が積みあがっているケースです。今すぐではないにせよ、いずれは直面する大変な仕事が大量に放置されている場合、気づいた一部のエンジニアだけは、なんとかしようとしてくれる。でも会社や自分の目標に結び付いてないから、頑張っても評価されないというのはダメだと思うんです。そういう長期的な技術課題を解決できる人をちゃんと見つけて、励ましながら、成果が出たら組織全体にアピールする動きを大事にしています。PdMの役割の一つとして言われる「調整」は、ただ傍観したり、御用聞きするだけの調整役ではないです。自分の意志を織り交ぜながら、思い描いた仮説へと「誘導」し、組織として「チャレンジしよう！」と思える雰囲気や空気作りも、PdMに求められることなのではないでしょうか。
──参加者からもいくつか質問をいただいていますが、エンジニア出身でないと、PdMとしての活躍は難しいのでしょうか？
たいろーさん：活躍できると思います。例えば、メルカリのカスタマーサクセス(以下、CS)メンバーの中には、自分でSQLを書ける人もいましたが、必要に迫られて習得したそうですし、CSからPdMにジョブチェンジした人もいて、彼らは非常に優秀です。エンジニアとスムーズにコミュニケーションしながらスピーディーに開発を進められることが重要なので、自分のスキルや経験にエンジニア的リテラシーを混ぜていければいいと思います。
奥原さん：弊社delyでは、エンジニア以外にも、デザイナー出身のPdMがいます。具体的な数値やデータを使って話を進めるのが得意なのがエンジニア、一方でデザイナーは、抽象的なことを具体化させて進めることが得意。各々の得意なスキルを活かしながら、瞬時に「これはできる・できない」を判断し、どれくらいの工数がかかるかを感覚的に捉えることができれば、どんな職種出身の人でもPdMにチャレンジすることは可能なのではないでしょうか。
──ありがとうございます。次に「イケてるPdM」の基準についてお伺いできればと思います。イケてるPdMには、どんな特徴があると思いますか？
たいろーさん：サービスを成功させる「筋の良い仮説」を発見できるかが、PdMとしてイケてるかどうかの決め手ですね。そして次に、それがなるべくシステムとして無理がないよう定義するところに、開発職としてのPdMの真髄があると思います。イケてないPdMは、問題や不満などの課題をひたすら列挙し、解決策を100個並べて、みんなで会議を開いて「さあ、どうしよっか」と投票を募るんですが、あれはダメなやり方で(笑)。取り組むべき大事なものを投票で決めるこのプロセスは、フタを開けてみれば、大事なもの順ではなく「やりやすかった順」になることがよくあるんです。本当は何をするべきかというと、最初にざっと問題の種をリストアップし、実現したときのインパクトで大まかに優先順位をつける事です。「これは確かにやったらいいかもしれないけれど、やれてもそんなにインパクトないよね」「これは結構難しそうだけど、やれたらすごいね」みたいに。次に、課題が壮大なままだと扱えないので、問題を「扱える形＝具体的な行動」までに分解していきます。そして最後のステップで、「この解決策を実行すると複数の課題が一挙に解決できる」ような施策の優先度を上げます。こういう、一粒で二度も三度も美味しい解決策、改善の「ツボ」を発見して開発をリードできる人は、PdMとしてもビジネスパーソンとしてもセンスあるなって感じますね。
奥原さん：その話、よく分かるな...。僕も最初PdMになりたての時、みんなで課題リストアップして、優先順位をつける、って確かにやってました。PdMになったことで、改めてTHEユーザー視点の気づきもありましたね。奥さんがいるのですが、2人分の料理を作る際に、めちゃめちゃ課題が降ってくるんです。「共働きしながら自炊するの、非常に困難だな...誰か献立教えてくれ！」って(笑)。クラシルのユーザーが言ってくれていたのは、こういうことだったんだ、と腹落ちしました。
──実体験することで課題が見えてくる。CS的な視点が求められるのも、PdMの面白いところですね。
たいろーさん：メルカリ時代、仙台支社に行ってCS業務をやらせてもらったことがありました。一時期までメルカリには注文のキャンセル機能がなかったんです。何らかの事情で注文の取り消しをしたい際、毎回CSに問い合わせをしなければならなかった。その作業が単純な割には数がそれなりにあって、今は注文キャンセルは機能化して、お客さま同士で一定のルールでやってもらっています。これは現場でこそ気づけた視点で、お客様が楽になっただけではなく、同時にCS業務改善にもつながりました。PdMは、より多くの人が深刻に困っていそうな課題をイメージする必要があります。
──お二人が考える、PdMの醍醐味はどんなところにありますか？
奥原さん：PdMって情報の集約地点だと捉えています。色々な情報がある中で、意思決定していくことが重要だと思うので、みんなを鼓舞し、エンパワーメントしていくことに醍醐味があると思います。
たいろーさん：僕は「こうなると最高だな」と自分が思うアイデアを、「もっと大胆に発想してみるとどうなるかな？」と膨らませて、やりすぎるギリギリまでチームで一緒にチャレンジできた時、この仕事にやりがいと面白味を感じますね。
──お二人は言語化が本当にお見事です...。言語化する上で、意識されていることはありますか？
たいろーさん：何にワクワクするかって、人によって違いますよね。なので、チームで仕事をする時には、相手がどんなことに興味をもつのか、意識しながら伝えています。例えば、Machine Learningエンジニアにも、アカデミックなリサーチャーのようなタイプの人と、実装して動くものをつくるのが好きなタイプでは、使う言葉や強調するポイントを変えたりしますね。
奥原さん：僕はtoC向けのプロダクトを扱っていることも影響しているかもしれませんが、ユーザーとして「こうあったらいいな」という世界観を、常に未来に据えることを大切にしています。クラシルに例えると、冷蔵庫に入っている材料から献立をレコメンドしてくれて、動画を見ながら調理できるようになったら、今の生活がもっと良くなると思うんです。ワクワクする未来を発想して、逆算すると1年後はこうしないといけないよね、半年後はこうだ、じゃあ1週間後はここを目指そう！と、落とし込んでいく。そんな目指し方なのかなと思います。短期視点では悲観して、長期視点では楽観であるべきと捉えていますね。コロナの影響も作用して、EC産業は伸びたかもしれませんが、数年後どうなっているのかは誰も分からない。短期視点の未来はどうなるか分からないけれど、長期視点では「こうあってほしい」というワクワク感を、僕も大事にしています。
失敗経験さえも「勲章」になる。何でもありなPdMのキャリア
──PdMとして経験を積むと、将来どんなキャリアに活かせるのでしょうか？
たいろーさん：エンジニア出身のPdMの次のキャリアとして有望なのは、「起業」だと思いますね。シリコンバレーの著名VCであるYコンビネーターも言っていますが、0→1でサービスを作る時にやるべきことは「自分で手を動かしてプロダクトを作ること」と「お客さんのところに行って話を聞くこと」の2つだけ。パーティーなんか行ってないで、これだけに集中しろと。だとすると、この２つは「エンジニア出身のPdM」こそが最も近い役割のはずです。
奥原さん：僕も起業なのかなと思います。ファイナンスと組織作り以外の経験をPdMは網羅的に積むことができるので、自分の手で動かして、ユーザーにヒアリングするPdMの仕事は、スキルセットとして身につきます。個人的には、PdMの経験を積んでから、エンジニアに戻るのもありだと思うんです。エンジニアとして仕事をすると、誰かがPdMにつきますよね。自分にどう動いてほしいのかが、分かるようになってくる。エンジニアは市場価値が高いから、抽象と具体の両方の観点を心得ている動きができる人は、ハイパフォーマーになれます。
たいろーさん：フルスタックエンジニアとして起業するも、スタートアップに参画するも、いくらでもやってみたらいいと思うんです。この業界では、失敗経験さえも履歴書を彩りますから。面接でいくらでも、しくじり先生みたいに説明すればいいんです(笑)。もはやそれは勲章みたいなもので、チャレンジに失敗しても、エンジニアとしての仕事は世の中にいくらでもありますからね。
──お二人は、良いアイデアや仮説を生むために、取り組まれていることはありますか？
奥原さん：色んなサービスを一度は試してみますね。気になったものは試しに使ってみて、何が良かったか、ダメだったかをインプットしています。毎日フレッシュな情報を入れることで、お風呂入る時や散歩している時に、ふと浮かんできて掛け算されたものがアイデアになっていく。部屋に籠っているよりは、外に出て情報を得る、こうしたら実はクラシルに生きるのでは？ということを日々考えています。
たいろーさん：toB向けだと利便性を、toC向けはパッと見て直観的に今まで見たことのないUIを、という視点を大事にしています。例えば、思い付きでやってみたいと思うのは、スマニュー上で、見た目はメルカリのようなUIなんだけど、それが実は広告である、みたいな。そんな広告は作ってみたいですね。大量のデータを使って、eコマースをやっているのか、ニュースアプリをやっているのか、よく分からないけれど面白くないですか？ 読書は雑食なのですが、『デザインの輪郭』という本に「いかにプロダクトを消滅させるか？」というテーマが述べられていました。例えば、傘立てが目の前にないと無意識的に人間は、地面にある溝に引っかけて傘を立てかける。人間は学習をしていなくても、ちょうどいい溝を見つけて、立てかけてしまう。この本の著者は、定義として「傘立てとして成立している」と言っているんです。
面白い考え方だなと思って。テスラ社を例に出すと、実は車一台一台にIDが振られていて、ログインしたらwebサイト上で、自由に売買できるらしいんです。現状、これをやっているのはテスラぐらいかと思いますが、いずれ手軽に売買できるプラットホームを展開するスタートアップがグロースしたら。あらゆるBtoB企業は、勝手に二次流通的にメルカリみたいなやりとりが活発になっていく。自分たちのところにお金が入ってこないのは嫌だから、自社の中古プラットフォームを正式に作る企業も現れるでしょうね。こういうのができたら、メルカリはやばいだろうな、とか考えたりしています。
──時間の流れが早すぎて、もう少し話していたい気持ちもありますが、締めに入れたらと思います。最後に、お二人からメッセージをお願いします。
たいろーさん：エンジニアやPdMを目指す人向けのブログをやっていますので、ご覧頂けると嬉しいです。あと、毎朝6時にVoicyでラジオ配信をしています。僕が感じたり考えていることを、毎日気軽に配信してますので、ぜひアプリをダウンロードして聴いてみて頂きたいです。
奥原さん：delyでは定期的にイベントを開催しており、PdMの人たちの仕事や、普段表に出ないような具体的なエピソードなどをお話させていただきます。第一弾のイベントを先日実施したのですが、200人以上の方に参加いただき好評でした。第二弾を1月14日(木)に開催予定なので、ぜひこちらにもたくさんの方にお越しいただけますと嬉しいです。
──お二人とも、本日はありがとうございました！
以上で本イベントは締めくくられました。ここまで読んでいただき、ありがとうございました！
よろしければ、エンジニアの皆さまはFindyでご自身のスキル偏差値を測定してみてください。
[正社員の方]
ハイスキルなエンジニアのプレミアム転職サービス Findy
