Vol.143

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

  • このエントリーをはてなブックマークに追加

【連載】及川卓也のプロダクトマネジャー探訪

昨今、日本でも注目度の高まっているプロダクトマネジャーの仕事。しかし、業界内における人数の少なさから、その職責やジョブディスクリプション、どうすればプロダクトマネジャーになれるのかetc...といった部分はまだまだ不明確だ。そこでこの連載では、MicrosoftやGoogleで長くプロダクトマネジメントのスキルに磨きをかけてきたIncrementsの及川卓也氏を聞き役に迎えて、各社のプロダクトマネジャーが日々行っている業務や、愛用しているツールを紹介しながら仕事ぶりに迫る。

第2回となる今回は、楽天トラベルのPrincipal Product Managerである齊藤満氏に話を聞いた。

日米のMicrosoftで通算15年、楽天に移って3年間「プロダクトマネジャー」を務めてきた齊藤氏の、仕事の流儀とはどのようなものなのだろうか。

■組織づくり
■仕事の進め方
■よく使うツール
■スキルを伸ばす方法

という4つの軸で、齊藤氏の持論を紐解いていく。

楽天株式会社 ライフ&レジャーカンパニー
トラベルサービス開発・運用部 トラベルプロダクトマネジメント課
プリンシパルプロダクトマネージャー
齊藤 満氏商社勤務を経て、1998年にマイクロソフトの日本法人に入社。Internet ExplorerやOutlook Express、Windows Millenniumなどのローカライズを経て、通信規格の仕様策定を担当するエバンジェリストとなり、国内メーカーと本国の開発部隊をつなぐ役割を果たす。2006年に米MicrosoftのWindows Divisionに移り、2013年からは楽天に所属。現在は同社にて楽天トラベル開発の担当をしてプロダクトマネジメントを行っている

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人がプロダクトマネジャーをやっている計算になります。

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

齊藤 楽天トラベルでは、プロダクトマネジャーを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
この記事が気に入ったらいいね!しよう

エンジニアtypeの最新情報をお届けします
  • このエントリーをはてなブックマークに追加

RELATED POSTS関連記事

JOB BOARD編集部おすすめ求人

この記事に関連する求人・キャリア特集

  
エンジニア転職フェア開催 IT&モノづくりエンジニアを求める優良企業が大集結!

AIU損害保険株式会社/富士火災海上保険株式会社[合同募集] 社内シ…

株式会社エムズワークス ITエンジニア/Web系・オープン系・汎用機…

株式会社ボールド 開発エンジニア◆5年毎の勤続手当で最大200万円…

株式会社ウィクレソフト・ジャパン インフラエンジニア◆外資系IT企…

株式会社アリーナ・プロフェッショナル 汎用機系エンジニア(COBOL)…

サッポロビール株式会社 【生産技術担当】サッポロブランドを生産…

株式会社ドコモCS 電波調査員 ★7200万ユーザーが利用するドコモ…

株式会社テクノプロ テクノプロ・デザイン社 機械・電子設計/CAD…

トーテックアメニティ株式会社 機械設計エンジニア◆大手メーカープ…

株式会社デンソー 【東証一部上場】 品質保証◆エンジニアを目指した…

「マネジャーがコードを書けない」は言い訳だ! 伊藤直也×柄沢...

データアナリストになる方法~コンサル型かエンジニア型か?ビッ...

採用は売り手市場も、5年後の安泰はなし~若手SEが知っておく...

生涯「エンジニア」として食っていくには何が必要?及川卓也氏×...

なぜ、いまだ7割のITプロジェクトが失敗するのか? 「再生人...

>>過去のエンジニアtypeのページはこちら

typeメンバーズパーク