プロダクトマネージャーに訊く #6：スマートニュース渡部さん
― まずご自身について教えて下さい。
スマートニュースの渡部です。SmartNewsにはニュースと広告という2つのプロダクトがあります。それぞれ開発体制もサーバーもコードも全く別のプロダクトで、私は広告プロダクトの『SmartNews Ads』の責任者としてプロダクトマネジメントを行っています。
私がスマートニュースに入社したのは、2年ほど前の2014年9月です。当時のスマートニュースはこれからマネタイズをしていこうというフェーズで、私を含めて5人ほどの開発チームで広告プロダクトをゼロから作りました。現在は10人ほどのメンバーでSmartNews Adsを開発しています。
SmartNews Adsの最大の広告配信先はSmartNewsですが、その他の媒体にも広告を配信しています。
― スマートニュースに入社するまでの経歴を教えて下さい。
新卒でNTTコミュニケーションズに入社しました。もともとエンジニアとして採用されたのですが、最初の配属先は営業部門でした。営業の仕事はとても楽しかったのですが、エンジニアのキャリアを歩みたいと思い、転職することにしました。
転職先のグラファイトでは、エンジニアとして受託開発の仕事をしていました。当時グラファイトはまだ規模が小さかったこともあって、自分で営業して案件をとってくるところからが私の仕事でした。その後、ニフティに転職してエンジニア専業の仕事につきました。ニフティ時代にとても良い先輩に出会い、「良いコードとは何か」「チームで良いコードを書くにはどうすべきか」といったエンジニアとしての基礎を叩き込んでもらいました。
ニフティはエンジニアとして成長できる環境だったのですが、インターネット業界の盛り上がりをみて自分もそこで戦いたいという思いが強くなり、GREEに転職しました。
GREEには4年間在籍して、前半の2年は現場のエンジニア、後半の2年はマネジメントを経験しました。最後の1年間は事業責任者兼開発責任者として、新しいブランドのゲームスタジオを立ち上げました。新スタジオではモノづくりとビジネスづくりを両方やらせてもらい、一定の成果をあげることができました。
― スマートニュースに転職したのはどういう理由だったのでしょうか？
マネジメントポジションになると、どうしても複数のプロダクトラインを見る必要がありました。その職務の中で各プロダクトへの予算配分やP/Lのポートフォリオを組むようなことはあっても、自分でゼロからプロダクトやビジネスを作っていくという、GREE創業期の頃のような体験をしてみたいと思うようになりました。
自分でビジネスを作っていきたい、そして、どうせやるなら「私が稼がないと会社が倒産してしまう」というくらい強いプレッシャーを感じて仕事をしたい。そうしたチャレンジができる環境を探している時に出会ったのがスマートニュースでした。
― 渡部さんの役割の範囲を教えて下さい。渡部さんがプロダクトマネージャーで、他に開発マネージャーやスクラムマスター的な人がいるのでしょうか？
全て私が兼任しています。大きな会社だとプロダクトマネージャーとエンジニアリングマネージャーとスクラムマスターを別々にアサインすることが多いのかもしれませんね。SmartNews Adsはプロダクトの立ち上げフェーズだったこともあって、自分がそうした役割を全て引き受けることにしました。
広告もニュースもエンジニアリングが差別化要素になるサービスだというとこともあって、スマートニュースではエンジニア出身者がプロダクトマネージャーをやる方針にしています。私は現在進行形でエンジニアのつもりですし、エンジニアだからこそプロダクトマネージャーもエンジニアリングマネージャーも兼務できます。
― そうすると、今でもコードを書かれているのですか？
プロダクションコードは書いていません。エンジニアリングマネージャーはタスクをアサインする権限があるので、自分自身に技術的にチャレンジングなタスクをアサインしたくなります。ただマネジメント業務とエンジニア業務を兼任すると、どうしても自分がボトルネックになりがちです。
特にインターネットサービスはリリース後に運用しながら改善を繰り返して成長させていくものですし、障害が発生したときに即応できない人間はプロダクションコードを書かない方がいいのです。ですから、プロダクトマネージャーなどマネジメントロールに付いている時は、基本的にプロダクションコードを書かないようにしています。
ただ、コードを書きたいという欲求は強いですね。
― それはエンジニアとしてジレンマを感じてしまいますね。
プロダクションコードは書きませんが、プロトタイプは自分で手を動かして作ります。
最近のインターネットサービスは、カバーしなければいけない技術分野が非常に幅広い。一つのサービスが、AndroidやiOSなどのアプリからサーバーサイドやインフラ、さらには機械学習をはじめとしたデータサイエンスなど、複数の技術によって一つのサービスができあがっています。
私の立場ではそれぞれの技術についてエンジニアと対等に議論できる必要があります。そのため、最新の技術やスマホOSの新仕様にキャッチアップできるように自分でプロトタイピングして、新しい技術で未解決課題を解決できるか確認するようにしています。自分でもうまくいくか確証がないR&D的要素が強い試みの場合は、サーバーとクライアントの両方のコードを書いてみます。プロトタイプが期待どおり動くことを確認した後で、エンジニアチームで開発してサービスに取り入れます。
また、専任のアナリストがいるわけではないので、プログラムだけでなくSQLも自分で書いてデータ分析しています。
― 役割の範囲が広いですね。
プロダクトの成功確率を上げるために必要なことであれば何でもやる、というスタンスです。仕事の範囲を限定せず、良いプロダクトを作るために自分はどういう役割を担うべきか、と考えるのがプロダクトマネージャーの役割だと思っています。
「コンテンツとしての広告」で価値ある情報を届けたい
― SmartNewsというプロダクトを通じて、どのような価値を提供したいと考えていますか？
ニュースサービスとしてのSmartNewsについてはご存知だと思うので、広告プロダクトについてお話ししますね。SmartNews Adsのステークホルダーは大きく分けるとメディア、広告主、ユーザーの三者がいます。それぞれに価値提供できるプロダクトを作っていきたいと思っています。
各メディアにコンテンツを提供いただくにあたり、レベニューシェアの仕組みなども用意していますので、メディアさんに高い収益をお返しできるようにしたいです。今月や来月といった短期的な収益ではなく、長期で見た時のトータル収益ではどこにも負けない、と言えるようにしたいと考えています。
広告主に対しても当然成果でお返しする必要があります。簡単に言うと、広告に1万円投資して1万1000円の利益があがったら出稿し続けてくれますよね。広告費のROIが可視化できて、かつ高いROIを実現できる広告サービスを提供する必要があります。
そしてユーザーに対する価値提供も大切にしています。広告はユーザーから嫌われることも多々あり、特にインターネット広告を邪魔だと思う方が多いように感じます。これは広告に関わる人間として非常に悲しいことです。スマートニュース社内では『Ads as Content』と言っていますが、私たちは広告もコンテンツだと思っています。SmartNewsはユーザーに価値ある情報の発見機会を提供したい。それは広告であっても同じです。もちろん広告であることは表記しつつ、新しい発見に繋がるコンテンツとして捉えていただけるような広告を提供したいと思っています。
ハッとするほど面白くて見入ってしまうような広告クリエイティブもたくさんありますし、広告を通じて「ああこういう商品やビジネスがあるのか」と知ることが個人的にもよくあります。コンテンツとしての側面を伝えつつ、かつユーザーの操作を邪魔しない形式でどう広告を表示するのか、という点には特にこだわっています。
良いプロダクトを作る秘訣は、成功から逆算すること
― 良いプロダクトを作るための定石として意識していることがあれば教えて下さい。業界や分野を超えて、良いプロダクトを作るために共通する考え方はありますか？
一番大事なことは『成功から逆算すること』です。チームにはいつも「当たったら勝てることをやろう」と話しています。麻雀の例で説明すると、「最終局で一発逆転して1位とりたい、でもトップと1万点差がある」という時に5000点で上がっちゃダメですよね。スタートアップ企業だと切実な問題としていつまでに成功していないと事業を継続できない、という期限があります。例えば、１年後に1億円の売上が必要であれば、それを実現するために今何をしなければならないのかを考えます。
ゴールから逆算せずに、「できること」を積み重ねていってしまうと失敗します。「最終的にこういうタワーを作りたい」というゴールから逆算して計画せずに、下から積んでいくとジェンガになってくるんですね。「倒れそうだからここに積もう」「次はこっちに積もう」となって最終的には崩れてしまいます。
マクロな視点で市場を見て、どんなプレイヤーがどれくらいの事業規模で、どれくらいの売上なのかといった調査をすると、目標達成のために１年後にその市場で目指すべき事業規模やポジショニングが見えてきます。そこから逆算してどんなプロダクトが必要なのか明らかにする。これが一番大事なことだと思います。
― でも収益というのは自社にとってのゴールですよね。
もちろん自分たちが作りたいものを作っているだけではうまく行きません。「誰のどんな課題をどう解決するのか？」を明確にすることが大事で、その結果として収益が生まれます。
「広告主はなぜSmartNewsに出稿するのか」「ユーザーはなぜ他のニュースアプリではなくSmartNewsを使うのか」といったように、誰のどんな課題を解決するのか、各ステークホルダーに最終的に提供したい価値を定義することが重要です。
SmartNewsの広告事業の場合、広告配信事業者、メディア、アプリユーザーの三者がいて、さらに広告代理店や広告主がいる。短期的には各プレイヤーの利害相反が起きる場合があります。短期的には三者の利害が相反するようなケースがあっても、自分たちが最終的に提供したい価値が決まっていれば、ステークホルダーの皆さんの理解を得ながら多くの人が満足できる解に近づいていくことができます。これはBtoBでもBtoCでも同じことだと思います。
― ユーザー課題を理解するために日常的に心がけていることはありますか？
色々な人の話を聞きに行くようにしています。例えば「今度こういう機能を考えているんだけどどうだろう？」と自分のアイデアを広告のセールス担当に話すと、「最近はこういう広告商品の方が人気がある」「それならこういう見せ方に変えればどう？」といったように何らかのリアクションがあります。とにかくステークホルダーをアクティブソナーだと思ってPingを打ち、帰ってくるものを確認しながらプロダクトマーケットフィットに近づく方向を模索します。もちろんインターネット上でも情報収集はしますが、そうしたオフラインの声を集めながら、業界やプロダクトを俯瞰して見ることがとても大事だと思っています。
― そうしたアイデアをプロダクトとして実現するために、開発チームとはどのようなコミュニケーションをしていますか？
「成功から逆算する」ということと通じるのですが、「1年後にこうなっているためには、この四半期でここまで到達する必要がある」「こういう機能があればその状態に到達できる可能性が高いと思っている」というように、ゴールから逆算して今何を作るべきかを開発チームに正しく伝えるようにしています。
そのときに大事なのが「How、WhatじゃなくてWhyを書く」ということです。エンジニアはコードのコメントには「Whyを書け」と言われます。何をするか、どうやってやるかはコードに書かれており、良いコードはコメントで説明しなくてもそれは分かります。一方で「なぜこの処理をここで必要なのか」という背景情報はコードからは読み取りにくい。
同様に、プロダクトマネージャーは「なぜこの機能をつくるのか」を説明する必要があります。例えば、「売上を10％上げる必要があって、この機能は売上を5％上げる可能性がある」「その理由は、○○というお客様のニーズが増えていて市場のトレンドともマッチしている。」「だから☓☓というサービスを提供すれば対価を支払ってくれるだろう」といったロジックを整理してドキュメントにして共有します。その上で「本当にそうなのか」「仮説が間違っていないか」などエンジニア全員で納得行くまで議論します。
― 議論の過程で渡部さんがたてた仮説が変わることもありますか？
仮説は頻繁に変えます。エンジニアにも「朝令暮改を恐れないようにしよう」と言っています。「ここまで作ったのだから」とか「ここまで議論したのだから」という『サンクコストの呪縛』にとらわれてはいけません。
今日の自分は昨日の自分が知らなかった情報を得ているのですから、少し賢くなっているはずです。決断した翌日に問題に気づいたとして、その時すぐに方針を変えれば1日分しかロスで済みません。これが1週間様子を見て「やっぱりダメだった」ということになると、1週間分のロスになってしまう。だからダメだと思ったらすぐに変えるようにしています。
判断ミスをしたら減点されてしまうカルチャーの組織もあるかもしれませんね。でも私たちのようなスタートアップは、プロダクトが成果を出さなければ、会社が立ち行かなくなるかもしれない。そういう緊迫感のある環境を求めてこの会社に集まっています。より良いプロダクトを作るためであれば、方針を変えることに納得してくれます。
ただ、自分の判断ミスについては素直に謝ります。昨日の自分がベストな答えを出せなかったのは事実ですから。もちろん失敗続きだと「また変えるのか、この前も途中で変えたじゃないか」と信頼を失ってしまいますから、成功確率をあげていく必要はあります。
プロダクトでビジネスを成功させることでエンジニアを幸福にしたい
― 渡部さんがマネジメントの重要性を意識するようになったきっかけは？
GREEでマネジメントを経験したことが大きな転機になりました。
昔は「技術で食っていくんだ」という強い拘りがあり、頑張って技術を磨いていました。「技術で突き抜けていくのが一番格好いいんだ」と思っていたのです。そんな中、GREE時代にアメリカに赴任してグローバルなゲームプラットフォームの開発に携わった際に、向こうのエンジニアと一緒に机並べて働いてみて大きな衝撃を受けたんです。
日本にいた時はシリコンバレーに対して漠然とした憧れを持っていて、「アメリカのエンジニアはきっと相当レベルが高いんだろう」と思っていたんですが、私の目からみるとあまり大きな差がない。日本にもシリコンバレーのエンジニアより優秀な人材がたくさんいるんだということを再発見して、「あれ？」とちょっと拍子抜けしました。
ただ、プロダクトがリリースされた後に商売がうまく回る確率はアメリカのチームのほうが高いように見えました。これは何なんだろう、と不思議でした。アメリカ人の同僚や友人でマネジメントに関わる人達と話してみると、エンジニアとしての能力は負けていなくてもマネジメントのスキルがすごく高い人がいることがわかりました。彼らと話すなかで、「一部の優秀なエンジニアが頑張れば、良いプロダクトを作れる」と考えていた私も、組織として成果を出すにマネジメントが重要であることに気づきました。
― 技術力以外の要素の重要性を実感したのですね。
はい。GREEで痛感したことが2つあります。一つは、エンジニアリングによるアウトプットで商業的に成功しなければ、関わったエンジニアはハッピーにならない、ということです。頑張って作ったプロダクトでも、事業としてうまく行かなければ努力は評価されないし、悔しい思いをすることになる。エンジニアリングやプロダクト・アウトで勝負するのは、事業としてはオプションの一つでしかありません。プロダクトで成功できなければエンジニアを取り巻く環境は悪化していきます。
もう一つは、エンジニアが商売を作れないとエンジニア組織の代弁者としてエンジニアの主張を通すことはできない、ということです。インターネット業界はダイナミックですごく面白い業界です。そのインターネット業界を支えるエンジニアをもっとハッピーにしたい。でも「エンジニアがより良いものを作れる環境にしよう」と主張しても「それでどれだけ売上があがるの？」という問いに答えられないと会社を動かすことはできません。
― プロダクトによるビジネスの成功とエンジニアの幸せは直結しているということですね。
そうです。プロダクトによってビジネスを成功させた体験の中でこそ、エンジニアは成長できると思っています。ですから一緒に働くエンジニアのためにもプロダクトを絶対に成功させたい。
私のチームのエンジニアは皆んな優秀ですから、フリーランス・エンジニアとして興味を持った案件だけを選んで稼ぐこともできるのです。だからこそ、個人で仕事をするよりも成長に繋がる環境を提供して市場価値を高められるようにしないと、彼らにとって私の存在価値は無いと思っています。
エンジニアのキャリアとしてのプロダクトマネージャー
― 渡部さんは何度かの転職を経て、大きくキャリアが変遷して行ってますね。
そうですね。エンジニア出身のプロダクトマネージャーとして、私がエンジニアの皆さんに伝えたい事は「積極的に次のキャリアを考えてみませんか？」ということです。私がエンジニアを始めた頃は、Webの申込フォームを作る仕事でお金を稼げていたんですが、そういう仕事ってもう存在しないですよね。エンジニアが生き残っていくには、専門的で高度な技術を突き詰めていくか、事業会社の中で事業貢献に繋がるアウトプットが出せるか、どちらかの方向で成長し続けるしかないと思っています。
事業貢献志向のエンジニアの方は、プロダクトマネージャーを目指してみてはどうでしょうか。私は今でも本職はエンジニアのつもりですし、自分の一番得意な分野は技術マネジメントだと思っています。得意領域でさらに成果を出すためにプロダクトマネージャーや事業責任者をやっています。
― 渡部さんご自身はプロダクトマネジメントをどう学ばれたのですか？
プロダクトマネジメントはまだ体系的に整理された分野ではないので、実際のプロダクト開発のプロセスの中で身に着けていきました。GREEで幸運だったのは、エンジニアがプロダクトを考える文化だったことです。エンジニアは企画されたものを作れば良いというわけではなく、どんなゲームがユーザーに受けるのか考えながらプロダクトを開発していました。尊敬できる優秀なゲームデザイナーと議論しながらプロダクトを開発していたので、そうした過程でプロダクトマネジメントについて色々と学ぶことができました。
また事業責任者として企画をレビューするために、競合プロダクトについて相当研究しました。GREEのプロダクトはゲームでしたから、有名タイトルは一通り徹底的にプレーしました。ユーザー視点でプレーしつつ、作り手の視点でそのゲームの戦略や技術的に優れている点を分析するのです。
新規プロダクトは不確実性が高く、どれが当たるかはわかりません。ただ、企画の評価や競合の研究を繰り返していると、「こういう方向性は失敗する」とか「この企画は絶対うまくいかない」といった避けるべきパターンは見えてくるようになります。
― プロダクトマネージャーにはそうしたパターンを見抜くためのセンスが求められますね。
私は「センスとは磨くものだ」と思っています。ゲームであれば上位タイトルを全てプレイする、メディアサービスであれば良いコンテンツに触れ続ける。こうしたことを続けていく中で、センスは磨かれていきます。業界が変わればユーザーの要求も変わるので以前と同じパターンは適用できませんが、新たなパターンを勉強すればいいのです。
― エンジニアのなかでもプロダクトマネージャーに向いている人と向いていない人はいるのでしょうか？
できない人はいないと思いますが、できないと思い込んでいる人は多いかもしれませんね。
エンジニアは知識を積み重ねていくことでスキルを向上させることができます。ある程度は努力に比例した見返りがある。一方で、知識量ではなくクリエイティビティで勝負しなければいけない分野になると「自分にできるだろうか」「自分にはセンスがないんじゃないか」と不安に思うエンジニアも多いんじゃないかと思います。ただ先ほども言いましたがセンスは磨けばいい。
エンジニアとして難しい技術を体得するための頭脳があって努力ができる人であれば、プロダクトマネジメントも当然できると思っています。もちろん、その人が最終的にどういう立ち位置で仕事をしたいのか、という価値観によるところはあります。
― 渡部さんのアメリカでの経験のように、価値観が変わるタイミングがあるのかもしれませんね。
エンジニアリングのアウトプットでビジネスに貢献することが、事業会社におけるエンジニアの存在価値です。ただ、エンジニアとしての実力が一定以上になると、1年後に倍のエンジニアリング力を身につけるというのは現実的に難しくなってきます。そうした時、上位のエンジニアになればなるほど、エンジニアリングの力を最大限活かして良いプロダクトを作るにはどうすればいいのか、という発想をするようになる。より事業に貢献するにはどうすればいいのか、と考えるようになります。そうした人にはプロダクトマネージャーを次のキャリアの選択肢として考えてみてもらいたいですね。
ただ、エンジニア出身のプロダクトマネージャーは、実装方法にばかり意識が向いてしまいがち、という弱点もあります。だから私は、どういうフィーチャーを作るべきかをて考える際には、逆に一切技術的な実現方法を考えないようにしています。さもないと自分の技術の幅がプロダクトの幅になってしまう。
とはいえ「技術的にはこんな事もできる」という知識の積み重ねが新しいサービスのアイデアを生むことはあるので、技術に関する勉強はし続けるべきです。プロダクトマネージャーはゼネラリストであることが求められますが、自分の強みを磨きスペシャリティを持ち続けることも重要です。
― これからプロダクトマネジメントに関わる人におすすめの本があれば教えて下さい。
マネジメントに関するお勧めの本を聞かれた時に紹介するのが、『プロフェッショナルマネージャー』という本です。今日僕が話したことは、だいたいこの本に書いてあります。
プロダクトを考える上で勉強になったのが『ライト、ついてますか―問題発見の人間学』という本です。私の師匠であるGREE CTOの藤本さんがお勧めされていたので読んだのですが、とても良い本です。同じ現象でも見る角度によって異なる解釈ができます。複数の視点で問題を理解することの重要性が分かる本です。
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (190件) を見る
― 最後に告知などがありましたらお願いします
当社では技術を突き詰めたいエンジニアも事業を作りたいエンジニアも募集中です。また、エンジニアとして実績を積んだ後でプロダクトマネージャーになりたい、という方も大歓迎です。
私のポジションを奪ってくれるような人が来てくれたら頼もしいですね。私は「こいつには敵わないかもしれない」と思う相手がいると闘志がわくタイプです。自分のポジションを脅かすような優秀な人が来てくれると、さらに仕事が楽しくなるだろうなと思っています。
― ありがとうございました
