なぜタクシーアプリGOではPdMが十数名も所属しているのか?
以前在籍していたタクシーアプリGOについての記事です。
現在は所属していませんので記載当時の情報としてご理解ださい。
最新情報はGO株式会社までぜひ問い合わせをしてみてください!(多分歓迎されます!)
こんにちは、フリーランスでプロダクトマネージャーをしている @go-go-pdm と申します。
https://twitter.com/go_go_pdm
今日も「プロダクトマネージャーブログリレー2022@MoT」の一環でブログを書きます。
今回はGO株式会社(旧MoT)におけるPM組織・制度について取り上げようと思います。
タクシーアプリGOにおけるPdMの人数と役割分担
まず初めに、GO株式会社はタクシーアプリGOをメインに、複数の事業・サービスを展開しています。
ご想像通り、タクシーアプリGOにアサインされるPdMが大半となりますが、GO以外の事業・サービスにアサインされているPdMもおります。
(GO DineやDRIVE CHARTなど)
上記の前提で、PM組織の説明を続けます。
タクシーアプリGOのPM組織は以下の図のように、開発本部や事業本部(Bizサイド)と並列した組織体となっています。
通常、開発組織や、事業本部の中にPdM組織が入っていることが多いと思いますが、タクシーアプリGOではそうでないことから、
会社としてプロダクトマネジメントを重要視している、ということが言えるかと思います。
PdMは十数名おり(22年1月時点)、上記の図はタクシーアプリGOでのプロダクト・役割分担を示す用語(説明後述)で表されていますが、
先述の通り、タクシーアプリGO以外のサービスを担当しているPdMもいます。
特徴的なタクシーアプリGOのPM組織
もう一度先程のPM組織図を見てみましょう。
PdM組織の中に、PjM、デザイナー、データアナリスト、UXリサーチャー、QAが存在しています。
これらの役割の方々とは別組織になることが一般的かと思いますが、
タクシーアプリGOでは同じ組織に所属しています。
なぜデザイナーたちとPMが同じ組織か?
PM部門のトップである黒澤が、他メディアでのインタビューでも述べていますが、
「多様なスペシャリストと協働し、プロダクト開発に専念できる環境」
を組織作りの根幹としているために、PdMだけが属さない組織となっています。
PdMというのは、スペシャリティとしては他の専門家に劣るケースが多いかと思います。
ビジネスのことであれば、Bizdevやマーケの方の方がより専門的でしょうし、開発ならエンジニア、UXならデザイナーの方が専門的です。
確かに、元がエンジニア出身のPMです、という話なら、エンジニアとしての専門性も高いかと思いますが、もしPMに転向して数年経って、最近コードを書いていないという状況にもなれば少し話は変わると思うのです。
さて、そんな中でも総体として良いプロダクトマネジメントをするのは?という答えの一つとして、GO株式会社では、「スペシャリストを結集する」ということをしているのです。
いわば、プロダクトマネジメントトライアングルを「組織」という単位で捉えています。
そのために、上流工程に関わるようなメンバーの大半がPM本部に結集しています。
スペシャリストが集う組織のメリットは?
メリットとしては以下を挙げることができるかと思います。
① POが部門トップなので意思伝達と指示がしやすい
ー 上流工程に絡むメンバーが同一組織で、視座が一致しやすい
ー 会社の状況や、各施策のコンテキストが理解されている
ー PO(弊社では黒澤)が役割分担と業務指示を出せる
②協働と役割分担しやすい
ー 同一部門なので相談しやすい
ー 役割分担がしやすい
この組織体制に至るまでの経緯
上記のような形で、PdMがPdMとしての責務を果たせるようにするために、
餅屋の召喚を続けた結果、このような組織体制になっていきました。
もちろん、今の体制に向かうほどに、PdMとしての業務負荷は軽減され、より顧客体験や顧客価値の創造に重きを置くことができるようになったと私は実感しています!
なぜ十数名ものPdMが必要なのか?
ようやく本題ですが、まず以下の前提をお伝えする必要があります。
話としてイメージしやすいかと思うので、タクシーアプリGOのプロダクトマネジメントを例とします。
① タクシーアプリGOは複数のプロダクト・コンポーネントが合わさり1つの「GO」というサービスになっている
上記のブログでも弊社の脇水が述べていますが、
タクシーアプリGOは、
・ 一般ユーザ向けのスマホアプリ(ToC)
・乗務員、タクシー事業者向けのアプリ(ToB)
などが合わさり、実現できているサービスとなります。
そのため、「プロダクト(アプリ)」は複数存在し、それぞれにPdMを配置する必要があるのです。
まずこれが1点目でした。
② Epic(機能の集合体)単位でのリリースが続いている、かつその量が相当多い
弊社においては、新規と開発のバランスはだいたい以下くらいのイメージかと思います。
それの理由として、以下のグラフをご覧ください。
利用回数(アプリでタクシーを呼んだ数)というのは右肩上がりで推移し、200万回/月利用というところまで来ています。
一方、200万回/月利用、というのは、全国のタクシー利用回数における、2~3%程度しか占めていない状況です。
言い換えれば、タクシーに乗る際に、アプリで呼んで乗ることはまだまだ超マイナーな行為であり、
道端で手を挙げて乗り込んだり、駅から乗り込んだりする方が、タクシーの乗り方としては一般的なのです。
つまりタクシーアプリGOの伸び代はめちゃくちゃある
ということになります。
マーケティングを促進するような機能も必要ですし、
もっとユーザの方に利用いただくための機能も必要ですし、
やることとしては山盛りな状況です。
結果、数ヶ月単位でのロードマップは上記のようにパンパンに詰まった状況となっています。
そのような状況では、これらを推進するPdMが相当数必要になるとご理解いただけるかと思います。
そしてこれだけの量をこなせますので、必然としてPdMのスペシャリティは磨かれると思っています。
タクシーアプリGOの開発スタイル - LeSS
タクシーアプリGOではさまざまな開発スタイルを導入しており、プロダクトやサービスによって形態はさまざまなのですが、
一般的にLeSS(大規模スクラム)を導入しています。
LeSSの導入に至った背景や、どのように運営しているかなどは以下のブログをご確認ください。
PdMとPMMとPjMの役割の違い
先程の組織図を見て、PdM以外にも似たような職種として、
・PMM
・PjM
がいることに気づいた方もいらっしゃるかと思います。
タクシーアプリGOにおいてはざっくりの以下の区分けをしています。
もちろん、多少重なる部分やカバーし合う部分はあります。
PdMは「プロダクトの価値」の最大化に責任を持つ
PjMは全体のリソース管理に責任を持つ
PMMは「PL」に責任を持つ
と考えていただければ良いかと思います。
よくPjMの業務についてご質問いただくので、もう少し解説をすると、
先程も図を出したように、MoTでは「新規」の大きな開発が複数ラインで、かつ複数プロダクトにまたがって開発が進むことが多いです。
そうなると、
ー 新規案件同士の前後関係の調整
ー 平行している新規案件のリリースタイミング調整
を専門で行う役割が必要になります。
そのためにPjMが日々活動している、とイメージしていただければです。
また、PMMとどのように関わりを持っているかは以下の図をご覧いただければです。
このように、プロダクトのストラテジーとロードマップにおいてMoTではPMMとPdMが協力し合うようになっています。
タクシーアプリGOのPdMの一日
カジュアル面談などでご質問いただくことがありますので、簡単に紹介します。
このような形で、そこまで他の会社さんでのPMとやっていることは変わらないのでは?と思います。
一方、雑用みたいな仕事が少ない、というのに気づいていただく方も多いのではと思います。
プロダクトマネージャーは何でも屋でも雑用でもない!
上記の絵にも熱く記載をしましたが、
プロダクトマネージャーの仕事は基本的には「ユーザが得られる価値の最大化」
かと考えています。
もちろん、それが売り上げに直結したり、影響したりすることが前提とはなりますし、
事業やプロダクトのフェーズ次第では「顧客価値の最大化」よりも、PMFを達成することがPMの目標になることもあるかと思います。
売り上げに関わる、責任を持つ、ということならば、PdMの仕事の範囲として納得ができますが、
そうではなく、
ー 開発者がやりたいくないことを代行する
ー ビジネスと開発のトランスレーション
だけは、PdMの仕事ではないですし、
タクシーアプリGOにおいてもそれだけが仕事になることはありません。
この記事が気に入ったらサポートをしてみませんか?