小さなごちそう

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

読書メモ: 教育者のための「計算論的思考」入門ガイド

先日発売したComputational Thinking(CT、計算論的思考)の入門書を早速購入。著書の一人は以前このブログでも紹介したキキ・プロッツマン氏。 

Computational Thinking and Coding for Every Student: The Teacher’s Getting-Started Guide

Computational Thinking and Coding for Every Student: The Teacher’s Getting-Started Guide

 
  • なぜCTが必要なのか
  • Computer Science(CS)との違いは何か
  • ExcelやWordの使い方を習うのはCTではない
  • CTの基本4要素、Decomposition、Pattern Recognition、Abstract、Automation(Algorithm)とは

などが平易に解説されている。うちの娘の小学校にもコンピュータークラスがあるのだが「パソコンの使い方」の域を出ていない。日本におけるCT普及のためにも日本語版をぜひ出して欲しい。

CTの4要素はエクササイズがいくつか用意されていて実際に子供に教える際に参考になりそう。ただ大人に教えようとするともう少し日常的な課題や実務につながるような例が欲しいところ。

CTとはいわばコンピュータを使って問題解決をするために必要な考え方。ソフトウエア領域でプロダクトマネジメントに関わる人にとってはシステム思考と合わせて必ず身につけるべき思考法だと思われる。

読書メモ:スノーピークのプロダクト開発とマネジメント

アウトドア・ブランドのスノーピーク、山井社長による著書。 

スノーピーク「好きなことだけ!」を仕事にする経営

スノーピーク「好きなことだけ!」を仕事にする経営

 

  「私達は自らもユーザーであるという立場で考え、 お互いが感動できるモノやサービスを提供します」

これはスノーピークのミッション・ステートメントに含まれる一文だ。

社長自身が熱心なアウトドア愛好家であり、プロダクトの企画には社長である著者自身が全て目を通す。ユーザーとして使いたいと思わないプロダクトの企画は承認しない。
著者自身が本書中で尊敬する経営者としてスティーブ・ジョブズを上げているが、かつてのAppleと同様に社長自身が大プロダクトマネージャーとしてプロダクト開発の舵取りをするタイプの企業のようだ。

ユーザーから価格の高さと販売店での品揃えの悪さを指摘されたのをきっかけに、問屋経由から直接取引に変更して流通コストをカット。さらに品揃えやショップ体験の改善のため、全国に250店の正規代理店網を構築する。

スノーピークはユーザー同士のつながりの強いコミュニティブランドで、本書中では類似ブランドとしてハーレーダビッドソンがあげられている。高価格商品である、コミュニティブランドである、ショップ体験を重視する、ユーザーイベントを定期開催する、ファンによるクチコミが新規顧客を増やす、など色々とハーレーと共通するものを感じる。

本書を読んで、スノーピークのテントをバイクに積んでキャンプに行ってみたくなった。今年の夏に挑戦してみようかな。

読書メモ:Harley Davidson Japan(HDJ)のマネジメント

昨年、10数年ぶりにバイクに乗ったところ思いのほか楽しく、勢いで大型二輪の免許を取得してしまった。ドラマ「Beautiful Life」でTW200に乗るキムタクに感化されて普通二輪の免許したので、教習所は15年ぶり。以前乗っていたのが120kg程度のFTRだったこともあり、200kgを超える大型の重量になかなか慣れなくて苦労した。(ちなみに普通二輪免許を持っていれば、12回の実技教習/10万円程度で大型二輪の免許が取れる)

そんな経緯で大型バイクを色々と物色しているなかで、Harley-Davidsonの正規販売店を訪問した。店舗の雰囲気はこんな感じ。

f:id:tannomizuki:20161204123625j:plain

ガジェット好き向けに一言で説明すると、Apple Storeっぽい。バイク本体だけでなく、アパレルやグッズも販売していてすっごくオシャレ。

その場でハーレーを試乗。エンジン音と体に伝わる鼓動、軽くクラッチをつないだだけでずるずると前に引きずられるトルク感にぐっと心を鷲掴みにされた。実はハーレーは「革ジャンを来たアウトロー」のイメージが強くて、ファッション的にはDucati Scramblerに惹かれていたんだけど、販売店での経験ですっかり関心が移ってしまった。

興味を持った勢いで車体以外についても色々と調べてみたところ、Harley Davidson Japan(HDJ)のマネジメントがとても面白かったのでメモ。

日本におけるハーレーダビッドソンの状況
  • 751cc以上の二輪市場におけるハーレーのシェアは24.2%で首位(2002年当時)
  • モノを売るのではなくコトを売るライフスタイル・マーケティングを実践
  • 二輪市場が縮小するなかで(1982年に328万台→2002年には77万台と減少)、販売台数を伸ばす(1982年に1099台→2002年には10,869台と10倍に)
  • ハーレーオーナーの平均年齢は37歳を維持している。これはバイク保持者全体の平均年齢よりも10歳若い。若い層を新規顧客として獲得できており、ユーザーの高齢化が進んでいない
プロダクトについて
  • ハーレーは実用ではなくレジャー用途のバイク
  • オートバイを売るのではなく、ライフスタイルを売る
  • ハーレーのプロダクトコンセプトは「Look,Sound,Feel」であり、「走る、曲がる、止まる」ではない
  • ハーレーの耐用年数は50年以上。一生同じハーレーを乗り続けるオーナーもいる。買い替えではなくカスタマイズで売上を伸ばす必要がある。よって販売した後に顧客と関係を継続する必要がある。
  • HOG(ハーレー・オーナー・グループ)というオンライン/オフラインのユーザーコミュニティ
マーケティング戦略
  • HDJはマス広告を出稿しない。店舗とイベントを顧客接点として新規顧客を獲得している
  • イベントはブルースカイヘブンを代表に年間多数開催。現オーナー以外も来場し、見込み顧客獲得の機会になっている。
  • 付き添いでふらっと入店した客が一目惚れして購入を決めてしまうこともある
  • 接点をもった見込み顧客の情報をDB管理してナーチャリングする。
HDJの販売店改革
  • 元々バイク店の多くは町の自転車店だったため、以前は店内は薄暗く作業場のような雰囲気だった。
  • ハーレーの価格は平均200万円以上する高級品。高級品を購入する雰囲気ではない。女性も入店しづらい。
  • 「息子が店を継ぎたくなる、彼女を連れてきたくなる店に」
  • リテールエンターテイメントを標語に販売店を改革。バイクだけでなくアパレルも販売。
HDJにおける営業部門の役割
  • HDJの営業パーソンは販売代理店の経営コンサルタントとして、販売店の経営と業務の改善を指導する。
  • HDJは販売店の財務諸表を把握している。
  • 売店を管理するSFAと、顧客を管理するCRMの二本立て
  • 認知、来店、試乗、見積もり、購入のプロセスを管理する。
  • 購入が少なければどのアクティビティを増やせばよいのか考える。
  • 値崩れの原因となるため販売店に対してインセンティブマージンを設けない。

このメモは以下の書籍を元にまとめた。 

ハーレーダビッドソン ライフスタイル・マーケティング

ハーレーダビッドソン ライフスタイル・マーケティング

ハーレーダビッドソン ジャパン実践営業革新

ハーレーダビッドソン ジャパン実践営業革新

なぜハーレーだけが売れるのか (日経ビジネス人文庫 ブルー み 2-3)

なぜハーレーだけが売れるのか (日経ビジネス人文庫 ブルー み 2-3)

 販売店での試乗で経験したのはまさに「Look,Sound,Feel」の体験。

そういえば通っていた教習所でもハーレーの試乗会が開催されており、確かにリアルな接点を意図的に作って新規顧客の獲得機会にしているようだ。

見積もり時はローンプランも提示して手に届く感を与える、「ハーレーはゆったり走って楽しむ乗り物」と説明して配偶者を安心させる、などの本で書かれていた通りの接客も経験したが、まさに狙いどおりの効果をもたらしていると実感したw

はてなブログでブログを書いているオーナーの方もいるが、とても楽しそう。

ケーススタディは当事者にならないとなかなか身にならないつまり仕掛ける側か顧客側かを経験すべきだからとりあえずXL883Nを買うことにした。

ちなみに883のデザインはダイス・ナガオさんという日本人が手がけている。こういう動画も僕から見るとAppleのジョニー・アイブのビデオっぽくってブランドとの距離が近づいてしまう。

www.youtube.com

Product Principles(製品の原理原則)とは

(この記事はProduct Manager Advent Calendar 2016の24日目のエントリーです)

Product Principles(製品の原理原則)とは、プロダクトの方向性を決める意思決定の基準となるものだ。Inspiredの13章で解説されているものを超ざっくり要約すると下記のような感じだ。

  • プロダクトに関する信念や意図を宣言したもの
  • トレードオフや優先順位の判断に役に立つ
  • 機能リストではないし、具体性を持ったものではない
  • 例えば映画サイトにおいて「映画コミュニティの意見は専門家のレビューより価値がある」という原則を定めたとする
  • 制作会社から「専門家の映画評を載せたい」とリクエストされたときに容易に可否を判断できる 
Inspired: 顧客の心を捉える製品の創り方

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

 

 確かにプロダクトのコンセプトとしてターゲットや提供価値を明確にしていても、プロダクトマネージャーとして判断に迷ったり、チームの意見が割れたりする局面がある。

例えば、競合の新機能は評判が良いと聞いた、大口の見込み顧客から要望を受けた、といった状況で「際限のない機能追加の誘惑」にかられたりする。スポーツカーとファミリーカーとトラックの特徴をもった自動車を作るのは難しいが、物理的な制約がないソフトウェアの場合、「やらない判断」をせずに次々と機能を付け足していくことができてしまう。

そんな時は、「プロダクトが大切にすべきこと」が言語化されており、原理原則として共有されていれば議論になったり迷ったりすることなく判断できる。

こちらのスライドの説明もわかりやすい。

 

具体的にこうした原理原則を定めているサービスの例を探してみたのだが、ちょっと適当なものが見つからなかった。

下記はGoogleのミッション・ステートメントだが、具体的でProduct Principlesに近いように感じた。

1. Focus on the user and all else will follow.
2. It’s best to do one thing really, really well.
3. Fast is better than slow.
4. Democracy on the web works.
5. You don’t need to be at your desk to need an answer.
6. You can make money without doing evil.
7. There’s always more information out there.
8. The need for information crosses all borders.
9. You can be serious without a suit.
10. Great just isn’t good enough.

下記の記事ではTrelloのProduct Principlesが紹介されている。

もう少しわかり易い例が見つかったらまたこのブログで紹介でしてみたい。

参考

下記はそれぞれFacebookとAsanaのDesign Principles(Product Principlesではない)。
▼ Facebook Design Principles
Developing Design Principles - Our Design and Product Experience Goals

Design Principlesについては下記のサイトで色々なサービスのものがまとめられていた。
▼ Design Principles FTW

因果ループ図でプロダクトの改善点を考える

システム思考では、システム(物事が動くカラクリ)を因果ループ図(Causal Loop Diagram)によってモデル化する。例えば、人口の増加は下記のようにモデル化される。

f:id:tannomizuki:20161213205328p:plain

出生数が増えれば人口が増える。人口が増えればさらに出生数が増える。このサイクルだけだと無限に人口が増加していくが、死亡によって人口増は抑制される。人間の寿命の存在がこのシステムの制約(Constraints)の一つになっている。

f:id:tannomizuki:20161213205444p:plain

ここに医療の発展や戦争などの影響を考慮すると、下記のようになる。

f:id:tannomizuki:20161213210715p:plain

因果ループ図ではシステムの状態を表す変数(Variables)を書き出し、変数同士の関係を矢印で示す。変数間の相関の正負(片方が増えれば連動してもう一方も増えるのか、逆なのか)を+-の記号で表す。因果ループ図は下記の参考図書でわかりやすく解説されている。 

 プロダクトやプロセスの改善を通じてシステムのパフォーマンスを最大化するのが、プロダクトマネージャーの仕事だ。その際、この因果ループ図を書くと改善すべきポイントを発見しやすくなる。

フリマアプリを例に因果ループ図を書いてみよう。売りたい、または買いたいと思う取引希望者が増えれば、売買の成立が増える。売買の成立が増えれば手数料売上が増える。売上が増えると広告費を増やすことができ、新規ユーザーを獲得できる。ユーザーが希望通り売買できればリピート取引やクチコミが増える。

f:id:tannomizuki:20161213210958p:plain

さて、このシステムの最終アウトプットが手数料売上だとすると、このシステムのパフォーマンスを最大化するにはどうすれば良いだろうか。広告の投下量を増やすことで短期的な売上は伸ばすことができるが、投資回収に必要な期間は長くなり、システム全体の効率が上がったとは言えない。

因果ループ図を元に考えると手数料売上の先行指標は売買成立数となる。そこで売買成立数を制限しているものが何か考えてみよう。

買う側の立場で考えると、いかに出品が多くても欲しいものがなければ買わないし、値ごろ感がなければやはり買わない。そうすると、売買成立数の制約になるものとして、
1. 出品ニーズと購入ニーズのアンマッチ
2. 出品金額と相場とのアンマッチ
があげられそうだ。

f:id:tannomizuki:20161213211021p:plain

そこでニーズのアンマッチを解消する施策として、
a. 販売実績の多い品種を売り手に提示することで、出品傾向を変える
b. 広告のクリエイティブや媒体を変更することで、売り手が多く買い手が少ない品種に対してニーズを持つ会員を増やす
というのはどうだろうか。

出品金額と相場のアンマッチを解消する施策としては、
c. 売買成立実績をもとに出品時に相場価格を提示する
などが考えられそうだ。

a,cはプロダクトの機能追加によって、bはマーケティング活動によって改善できる。

以上の例のように、ビジネス・システムの全体像を因果ループ図で描き、ユーザー心理を踏まえてボトルネックになる箇所を特定することで、改善施策を検討しやすくなる。

KPI設計を行う際に因果ループ図を書いておくと、活動の因果関係に関する認識を関係者間で合わせやすい。このフリマアプリの例では、ニーズのマッチングを考慮せず新規ユーザー数だけを指標にしてマーケティング活動を行うと、ユーザーのLTVが上がらない可能性がある(ユーザー増加量と売買成立数の増加量が相関しない)。よって入会したユーザーに期待するアクティビティを考慮して、ユーザー獲得活動をコントロールする必要がある。例えば「新規登録ユーザーのうち、注力品種に購買意欲を示したユーザーの数」といったKPIを設定する。

なお、少ない労力で大きくパフォーマンスを改善できる箇所を、介入点(leverage points)という。限られたリソースで最大の効果を得るためには、この介入点をいかに発見するかが重要となる。

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

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

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

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

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

CyberZに入社する前はベンチャー企業で2年ほどCTOをつとめていました。iPhoneの利用者が増えて、GoogleAndroidを出し、スマートフォンが一般ユーザーに普及し始めていた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については僕も学び初めたばかりなので、このブログで改めて詳しい解説をしたいと思っている。

【関連記事】

tannomizuki.hatenablog.com