前編に引き続いて、楽天トラベルの齊藤満氏、メルカリの伊豫健夫氏、LINEの御代田亮平氏、サイバーエージェントの藤田和司氏、そしてファシリテーターの及川卓也氏による「プロダクトマネージャートークセッション」後編をお送りします。
楽天株式会社 Senior Manager
齊藤 満
株式会社メルカリ 執行役員
伊豫 健夫
LINE株式会社 開発1センター プロダクトマネージャー
御代田 亮平
株式会社サイバーエージェント アドテク本部 アドテクスタジオ チーフプロダクトオフィサー
藤田 和司
Product Manager Conference 実行委員・フリーランス
及川 卓也
各登壇者の詳しいプロフィールはこちら
PMは、あらゆるチームのハブになる
Q4. プロジェクトマネージャーとプロダクトマネージャーの1番の違いは？プロジェクトマネージャーの経験があるのですが、プロダクトマネージャーに転身しようと考えています。
及川：先ほど御代田さんがプロジェクトマネージャーの人を採用してプロダクトマネージャーに育てているとお話いただきました。みなさんを代表して、プロジェクトマネージャーとプロダクトマネージャーの一番の違いについて、「何を学んだり経験すればプロダクトマネージャーに進めるか」お話いただいてよろしいですか？
御代田： 直接そのプロダクトに張り付いて、開発チームや実際のユーザー、さらに言うと社内のセキュリティチームやリーガルチームだとか、そういったものの中心に、というかハブになって仕事ができるかどうかじゃないですかね。
ぼくらのチームであれば、全体的なファシリテートをする部分に関してはプロジェクトマネージャーがすることもあるんですけど、プロダクトマネージャーとなると実際にいろんな人と話して「えいや」とディシジョンをするところまで進めなくてはならないので、そこに大きな違いがあるかなって思います。
実際に「えいや」ってやってみると、意外とできるもんですよ。転身してみたらいいかと思います（笑）
ただ、開発チームやエンドユーザーとだけ関わると思うかもしれませんが、実を言うとそうでもなくて、セキュリティチームやリーガルチームなど思いもよらぬチームとのディスカッションが非常に重要だったりするんですね。
そういった認識というか勘所っていうんですかね、「ここは先にセキュリティチームと全部話してチェックしとかなきゃいけないな」だとか、「リーガルチームに全部通しておかなきゃな」とか、そういうところの勘所ができるかどうかは、直接プロダクトを育てたことのあるなしに関わってくるんじゃないかなという気がします。
及川：これは、スクラムをやっていた場合のスクラムマスターとプロダクトオーナーの違いに置き換えて考えていただくと分かりやすいかなと思います。
あとプロジェクトってスケジュールがあるんですね。初めがあって終りがあると。でもプロダクトをつくっているときって終りが見えてることって少ないじゃないですか。プロダクトの中にプロジェクトがいくつか存在しているってかたちになっていると考えていただくとわかりやすいのかなと思ったりします。
アーキテクチャとPMの分離がスケールを生む
Q5. 規模の大きいアプリ・サービスだと、領域を分解してプロダクトマネージャーを複数配置しても、全体のUI/UXやソースコードが分解できず、複数の施策がコンフリクトしてしまい、スピードの鈍化や施策のサスペンドが多発してしまいがちだと思っています。どういったアプローチでこういった課題を解決していますか？
齊藤： この話には、PM自体のEnd to Endのシナリオのコンフリクトと、あとアーキテクチャのコンフリクトの話の2つが含まれていると思います。
PM自体のコンフリクトに関しては、大きなプロダクトになってくることがありますので、そのときはなるべく「全体の流れとしてはこういうふうになるんですよ」っていうビジョンをきっちりとみんなに指し示して、「その後の詳細はそれぞれ決めていってください」といった話し方をすることで、なるべくコンフリクトが起きないようにしています。
アーキテクチャの話に関しては、開発の中にアーキテクトのような方をきっちり置いていただいて、極力全部のリクワイアメントを見ていただいて、こういうリクワイアメントが全部あるのであれば、こういったアーキテクチャをつくった方がいいねと議論していただくような体制に、楽天トラベルはしています。
それでも問題は起きますが、これで7割から8割方は解けるかと思っています。
伊豫： やっぱり横でコミュニケーションを取ったりだとか、共通でデザインを担当されている方が直接コミュニケーションされたりだとか、そういったコミュニケーションで吸収することって多々あるんじゃないかなと思います。ただ、ぼくもアーキテクチャ寄りの話が本質的なのかなと思っていて、これってコミュニケーションで解決するにも絶対限界があるし、アーキテクチャにちゃんとメスを入れないといけない問題かと。
メルカリの例で言うと、分割の歴史があります。最初はアメリカもイギリスも日本も全部ワンソースで、サーバサイドもクライアントサイドもつくっていたんですけれども、1年くらい前に国ごとに全部分割しました。いまはさらにそこからマイクロサービス化するのを考えていて、そうすることによっていろんなコンフリクトを物理的に解消していきます。
そして、それに合わせた組織をつくっていく方向に持っていかないと、なかなかスケーラブルな組織は作れないかなということを議論しています。そのときに、CTOをはじめとしたアーキテクトのメンバーが重要になってくるのかなと思います。
御代田： ぼくはサーバチームと関わることが多いので特に顕著だと思うんですけれども、弊社でもマイクロサービスのアーキテクチャに切り替えることを積極的にやっています。
そういったサービスに移行して、各開発者がつくりやすいようにオープンスタック上のプライベートクラウドを社内に導入したり、RPCのプロトコルを全マイクロサービス間で共通のサービスを使ったりだとか、そういった異なるリージョンでの開発チームが今５，６拠点くらいあるので、各チームある程度独立して開発できるような環境づくりっていうものを積極的に導入しています。
藤田： 我々のプロダクトもそれぞれ独立しているんですが、最後のレポートやデータをひとところに集めて、何か処理したいときに、共通のサーバサイドと個々のプロダクトやサービスが、うまく連携が取れるかどうかという話があります。
だいたいは対話をしながら対処しているんですが、ぼくたちの会社特有のやり方で「未来会議」とか「理想会議」といわれるような会議体を使って解消しているというのがひとつ例としてあります。関係者を入れて5人ほどのチームをつくって、本当に何か成し遂げたいものがあったときに、ぼくたちはどういうふうにやっていけばいいんだろうねということを話し合い、その中で「これはいい」というものをこの会議体を使って解消することもあります。
やはりPMひとりだと、「どこそこがうまくいかないのはこれが原因だ」みたいなのが見切れなかったりとか、なかなか出てこないこともあるので、こういった現場からの吸い上げのような仕組みを使ってたりもします。
及川：まとめると、アーキテクチャ的なところとそれぞれの組織に付くプロダクトマネージャーの分離が、スケールさせていくのに大事かというところがあったと思います。
ただ、ここでもうひとつ気になるのが、いわゆるソフトウェアと意味ではいいと思うんですけれども、ユーザー体験と言われているところにUI/UXがあり、例えばマイクロサービス化したとしても、そこに流れている何かとマイクロサービスからのフィードが混在されてますと。そこに統一されたユーザー体験の世界観をつくらないといけないといったときに、このUXを誰かが最後見ないといけません。
それはUXのトップの方になるのか、プロダクトマネージャーが責任を持つのか。どちらがいいというのではなく、おそらく組織の中でどういう形で運営されて運用されてますかってことになると思います。みなさまのところで、UXの最後のディシジョンは誰か下しているかを教えてもらっていいですか。
伊豫： メルカリの社内事情でいうと、少し近い将来にたぶん起こりうることになってくると思うんですけれども、例えば非常に重要なパーツの場合は私が各方面と話をしながら最後は決めるべきことなのかなと。
齊藤： これはマイクロソフトでのやり方を引き継いでいるんですが、最終的な責任者となるとPDMのトップですね。楽天だと私になります。基本的には各PMがEnd to Endを考え、昔はビル・ゲイツも参加していた「クラフトマンシップレビュー」に全プロダクトを持ってきて力のある素人にプロダクトをみてもらい、マイクロソフトあるいは楽天トラベルとしてのパーソナリティがきちんと保たれているかについて全体的にフィードバックをもらいます。
そのフィードバックは力を持った人が言うので一旦聞きはするんですが、決定権はありません。フィードバックを持って帰って各PMと話をして、「こう全体を変えたらあなたのEnd to Endは困りますか？」と問う流れです。単純に言うと、まずは縦で決めていくんですけど、次に横で見て、横からまた縦に落としていくというのを繰り返すかたちでUXのコンシステンシーを決めています。
御代田： ぼくのプロダクトの場合、UXというよりDX、つまりディベロッパーエクスペリエンスなのでちょっと趣が違うんですけれども。DXの場合、ある程度簡単な部分があります。開発者に使っていただくものを開発者がつくっているので、最終的なインターフェイスは開発者にとってわかりやすいものをつくります。そのためPMでもコンセンサスが取りやすいというのはあります。
社外でも、例えばネームスペースの使い方だとか、非常に細かい仕様が全部ドキュメントにまとまっていて、それに従ってつくるというふうになっています。特にそのGoogleさんなんかはそういったものを「こういうふうにつくっています」と公開しているんですけれども、似たようなものが社内にもあります。
おもしろい仕事をつくり、自分自身が仕事を愉しむ
Q6. 弊社のPMは製品のデリバリーまで責任を負っています。製品に組み込んでいるミドルウェアの不具合でデリバリーが２ヶ月遅延しています。自チーム都合ではないので残業してリカバリーをするにも士気が落ちてしまっており、どうしたものかと思案しています。あなたならどうしますか？
藤田： これはスケジュールの引き方がおかしいのかもしれないなと思うんですが、自分たちの責ではない遅延は、うまく経営とも話をして、適切なリリースタイミングや仕様の変更をまずはやっていかないといけないのかなと思いました。
こういうことって度々起こるものだと思うので、PMは経営としっかり話をして、適切にゴールラインを引き直すみたいなことをやってあげればいいのかなと思います。
及川：モチベーションを上げるために工夫されていることって、もう少し広く捉えていただいてもいいと思います。例えば、去年ナイアンテックの河合さんがランチセッションで質問を受けたときに言っていたのが、とりあえずエンジニアは焼肉につれていけばいいんだと（笑）
会場： （笑）
伊豫： 「おもしろい仕事をいかにつくれるか」が、組織にとってこれ以上はないカンフル剤といいますか、いい働きかけをするんじゃないかなと思っています。PMのアイデアひとつにしてもそうだと思うんですけども、その人たちの意思決定によっていかに面白い仕事が生み出されるかが決まるというのは非常に重要なディシジョンメイキングの要素だと思うので、ぼくはこの観点をけっこう重視していますね。
それをちゃんと「おもしろいことである」と、「これは全てのお客さんが待ち望んでいることである」みたいに伝えることが大事。これは別に嘘をつくわけではなくて、コミュニケーションのひとつのやり方として、しっかり話したりとか、その先に何が待っているのか、お客様がどのくらい喜んでくださるのかを、みんながイメージしやすいように伝えるっていうことです。
実際におもしろい仕事をつくることを伝えるのは、シンプルですけどすごく難しいことではあるので、常々意識すべきことなのかなと思っています。
御代田： 焼肉的なことなんですけども、弊社の場合はコアのチームが一部福岡にあるので、大きな機能のリリース前には、みんなで福岡に行くという話はよくあります。
齊藤： 私自身が心がけているのは、自分が楽しんでいる姿を見せること。「齊藤が楽しんでいるのは何かおもしろいことがあるんだろう」ってことを、なるべく背中でまず見せようと努力をしています。
それ以外だと、エンドユーザーもしくはカスタマーになるべく接する機会を持つこと、もしくは世の中の動きに接する機会をできるだけ設けるようにしています。例えば海外のカンファレンスに行ってもらうとか、事業的にはあんまり必要ないかもしれないけれども旅行博のようなイベントに出てブースをあえて置いてみて、そこにPM主導でエンドユーザーに自分のプロダクトを使ってもらって、生でどういう声が聴こえるかっていうのを定期的にするようにしています。
社内にこもっていると世界中が敵に見えてくるので、良い声が聴こえることで少しモチベーションが上がると思っています。こういったサイクルをなるべく最低一人一回、世界のカンファレンスもしくは日本のカンファレンスなどのイベントに参加してもらうようにしています。
めんどくさがられる仕事を率先してやる
Q7. プロダクトマネジメントという言葉自体、社内における認識が低い、もしくはないと感じていて、それにより会社全体としてプロダクトに向かうような取り組みができていないのかなと思っております。プロダクトマネジメントを社内に広めるためのアプローチなど、トップダウン・ボトムアップ含めて、ご経験からお聞かせ願いたいです。
及川：みなさん方の組織はプロダクトマネージャーというものがしっかり職種として存在されているわけですけれども、最初はなかったか、もしくはひとりだったりというところから今のかたちまでつくられていると思います。まさに今その初期の段階で、プロダクトマネージャーが認知されていない組織いる方へのアドバイスということで、最後にアドバイスをお願いします。
齊藤： 楽天トラベルでは4年前くらいにPDMチームというのができまして、そのときに私がやったことというのは、PDMがなぜ必要なのか、アメリカの西海岸で特に脚光を浴びているのはなぜか、こういうことに対して私たちは責任を持ちますというのを、ディベロッパー側及び事業部側、あと楽天グループ全体に説明することでした。これまでお話したようなものの10倍くらいのボリュームで、説明して回るのに1ヶ月くらいかかった気がします。
このときの私がラッキーだったのは、上司のCTOがサポートしてくれたこと。自分の経験をもとに「PMとは何か」を、なぜこの会社にとって必要なのかを一緒に説明して回った結果、一旦やってみようじゃないかというような形になり、4年経って曲がりなりにも少しづつ組織ができてきているのかなと。
私どももまだ不完全ですが、みなさんがこういう組織をつくろうとしているのであれば、PMが会社にとってどんなバリューを与えられるのか、プロダクトにとってどんなバリューが与えられて、利益やGMSというかレベニューとか、そういったものにどれだけ影響を与えられるのかっていうのを自分自身で一回プレゼンをつくってみて、近く人でもディベロッパーでも、もしくは事業の近くの方でもいいのできっちり説明していくのが第一歩かなと思います。
伊豫： すごく抽象的な話になってしまうんですが、プロダクトマネジメントを広げるのはけっこう難しいというか、平たく言うと誰よりもお客様の方を向いていて、誰よりもお客様のことを知っていて、お客様を中心にプロダクトにコミットできるという文化を、プロセス面あるいは自分自身の日々の動きも含めて、じわじわ浸透させていくということが何よりかなと思っています。
PMやそれを志す人って真面目な人がすごく多いんですね。ぼくはもっとはっちゃけていいと思うし、さっき楽しい仕事って話もありましたけど、そういう空気をもっと出していくとか、企画をするってことは楽しいことだしワクワクすることのはずだから、やっぱりそこをいかに高めていけるか、より訴えかけていけるかというところが、PMっていう職種の魅力を高めるとぼくはすごく思っています。
そういう雰囲気を演出も含めてどれだけ自分が出せるかは、自分自身に言い聞かせていることでもありますし、みんなやっていくといいかと思います。
御代田： たぶんこの質問を書かれた方は、あんまりPMが会社にいない組織なのかと思っていて。たとえば自分はPMなのに、自分をすっとばして知らないうちに話が進んでいたみたいなことってよくあると思うんです。PMをすっとばした側も、すっ飛ばしたかったわけではなくて、こういったところまでPMってやってくれるんだみたいなこととか、ここまでカバーしてくれるんだという認識があまりないんだと思うんですね。
開発者だけじゃなくて、セールスチームだとかセキュリティ、リーガルチームだとかも、リリースすることが一番うれしいですよね。かといって、リリースにあたってはみんな楽をしたいところってあるじゃないですか。
楽というか、自分の専門範囲だけ注力してやっていたり、その間のめんどくさいこととかをもれなくPMがカバーしてくれると、昔はこんな機能をリリースするのは大変だったのに、なんかスムーズになったなと感じてもらえると思います。
そういうフィードバックがもらえるようになってきたら、浸透してきたって言えるんじゃないのかなっていう感じですかね。もしくはそんなフィードバックがもらえるような仕事をするっていうのが重要なんじゃないかなと思います。
藤田： ぼくがPM的な仕事をするようになったときは、まだそんな言葉がなかったと思っているんですけれども、いま御代田さんの話にもあったように「こんなこともやってくれるんだ」ということを体現していくのが、ひとつ非常に効くのかなと思います。
結局いいものをステイクホルダーも巻き込んでつくっていくっていうのが仕事かなと思うので、こいつこんなところまで出張ってちゃんとやってくれてるんだなということを、行動というか居場所というか、ポジションをちゃんとつくっていくということを、自分はやってきたかなと思います。
今はPMの役割について、ある程度役割分担だとかそういったことが整理されてきて、手法も確立されつつあります。それを宣言し、行動で示していくというのが、最初の一歩として取り組みやすいのかなと思います。
