Product Principles（製品の原理原則）とは

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

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

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

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

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

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

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

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

• 会社にはミッションステートメント（理念）がある。
• ただ交渉なミッション・ステートメントを具体的なプロダクトのあり方に翻訳するのは難しい
• 例えばEtsyのミッション・ステートメントは「より充実感があり持続的な世界に貢献するビジネスのあり方を再考する」
• 果たしてこのステートメントは、レビュー機能の設計指針を考えるのに役に立つか？
• Product Principlesはミッションステートメントを実践可能な形にするもの

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

下記は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）によってモデル化する。例えば、人口の増加は下記のようにモデル化される。

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

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

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

なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（出典：The stage and crowd at KeyArena for The International 2014）

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

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

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

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

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

以前格闘技がブームになった時は、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万人規模の人が集まりますが、それはコアな音楽マニアだけを対象にしたイベントではないからだと思うのです。「普段はゲームをやらないしルールもよく分からないけど対戦動画を見るのは好き」という層にも届くサービスにするためには、普段ゲームをやらないエンジニアの意見も必要になります。

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

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

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年で会社を変えられますか (日経ビジネス人文庫)

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

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

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

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

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

例えば、私が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のサイトが非常にわかりやすい説明が掲載されている（詳細閲覧には会員登録が必要）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

株式会社シャノンの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を定義して測定し、マーケティング活動の内容と結果の因果関係が明確になり、そして最終的にマーケティング活動を自動化する、という３つのステップを順番にクリアしていく必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

― 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作成の手戻りも無くなりました。

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

The Pragmatic Marketing Frameworkより

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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