プロダクトマネージャーの道具箱

読者です 読者をやめる 読者になる 読者になる

小さなごちそう

プロダクトマネジメントや日々の徒然について

プロダクトマネージャーに訊く #8:CyberZ中村さん

PMインタビュー

f:id:tannomizuki:20160728202724j:plain

— 中村さんの担当プロダクトを教えていただけますか?

4年前にCyberZに入社し、スマホ向け計測ツール『F.O.X』のプロダクトマネージャーを2年半つとめた後、現在はOPENREC.tvというゲームに特化した動画配信プラットフォームの開発マネージャーを担当しています。

OPENREC.tvは今CyberZが注力しているサービスの一つです。日本ではYouTubeやニコニコ動画を見ている人が多いと思いますが、海外だとゲーム専門の動画サイトがたくさんあって、非常に多くの視聴者がいます。

f:id:tannomizuki:20161026092814p:plain

— ゲームを自分でプレイするのではなく、他の人のプレイ動画を見るんですね。海外ではどれくらい流行っているのでしょうか。

海外ではビデオゲームを実際のスポーツのように観戦することをe-Sportsと呼び、非常に盛り上がっています。プロ選手がいてプロリーグがあり、エンタテーメントとしての地位を確立しています。あるe-Sports大会の決勝戦では、5万人規模のスタジアムが満員になります。

日本と海外ではゲームに対する認識が大きくかけ離れています。これは海外のゲーム大会の様子ですが、日本でいうと埼玉スーパーアリーナのような大きな会場に、何万人という規模で観客が集まります。

f:id:tannomizuki:20161026093220j:plain(出典:The stage and crowd at KeyArena for The International 2014


— 本当にスポーツ観戦のようですね。恥ずかしながらe-Sportsというジャンルを知りませんでした。

日本でもようやくe-Sportsがメディアで取り上げられるようになり、プロ選手として生計を立てている人が出てきています。とはいえ、一般的な知名度も社会的認知度もまだ低いんです。日本ではゲームは家に引きこもって一人でやるものというイメージが強く、ゲームをプレイしてお金を稼ぐということを肯定的にとらえている人がまだ少ないのです。職業の一つとして受け入れられていません。

一方、海外はプロゲーマーがサッカー選手と同じような地位を確立しています。サッカー選手と同じようにプロゲーマーは子供が憧れる職業の一つになっています。オリンピックの種目にしようという議論が真面目に行われているくらいです。NBAやフットボールと同じようにチームにスポンサーがついて、ゲームの実況中継の放映権が売買されるなど、既に大きな市場ができています。

— 確かに日本ではゲームの愛好家は多くても、ゲームをプレイすることが職業になると認識している人は少なそうですね。

海外と同じように日本のe-Sportsを盛り上げていくことがOPENREC.tvのミッションだと考えています。CyberZでRAGE(レイジ)というe-Sportsの大会を主催しています。スマホゲームのシャドウバース、VaingloryやストリートファイターVなどのゲームのトーナメント大会を開催しています。現在開催しているRAGE vol.3は、オフライン大会の予選で1,024名の出場者が一堂に会するほどの規模になっています。

f:id:tannomizuki:20161026094029p:plain

以前格闘技がブームになった時は、K-1などの格闘技イベントを一般の人がエンターテイメントとして楽しんでいました。ゲーム大会というと日本ではまだ一部のゲーム好きの人向けのイベントというイメージですが、OPENREC.tvを通じて、e-Sportsを一般の人が楽しめるエンターテイメントに育てて行きたいと思っています。

— ちなみにゲームはどうやって録画するんでしょうか?

Wii UやPlayStationのようなコンソールゲームは、市販のキャプチャデバイスを使ってPCと接続することでプレイ動画の録画と編集が可能です。以前は数十万円したキャプチャデバイスも、最近では3万円程度で買えるようになりました。ゲーム機とキャプチャデバイスをHDMIで接続して、キャプチャデバイスとPCをUSB接続するだけで簡単に録画できます。
ゲームのプレイ動画をそのままライブ配信している人もいれば、プレイ中の自分の様子をワイプで合成したり効果音を重ねたり、編集して配信する人もいます。

外資系大企業のエンジニアからベンチャー企業のCTOを経て、プロダクトマネージャーに

— CyberZ入社までのキャリアを教えて下さい。

4年前の2012年7月に、スマホ向け計測ツール『F.O.X』のプロダクトマネージャーというポジションでCyberZに入社しました。

CyberZに入社する前はベンチャー企業で2年ほどCTOをつとめていました。iPhoneの利用者が増えて、GoogleもAndroidを出し、スマートフォンが一般ユーザーに普及し始めていた2010年頃のことです。アプリビジネスについてはまだ黎明期で、一部の個人デベロッパーがすごく稼いでいるといった話がニュースになっていた時期でした。

新卒で入社した会社は日本オラクルで、セールスエンジニアの仕事をしていました。
急速に普及し始めていたスマートフォンに初めて触れた時に、これは従来の携帯とは全く違うものだと感じました。「これは今までとは違う何かがおこる」と思い、すでに起業していた友人と一緒に新しいアプリのアイデアについて色々とディスカッションしていました。

オラクルを辞めて起業しようという意識はなかったのですが、友人から「せっかくだから一緒にビジネスとしてやってみないか」という誘いを受けて、友人の会社にCTOとしてジョインすることになりました。

 外資系の大企業からベンチャーへの転身ですが、苦労はありませんでしたか?

最初はとにかく大変でした。日本オラクルはソフトウェア・ベンダーです。日本国内でエンジニアがプロダクトに手を入れることはありますが、基本的には完成したプロダクトを売るのが主な仕事です。そこからスマホの世界に入って自分達でゼロからアプリを作るというのはまったく違う畑で、未経験のスキルや知識が要求されました。

今と違ってアプリエンジニアが世の中にほとんどいなかったので、自分でアプリもサーバーサイドも作りながら、どうやってアプリで収益を上げるか考えていました。

当然ベンチャーなので資金繰りがとても大変です。1回の失敗が命取りになるような緊張感の中で、より良いサービスを作るにはどうしたらいいか、ビジネスとして成立させるにはどうすればいいのか、ベンチャーにいた2年間はそれを必死に考え続ける日々でした。

— CyberZ入社前に広告関係のプロダクトの経験はあったのでしょうか?

いいえ、広告というジャンルは初めてだったので、半年ほどかけて猛勉強しました。ただ、開発面ではそれまで培ってきたスキルや経験は活かすことができましたし、ビジネス視点での考え方やサービスの作り方など、ベンチャー時代の経験を集大成してプロダクトマネージャーとしての仕事を進めました。

未経験の分野でプロダクトマネジメントする上では、まず自分で実際にプロダクトに触れたり、顧客の意見聞いたりすることがとても大事です。本を読んで知識を得ることも大切ですが、それは誰でもできることですし実践的な知識は身につきません。私はプロダクトのソースコードを読んで仕組みを勉強しながら、2ヶ月間ひたすら営業に同行して顧客はどんな考え持っているのか、どんなもの求めているのかヒアリングしました。

— 未経験分野のプロダクトを担当されて、結果はどうでしたか?

おかげさまでF.O.Xはかなりの勢いでプロダクトの改善を進めたこともあって広告主からの評価も高く、国内のスマホ向け計測ツールとしてはナンバーワンのシェアを獲得しています。F.O.Xの利用企業様からは、ツールだけでなく広告運用も一括してCyberZに任せていただくようにもなりました。

2012年に約1,000億ほどだったスマートフォン広告市場は、現在約5,000億円の規模にまで成長しており、まだ伸び続けています。ただ、CyberZがスマートフォン広告市場に参入した2011年当時は、まだクライアント企業もスマートフォン広告を試行錯誤しながら利用し始めた段階で、広告の効果測定ができず、正しい広告が運用できているかどうかチェックできない状況でした。そうした問題を解決するソリューションとしてF.O.Xを提供し、スマホ広告市場の成長にあわせて導入企業数を増やすことができました。

エンジニア主導のサービス開発で実現した、圧倒的なスピード感

— OPENREC.tvにはいつから関わっているのでしょうか?

OPENREC.tvを担当することになったのは1年半ほど前です。F.O.Xも新しいチャレンジでしたが、動画プロダクトを作ることもやはり自分にとって新しいチャレンジでした。ゲームに特化しているとはいえ、開発レベルでやってることはYouTubeを作っているようなものです。

OPENREC.tvはCyberZとしてもかなり力を入れて開発しており、私が担当してから1年間で3回リニューアルしています。

— 1年で3回のリニューアルはすごいですね。どのようなリニューアルを行ったのでしょうか。

例えば、録画動画からライブ動画の配信に軸足をおいたサービスへのリニューアルを行いました。

当初は録画した動画をアップロードする配信者が多かったので、ストックされ続ける動画の中からユーザーが自分の好みにあった動画を発見できるように、機械学習を使った動画レコメンド機能を開発しました。

ただ、次第にライブ配信する配信者が増えてきたことで、レコメンド機能がうまく機能しなくなってきました。レコメンド機能ではユーザーの過去の視聴履歴を元に、ユーザーが好みそうな動画を推測します。例えば過去にサッカーゲームの動画を見たユーザーにはスポーツ系ゲームの動画をおすすめ表示するのですが、その仕組みだとスポーツ系以外ですごく盛り上がっているライブ配信があっても、このユーザーにはレコメンドされません。「せっかく盛り上がっているライブ配信あるのに気づかれない」という問題がありました。

そこで、一旦レコメンデーション機能を削除して同時視聴者数でランキング表示する形式にしました。これはライブ配信者のモチベーションアップにつながりました。

作り込んだ機能でも、ユーザーの反応が良くなかったり、サービスの成長フェーズに合わない機能は、思い切って削除するようにしています。

— せっかく作った機能が削除されてしまうことにエンジニアから反対の意見はないのでしょうか。

OPENREC.tvでは企画段階からエンジニアと一緒に考えながら開発を進めています。エンジニアと事業責任者が一緒に考えながらプロダクトを作っているので、仮説が外れた場合は、エンジニアは自分たちの責任と捉えています。やらされ感が全くないので、軌道修正する際にも「また仕様が変わるのか」といったネガティブな反応はありません。

新規サービスの立ち上げは朝令暮改が当たり前の世界です。昨日言ったことが今日変わる。ユーザーの反応を見ながら「ここは当然変える必要があるよね」とお互いに納得しながら進めているので、変化していくことへの抵抗はありません。改善のスピード感はとても早いですね。

以前はプロデューサーやディレクターが要件やスケジュールを決めて、エンジニアが開発するという一般的なスタイルでした。現在は私が開発責任者としてまとめ役をしつつ、エンジニアの主要メンバーが集まってサービスの方向性を吟味してプランをつくる、というスタイルに変えました。決まったことが降りてきて受託的に開発する、というのではなく、自分たちで考えたもの作るというスタイルだと、エンジニアのモチベーションが全然違います。

— どうしてそうしたスタイルに変えようと思ったんでしょうか。

動画プロダクトを作るには人員体制としても大きな投資が必要です。良いものを短期間に作ってユーザーが集まるサービスにしないと、事業を継続できません。そのためには
各自が危機意識をもって主体的にアイデアを出し、サービスを改善していく必要があります。どうすればそうした開発チームを作れるのか、と考えた時にたどり着いたのが『開発ボード』を組織してメンバーの意識を上げていく、という方法でした。

CyberZには「先送り撲滅会議」というものがあります。人事や事業など様々な会社の課題について、一時的なタスクフォースを作って解決策を考えます。タスクフォースが「先送り撲滅会議」で社長にプレゼンし、承認されたプランが実行に移される、というものです。

この「先送り撲滅会議」のOPENREC.tv版を事業部内で開催することにしたのです。チームをより良くする案、OPENREC.tvを急成長させる案、など色々なアイデアをみんなで持ち寄って、社長も参加する場で議論して意思決定をしました。これがすごくうまく行ったので、このやり方を継続することにしました。

— エンジニア全員が参加して議論するのでしょうか。

いえ、20人を超える開発メンバー全員で議論するのは難しいので、取り組むべき課題に応じて必要なメンバーをアサインしています。アサインするのは役職者やリーダーに限定しません。開発ボードにアサインされると当事者意識が生まれて、自分のチームがどう事業に貢献するのか、より良いサービスにするにはどうすればいいのか、といったことを率先して考えるようになります。

— ただ中には「要件を決めてもらった方が楽だ」というスタンスの人もいますよね。

もちろんいますが、それは適材適所だと思っています。エンジニアにも様々なタイプがいます。マネジメントに興味があるエンジニアもいれば、コードをガリガリ書きたいっていう技術志向のエンジニアもいる。技術志向の人でも色々な技術に触れて多様なスキルを身につけたい、という人もいれば、一つのことだけ追求したいという人もいます。私が毎月面談をして、現状や今後どういうふうにしていきたいのか、などをすり合わせながら、適材適所でアサインしています。

— ちなみにエンジニアの皆さんはやっぱりゲームが好きな人が多いんですか?

それも人によります。ゲームをすごくやる人もいますし、全く興味がない人もいて、そうした多様性が実はとても大事だと思っています。日本でe-Sportsを一般的なエンターテイメントにするには、ゲームに興味ない人にも楽しんでもらえるようにしないと駄目なんです。例えばフジロックやサマソニなどの音楽フェスには10万人規模の人が集まりますが、それはコアな音楽マニアだけを対象にしたイベントではないからだと思うのです。「普段はゲームをやらないしルールもよく分からないけど対戦動画を見るのは好き」という層にも届くサービスにするためには、普段ゲームをやらないエンジニアの意見も必要になります。

f:id:tannomizuki:20160728202843j:plain

マネタイズは後、まずは最高のプロダクトを作る

— リニューアルを繰り返した結果、現在の手応えはいかがですか?

OPENREC.tvは世間一般の認知はまだこれからですが、この分野では存在感がようやく出てきています。

Twitterでフォロワーが3万人を超えるゲーム配信者の方が、どのサイトで動画配信をして欲しいか、Twitter上でフォロワーにアンケートをとったんです。その際に3,500票を超える回答が集まり、50%の人が「OPENREC.tvで見たい」と回答しました。1年前は誰もOPENREC.tvを知らない状態でしたが、その頃から比べるとかなり認知度があがったと感じます。

— どうやって認知を獲得していったのでしょうか?

地道な活動やクチコミですね。まだ改善フェーズのサービスなので広告での集客はしていません。1年前にサービスを開始した当初は「YouTubeやニコニコ動画で十分」という反応がほとんどでした。「なんでいまさら動画サービス?」「こんなのいらない」「絶対流行らない」といった声ばかりだったんです。配信者の方にこちらから声をかけても「なしのつぶて」でした。

コアなゲーマー層からの印象も悪く、もともと広告代理ビジネスで成長したCyberZが手がけるサービスということもあって「e-Sportsがちょっとメディアで取り上げられるようになってきたから、流行りに乗ろうとしているだけじゃないの?」といった反応が本当に多かったんです。Twitterでエゴサーチするたびに心が痛かったですね。

ただ、RAGEのようなイベントを開催し、フルリニューアルや機能改善を積み重ねていくことで、会社として本気でこの分野に投資している姿勢がゲーマーの皆さんに伝わっていったように思います。Twitterで目にするOPENREC.tvに対する言葉も次第に暖かいものが増えてきました。コアな層だけでなく一般の方の認知も広まってきて、OPENREC.tvを使ってくれる配信者の方が増えてきました。以前は一度使ってもらってもすぐ離脱してしまうサービスだったんですが、ようやくユーザーが定着して、DAUが右肩上がりで増えていくようになりました。

— ユーザーが定着するサービスに改善できた理由、秘訣はなんでしょうか?

一つは「最高のプロダクトを作る」という点に集中したことです。1年ほど前にCyberZ代表の山内がOPENREC.tvの総合プロデューサーになり、この事業に注力することになりました。その際に山内が「当面マネタイズは考えなくてもいい。その代わりに最高のプロダクトを作って欲しい」と宣言したのです。

それまではユーザー目線で使いやすいサービスを作るのと同時に、収益化のための機能を並行して考えなくてはならず、どうしても思考が分散していたんです。収益を上げなければ事業は続けられない。でも良いサービスでなければユーザーは集まらないですし、ユーザーが集まらなきゃ収益も上がらない、そのジレンマの中で事業を作っていく必要があるのですが、やはりユーザーにとっての価値と収益性を同時に考えるのはとても大変なことです。

そんな中で、良いサービスを作ることを優先するとトップが方針を決めたことで、開発チームがすごく動きやすくなり、最高のプロダクトは何だろう、使いやすさって何だろう、という点に集中して考えられるようになりました。本当にサービスが良くなってきたのはそれからですね。

ただ、短期的な売上は追わないとはいえ「最高のプロダクト作る」ということに対するプレッシャーは非常に大きいものでした。「ここが使いにくい」「ここは訳がわからない」とあらゆる点についてダメ出しをされ、使いやすさを徹底的に突き詰めてプロダクト開発を進めました。

創って作って売る仕組みを作るのがプロダクトマネージャーの仕事

— プロダクトマネージャーの役割として意識していることがあれば教えてください。

OPENREC.tvでは「最高のプロダクトを作る」という点にフォーカスしていますが、F.O.Xを担当していた時にプロダクトマネージャーの仕事として強く意識していたのは、営業がいかに売りやすい状況を作るか、ということです。BtoBプロダクトの場合、良いもの作るだけでは顧客に届きません。資料作りや勉強会の開催など、営業が売りやすいプロダクトにするための泥臭い準備を避けないことです。営業戦略とのすり合わせも大事です。

また、プロダクトの提供価値や提案の仕方を考えて開発しないと、顧客やビジネスサイドが全く求めていないものができあがってしまいます。BtoBプロダクトはビジネスサイドがどう売るのかイメージし、BtoCプロダクトはユーザーがどう使うのかイメージしながら作る必要があります。

「創って作って売る」という言葉がCyberZの共通言語になっています。これは『V字回復の経営』という本に出てくる言葉です。 

V字回復の経営―2年で会社を変えられますか (日経ビジネス人文庫)

V字回復の経営―2年で会社を変えられますか (日経ビジネス人文庫)

 

 この本は、危機的な経営状況に陥った製造業の会社をコンサルタントである主人公が立て直す、という著者が実際に経験したケースをモデルにした物語です。開発サイドは「製品が売れないのは営業のせいだ」と主張して、営業サイドも「製品に問題があるから売れないのだ」と主張している。それぞれが責任を押しつけあっている、という状況から、最終的には両サイドが協力して会社を立て直すというストーリーです。

ものづくりだけがうまくても駄目だし、営業力だけでも駄目。両者が噛み合うサイクルを作る必要がある、というお話です。

開発サイドはプロダクトを企画して実装する。営業サイドがそれをユーザーに届けて、ユーザーの反応や意見を開発サイドにフィードバックする。開発サイドはフィードバックを元に次に何を作るべきか考える。プロダクトマネージャーはそうしたサイクルを作らなければなりません。そのためにはビジネスも技術もプロダクトも全て理解している必要があります。

— 作りたいものを作るのではなく、ユーザーや市場の反応を確かめながらプロダクト開発を進めることが重要ということですね。

「これは受けるんじゃないか」という新機能のアイデアが思い浮かぶことがあります。でも、そうしたアイデアを実際にいろんな人にぶつけて意見聞いてみると、予想していた反応と全く違ったりするんですよね。そこがすごく面白いところです。

例えば、私がF.O.Xを担当していた時はソーシャルゲームの全盛期だったんですが、ソーシャルゲームの世界ではリアルタイムにユーザーの反応を分析してパラメーターを調整しているんじゃないかと思って、リアルタイム解析機能の開発を企画したんです。でも開発する前にお客さんのところに行って話を聞いてみたところ、リアルタイムでは分析していないし前日の数字が見られれば十分だ、ガチャの運用も前回のイベントの数字に比較できればいい、とのことでした。リアルタイムに更新されるシステムを作るのはすごく大変です。3カ月かけて頑張って作りました、でもお客さんには刺さりませんでした、ということになると、結局3カ月何もやってないなかったのと同じになってしまうんですね。

— 使われないもの一生懸命作る無駄が発生してしまう、と。

そうなんです。単に自分たちの思いつきでサービスを考えるのではなく、市場がどんなのを求めているのか、お客さんが何を求めているのか、といったことをきちんと分析することの重要性をその時に改めて認識しました。

ただ一方でお客さんの言うことも正しくないんですね。「こういう機能が欲しい」と言う要望を受けて作ったのに全然使われなかったというケースも沢山あります。営業担当から「こういう機能があったら絶対に使われますよ」みたいな事を言われることってありますよね。「要望が多い機能です」とか「この機能が無いと困ります」とか、リクエストを沢山もらいます。プロダクトマネージャーはそうしたリクエストを真に受けるのではなく、ユーザーが本当に求めるものが何かを嗅ぎ分ける嗅覚や分析力がすごく求められます。やらなくちゃいけないこと、やって欲しいと言われることが山のようにある中で正しい優先順位をつけることがプロダクトマネージャーの最も重要な仕事の一つだと思います。

— 優先順位付けに悩んでいるプロダクトマネージャーは多いと思いますが、どうやるのがいいんでしょうね。

何を作るかを選ぶのはすごく難しいんですよね。ちょっとヒアリングするだけでも要望は沢山出てきてしまうし、その中から本当にやるべきことをピックアップするのはすごく難しい。ですから私はまず「やらないこと」を決めるようにしています。

「開発の断捨離」と呼んでいるんですが、これは開発しないって、今はやらない、というものをどんどん決めていくんです。その結果、これはやったほうが良さそうだというものが残ります。次にプロダクトの哲学と照らし合わせて、一つ一つの機能の組み合わせがどういうストーリーを描くのかを考えていきます。その作業をやらないとバラバラと散漫としたプロダクトになってしまいます。

多機能でも使いにくい製品の例としてテレビのリモコンが挙げられることがありますが、そうならないようにするには「いかに引き算をするか」という発想が大事です。自分の頭の中でイメージを具体化しながら「本当にこの機能はいるのか?」という自問を繰り返します。イメージするだけでなく、実際に数え切れないほどのモックアップを作ります。場合によってはプロトタイプを作って、営業担当やユーザーに見てもらいます。

— ユーザー視点で機能を付け加えるのではなく、ユーザー視点で機能を断捨離するんですね。

そうです。ユーザー視点やユーザーの感覚を持つためには、ユーザーとの接点を持ち続けることが大事です。先日OPENREC.tvでは、配信者の方を対象にしたオフ会を開催して、多くの方に参加していただきました。オフラインの場で「ここが使いにくい」など色々な意見を直接もらうことができ、逆に「OPENREC.tvは何を目指しているのか」といったプロダクトのビジョンを伝えることもできました。オフ会はこれからも継続的に開催していきたいですね。

 ハイブリッドなスキルセットはプロダクトマネージャーを余人に代えがたい人材にする

— 中村さんがプロダクトマネージャーという役割を認識したのはいつからでしょうか。

CyberZ入ってからですね。もちろんそれまでもビジネスとエンジニアリングの両方を意識してプロダクトを開発していたので、「創って作って売る」のようなCyberZが大切にしている価値観はとてもしっくりきましたし、プロダクトマネージャーとして自然に振る舞うことができました。ただ以前は、今ほどしっかり考えてはいなかったと思いますし、CyberZでの仕事から学んだことがたくさんあります。手探りしながら自分のやっていることを体系立てて整理していきました。この資料は以前プロダクトマネージャーのイベントに登壇した時に作った資料です。

 

プロダクトマネージャーの役割はエンジニアでもなく営業でもなく、とにかく曖昧になりやすいので、こうした資料を作りながら常に自分の役割を定義するようにしています。

— これからプロダクトマネージャーを目指す人にアドバイスはありますか?

プロダクトマネージャーには事業理解やビジネス理解が求められます。もしプロダクトマネージャーを志望するのであれば、技術者として一定のスキルを身に着けた後に、キャリアのなかで一度はビジネスサイドを経験したほうが良いでしょう。

私の最初のキャリアはセールスエンジニアでした。オラクルではセールスエンジニアに必要な技術とビジネススキルの基本を叩き込まれました。職務上、営業に同行する機会が多く、BtoBの世界で商品を売るということはどういうことなのか学ぶことができました。少し前にセールスエンジニアの仕事に関する記事が話題になっていましたが、技術とビジネスの両方を経験できる職業だと思います。

また、ベンチャーのCTOはコードを書けるだけでなく、システム全体を把握してより深く技術を理解することが求められます。更に、ベンチャーでは投資家向けの事業計画を作ったり、会計や資金繰りに関わったり、事業の立ち上げを行ったり、と経営について様々な経験ができました。そうしたキャリアを通じて、プロダクトマネージャーに必要な営業や技術に関する知識を得ることが出来ました。

— 今はご自身でコードを書くことはないのですか?

そこはやはりジレンマがあって、最近またコードを書き始めています。
OPENREC.tvにリアルタイム・メッセージングの仕組みを入れようとしてるのですが、ゼロベースでサブシステムを作る必要があり、私がまず一通りの機能を実装してメンバーに引き継ぎました。

プロダクトマネージャーには、経営の視点からサービスを考えるビジネススキル、マネジメントスキル、そして技術者と対等に会話できる技術力が必要です。いつまで続けられるかわかりませんが、やはり定期的にコードを書いてキャッチアップしたいと思っています。

— 技術を理解していることはプロダクトマネージャーにとって重要なことなんですね。

エンジニアから信頼されていないと開発が進みにくいんですよね。ビジネスサイドだけで考えたアイデアは、エンジニアの受けが悪いことが多いんです。技術的難易度や実装コストが考慮されていないので、労力に見合った効果があるのかという疑問が先に立ってしまい、「なんでそれが必要なの?」といった反応が返ってきてしまう。でも技術が分かっている人のアイデアだと話が早いんですよね。何が実現可能で何がそうでないかわかっているので、無理なアイデアを強引に押しつけて開発プロジェクトが迷走する、といったこともありません。

— どういう人がプロダクトマネージャーに向いていると思いますか?

自分の作ったプロダクトが世の中でどう使われるのか、ということに関心があったり、プロダクトをもっと広めたいという思いがある人はプロダクトマネージャーに向いていると思います。

プロダクトマネージャーは常に正解がわからない中で判断することを求められる仕事です。「どんなプロダクトを作るべきか」という問いの答えはどこにもありません。「次の開発の優先度をどうすべきか」というレベルですら、どこかに答えがあるわけではないんです。答えがない中で自分の頭で考えて決断できる人がプロダクトマネージャーに向いています。逆に「言われたことをやるほうが楽だ」という人は向いていないですね。

プロダクトマネージャーは万人に勧められるキャリアではないかもしれません。ずっと技術に触れているわけではないのでエンジニアとしては中途半端になってしまいますし、営業スキルもその道一本で来た人には勝てません。どっちつかずになるリスクがある職業だと思っています。ただ、ハイブリッドであることの強みを発揮できるようになれば、代わりのいない貴重なポジションを築くことができます。

— 最後に読者に伝えたい事があればお願いします

エンジニア出身のプロダクトマネージャーとして、エンジニアの皆さんには是非プロダクトマネージャーを目指して欲しいと思っています。エンジニアリングのスキルはある一定の年齢を過ぎるとなかなか大きく伸ばすのが難しくなります。ただ、ビジネススキルはそこから伸ばすことができます。ハードルの高い職業に見えるかもしれませんが、エンジニアとしも営業としてもそこまで尖ってない、という人が実はプロダクトマネージャーとして力を発揮したりするんですよ。エンジニアとして経験を積み、さらにビジネスについて学べる環境に身を置くことで、誰でも目指せるポジションだと思います。

CyberZでは私たちのビジョンに賛同して一緒に働いてくれるエンジニアを大募集しています。チャレンジングなプロジェクトで技術を磨きたいというエンジニアの方も、将来プロダクトマネージャーになりたいというエンジニアの方も大歓迎です。興味を持った方はぜひご連絡ください。

— ありがとうございました

Computational Thinkingとは何か

考える技術

Computational Thinking(CT/計算論的思考)とは問題解決のプロセスを分解したもので、その名の印象とは異なり、科学分野のみならず人文領域も含めてあらゆる問題の解決に使える手法だ。

1. Decomposition(問題の分解)
複雑な問題を解決可能なレベルまで分解すること。

2. Pattern Recognition(パターンの発見)
周期性や法則性を見抜くこと。

3. Abstraction(抽象化)
枝葉を切り落として重要な要素だけを抜き出すこと。(数学の文章問題を解くときの作業に近い)

4. Algorithm Design(手順化)
ステップバイステップで、問題解決の手順を明らかにすること。(料理のレシピのイメージ)

初等教育におけるプログラミング教育の目的は、プログラムを書けるようになるのがゴールではなく、このComputational Thinkingを身につけることに他ならない。(と僕は思う)

Computational Thinkingという言葉はSeymour Papert氏が1980年に初めて使用した言葉らしい。Jeannette Wing氏によるエッセイによって、Computational Thikingが問題解決の基礎スキルとして万人に役立つものであると認識されることとなった。(Wing氏はMicrosoft ResearchのVPであり、カーネギーメロン大学の教授である)

Computational Thinkingを知るためのサイトや動画

Googleが教育者向けにCTを理解するためのオンラインコースを開設している。

イギリスのコンピュータ教育の支援団体Barefoot projectのサイトが非常にわかりやすい説明が掲載されている(詳細閲覧には会員登録が必要)。

f:id:tannomizuki:20161018125414j:plain

code.orgの小学生にCTを教えている動画がわかりやすい。


CS Fundamentals Unplugged: Computational Thinking

1から200までの足し算の答えを簡単に算出する方法(201*200/2)を例に「パターンの発見」を解説している。(生徒があっさりパターンを見抜いていてスゴイ。)

下記は講師による解説動画。


Course 3 - Computational Thinking

Computational ThinkingはPMの必須スキル(だと思う)

「プロダクトマネージャーはコードを書ける必要があるか」という点が議論になることがあるが、多くのベテランPMはこの問いに「必ずしも必要でない」と答える。僕も同意だ。だが、「PMはComputational Thinkingを身につけている必要があるか」という問いに対してはYesと答えたい。

Computational Thinkingについては僕も学び初めたばかりなので、このブログで改めて詳しい解説をしたいと思っている。

プロダクトマネジメントが難しい7つの理由

プロダクトマネージャーの仕事

企画の承認を得たら要件を整理して共有し、成果物レビューしてリリースされたらプロモーションを行う。言葉にすると簡単だけど、プロダクトマネジメントが一筋縄では行かない理由は何なんだろうか。

  1. 自分たちが提供できるもの、提供したいものを作ってしまう病(自社都合の引力)
  2. ユーザー要望の背後に潜む本質的問題を発見しなければならない
  3. 様々なステークホルダーがプロダクトに対して異なる理想像を描いている
  4. ユーザーは期待通りに都合よく動いてくれない
  5. 企画した通りに実装されることはない
  6. 実はプロダクトだけの問題ではない

あ、7つにしようとしたのに一個足りない。

真の顧客ニーズは何か、競争環境はどう変わるのか、何もかもが不確実で正解がわからない。そんな中で、とにかくPMはいろんな専門家の力を結集してプロダクトを作り、顧客に届ける必要がある。ただ専門家固有のメンタルモデルによるバイアスがあったり、専門家同士の共通言語がなかったりする。さらにはチームに特定のスキルセットが不足していたりもする。専門家同士のの橋渡しをしたり、時には穴を埋めたりといったことをする係がいないとうまく行かない。せっかく発見した市場機会を逃してしまうことになる。

そういう意味ではクロスオーバーするスキルを持ったメンバーで構成されたチームではPMの必要性は限定的かもしれない。

そんな議論に興味がある方はプロダクトマネージャーカンファレンスにぜひお越しください。

プロダクトマネージャーカンファレンス2016を開催します

おそらく日本初となる、プロダクトマネジメントをテーマとした大型カンファレンスを10月に開催します。私も9人の実行委員の一人として企画に参画しております。

先日、登壇者の情報を一部公開しましたが、皆さん第一線で活躍する著名な方々です。

f:id:tannomizuki:20161007215146p:plain

また、第一回目という開催実績のないカンファレンスにも関わらず、多くに企業様に協賛いただきました。非営利のイベントながら、参加者の皆さんの負担を減らしつつ豪華なイベントにしたいと考えており、ご支援ご協力いただいた皆様には実行委員一同本当に感謝しております。

企業の壁を超えたノウハウ共有を促進したい、現場で奮闘するPMを応援したい、企業経営に関わる方にプロダクトマネジメントの重要性を認識して欲しい、プロダクトマネージャーの社会的地位を向上させたい、そして世の中に良いプロダクトが生み出される環境を作っていきたい、などなど様々な思いを込めて企画したイベントです。ぜひ多くの方にご参加いただけると嬉しいです。

プロダクトマネージャー・プロダクトオーナーのためのイベントと銘打ってますが、現在の肩書きや役割に関係なく、良いプロダクトを作ることに関心のある方なら誰でもご参加頂けるイベントです。

「プロダクトマネージャーとして専門性を高めたい」
「顧客に愛されるプロダクトを作れるプロダクトマネージャーになりたい」
「これからプロダクトマネージャーを目指したい」
という方はもちろんのこと、

「コードを書くのは大好きだが、プロダクトを作るのはもっと好きだ」
「良いプロダクトを作れる開発チームにしていきたい」
というエンジニアやデザイナーの皆さんも歓迎です。

また、
「どうすれば市場機会をプロダクトとして狙い通り現実化できるのか」
「プロダクトドリブンの事業運営をするためには自社に何が足りないのか」
とお悩みの経営者や事業責任者の方も是非ご参加ください。

さあ、始めよう日本のプロダクトマネジメント!

プロダクトマネージャーに訊く #7:シャノン堀さん

PMインタビュー

f:id:tannomizuki:20160830082602p:plain

― 堀さんご自身について教えてください。

株式会社シャノンのCTOの堀です。技術部門のマネジメントをしています。

開発のディレクションと製品企画のディレクションを両方担当していますが、製品企画のほうがウェイトが大きく、7割ぐらいの時間を製品企画側の仕事に費やしています。どんな製品をつくるべきか、どういうプロジェクトチームでいつまでにリリースするのか、といったプロダクトマネジメント全般を他のプロダクトマネージャーと一緒に行っています。

― プロダクトの開発体制を教えて下さい。

現在シャノンの社員数は150人ほどですが、開発部門はQAチームを含めて約25人、インフラチームが約5人、プロダクトマネジメントを行う製品企画チームが4人、といった構成です。上海にも開発拠点があります

プロダクトマネージャーは各スクラムチームのプロダクトオーナーの位置づけで、要件の優先順位の決定やスプリントのレビューを行っています。私自身は各プロダクトマネージャーをフォローしつつ、個別の開発プロジェクトを俯瞰した製品戦略を考えて、MRD(Marketing Requirement Document)を整理するような役割をしています。

テクニカルな内部仕様は開発マネージャーやエンジニアが作成します。設計の方向性が大きく異ると感じた時は指摘しますが、基本的には開発現場に任せており、私はプロダクトマネジメントに時間を割いて製品の競争力強化のプランニングに注力しています。

MBAセミナーで意気投合、大手外資から15人のベンチャーに

― シャノンに入社する前はどのような仕事をされていたんでしょうか?

シャノンには約10年前の2005年の末に入社したのでが、その前は新卒で入社した日本オラクルでエンジニアをしていました。最初の数年は国際化のQAエンジニアを担当して、その後、アプリケーションサーバソフトの不具合に関するエスカレーションをハンドリングして修正パッチを書く、といった仕事をしました。外資系のソフトウェア企業の場合、製品に不具合があって顧客が困っていても本社以外では不具合を修正できないことが多いんですが、日本オラクルの場合は国内のエスカレーション対応部隊がコードを書いて問題を解決することができました。

その時の得たオラクル本社のソフトウェア開発手法とWebアプリケーションのバックエンドの技術的な知識はシャノンに転職してからもすごく役に立ちました。

― ミドルウェアの外資ベンダーから、マーケティングソリューションの会社に移ろうと思ったきっかけは何だったのでしょうか?

より製品開発のコアに関わる仕事をしたいと考えるようになったのです。オラクルでは不具合を改修するパッチを書くことは出来ても、製品そのものを開発するためにはアメリカにいかなければなりません。シリコンバレーのオラクル本社に行くか、日本でベンチャー企業に転職するか、など色々と考えながら情報収集をしていました。当時B2Cでは楽天やライブドアなどのWebサービスのサイトが一般的になってきており、「これからはB2Bでもパッケージ・ソフトではなくWebサービスの時代だ」と思っていました。

また、技術だけでなく経営やビジネスにも興味を持ち始めていて、MBAをの取得も検討していました。ただ、数年間大学院に通うための時間的金銭的コストを回収できるだろうかという懸念もありました。そこで、まずさわりだけでも勉強してみようと思い、MBAで得られる知識の一部である企業価値評価に関するセミナーを見つけて、1泊2日で参加することにしました。

そのセミナーでたまたま隣に座っていたシャノンの現CFOの永島と意気投合して、シャノンに入社することになりました。まだシャノンは15人くらいの会社で、まだクラウドやSaaSのような言葉もなくASPと呼んでいた時代です。「自社でイベントやマーケティングのソリューションをASPで提供していてる。エンジニアも7、8人いるから一緒にやらないか」と誘いを受けて入社することにしました。

― 外資系の大企業から15人のベンチャーに飛び込むことに不安はありませんでしたか?

特に不安はありませんでしたね。グローバル企業で働くなかで、日米でエンジニアのスキル差を感じることはありませんでしたし、トップオブトップのエンジニア達の概念設計スキルは別として、個別のコーディングスキルは日本人のほうがクオリティ高いし負けている感じはしない。うまくやれば海外の企業にに負ける要素はない、と当時思っていました。それは今でも変わりません。

シャノン入社直後は、プロジェクトマネージャーとしていくつかの案件を担当して開発プロジェクトのマネジメントを行っていました。当時は代表の中村がまだ自らコーディングしていたんです。中村がコーディングせずに社長業に専念できる体制をつくるのが最初の役割でした。

以来、開発プロジェクトのマネジメント、開発部門の組織づくり、製品の戦略やコンセプトづくり、仕様策定などを継続して行っています。

― 役割がエンジニアリングからプロダクトや組織のマネジメントにシフトしていくあたって、苦労した点はありますか?

オラクル時代に製品をゼロから作ったり大きな機能追加をしたりという経験があったわけではないので、色々と苦労はしました。特に「企画して開発してリリースする」という製品開発のプロセスと、「世の中に製品を知ってもらって販売する」という営業・マーケティングのプロセスのバランスをとりながら仕事を進めていくのが難しかったですね。今でもここは大きな課題だと思っています。

最初からマーケット・トレンドを広くとらえながら戦略的に製品を企画できたわけではなく、とにかく目の前のお客さんの要望に応えながらどうユーザーを増やしていくかを考えていました。現実的な目前の話と、抽象的な概念の話を行き来しながらあるべき方向性を見出していく、という行為をひたすら繰り返してきました。

再現性の高いBtoBマーケティング活動を実現する

― シャノンさんの製品について教えて下さい。

マーケティングオートメーションを軸とした、マーケティング統合環境を提供しています。マーケティングオートメーション製品はたくさんあるのですが、弊社の場合は展示会などのイベント管理ソリューションから発展した製品のため、オンライン・マーケティングとオフラインのイベントやセミナーを統合的に管理できるのが特徴です。

日本ではイベントやセミナーを重要視する顧客がとても多く、マーケティング活動をオンラインだけで完結できません。むしろオフラインのほうがビジネス上重要だというケースも多くあります。そうした企業様の課題を解決するソリューションを展開しています。プライベートショーや大規模展示会のバックエンドとしても利用できるのが特徴です。

また、BtoBマーケティングで効果をあげるには、ITシステムに加えて営業とマーケティングの組織改革をセットで考える必要があり、ITソリューションとコンサルティングの提供を同時に行っています。

我々は「マーケティング・イズ・サイエンス」というミッションを掲げており、再現性の高いマーケティング活動の実現を目指しています。BtoCを中心としたオンライン・マーケティングは定量的に効果測定をしやすくなり再現性が高くなってきていると思いますが、オンラインとオフラインを統合する必要があるBtoBマーケティングについては、まだまだケースの数も不十分で再現性が高い手法が確立しているとは言えない状況です。

どうすればデータ・ドリブンで再現性のあるモデルを構築して顧客にマーケティング・ソリューションとして提供できるのか、これが私たちのプロダクト開発の中心テーマです。

― 競合サービスとの違いを教えて下さい。

例えば、北米のマーケティング・オートメーション製品の場合、企業と顧客が地理的に離れていることが前提となっています。メールやサイトで資料請求を受け付けて、Webinarでサービス説明をして、ビデオチャットや電話で商談を進める、といったようにオンラインでマーケティング活動や営業活動が完結することを想定した設計になっていることが多いのです。

一方で人口密度が高い日本の場合、セミナーを開催して参加者の名刺を収集し、すぐに営業担当が見込み顧客を個別に訪問して詳細な説明を行う、といったように商習慣やプロセスが全く異なります。マーケティングの効果測定をするためには、そうしたオフラインの活動を含めた活動をトラッキングする必要があります。

私たちの製品は、セミナーの申し込みフォームを作成する、顧客リードに対してメールを配信する、営業担当者の営業活動によってセミナー参加者を獲得する、といったプロセスをトラッキングし、最終的にどれくらい商談に結びついたか分析できる仕組みになっています。

Webサイトやメールなどオンラインのアクティビティと、セミナーや名刺交換などのオフラインのアクティビティを統合してトラッキングできるのが我々シャノンのサービスの特徴です。オンライン広告のアトリビューション測定と同様に、オフライン活動の売上貢献度の測定も誰もができるようにしたいと考えています。

また、海外ベンダーのサービスは「マーケティング・オートメーションはこうあるべき」というベンダー個別の思想にユーザーが合わせるものが多いのですが、弊社の場合はあるべき姿を示しつつ、現状の業務プロセスに適応できる柔軟性をシステムに持たせています。

マーケティング・サイエンスの最初のステップは、結果を数値で見るようにすることです。実はBtoBマーケティング活動の成果について、KPIをしっかり定義できている企業はまだ少ないんです。KPIを定義して測定し、マーケティング活動の内容と結果の因果関係が明確になり、そして最終的にマーケティング活動を自動化する、という3つのステップを順番にクリアしていく必要があります。

― お客さんはマーケティング部門の方が多いんでしょうか?

マーケティング部門以外の方も多いですね。例えば営業部門や経営企画、新規事業部門などの方も多いです。私たちの顧客企業に関わらず、一般的に「10年以上マーケティング担当をやっています」というような方は少数です。「去年までは営業部門にいて、今年から異動でマーケティングを担当することになった」といった方がマーケティング部門には多いのです。BtoBマーケティングのソリューションは、そういった方でも使いこなせるプロダクトであることが求められます。

BtoBマーケティングは、リストにメール配信して終わりではありません。営業と連携してターゲット顧客の定義の認識を合わせながら、成果に結びつくようパイプライン管理する必要があります。そうしたあたりまえのプロセスをきちんと回して結果を出せるようにするのが我々のソリューションです。

ものが売れない時代だと言われて久しいですが、製品を作って営業をすれば売れた高度経済成長期とは違って、プロダクトの価値を正しく伝えて、ソリューションとそれを求めている人を正しくマッチングすることがとても大事です。それができれば企業は新規市場を開拓できて利益を生むことできます。

― BtoBマーケティングにはIT化されていないプロセスが多そうですね。

はい、BtoBのマーケティング活動には、まだまだ人的労力を必要とする部分が多いのです。例えばセミナーを開催するためには、会場の確保、顧客リストを抽出、案内メールの配信、申し込み管理、など様々なタスクの実行が必要です。担当者がそうしたオペレーションで精一杯になり、イベントを開催することが目的化してしまいがちです。その結果、頑張ってセミナーを開催して100人集客したにも関わらず、営業担当からみると全く価値の無いリードになっている、といったことも往々にしてあります。セミナー開催後に営業担当が個別にアプローチしても全く響かない。求めていないソリューションを営業されるお客さんも迷惑ですよね。労力をかけてすごく頑張っているのに誰もハッピーにならない。

オペレーショナルな部分の労力を最小限にすることで、「誰に何を伝えるべきなのか」という本来やるべきマーケティングのコアな部分に注力できるようにすることで顧客が利益を生み出せるようにすることが、一番大事な我々のミッションだと思っています。

顧客のペインポイント、課題を抽出する

f:id:tannomizuki:20160830082316p:plain

― 顧客の課題が解決できるよいプロダクトを作っていく上でどのような工夫をしていますか?

まずは顧客のペインポイントは何か、本当にしたいことは何なのかを理解することです。お客さんと話す時でも、社内で議論するときでもありがちなのが「こういう機能を追加して欲しい」という機能の話が中心になってしまうことです。何を作るかではなく、その機能が必要な理由、顧客が抱える課題の話にフォーカスするように注意しています。

プロダクトマネージャーに相当する人が不在で、事業側の声が大きい人の意見に引きずられていたり、逆に開発チームだけで閉じてしまっているプロジェクトはうまくいかないですね。そうしたプロジェクトでは、どんな機能が必要かという話ばかりが先行していて、なぜユーザーはその機能が必要なのか、ビジネス上のどんな必要性があるのかが曖昧なまま開発が進行してしまう。

また、「本当にお金を払ってまで解決したい課題なのか」を問うようにしています。お金払ってまで解決したいのかどうかで、痛みの深さを大別できます。解決しないとビジネスが回らないほどの課題なのか、今よりちょっとベターになるという程度の話なのかに分類することで優先順位を検討しやすくなります。

― 機能要望から課題を特定するためにはどうすればいいんでしょうか?

単純に「なぜ」を繰り返すことです。その機能がなぜ必要なのか、社内で要望を出した営業担当もわからない、実は要望元のユーザーも言語化できていない。ユーザーの上長に確認して初めてわかる、ということもあります。

顧客へのインタビューを行って、営業スキームや営業部門とマーケティング部門との関係性、部門ごとの課題、サービスの利用状況、などビジネス・プロセスや組織構造の全体像を紐解いていく必要があります。組織的な課題に目を向けることで、要望の背景を理解することができます。

例えば「このデータをCSVで出力できるようにして欲しい」といった要望があった時には、「出力して何をするんですか?」と聞くと、「CSV出力してExcelで集計した結果を営業に渡したい」といったデータ出力の目的がわかります。であれば、営業担当に直接データを共有できるようにしたほうがいいですよね。最終的に実施したいアクションに直結する機能を提供したほうが業務効率がアップします。

全ての要望に対してそこまで深くヒアリングできないので、推測で進めることも多いのですが、課題に関する仮説をたてて仕様やコンセプトを決めることが重要です。

― 堀さんが直接お客さんにヒアリングされることも多いのでしょうか?

はい、定期的に既存顧客へのヒアリングをするようにしています。組織が小さかった頃は商談やアフターフォローに同行することが多かったんですが、最近はそういう機会が減ってきたので、意識して顧客訪問の機会を作っています。

― ヒアリングはどのように進めているのでしょうか。

顧客インタビューについてはAtrasianで利用されているフォーマットが参考になります。

このフォーマットでは、観察結果の伝達、問題の解釈、機会への接続、という3つの項目にわけてインタビュー結果を整理します。

私がインタビュアーになってお客さんに質問して、同行した製品企画部のメンバーがフォーマットに基いてヒアリング結果を整理します。毎回とても気づきが多いですね。自分たちの製品が実際にどう使われているのか、実際の利用シーンでどのような課題があるのか、具体的に見えてきます。

― BtoB製品の場合、営業担当から「大手のA社がこの機能があれば買うと言っている」といった機能追加のリクエストが出ることも多いと思いますが、そうした案件固有の要望に対してはどのように対応していますか?

以前はそうした機能要望にも対応するようにしていたのですが、最近は機能追加をすれば売れるというような案件はすごく減ってきていますし、営業提案でカバーできるものについてはそうしてもらうようにしています。もちろん、大手顧客からのリクエストが他の顧客にも大きく役立つ場合などは前向きに検討しますが、それよりもBtoBマーケティングのあるべき姿を強く打ち出せるような、メッセージ性のある戦略的な機能開発にウェイトが移ってきています。

プロダクト発表イベントから逆算して発想する

― ユーザーヒアリングによって様々な課題が抽出されると思いますが、そこからどのように製品コンセプトに落とし込んでいくのでしょうか。どうやって着想を得ていますか?

最近弊社のプロダクトマーケティング担当が取り入れているのがキーノート・ドリブンの発想法です。例えば1000人の前でプレゼンをするとしたら、どういうビジョンや機能だったら聞き手に響くだろう、と想像して実際に発表資料を作ってみます。冒頭で社長がプロダクトの思想やビジョンを発表して、その後に自分が機能の詳細を説明してデモをする、という具体的なシーンを想像してみます。どんなプロダクトだったら聴衆にインパクトを与えられるだろう、というところから逆算して発想するのです。

Amazonでは製品開発の前にプレスリリースを最初に書く、という話を聞いたことがあるかもしれませんが、それと同様の手法ですね。

プレスリリースでも一度試したことはあるんですが、日本の典型的なプレスリリースのフォーマットだとイマジネーションがわきにくい。キーノートの方が「なぜこのプロダクトが顧客にとって重要なのか」というストーリーを整理しやすいですし、作り手であるエンジニアにもビジョンを共有しやすいと感じています。既存機能の改善ではない、大型の新機能の企画の際にこのやり方をしています。

― 着想を得た後は、どのようなプロセスで製品企画を進めていますか?

製品企画は2ページ程度のMRD(Marketing Requirement Document)からスタートします。Inspiredという書籍で「プロダクトに関する10の質問」という、なぜ今このプロダクトを作るのかを問うチェックリストが紹介されています。

  1. 製品化によって具体的にどんな問題を解決するのか? (バリュープロポジション)
  2. だれのためにこの問題を解決しようとしているのか? (ターゲット市場)
  3. 市場の大きさは? (市場規模)
  4. 製品化の成功をどうやって評価するのか? (指標、収益戦略)
  5. 現在、他に競合する製品はあるか? (競合の見通し)
  6. なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか? (差別化要因)
  7. なぜ今なのか? (市場投入の時期)
  8. どうやって製品を市場に出すのか? (市場投入戦略)
  9. 成功のために絶対に必要な要素は何か? (ソリューションの要件)
  10. これらを前提とした上で、最終的な提案は何か?(やるかやらないか)

Inspired: 顧客の心を捉える製品の創り方より

 このチェックリストを基にしたMRDのテンプレートを作りました。なぜやるのか、なぜ今か、どの市場向けか、ターゲットユーザーは誰か、開発コストはどれくらいか、といった項目を整理してMRDとしてまとめます。MRDをベースにビジネス的に価値がある企画なのか、経営陣と営業部門、マーケティング部門の責任者、そしてプロダクトマネージャーで議論します。

MRDが承認されたら、ユーザーストーリーの整理や画面設計を行って要件定義をし、アーキテクチャの概要を検討して開発スケジュールのアウトラインを作成して、PRDとしてまとめます。PRDが承認されると初めて実装に着手できます。

以前はMRDを作る前に数十ページに及ぶPRD(Product Requirement Document)を作成していたのですが、最初の一歩を間違えると、また数十ページのドキュメントを書きなおす必要がありました。まずMRDを作成することで、やるかやらないのかの意思決定を短期間でできるようになり、PRD作成の手戻りも無くなりました。

また、プロダクト開発とビジネスを網羅的に考えるフレームワークとして、プラグマティック・マーケティング・フレームワークを使うこともあります。

f:id:tannomizuki:20151221100826j:plain

The Pragmatic Marketing Frameworkより

横軸にストラテジーとエクセキューションの軸があって、上下にボックスが積み上がっていますが、上側がプロダクトマーケティング寄り、下側がプロダクトマネジメント寄りのタスクやプロセスになっています。これをチェックリストとして使うことで、バイヤーペルソナを考えたか、重要な販売チャネルを忘れていないか、デモサイトは用意したか、といったようにマーケティング活動の抜け漏れを確認できます。

― かなりプロセスが整備されているように見えますが、これからより強化したいポイントはありますか?

いくつかありますが、プロダクトが完成した後のプロモーションを企画の初期段階でどう詰めるか、という点はまだ試行錯誤しているところがあります。外向けのプロモーションもそうですが、弊社の場合は営業担当がサービスを販売するので、インターナルのプロモーションも重要です。リソースが限られているなかで、営業担当に新しいプロダクトや機能の魅力をどう伝えるか、企画の初期段階からどう巻き込むか、という点が手薄になりがちなので注意しています。

ゴールイメージを共有し、要件と技術的制約の妥協点をエンジニアと共に探る

― PRDを作成した後のプロセスで気をつけるべき点はありますか?

「プロジェクトだけを見て、プロダクトを見ていない」という事態にならないように注意をするようにしています。プロジェクトの進捗だけ報告を受けて、忙しさにかまけてプロダクトのレビューを怠ってしまい、蓋を開けてみたら想定と全然違うプロダクトになっていた、といった事態は避けたいものです。スクラムを導入していますが、最低でも週次でスプリント・レビューが必要です。

レビューをするのはプロダクトマネージャーだけに限る必要はありません。第三者が定期的にプロダクトを確認することでプロダクトの完成度が大きく変わります。開発に一定のリズムを作って、実際のモノを見るタイミングを作ることが大事です。

― 企画と最終的なアウトプットのずれが生じてしまうのはどうすれば避けられるのでしょうか?

最終イメージを文字面ではなくビジュアルで合意することですね。PMとエンジニアが同じ景色を共有できるようにする努力する必要があります。

エンジニアと企画サイドは言語に違いがあるので共有するのは難しいのですが、ゴールイメージを極力具体的なビジュアルに落として、同じ風景を見るようにすれば、レビューが少なくてもうまくきます。ただ、開発体制が大きくなってくるとそれもだんだん難しくなってきますね。特に弊社の製品はBtoBマーケティングのソリューションですから、エンジニアからすると製品の良し悪しの基準がわかりにくい。自分自身がユーザーになりうるECサイトのようなBtoCサービスであれば、「こういうカートは使いづらいだろう」と自分のユーザー体験をベースにあるべき仕様の議論がしやすいのですが、BtoB製品の場合はそれが難しい。だからこそ具体的にゴールイメージを共有する必要があります。

― エンジニアにゴールイメージを伝える上で、どういう点に注意すればいいでしょうか。

PMが仕様を噛み砕き過ぎてしまうと、エンジニアが「なぜ作るのか」を考えて創意工夫する余地がなくなってしまい、受託開発のようになってしまいます。要件を伝えて仕様はできるエンジニアに限り考えてはもらうようにしています。ただケースバイケースですね。PMが詳細な画面設計までしてしまうこともあります。いずれにしても、なぜやるのか、ビジネス上どんなメリットがあるか、という開発の趣旨をエンジニアが理解できるように気をつけています。

― ゴールイメージを共有した後のPMの仕事は?

要件を満たす上で技術的な課題がある場合は、PMはエンジニアと一緒に妥協点を探る必要があります。ビジネス側の理屈だけで要件を押しつけると、開発する側に負荷がかかって製品開発は滞ってしまいます。

また、将来の拡張性のために抽象度を上げて設計した結果、開発工数が増大してしまう、というのはソフトウェア開発でありがちな失敗です。技術的な観点ではすごく良い仕組みだったとしても、その「将来」というのはたいていの場合予期せぬ違った形で訪れます。会社の戦略を考えると確かにその拡張の可能性はある。でも往々にして次のプロジェクトでは方針が変わって別の要件の優先度が高くなり、拡張するより作りなおしたほうが早い、ということになってしまう。そうした過剰な開発をしないようにPMは開発チームと共に気をつける必要があります。

― どうすれば過剰な作りこみを避けられますか?

開発マネージャーには、今必要な要件にフォーカスをきっちり合わせよう、ただ変更はできるようにしておこうと話しています。抽象度を上げて拡張性を高めるのではなく、CIやテストの自動化によって変更に強い仕組みやアーキテクチャにしておこう、と。

これはシステムの設計上の話だけではなく製品企画も一緒です。「この機能は将来お客さんが必要になるかもしれない」という「いつか使う」系は大抵失敗しますね。

BtoBのインターネット・サービスはこれから益々面白くなる

― PMを目指す人にお勧めの本を教えて下さい。

シャノンに入ってすぐに読んでとても勉強になったのが、「売れるもマーケ当たらぬもマーケの22の法則」という本です。 

売れるもマーケ 当たるもマーケ―マーケティング22の法則

売れるもマーケ 当たるもマーケ―マーケティング22の法則

  • 作者: アルライズ,ジャックトラウト,Al Ries,Jack Trout,新井喜美夫
  • 出版社/メーカー: 東急エージェンシー出版部
  • 発売日: 1994/01
  • メディア: 単行本
  • 購入: 17人 クリック: 250回
  • この商品を含むブログ (61件) を見る
 

マーケティングというのは、製品機能の戦いではなく、商品の認知をめぐる戦いである。ユーザーのマインドシェアを何%獲得できるかが重要だ、という内容の本です。私はエンジニア出身なので、製品企画に関わり始めた時はマーケティングの知識が不足していました。4P(Product/Price/Promotion/Place)のような基本的な用語を聞いたことはある、という状態でした。この本はマーケティングについて学び始めた時に最初に読んだ本で、マーケティングの本質的な部分を理解するのに役立ちました。

定番ですが、プロダクトマネジメントについては「Inspired」は参考になります。その他には、「キャズム」「イノベーションのジレンマ」「エクセレントカンパニー」などはPMとして一度は読んでおいたほうがいいと思います。

本ではありませんが、新しい概念を学ぶ時にはSlideShareが便利です。調べたい単語で検索してスライドを3つぐらい読むと、短時間でおおよそのポイントをつかむことができます。

― 最後に記事の読者に伝えたいことはありますか?

我々と一緒にやりたい方を継続的に募集しています。日本ではまだまだ少ないBtoBのWebサービスを一緒に作ってくれる人、自分の力を試してみたいという人をお待ちしています。

マーケティングオートメーションの領域は変化も激しくて大変ですが、今すごい勢いで成長している面白いフェーズです。BtoCの世界も非常にビジネスとして面白いと思いますが、既にメガプレイヤーが多くてこれから競争に勝つのはすごく大変です。BtoBのWebサービスはこれから発展する市場なので、自分のアイデアを活かす余地が大きく、やり方次第で世の中に大きな影響を与えられます。ですから、自分の力を試してみたい人にとってはすごく向いている市場だと思います。

私は「何かを変えたい」「世の中に自分の足跡を残したい」と思いながらこの仕事しています。同じように感じていて、自分の思いを実現する場を探している方はぜひご連絡ください。

― ありがとうございました。

 

プロダクトマネージャーに訊く #6:スマートニュース渡部さん

PMインタビュー

f:id:tannomizuki:20160823164221j:plain

― まずご自身について教えて下さい。

スマートニュースの渡部です。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年後に1億円の売上が必要であれば、それを実現するために今何をしなければならないのかを考えます。

ゴールから逆算せずに、「できること」を積み重ねていってしまうと失敗します。「最終的にこういうタワーを作りたい」というゴールから逆算して計画せずに、下から積んでいくとジェンガになってくるんですね。「倒れそうだからここに積もう」「次はこっちに積もう」となって最終的には崩れてしまいます。

マクロな視点で市場を見て、どんなプレイヤーがどれくらいの事業規模で、どれくらいの売上なのかといった調査をすると、目標達成のために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の藤本さんがお勧めされていたので読んだのですが、とても良い本です。同じ現象でも見る角度によって異なる解釈ができます。複数の視点で問題を理解することの重要性が分かる本です。 

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

 

 ― 最後に告知などがありましたらお願いします

当社では技術を突き詰めたいエンジニアも事業を作りたいエンジニアも募集中です。また、エンジニアとして実績を積んだ後でプロダクトマネージャーになりたい、という方も大歓迎です。

▼ 採用 | スマートニュース株式会社

私のポジションを奪ってくれるような人が来てくれたら頼もしいですね。私は「こいつには敵わないかもしれない」と思う相手がいると闘志がわくタイプです。自分のポジションを脅かすような優秀な人が来てくれると、さらに仕事が楽しくなるだろうなと思っています。

― ありがとうございました

 

2016年7月号:注目記事まとめ

まとめ

プロダクトマネジメントに関係する記事で、7月に話題になった記事、気になった記事をピックアップしてご紹介。

コンセプト・メイキング

クリエイティブ・ディレクションのIdeationプロセスを分解して解説。こうあるべきという哲学や情熱がスタート地点になるわけですね。 

要件定義

↑ 開発要件のフォーマット例。開発の背景やゴールを最小限の工数で適切に伝えられるように工夫されたフォーマットです。

チーム開発、組織

開発プロジェクトのマネジメントを外部に依託することでエンジニアがコードを書くことに集中できるようにした、という事例。この発想は面白いですね。同じ発想で考えると、プロダクトマネジメントを受託するフリーのプロダクトマネージャーというのも需要があるかもしれませんね。 

チケットキャンプのリニューアルをケースとしたデザイナー主導のチーム開発について。ある意味、ひとつ前のスライドにあったようなマネジメントの外部依託の事例のようにも見えます。

こちらもひとつ前のスライドと共通するものが多く、合わせて見ておきたいスライドです。 

デザイナー主導のチーム開発からスクラムまで色々なスライドが紹介されています。どれも一見の価値あり。

職能別組織にするのか、事業別組織にするのか。これはデザイナー以外のエンジニアやPMの組織にも共通する話ですね。

PMの役割

▼ pmjp#4に出席して分かったPMとPMMの違い – aomeganeビジョン | 五反田で働くプロダクトマネージャーのブログ

プロダクトマネジメント担当とプロダクトマーケティング担当は兼任すべきか、という問題。これは担当する人の能力次第ではないかと思う。プロダクトマネジメントのExecutionとプロダクトマーケティングのExecutionを同時に担当するのは結構大変なんじゃないかという気がしています。 

PMはSQLを使えるようにすべし、というのは私も何度か言及していますが、その理由が明確に示されています。
SQLを覚えて仮説設定し分析することは、エンジニアリングのバックグラウンドのないPMが計算論的思考を身につけるきっかけになるのではないかと個人的には思っています。
ところで記事中で紹介されているre:dashは本当に便利。