アイキャッチ

18年間プロダクトマネジメントを生業にして来た男を支える「5%の光」とは~楽天トラベル齊藤満氏の流儀【及川卓也のプロダクトマネジャー探訪】

働き方

    楽天株式会社 ライフ&レジャーカンパニー
    トラベルサービス開発・運用部 トラベルプロダクトマネジメント課
    プリンシパルプロダクトマネージャー
    齊藤 満氏

    プロフィール画像

    Increments株式会社 プロダクトマネージャ
    及川卓也氏

    早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウエア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』などを運営するIncrementsに転職して現職に

    【組織づくり】約30名のプロダクトマネジャーを「3つの職制」に分けてチーム運営を行う理由

    共にMicrosoftでプログラムマネジャーをしていた経験を持つ及川氏と齊藤氏

    共にMicrosoftでプログラムマネジャーをしていた経験を持つ及川氏と齊藤氏

    及川 僕と齊藤さんは一時期、MicrosoftのWindow開発チームで同じプログラムマネジャーとして仕事をしていたんですよ。僕がエンタープライズ系の製品担当で、齊藤さんはデバイス系のプログラムマネジャーでしたね。

    齊藤 ええ、懐かしいですね。

    及川 最初に確認したいのですが、Microsoftで言う「プログラムマネジャー」と、楽天の「プロダクトマネジャー」は同じ意味合いの仕事だと思っていいですか?

    齊藤 楽天全体での意味合いと、私が担当している楽天トラベルとでは、少し意味合いが違う部分があります。楽天は今まさに、グループ全体でプロダクトマネジャーの職責を統一しようとしています。

    及川 なるほど。

    齊藤 でも、今、私がいる楽天トラベルのプロダクトマネジャーは、Microsoftで言うところのプログラムマネジャーとほぼ同じ役割ですね。すごく簡潔に説明するなら、「プロダクトやサービスをディファインして、カスタマーのためになるもの、そして楽天に価値を生むものを作る」のが私たちの役目です。

    及川 「私たち」ということは、楽天トラベルの中に複数名のプロダクトマネジャーがいらっしゃる?

    齊藤 ええ、現時点では約30名弱となっています。楽天トラベルではエンジニアが約130名くらいいるので、開発チームの中でだいたい4人に1人がプロダクトマネジャーをやっている計算になります。

    楽天トラベル

    楽天トラベルのWebサイト

    及川 そんなにたくさんいるんですか! それぞれ、どんな役割で働いているんですか?

    齊藤 楽天トラベルでは、プロダクトマネジャーを3つの役割に分けています。UX担当とイノベーション担当、プロトコル担当の3つです。

    この中で、一番技術力が求められるのはプロトコル担当のPDM(プロダクトマネジャーの略)。例えばXMLのスキーマが書けるとか、 XMLとJSONだったらどっち選ぶべきか? みたいな判断ができる程度の技術力は持ち合わせています。

    及川 この連載の最初に登場してもらったお金のデザインの梶田岳志さんは、PDMのことを「開発補佐」と「コンサル寄り」両方の視点を持つ人と話していたんですよ。梶田さんの言葉を借りるなら、プロトコルPDMは「開発補佐」というわけですよね。じゃあ、UX PDMとイノベーションPDMは何を?

    齊藤 UX PDMは楽天トラベルが展開している既存サービスのグロースを担当していて、イノベーションPDMは未来のサービス構想を考えていく人になります。

    及川 既存サービスを育てるのと、完全に新しいモノを考えるのは両立が難しいですから、うまく切り分けているんですね。

    齊藤 ただ、PDMをUX/イノベーション/プロトコルと3つの職制に分けられるようになったのは、PDM全員を統括できるマネジャーが育ってきたからという背景もあります。ですから、この体制を敷けるようになったのは、つい最近のことなんです。2015年からですね。

    及川 今、PDMをやっている方々の内訳は? そして、皆さんどんなバックグラウンドの方々なんですか?

    齊藤 UX PDM が10人ぐらい、イノベーションが5人ぐらい、プロトコルが5人ぐらいです。バックグラウンドとしては、もともと楽天グループでプロデューサーをやっていた人と、エンジニアからPDMになった人、それと私のような中途入社組の3パターンが多いですね。ただ、中にはセールス出身の人もいたりするので、けっこうさまざまですよ。

    【仕事の進め方】ベストな打ち手を考え抜くために「技術はいったん忘れる」

    楽天トラベルにおけるプロダクトマネジャーの役割を説明する齊藤氏(写真右)

    楽天トラベルにおけるプロダクトマネジャーの役割を説明する齊藤氏(写真右)

    及川 なぜPDMチームのバックグラウンドについて質問をしたかというと、PDMの出自や経歴によって、プロダクトマネジメントのやり方ってけっこう変わるじゃないですか? 例えばMicrosoftだと、プログラムマネジャーをやっている人もけっこうテッキー(techie)な人が多かったですよね。

    齊藤 そうですね。楽天トラベルにも、すごく技術に詳しいPDMはいます。

    及川 他方で、エンジニア以外のバックグラウンドを持っているPDMの人たちはどうやって仕事を回しているのか?と。これは「プロダクトマネジメントあるある」の一つとして、エンジニアは技術に詳しくないPDMにリードされるのを嫌がる傾向があるじゃないですか。

    齊藤 ええ、「技術が分かるPDM」の強みは、私もMicrosoft時代に痛感しました。私自身が、OSのエンジニアリング経験のない人間でしたから。

    でも、ウチでは「プロダクトを作る際はいったんテクニカルなことをすべて忘れるように」とメンバーに伝えているんですよ。

    及川 ほう、興味深いですね。なぜですか?

    齊藤 開発のことが分かり過ぎていると、PDM自らが「ここまでやるのは無理かも」と考えがちだからです。本来、PDMはユーザーインタビューだったりユーザーリサーチの結果を踏まえた上で、ユーザーにとって最もベストなこと、そしてクライアントにとって最良なのは何かを考えてPRD(Product Requirement Document / 製品要求仕様書)を書くべきだと思うんです。そこで技術的な制約を考慮してはいけない。

    及川 PDMが高い要求をすることで、エンジニアチームと「健全な衝突」をしなければ良いモノができないと?

    齊藤 そう思います。私がMicrosoft本社で働いていた時、こんなやり取りがあったのを思い出します。私の作った担当製品のプログラム仕様を見せたら、エンジニアにこう言われたんです。「お前、ディベロッパーをナメてんのか」と(苦笑)。

    及川 「ソフトウエアに不可能はない」ってヤツですね。

    齊藤 ええ、かのデビット・カトラー(編集部注:名著『闘うプログラマー~ビル・ゲイツの野望を担った男たち』でも知られる、Microsoft Windows NTなどの開発設計者)の言葉そのものです。

    当時は「もしこんな中途半端なモノを開発させて、ユーザーに受け入れられなかったら、お前はエンジニアになんて言い訳するつもりだ?」と言われました。そういう経験を何度かしていくうちに、PDMは技術的な制約を意識してはいけないと強く思うようになったんです。

    ですから、今はPRDを作成する際、先にPDMのチームメンバーだけで「本当にこのUX、このプロトコルがベストなのか?」を議論してから次のステップに行くようにしています。

    及川 PRDを作成する段階では、エンジニアチームの意見は聞かないんですね。

    齊藤 正確には、開発におけるウィッシュリストをエンジニアも含めたチーム全員に開放しているので、そこから意見を吸い上げたりはしていますが。エンジニアチームには、我々が作成したPRDから【Devスペック】と【テストスペック】のドキュメントを作成します。

    この際、エンジニアチームには、「できないと考えず、PRDの内容を実現するために力を尽くしてください」、「できないようであれば、開発フローや環境を考え直すから」という風にお願いをしているんです。

    及川 ここでも、「ソフトウエアには不可能はない。唯一あるとしたら、それはリソース的な制約なんだ」というカトラーの金言をベースにしているわけですね。

    齊藤 そうです。

    及川 ちなみに、以前、ある企業のCTOに「プロダクトマネジャーはPL(損益計算書)も見るべき」と言われたことがあるのですが、楽天トラベルではいかがですか?

    齊藤 本質的には見るべきだと思っています。ただ、楽天トラベルでは、まだそこまでできるPDMが育っていないというのが現状です。

    少しずつやり始めてはいるものの、マーケティングやセールスから見たら、数字の取り方も予想の仕方も甘い。ですから彼らに教えてもらいながら学んでいるところです。

    及川 もう少し細かく聞きます。具体的なプロフィットとロスで言うと、どこまで見ることを期待していますか?

    齊藤 私たちはGMSと呼んでいるんですが、ある機能をリリースしたことで起こる、売上や利益への影響度を見るべきだと言っています。

    及川 なるほど。事業全体のPLを見るとなると、セールスの売上やそれに紐づくコストなどとPDMの範疇を超えてしまう部分も出てきますから、あくまでもサービスやプロダクトに限定するというのは理に叶っていると思います。

    でも、ユーザー体験を良くすることが、必ずしもプロフィットにつながらないこともありますよね?

    齊藤 そう思います。そこは私も悩みのタネです。私の中では、自分が本当に使いたいと思えるプロダクトを考える脳みそが全体の9割。ですからまだ、プロフィットを考えるのは、試行錯誤中という他ありません。

    及川 四半期ごとにそれを見るのか、それを2年間猶予を持たせてくれるのかによっても違いますしね。

    齊藤 確かに、そう思います。

    及川 もし2年間猶予があったら、ひたすらユーザー体験を良くしていけば結果は付いてくることを証明できると思いますが、四半期で見られてしまったらおそらく証明することはできないでしょう。かといって、短期的なプロフィットを求めれば、長期的にはユーザーが離れていくリスクもある。

    齊藤 はい。まさにそこも現在進行形で悩んでいるところです。おっしゃる通りPLを見過ぎると、現状の延長線上にあるようなアイデアしか出せなくなってしまいますし。

    及川 バランスの取り方が難しいですよね。

    齊藤 はい。試行錯誤の連続です。

    1. 1
    2. 2

    Xをフォローしよう

    この記事をシェア

    RELATED関連記事

    RANKING人気記事ランキング

    JOB BOARD編集部オススメ求人特集





    サイトマップ