-----------------------------------------------
BASE柳川さんをお招きしてのPMと事業責任者の違いシリーズ、第二回目はPMと事業責任者それぞれのコラボレーション先や、コミュニケーションをするレイヤーの違いを中心にお伺いしました。
・エンジニア、PM、事業責任者としてどんな方々とコラボしていくか
・PMと事業責任者で大きく異なるのは経営レイヤーとのコミュニケーション
・経営レイヤーが知りたい情報は何なのか
・「説明」する力の重要さ
等について語っていただきました。
-----------------------------------------------
ご質問、リクエストは下記からどうぞ
https://forms.gle/bvuWWPu1AjAb7Sse6
-----------------------------------------------
▼PMキャリアのあれこれはnoteにも!
https://note.com/pdm_kandc/
-----------------------------------------------
配信:隔週木曜日11時頃(たまに毎週配信)
出演:
柳川慶太氏(BASE株式会社/金融事業責任者)
山本航 (クライス&カンパニー/コンサルタント)
松永拓也(クライス&カンパニー/コンサルタント)
www.kandc.com/eng/?utm_source=podcast&utm_medium=referral&utm_campaign=pdm
感想
まだ感想はありません。最初の1件を書きましょう!
00:03
え。今回もベイス株式会社より、ベイスバンクの事業責任者をされている柳川さんにお話しを伺ってまいりま。す、柳。
川さん、よろしくお願いします。よろしくお願いいたします。
あの、第1回のところでですね。エンジニアとプロダクトマネージャーと事業責任者。こう時期感みたいなところとか、目線感が違うっていうふうに最後お話しされてたと思うんですけども。それぞれまず誰と仕事をすることが多いのかっていう。エンジニアは誰とするのか、PMは誰とするのか、事業責任者は誰とするのか、そこから伺っていってもいいですか?はい。
エンジニアはまあ、まず、基本的にはまあ、エンジニア同士で仕事することが多いかなというふうに思っています。あとまあ関わってくると、人としてはまあデザイナーだったりとか。まあもちろんそのプロダクトマネージャーがいればプロダクト。マネージャーも関わってくるかなとは思うんですけれども、すごく本当にこうプロダクトを作る、あの、もうこの機能を作るっていうところに、こうスコープするっていうのが、スコープとしてこう集中していくっていうところが特徴かなと思いますね。はい。で、プロダクトマネージャーになってくると、もちろんその現場でエンジニアと話もするんですけれども、だんだんこう、事業責任者だったりとか、まああとですね、言い方あれです。プロダクトオーナーみたいな人とか。と話をする機会も増えてくるのでこの
まあ中間に立って、両方のご都合をこう、両方ともこう解釈しなきゃいけないというか、合わせなきゃいけないっていう風な形に、まあ徐々に変わってくるのかなと思ってますね。開発サイドを見るし、事業責任者サイドを見るっていう意味での両方ですね。
そうです。で、事業責任者になってくると、まあさらにまあ経営だったりとか、まあそれこそこう、株主さんみたいな、どうやってこうプロダクトを作っているのかとかっていう事情は、そんなにこう需要じゃないっていうふうな形でのコミュニケーションになってくるので。さらにこの機能を作るみたいなことで言うと、抽象度が高くなってコミュニケーションするって形ですかね。頭。
の中では多分、聞いている皆さんも、まあそれは話す人のレイヤー変わってくるよねっていうのは簡単に理解できると思うんですけど。の東映実業務する中で、そこの話す人のレイヤー感、目線感、時期感が変わるっていうのは、具体的にどういうコミュニケーションに現れたりとか、どんなアウトプットを今までだったら通用してたけど、ここをこう変えなきゃいけないっていうのが発生するんですか?まずエンジニアからPMにおいていかがでし。
ょうか、そうですね。エンジニアからPMに変わった時に関しては、まあ正直。そう、ここはね、そんなにギャップなかったんですよね。そのプロダクト開発チームの一員っていうところで差はなかったので。はい、そんなにギャップなかったかなとは思いますかね、結。
構目の前の与えられた開発だけやっていればよかったのが、そこそこピーエムになって、12年後ぐらいのロードマップ意識しなきゃいけなくなったとか、そういうのはなかったんです。
か?いや、なんか別にエンジニアだった時も与えられた機能開発してるって意識じゃなかったんで。って言ったらさ。すが男と目線が高かったわけですね。
03:06
僕はそのPMとエンジニアの違い、僕の中での役割の違いとしては、ただここと書かなくなったって、それだけでしかなかったんですよ。目線多分、細かく見ていけば変わったんだろうけど、変わんないと言いたいっ。て感じ。じゃあ、じゃあちょっとずるい質問なんですけど。柳川さんはそうだったかもしれないんですが。
一般的なっていうのも良くないから、他のエンジニアは?っていう方がいいのかわからないんですが、そういうの人たちと比較した時に、一般的にエンジニアとPMの目線感、どういうところにシフトチェンジ要素が発生しそ。うでしょう。まあ、その。だから何を作るかっていうところに対するその責任というか、それをこう定義しなきゃいけないっていうところには、まあ差が出るでしょうね。うん、一般。
基本的にはやっぱりこう、プロダクトマネージャーがこういう機能を作るよって話があった上で、それをじゃあどう作る?っていうところから入るのがエンジニアっていう形にはなってくるので、はい。何を作ると、どう作るっていうところでのあの思考とかの違いは出てくるのかなと。思います。でも、柳川さんはエンジニア時代から何を作るっていうところに意識時代があったので、PMAのチェンジっていうのはさほど大きなチェンジではなかったっていうことなわけですね。
そうですね。なかった?うん、ちょっとなかったと言いたいですね。はい。
でもこれは今、エンジニアの人にすごく大きなメッセージになるのかなと思いました。一方で、じゃあこのPMから事業責任者、もちろんシームレスに移り変わっていったと思うんですけども、ここでの何か差みたいなのはどういうところがありましたでしょ?うそうですね。やっぱりこう。
経営レイヤーとのコミュニケーションっていうところが、やっぱ一番差としてはあるかなというふうに思ってます。何に興味があるか、何に興味があるかって言ったらあれですね、難しいんですけど、その、まあどの理由と感で知りたいかっていうところがやっぱり全然違うと思っていて。まあ基本的にこう経営と会話したりとか、経営と会話することを通して、その株主と会話するってことに関して言うと、やっぱ数字の話がメインになってくるんですよね。なんでいついつ?までにこの機能が。できてそれによって、じゃあどういう風な売り上げになるんだいっていうところが、まあメインになってくるんですけれども、まあやっぱりこう、どちらかというとこう、その、なんですかね、開発目線というか、あの、どれぐらい、どれぐらいに、どれぐらいのものを作るっていう目線感とか、情報を渡してしまうと、逆にこう伝わらないというか、あの情報過多になってしまう、伝えることなんか情報過多になってしまうっていうところがあったので、それをこう減らすっていうとこですね。これどっちかっていうと話したがりなんで
どうなる?伝えるといやこの機能、幸運ぐらいの今計画になってて、この辺でリリース予定ですみたいなこと言うと。まあ、知りたいのはそこじゃないよっていうことになりますよね。話が噛み合わないって感じです。
かね、数字っておっしゃったんですけども、知りたいのは売り上げなんですか?やっぱ利益なんですか、経営陣は。まあ、もちろん会社によって違うと思うんですけれども。いや、まあ、ちょっと一般的な話としてなんですけど。やっぱりこう、事業活動って投資なので、いくらこの期間投資したら。
06:08
この期間経った後にこれぐらい帰ってきますって話がやっぱ基本的な。こう、骨子というかベースなんですよね。そこに肉付けして話していくっていう感じです。よこと、それがプロダクト開発現場における事業責任者だと。
どういう、どういうふうに説明するんですか?アールアイの説明。だと思うんですが、プロダクト開発の現場だと、基本的にやっぱり一番かかる費用って人件費なわけですよね。だから、このこれぐらいの人件費をかけて、それによってこれぐらいのこの機能ができて、それによってどれぐらいの売り上げがどれぐらいの期間で発生しますっていうところの話をまあするって感じですかね。
そこらへんがこう日常的に経営者と議論するレイヤー感になってきて、そこに目線を合わせていくのが、ちょっと少しのこうギャップだったというか、ハードルだったってことなんでしょうか。そうですね。だからな。例えばその、そんなこの機能を作って、いつまでにどれぐらい使われるかなんてわかるわけねえじゃんって。
予想思う。というか、思うというか、予想できないから新規事業やってるんでしょとか、まあ最初のから思ってたわけですよ。とりあえず作ってみるしかないじゃんみたいなことを思ってたりするんですけど、まあ、なんか予想できないことなんてわかってんだよって話ですよね、あの言わせると。
はいは。い、わかってるけど。その上でちゃんとこう、目標を立てながら。
それに対して進捗がどうだったかとかっていうのを確認しながら、精度を高めていくのが大事だよねっていう話ですよね。っていうところの、なんていうか言葉で言うと、いや、それはその通りでしょ、それはそうでしょっていうことだと思うんですけど、なかなかここがこう、自分のものになるまで時間が。かかり。
ました。なるほど。いや、なんかめちゃめちゃそれは今頷いてる人多いんじゃないかなと思うんですけど。そう、当時そう思ってたわかんねえよ。と思ってた枝川さんに、今ならどんなアドバイスをしてあげますか?もう。
こうやったらいいよって。経営者、あの社長と話すには?みたいな。そうですね。まあでも、なんかわかんなくても、とりあえずやってみなよっていう話だと思ってて。基本的にはうんうん。
やった上で、やっぱりこう、フィードバックというか、ピーディーシーのループ回していかなきゃいけないよねって。それもプロダクト開発が当たり前のことっちゃ当たり前のことなんですけど。うん、まあその場面でもそのしっかりそのdbc回していくってことをやっていくべきだよねっていう。まあアドバイスです。か、なるほど。実際わかんないじゃないですか。どれぐらい売り上げ立つからって。いや、これぐらいこういうふうにユーザー数が増えて、こうなっていったら単価がこうなんで。みたいな。どうしても鉛筆、ナメ、ナメの世界になっちゃう部分もあると思うんですけど。
それは問題ないんですか?事業責任者が経営者に報告するものとして。わかんないとの違いだと思ってて。プロダクト開発って結構わかるんですよ。それで言うと、あの事業計画に比べると実はわかるんですよ。これはあのエンジニアとかプロダクトマネージャーやってる人が聞くといや、わかんねえけどって言うかもしれないですけど、比較すると全然わかるなと思ってて。
09:12
KPIが予測しやすいっていう意味ですか?売上に対して。売上とかの予測、ユーザーがどれぐらい使ってくれるかの予測よりは、はるかにいついつまでにこの機能ができる、この人数でできるっていう話の方が全然予測がつくので、はい、それぐらいの精度で予測しなきゃいけないのかなって思うと、できないよってなるなります。
話が来るよ。ってなりますよね。特に新規事業。ある程度こう。
時間が経って実績ができてきた授業であれば、ある程度の精度で作れるんですよ。授業計画。作れる傾向とかもありますしね。
そうです。傾向が見えてくる。前はそれわかんないよって話なんですけど、わかんなくてもなんていうんですかね。なんか、どういうKPI分解したかみたいなことが結構大事だったりするんですよ。KPIの数字が当たってるかどうかっていうのは、本当にプロダクトの初期段階ではわりかしどうでもよくて、そのKPIを分解した時に、それぞれのKPIの傾向がどうだったかっていうところの答え合わせをしていくっていうのが結構大事なんですよね。なので、なんか数字が当たってるっていう目線管よりは、KPIの切り方間違ってない?みたいな会話になったりするんですよね。それはもう、やっぱ。や。っ。てみるまであそこなんだっていうあそこがポイントなんです
っていうのまで、わかんなかったですよ。ね。もちろん制度が正しいかわかんないけども、そこを早期にキャッチするために、じゃあどのKPIで中間測定するかとか、それを見ながらどう軌道修正するかとか、そういうところを見てるって事なわけ。
ですね。そうですそうですそうです。で、そのKPIの切り方切ったKPIにを通じて、まあディスカッションしていくっていうのが、経営レアとか数字を見ているレイアウトの。話の進め方にはなってくるので。っていうのに、やらないとわからなかったです。
いや、でも確かにそれはその目線感というか、そのフィールド感に慣れないと、ちょっと頭の使い方が違いますよね。伺ってると。そうですね。頭の使い方、だいぶ違いますね。なんか、どういう答えを求められているのかがわかんないというか。
どうなん?どういう流動感で話したりでいいかわかんない。みたいなところはありますよ。ね。経営陣も数値の正確性を求めてるんじゃなくて、どう保証するかというか、担保するかとか、プロセスでそこの仕組みをこう担保するみたいな、そこのロジックだったりが、あなたしっかり考えてるのとか、そのモニタリング状況どうなのっていうところを気にしてるっていうふうに理解したんですけど、合ってます。
か。そうですね。なんかあの説明ができるかどうかっていうのが、なんか結構大事なんだなっていうのを思っていて。僕、結構やっぱプロダクトドリブンなスタートアップに入ってきた。
っていうところがあるので、なんかまあ説明を説明でなんだけど、まあなっちゃうと、その大企業にいた時の説明の感じはやりたくないなっていうマインドだったんですよ。だから、その大企業にいると、どうしてもこう説明専攻になってしまうというか。そんな説明なんかする前に作っちゃえよっていうのが結構こう、なんていうか、スタートアップ。の。
12:11
そうなんですよね。かっこいいところっていうか。いいとこですよね。そう。
だと思って入った中で、なんで逆に言うと、こう説明に対して過剰にアレルギーを持ってたところがあったんですけど、なんかやっぱ説明をすることによって、あの自分の理解が上がって、結局事業の意思決定の精度が上がるっていうものもありますし、説明をすることによって。得られる協力の量が増えるっていうところもあるんだなと思っていて。まあ説明って案外悪いもんじゃないよっていう気づき。
得られる協力っていうのは。あのリソースを与えられるってことですよね。お金とか人。
とか。一番わかりやすいのはそれです。ちなみに、そこにたどり着くためには、もう事業責任者になってもがくしかないんですか?どうやったらそこに1種のジャンプをしてると思うんですけど、PMを日常ではちょっと使わない考え方かなという気がするんですが、いかがでしょう?
か、うん。あ、そうですね。まあ、さらされるっていう表現を僕は結構使うんですけど、うん、さらされるしかないんだろうだろうなと思ってるんですよね。されると説明しなきゃいけないっていう、その説明しなきゃいけない状態にさらされるっていうことを通してでしか、その説明を通して得られる果実っていうのは、なるほど腑に落ちないので、説明すると結構きつい。
きついし、例えば部下に説明をさせようとすると、結構申し訳ないなと思ってできなかったりするんですけど、説明させない、説明するっていう経験を得ててしか得られないものがあるなっていうのを今だと思うので、まあやっぱり段階論はありますけど、1種ジャンプアップするっていうところは、まあ必要なのかなと思いますね。ありがとうございます。めちゃめちゃ面白かったです。今回もですね、ベイス株式会社より、ベイスバンク事業責任者の柳川さんにお越しいただきまして、事業責任者とPMの違いについてお届けしてまいりました。ええ、引き続き、次回以降もご清聴いただければと思います。柳川さん、ありがとうございました。ありがとうご。
ざいました。
コメント
スクロール