エンジニアがある日突然PdMになったら何から勉強するべきか
横澤佑輔氏（以下、横澤）：次にいきます。今度はエンジニア側からの歩み寄りの話です。やはりエンジニアだけをやってきて、いきなり「今日からお前はPdMな」と言われても、ビジネス上の知識がないわけです。これは僕も経験があるのでわかります。
要はこちらが「プログラミングで何をやればいいの？」と言われるのと同じで、ある日突然、エンジニアがPdMになって「ビジネスサイドは何を勉強すればいいの？」と言われると、たぶん困ると思います。「何から」と言ってもメチャクチャあるぞと。その中で優先順位であったり、そもそもこのへんぐらいは先に（エンジニアに）見ておいてほしいと思うものがあれば、教えてください。友也さんはどうですか？
伊藤友也氏（以下、伊藤）：難しい質問です。やはりビジネスの状況によって何が必要なのかは違うと思います。そのプロダクトがどのような性質かによるのですが、ユーザーのことは知っておいたほうがいいと思っています。やはり、誰が使うのか、なぜ使うのか、をしっかり理解することは大事です。
もう1点。そのビジネスがどのようにビジネスとして運営されているのか。そのビジネスモデル、競合優位性、マーケットがどのようなトレンドなのか、それぐらいは知っているといいのではないかと思っています。どのようにキャッチアップするのかは、僕のおすすめは、競合企業のIRなどを読むことです。そうすればだいたいのことがわかると思います。
横澤：なるほど。さすがです。
ユーザー理解のために全メンバーがワークショップに参加する株式会社すむたす
横澤：友也さんはずっとtoCの不動産というキャリアを歩んでいるじゃないですか。当然、自分も不動産に住んでいますが、毎日買うものではないから、ユーザー理解がけっこう難しいと思うんです。
実際のユーザーとしゃべったりとか、なにか理解するためのアクションを取ったりすることはありますか？
伊藤：まず事実として、エンジニアが家を売る人の家にお邪魔することはありません。お客さまにとってエンジニアが自宅に来ることは気持ちがいいものではないと思います。
ただ、僕らのサービスを使ってくれた人、特に売ってくれた人にはインタビューのお願いを100パーセントしています。また、受けてくれる人はけっこうな割合でいます。マーケティングチームのメンバーがインタビューした内容を書き起こして、社内に共有していて、エンジニアも必ず見るようにしています。
横澤：なるほど。それを読むことでユーザーのインサイトがわかってくると。
伊藤：あと、不動産特有ですが、やはり感情的な部分がすごくあります。10年、20年住んだ家を売る。価格が良いだけではいけません。そのユーザーのインタビューを読んで「そうなんだ」だけではなくて、1ヶ月に1回、3ヶ月に1回、社内でオフサイトミーティング的なワークショップを開いています。グループワーク的に、社内のメンバーで「この人のインタビューを読んでどう思った」などと話し合うことは、エンジニア、ビジネス、ファイナンス関係なくみんなでやっています。
横澤：けっこうロールミックスで、チームを組んでやる感じですね。
伊藤：そうですね。全メンバーが参加していますね。
横澤：すばらしい。
鈴木康弘氏（以下、鈴木）：すごいですね。
伊藤：でもそれは、エンジニアに目線を持ってもらうというよりも、そういうことが好きで、楽しいと思っているメンバーが集まっているという側面もあります。
横澤：やらされているわけではなく。
伊藤：そうですね。
横澤：自分から気持ちを理解しにいくということですね。
伊藤：そうですね。
鈴木：チーム全体でそのお客さまのほうを向くようにする、共感状態を作るようにする、というのは組織設計上、すごく重要な気がします。
横澤：toCはわりとダイレクトに響くと思います。
伊藤：ちょっと話が長くなってしまっていますが、今のところで工夫していること。僕たちは不動産系の会社なのですが、エンジニア、マーケター、セールス、すごくいろいろな職種の人がいます。
普通に考えたら、マーケティングチームやエンジニアチームなどと括りたくなりますが、僕たちは「グロースチーム」という呼び方をしています。結局、ビジネスを伸ばす、ユーザーの課題解決をする、という意味でいうと、「全部HOWで目的が一緒だから、同じチームだよね」と意識しています。「俺はエンジニアなんだ」「マーケターなんだ」ではなくて、「ビジネスをグロースしているんだ」という意識を持てるチームの呼び方をしているのが、工夫しているポイントの1つです。
明石衛氏（以下、明石）：今、何人の組織でそれができているんですか？
伊藤：今は正社員が30名ぐらいで、コーポレート・ファイナンス系の人が5、6名いるので、グロースチームと呼ばれるところでいうと25名います。一方で、25名の1チームだとコミュニケーションがカオスになってしまうので、ユニットという概念を持ち出しています。1ユニット3人の単位で、それぞれの領域で仕事をしているかたちです。自分はグロースチームであり、エンジニアユニットである。そういう意識をみんなが持っています。
横澤：その代わり、グロースチームとしてのビジネスをグロースさせる。ひいてはお客さんを喜ばせるという成果貢献が、チームの目標として大前提で設定されているわけなのですね。
伊藤：そうですね。なので週1回、グロースチーム25名がGoogle Meetにバッと集まります。4人ぐらいの単位でランダムに振り分けられて、自分たちの状況を共有するミーティングをしています。また、ユニットごとにデイリースクラムを開催しています。毎日は同じ職種のメンバーと、週1回はグロースチーム全体でコミュニケーションを取っている感じです。
横澤：パクります。
（一同笑）
伊藤：これをやり始めてビジネスへの解像度が上がったという声がけっこうあったので、やって良かったとすごく思います。
toBのビジネスを展開する株式会社リテイギはスプリントレビューでプロダクトの価値を最大化している
横澤：逆に、明石さんはtoBのビジネスです。toBはtoBでガッツリとビジネスモデル、営業戦略、事業としての行動などが良くも悪くも固まっているじゃないですか。ユーザー理解への観点など、余計に理解が難しい気がしているのですが。
明石：そうですね。でも、伊藤さんが言っていたことと、僕らも似たようなことをやっています。ちょっとアジェンダに戻りますが、最低限持つべき知識は事業理解だと思うんですよ。それこそ、マーケットがどうか、ターゲットは誰か。そういったところをどうやって共有するか、意識を同じところに持たせるかという意味でいうと、僕らはスプリントレビューをしています。
今日は（参加者が）エンジニアばかりだと思うので大丈夫だと思いますが、スプリントレビューはビジネスサイドも出て全部報告しています。成果は全部ERです。議事録を全部そこに載せて、今週誰とどのような話をしてきたかも全部そこで報告します。今、僕らはどのような人たちと、どのような話をして、どう成長させようとしているのかを、エンジニアなど関係なくみんなに意識を持ってもらいたいからそのようなことをやっています。
そうすると「だったら明石さん、この機能から作ったほうがいいんじゃないですか」「明石さん、きっとアプリを作ると思うから、これを準備しておきました」など提案してくれるようになりました。エンジニアやビジネスなどが関係なく、みんなで共有することはすごく重要だと思っています。
横澤：事実上の営業会議のようなものが、スプリントレビューにドッキングされているという話ですよね。
明石：そうですね。僕らのチームはまだ僕を含めてもビジネスサイド2人、エンジニアとデザイナー5人、合わせて7人しかいないので、それができています。それしか定例ミーティングは行わない。その代わり、みんなで一緒にそこで全部話すようにしています。
横澤：ビジネスがうまくいって、組織が拡大すると営業もこのクライアントに行って、この話を聞いたみたいな、けっこう定性が大きい中で定量化していると思います。要はアタックリストが200件あって、何件行ってファネルが、歩留まりが、というのもやはり共有するのですか？
明石：基本は共有したほうが良いと僕は思っています。先ほど言ったように、エンジニアからの提案はビジネスサイドにはすごく重要でありがたいんですよ。結局、工数もわからないし、どういった回避方法があるかもわからないし。
状況を全部伝えた上でエンジニアから提案してもらうことが、その事業をもっとも推進すると思っています。そういった意味で、今はどのようなアタックをしていて、どれぐらいつらい思いをしているのかを知ってもらうことは良いと思うんですよね。だから、僕はそれをずっとやっていきたいと思っています。
横澤：なるほど。
明石：yamoryの時も初期はわりとやっていましたよね。
鈴木：そうですね。
横澤：そうか。一緒にやっていたんですもんね。
明石：みんなでやっていましたね。
鈴木：スプリントレビューで営業報告をするとかは今でもずっとやっていますね。案件ベースで全部やる。
横澤：yamoryの規模だと、たぶんけっこう多いと思うのですが。
鈴木：けっこう多くなってきていて、どう仕組み化するかを考えなければなりません。たぶん重要なのは、どのような課題があって、どのようなお客さんが困っているのかをエンジニアが共感できている状態にすることです。背景や知識があまりインプットされていない状態で「これをやりたいんだ」と言われても……昔、私もいろいろ反発を受けたこともありました。
明石：（笑）。
鈴木：背景や知識をきちんとそろえてインプットしていく、チームを共感できる状態にしていく。その情報流通の仕組みをきちんと設計するというのは、PMとしてとても重要だと思いますね。
イタンジ株式会社・永嶋氏が意識する“金の流れ”
横澤：そういうのがぜんぜんなさそうな永嶋さんは？
（一同笑）
横澤：実際にビジネスサイドとしてのジャッジばかりですよね。
永嶋章弘氏（以下、永嶋）：そうですね。別にコードも書いていないですね。
横澤：それで「数字がぜんぜん足りないじゃないか！」と言っているんですか？
（一同笑）
永嶋：この流れでその話をすると、僕がメチャクチャ悪者みたいになるんですよね（笑）。
横澤：ここらへんで落としておかないと（笑）。
永嶋：今はチームの話であって、けっこう僕が意識しているのは金の流れです。
横澤：はいはいはい。
永嶋：PLは人件費を意外とみんな意識していないんですよね。なので、話せる部分はけっこう話してしまいます。「このくらいの広告費になっていて、このぐらいになっているから、君たちはCVRをこのぐらい改善しないといけないんだよ」と、今はエンジニアにも金の流れをけっこう話すようにしていますね。
横澤：確かに。toCだから、CVRがけっこうダイレクトに売上に響いてしまいます。「CVRを上げるために、ボタンを突然赤色にしよう」と言われても「？」とならないように。
（一同笑）
永嶋：「ここのCVRが1パーセント上がると広告費が同じでもこんなにいっぱい利益が出るじゃん」みたいな。
永嶋・横澤：そうしたら給料も。
（一同笑）
永嶋：そのような話を僕はしています。けっこう下世話な、銭ゲバな感じですね。
横澤：そのへんのPLと言っていますが、CVRは要はファネルです。メディアで広告を出していて、CVRがあってCTRがあって、そこも全部、エンジニアを含めて開示をしている感じ。
永嶋：開示していますね。僕らの事業は賃貸仲介業なので、賃貸仲介をしている不動産営業スタッフもいるのですが、彼らにもそれを開示しています。サイトの構造はこのようになっているとか、SEOの話とか。そういったものを全部インプットするようにして、それで「君たちはここを担っていて、君たちがこれをちょっとやって成約率が上がると事業としてこんなにいいんだよ」みたいな。
横澤：なるほど。たぶん最初はメディアから入ってくるから、そこが下がっても営業マンの成約率が上がれば、最後の数値は当然良くなるということですね。
永嶋：そうですね。
横澤：すごいですね。それをエンジニアみんなが理解しているんですか？
永嶋：どの程度理解しているかどうかはわからないですけどね。
横澤：説明していないと、いきなりCVRのことを言われてもわけがわからないと思います。
永嶋：メンバーのレベルもあるので全員がいきなりすべて理解できるとは思いませんが、話すようにはしています。
横澤：説明があったほうがやはりいいと思います。
PdMは数字の感覚を持っておくべき
明石：今、聞いていて思ったのですが、やはり数字の感覚は持っているべきだと思います。広告費がいくらかかっているのか、人件費はどれぐらいか、僕らの売上はこれぐらいで、それはターゲットの予算から見たらどれくらい大きいものなのか、などをきちんと感覚として持っておくことがすごく重要だと思っています。
それを持っていると、ここは急がないといけないとか、開発はじっくりリファクタしていいという感覚も出てくる気がしています。そういった意味で、数字を全部共有することはすごくすてきだと思いました。
横澤：でも、toBだとなおさら難しい（笑）。メディアはわかりやすいです。逆にyamoryはtoBの中でも、きちんと商談をしないといけない性質のものだと思うので、数字の開示はあまりイメージがなかったのですが、数字の開示はしていますか？
鈴木：そうですね。基本的な情報はスプリントレビューで開示したいとは思っています。ただ、どれぐらい具体的に深掘りしていくかという話はちょっとまだできない状態です。PLを見ているのは、本当の意味では私です。エンジニアからPMになって、成長段階が上がっていくと、いわゆる事業戦略に行き着くんですよね。そこまで行った時に、本当に自分でPLを書いたり見たりします。
横澤：実際にエンジニアからPMをやっているじゃないですか。PLを書くのは教わらなかったと思うのですが、どうやって勉強したのでしょうか？
鈴木：私たちはありませんね。教わりません。やるしかないんです。
横澤：見よう見まねです。幸い、他のPMの事業で見られるかもしれないので、そのへんで勉強してくることもあります。
鈴木：成長段階でリードエンジニアぐらいになったあとに、だんだんPMに興味が出てきて、ビジネスサイドに興味が出てくるケースが多いと思います。その時は別にPLまで理解できていなくてもいいと思います。案件をきちんと回せるPM、スクラムチームの1チームがきちんと回せるPMになっていけばいいかと思います。
中長期のプロダクトロードマップを作るぐらいまでいくと、事業戦略と中長期のロードマップが合致しないといけなくなるんですよ。そこで初めて、事業戦略とプロダクトが接合してくる感じになります。いわゆる4Pです。マーケティングミックス、価格、チャネル設計、コスト構造などがどう接合していくのかを理解しないとプロダクトロードマップが書けなくなるんですよ。
マーケティング基礎知識をインプットする方法
横澤：やはりプロダクトロードマップを書く手前のインプットとして、4Pが出ましたけど、マーケティングの基礎知識はどうやってインプットしていくんですか？
鈴木：私はグロービスでしていました。基礎講座です。
横澤：メチャクチャちゃんとやっているじゃないですか。永嶋さんは？
永嶋：ご存じのとおりちゃんとやっていないですよ。
（一同笑）
鈴木：PMの師匠にあたる昔の上司から「マーケティングの知識はちゃんとインプットしなさい」と教育されました。
明石：yappyさんはちょっとビジネスオタクの面がある特殊な人なので。
横澤：やりたくなっちゃうんでしょうね。
明石：本をすごく読むので。
横澤：なるほど。
明石：ちょっと特殊な人だと思います。一応、言っておきます。
（一同笑）
永嶋：僕はあまり何も考えていないですね。ある程度考えたら突っ込んでいって、失敗して気づきながら学ぶ。
横澤：ちょっと効率が悪いやつですよね。
永嶋：経験でしか学べない。
横澤：友也さんはビジネスとしてのキャリアをずっと積んでいるじゃないですか。大企業から今はベンチャーだと思いますが。やはり継続的にインプットの機会を自分で取りに行くのですか？ それとも、必要に駆られて？
伊藤：そうですね。リクルートではいろいろなインプットの機会がありました。研修もそうですし、メンターや先輩からインプットをもらうこともありました。個人的には、Udemyで興味があるものを見たり、人と会って情報交換したりしています。
横澤：リクルートで勉強しつつ、外部からもきちんと情報を取り入れている。
伊藤：話が変わってしまうかもしれませんが、先ほど「自分でやっている」と言っていたと思います。すむたすを始めたばかりの時は、KPIをどう見ていくかをわりと一般的なフォーマットや指標に沿って管理していました。
その時に、なかなか周囲のメンバーに伝わらないという問題にぶつかったんですよね。それぞれの仕事や考えていることがある中で、全部を頭に入れるのは難しいし、逆に、本当にビジネスとして大事なところをそのビジネスのフェーズに合わせてピックアップすることがけっこう重要なことだと思いました。
横澤：プロダクトチームが進んでいく中で、いきなり全部ドンッとやるのではなくて、重要なところから小出しにしていく。
伊藤：そうですね。セオリーに沿って全部見るというよりも、その時に重要なことをピックアップしてみんなで共有することが、PdMの重要なポイントだと思います。
横澤：なかなか難しくて成長していきにくいと思うので、ちょっとずつやっていくのがいいのかもしれないです。まじめに勉強するスタイルでもいけるし、永嶋さんみたいに適当にやってもなんとかなるしということで、どのようなスタイルでも。
（一同笑）
横澤：勇気が湧く話でした。
（次回へつづく）
