1. Zero Topic - ゼロトピック -
  2. #9 プロダクトマネージャーの..
2020-03-16 12:59

#9 プロダクトマネージャーの役割やその難しさについて

ストラテジーと実装の一致が役割だけど、2つの不確実性から簡単なことではない、がんばろうなーという話をしました。こちらのブログの副音声としてお楽しみください。https://yamotty.tokyo/post/20191207_strong_point_of_startup/
00:06
こんにちは、ゼロトピックです。
今回は、ちょっと僕の専門的な領域というか、 プロダクトマネジメントという、
製品を何とかして成功させるために、 どういうことを考えているかという話をしたいと思います。
この内容は、すでに去年ブログに ちょっと簡単にまとめてあって、
ストラテジーと実装の一致が プロダクトマネジメントの役割であるみたいな、
そういう記事がどっかに上がっていると思うので、 URLも参考欄に貼っておきたいと思います。
その内容をもう少し掘り下げて 解説したいなと思っています。
そもそもストラテジーと実装一致させるって、 どういうことなのかというと、
分かりやすく言うと、例えば経営者が、 うちは取引のコストをゼロにする会社です、
みたいなミッションがあったとして、 実際に出しているプロダクトが、
チャットアプリみたいな時って、 結構乖離があるように見えるじゃないですか。
だけどその乖離の間には、 実際に将来どういうものをしたくて、
間としてどういうステップが必要で、 だから今チャットアプリなんですってストーリーがあるはずなんですよね。
かつ未来の足したい状態とは、 今駆け離れている状態にあるっていうのが、
ほとんどの会社で起きている、 普通の状態だと思うんですけど、
そこをどうやって埋めるのかとか、 その間を埋めるために必要なリソースを集めるにはどうしたらいいのかとか、
その集めたリソースをどうやってうまく使って、 会社が死ぬ前に勝てるような仕組みを作るのか、
みたいな問いに、今の大きな問いに対して、 もう少し具体な問いを立てたり、
そのために何をすべきかを定義していく。 必要な人を巻き込んでそれを実現していくっていうのが、
ストラテジーと実装を生きさせていくっていうのが 大きな概略かなと思っています。
この他にも、特にソフトウェアの領域だと、 実装って結構ずれていきやすいというか、
小さな改善を積み重ねたり、 何かの機能を追加していくと、
中のコードってすごい不要なコードが多かったり、 非効率なコードが多くなっていく。
その間を、そうするとどんどんスピードが落ちていくので、 そのスピードの落ちを抑えるために、
いわゆるリファクタリングとかリアーキテクチャみたいな形で、 設計とかコードの構造をガラッと変えるっていう処理が必要なんです。
03:05
そういうことを通じて、よりストラテジーが 早く実装できるような状態を作っていくみたいなのも、
この中には含まれていくかなと思います。
今回のメインは、なぜこのストラテジーと実装が必要なの、 実装の位置が必要なのみたいな話をしたいなと思っていて、
それを結構大きく分けて、外的な理由と内的な理由があります。
分かりやすい内的な理由のほうからいきますと、 内的な理由のほうでいうと、
多くの会社って常にリソースの制限があるっていう一つ目の制限と、
もう一つは、そのリソースを使って狙ったような パフォーマンスが必ずしも出せるわけではないという不確実性があると思うんですね。
その不確実性って何から生まれているかというと、
例えばソフトウェアとか、どの産業でも同じですかね。
人が厳選だと思うので、人を何人か、 数人、十人、数百人って集めて、
何か一つのことをやろうとすると、 絶対に摩擦係数が起きます。
その摩擦係数の元って何かというと、 情報量の不一致だったり、スキルの不足だったり、
スキルの不一致だったり、置かれた場所の悪さとか、
あとはそのコワークする人間の間の関係性、 コミュニティとしての健全さみたいなものがあるかなと思います。
例えば情報が揃ってない2人が、 ある一つの意思について議論したときに、
一方はよく知ってるので、 精度の高い回答を生み出せたとしても、
もう片方は情報がないので、 相手が言ってることを飲み込めなかったり、
そこに対して議論が発生して、 ものすごい不要な時間が発生してしまうみたいなのは、
結構分かりやすいかなと思います。 スキルが足りないのも分かりやすいですよ。
例えば明日からマシンラーニングを活用した ニュースアプリを作ってくださいって言われたときに、
どうすればマシンラーニングなんぞやとか、 ディープラーニングなんぞやみたいな人が、
一から勉強し始めるとすごい時間がかかっちゃう、 っていうのも分かりやすいかなと思います。
こういった狙ったパフォーマンスを出すことが必ずしも、 リソースが揃ってたとしてもできるわけでもないし、
リソースってそう簡単に揃えられないっていう不確実性が、 まず内的な不確実性になります。
もう片方の外的な不確実性も、 分かりづらいけど結構たくさんというか、
こっちのほうが要因としては大きいなと思っていて、 まず一つはデマンドというか、
必要とされているものは何なのかを見定めるっていうのが、 これほど難しい事例ってないんじゃないかなと思っています。
06:01
ユーザーってよく言うんですが、 自分の欲しいものを言うことができないんですよね。
それは自分をひるがえてもそうで、 今何欲しいって言われたら、
多分適当なことを答えるとは思うんですが、 その答えが正しい可能性がすごい低い。
なのでしっかり観察をしたり洞察を通じて、 相手の理解だったり世の中を理解するっていうことが必要になります。
それを通じてもう必要なものを見定めるって言って、 すごい科学だけでは追い切れない世界でもあるので、
難しい不確実性の一つだなと思います。
あとは、そもそもその必要性が見定められたとしても、 必要なものの要求水準が高いっていうのも、
今の特徴かなと思っています。
例えば、誰かに送金をするときの手数料をゼロにしたい、 みたいな要求が、
例えば日本人の80パーセントの人が持ってたとして、
今は銀行か何かに送金するとき、 絶対に手数料はかかりますよね。
それを紐解いていくと、全員のシステムだったり、 みたいなものすごいレガシーだけど、
動かしにくいもの。
あるいは法律とか、人権益みたいな形の大きな 参入障壁で守られているものによって、
その体験が形作られていることってのが、
やっぱり今だと残された大きな課題だと思っているので、
そういうものに捉えするってなると、
やっぱりそもそも要求される水準が高くなるっていうのが、 外的な不確実性の2つ目かなと思っています。
今の全員のシステムとか、 そういう話があったと思うんですけども、
3つ目が、あるべき姿を描けたとして、
現在のギャップが分かったとしても、
その理由はAとBとCであるっていう、
そのAとBとCを特定すること自体がそもそも難しいというか、
ものすごい暗黙地だったり、
一部のエキスパートにしか分からない形で 包摂されていることが多いなと思います。
なぜ食品はECであまり変われないのかとか、
なぜさっきの銀行手数料ゼロにならないのかとか、
その理由を突き詰めていったときに、
本質的な部分が何なのかっていうのを、
少なくともデスクトップリサーチだけで 突き詰めるのはほぼ不可能かなと思っていて、
情報収集の不確実性が、
残りの2つを生んでいるかなと、 外的な要因というのを思っています。
ちょっと戻ると、
ストラテジーと実装を一致させるっていうのは、
この外的な要因、外的な不確実性と内的な不確実性、
ちょっと滑舌が悪いので、はっきり言ってみました。
09:01
この2つを自分の責任範疇と置くっていうことだと思っています。
ので、実はプロダクトマネージャーっていう 肩書を持つ人ものすごい増えてきたと、
この3年ぐらいで実感しているんですけど、
僕は本来的にこの2つに責任を持っているような、
マネジメントをちゃんとしているような人って、
ものすごい少ないんじゃないかなと思っていたし、
逆に僕が1つの企業、大きな企業の中で、
PMっていうキャリアを踏んでいったとしても、
このどちらかのすごく一部の部分しか担当できないだろうなと、
それだと自分の能力って10X的に飛躍させるのは難しいなっていう限界を感じたこともあって、
企業を意思決定したっていう側面も10%ぐらいあります。
なので、すごい象徴的なお話が1個あって、
僕がメルカリっていう会社に本当に短い期間なんですけど、
大きな影響を受かせていただいたときに、
当時のメルカリはレッドマインか何かで、
過去の開発チケットを全部マネージしてたんですね。
そのマネージの仕方自体も結構レガシーだなと思ったのはあるんですけど、
僕が入社して一番初めにやったのは、
社内にあったWikipediaの中でビューが多いものをクローリングして、
まず読み漁るっていうことと、
あともう一つはレッドマインのチケットを同じようにクローリングしてきて、
スプレッドシートにブワーって書いて、
それを全部読むっていう、その2個やったんですよね。
そうすると結構重要なチケットの中にとか重要な記事の中には、
やっぱり必ず経営人が出てくるんですよね。
そうじゃないチケットにも出てきてて、
資金調達したり、ホームの整備したりしながら、
プロダクトの細かい物資通知の文言まで口を出すみたいな、
そういうオールグリップな姿勢っていうのに結構影響を受けたというか、
これ素晴らしいなと思って、今がどうか全く別、よく分からないので。
当時、創業から3年、4年ぐらいのタイミングはそうだったよっていう話で、
これこそ何というかプロダクトマネジメントのあるべき姿じゃないかな、
だし、プロダクトをマネージ、何とかするっていうのは、
ここまで多くの事象をグリップしたり、不確実性を確実性に変えていくっていうことに、
12:03
大きな捉えを払わなきゃいけないなっていうのを結構痛感したことあって、
今こういう考えが形成されているような気もします。
ということで、今回はプロダクトマネジメントの役割としての
ストラテジーと実装を一致させるということについて、
またその難しさを形成しているような、
外的な不確実性と内的な不確実性の話をしました。
チームのマネジメントもユーザーのマネジメントも、
全部あなたの責任だよっていう、そういう話ですね。
気に入っていただいた方は、ぜひフォローなどお願いしたいなと。
あとはTwitter上でフィードバックをいただけると、
すごい喜んで全員に反応すると思います。
ではまた。
12:59

コメント

スクロール