この記事は エムスリー Advent Calendar 2017 の24日目の記事です。
この記事では、プロダクトマネジメントと新規サービス開発についてお話します。
1. はじめに
エムスリー株式会社ではエンジニアリング強化の一環として12/1からCTO+VPoE（Vice President of Engineering）制度に移行し、私、@yamamutekiが初代VPoEを務めることになりました。最近は採用活動などに力を入れていますが、本業はプロダクトマネージャーで、新規サービス開発や既存サービスのテコ入れを担当しています。今回はプロダクトマネジメントと新規サービス開発について簡単にお話できればと思います。本文では、最初に、プロダクトマネジメントと新規サービス開発の関係についてお話し、次に、プロダクトマネジメントを活用した新規サービスの作り方についてお話します。最後に、プロダクトマネジメントと新規サービス開発に終わりはないことを示して、結びます。クリスマス・イブも16時を回っておりますので、本日中に公開できるようにどんどん進めます。出展などリファレンスや例えばなどの具体例は後からちょいちょい追加したいと思いますのでその点はご容赦ください。ワーディーなのでそのうち図でも挿入するかもしれません。
2. プロダクトマネジメントと新規サービス開発の関係
２.１. プロダクトマネジメントについて
昨今、注目を浴びているプロダクトマネジメントについて簡単にまとめると、製品に注目して経営を行う手法と言えます。言葉自体はアメリカを中心に古くから存在し、P&Gなどの活動が有名です。最近はIT業界でも注目され、各種カンファレンスも盛り上がっていますので詳細はそちらを参照してください。
2.2. プロダクトマネジメントとプロジェクトマネジメントとの違いについて
簡単に説明すれば、プロダクトマネジメントはWhatとWhyに注目します。一方で、プロジェクトマネジメントはHowとWhenに注目します。プロダクトマネージャーは一般に製品のCEOとして、その製品の普及や、その製品から得られる収益にまで責任を持ち、製品の開発など、製品に関する特定のプロジェクトを管理するプロジェクトマネージャーに比べて責任範囲が広いのが特徴です。
2.3. プロダクトマネージャーのバックグラウンドについて
元々、消費財の分野から発展したプロダクトマネジメントですが、今回対象とするWeb系サービス開発を中心に考えると、ビジネスサイド等の非エンジニアが推進する場合とエンジニアが推進する場合が考えられます。それぞれ以下のような強みと弱みがありますが、結論としては、そのサービスが展開される事業の特性を考慮して、どちらのバランスを優先するか、戦略的に決定すべきです。
非エンジニアが推進する場合
強み：一般にビジネスの知識が十分あり、マーケットや競合製品、エコシステムをビジネスレベルでよく理解している場合が多い
弱み：一般にマーケットの既存サービスに影響を受けやすく、エンジニアリング的に差別化した製品を生み出すことが難しい
エンジニアが推進する場合
強み：一般にテクノロジーの知識が十分あり、テクノロジーをエンジニアリングレベルでよく理解している場合が多い
弱み：一般に製品の開発は出来るが、マーケットの中で収益を十分に稼げる数の顧客に受け入れられ、生き残る製品を生み出すことが難しい
2.4. 新規サービス開発を支えるインベンションとイノベーションについて
プロダクトマネジメントを活かして新規サービスを開発するという文脈では、インベンションとイノベーションの両方を加速するという観点が重要です。それぞれの違いは以下の通りです。インベンションには成功するが、イノベーションまで至らないという失敗はよくあるパターンなので最も注意が必要です。
インベンションとは
インベンションとは発明であり、どの問題をどう解決するかを定義します。
イノベーションとは
イノベーションとは発明の普及であり、どの製品をどのマーケットで展開するかを定義します。既存のインベンションを、新しい製品 x 新しいマーケットで展開するようなイノベーションもありえます。
2.5. 2つのフィットとスタートアップサイエンス
昨今、スタートアップサイエンス的な理論が着々と整備され、新規サービス開発に素晴らしい枠組みが提供されつつあります。その中でも以下の２つのプロセスは重要です。これらはプロジェクトの初期の段階で十分に検討しておく必要があります。インベンションには成功するが、イノベーションまで至らないという失敗があるのと同じで、Problem / Solution Fitには成功するが、Product / Market Fitに至らないという失敗もよくあるパターンです。
Problem / Solution Fit
プロブレム・ソリューションフィットとは、言葉の通り、どの問題をどう解決するか、を定義します。つまり、上記のインベンションと深く関連があります。
Product / Market Fit
プロダクト・マーケットフィットとは、言葉の通り、どの製品をどのマーケットで展開するかを定義します。つまり、上記のイノベーションと深く関連があります。
2.6. インスピレーションと仮説検証の重要性
インベンションでもイノベーションでも、Problem / Solution FitでもProduct / Market Fitでも、インスピレーションは重要です。人間の脳は過去の些細な記憶でもほとんど覚えていると言われており、多数のことを一瞬で結びつけて考えることが出来るので、ひらめきによって製品を考えることが出来ます。一方で、その脳の働きは生存競争で生き残るために短期的な行動を促す簡略化されたモデルになっているとも言われており、長期的な正解を保証するものではないとも言われています。プロダクトマネジメントや新規サービス開発では人間のこれら両方の性質を生かす、仮説検証という作業が重要です。
3. プロダクトマネジメントを活用した新規サービスの作り方
3.1. チームを作る
さて、必要最低限の前提知識を説明したので、いよいよプロダクトマネジメントを活用した新規サービスの作り方について説明したいと思います。なにはともあれチームを作りましょう。とは言え、チームもインクリメンタルに作っていくのがポイントです。最初は呼び方はともあれプロダクトマネージャー一人から始まります。その次にチームに２人くらい追加して、仮説検証チームに拡大します。その後、仮説が検証できたらまた２人くらい追加して、プロトタイプ開発チームに拡大します。その後２人くらい追加してテストマーケティングでもやってみましょう。その後、また２人くらい追加して、ファーストユーザー向けのファーストリリースチームに拡大します。その後、また２人くらい追加してセカンドユーザー向けの製品を開発しつつ、ファーストユーザーの要望を満たすための保守開発も行うチームを作りましょう。ここまでくれば一般に立派なチームが出来あがります。
3.2. 仮説の検証
話が前後しますが、チームを作ったらまずやることは仮説の検証です。色々な手法がありますが、個人的には以下の２軸で仮説を深掘りしていくのがオススメです。どちらの場合もビジネスゴールがはっきりしていないと迷子になるので、仮説の検証に入る前に、期待収益やドメインをはっきりさせておく必要があります。
仮説をなぜなぜで深掘りしていく
その製品のその特徴はなぜユーザーを満足させるのか、なぜなぜを繰り返しながら、前提の証明が不要なほど自明になるまで分解していきましょう。自明なように見えて、自明じゃないことが多々あるので注意が必要です。また、掘り下げの方向が行き詰った場合、なぜに加えてそもそも、という掘り下げが有効な場合があります。
検証された仮説の前提となる前提仮説を深掘りしていく
仮説の検証というのは、必ずある一定の前提に則って行われます。せっかく検証した仮説が外れる原因となる多くは、その前提仮説が間違っている場合です。検証が単に甘かったり、データの取得方法が良くなかったりという部分に気をつけるだけでなく、前提仮説が正しいか、自明になるまで必ず検証しましょう。
3.3. プロトタイピング
ある程度の仮説検証が進んだら、並行してプロトタイピングを始めましょう。これもインクリメンタルにやるのがポイントです。HTMLやプログラミング言語を使ったプロトタイプは最終段階まで作成してはいけません。最初はコピー用紙に手書きで十分です。身近な人にこんなサービスがあったら利用したいか聞いてみましょう。場合によっては身近な人では不適当な場合もありますが、聞かないより聞いたほうがマシですし、聞いてみた上で適当な人にも聞いてみましょう。コピー用紙で感覚が得られたら、パワーポイントやエクセルなどに移行します。くれぐれもHTMLのモックアップやフォトショップなどの時間が掛かるツールはご法度です。理由は次のヒアリングまでに確実にバージョンアップさせるためです。最低１００回は書き直せるツールを利用しましょう。その製品を買ってくれることが確実になったら、HTMLや各種プロトタイプツールレベルのモックアップを作ります。サービスの規模によりますが、一般にはここまで来るのに３ヵ月〜6ヵ月はかかるはずです。
3.4. テストマーケティング
紙でも良いのでプロトタイプが用意できたらテストマーケティングを始めましょう。仮説検証やプロトタイプのヒアリング対象から選定するとスムーズです。ポイントはこのシステムを本当に買ってくれるか、コミットメントが得られるかどうかを確認します。様々な理由から、買いたいと口で言っても、実際に買わないユーザーは多数います。実際に買ってくれるかどうか、予約販売などの手法を使って具体的に確認しましょう。テストマーケティングの結果に寄っては製品化しない（＝販売できない）場合があることは一言添えておきましょう。
3.5. ファーストユーザーの選定
ファーストユーザーの選定はプロダクトマネジメントと新規サービス開発において最も重要な作業の一つです。テストマーケティングの対象者の中から要求の高すぎないユーザーを選定します。状況によっては、ファーストユーザー群として複数人に同時に展開したほうが良い場合もありますが、その場合でも最初は１名のみに絞った方が無難です。ファーストユーザーの要求が高すぎると開発の主導権を顧客に握られてしまい、プロダクトマネジメントそのものが成り立たなく場合があるので注意しましょう。ファーストユーザーからの要望は、セカンドユーザー以降に展開したいものだけを優先的に実装しましょう。無料で利用してもらうという手もありますが、費用対効果を検証したいなら費用を負担していただくのがベストです。というのも有料で買ってもらえないならテストマーケティングに失敗しているといえます（とは言え、初期数ヶ月無料、という作戦はありえます）。
3.6. セカンドユーザーの獲得とPDCA
ファーストユーザーが十分満足したら（＝文句を言わなくなったら）、ついにセカンドユーザーにスケールします。ファーストユーザーが２人になったつもりで対応しましょう。そしてセカンドユーザーを満足させたらサードユーザーに…と次々と繰り返します。この頃には、製品そのもの開発よりも、リードの獲得などマーケティングがボトルネックになっているケースが多いと思います。ここまで来たらプロダクトマネジメントと新規サービス開発の一つのマイルストーンを乗り越えたと言えるでしょう。
4 プロダクトマネジメントと新規サービス開発に終わりはない
4.1. 競合製品への対応
Problem / Solution FitでもProduct / Market Fitも満たす画期的なサービスを投入すると必ず競合が表れます。基本的な対応として競合の動きに振り回されず、自身のサービスを磨くことに時間を割くほうが無難です。それでも気になるという場合は、市場にチャレンジする立場であればより差別化する、市場を独占する立場であれば同質化するという方法があります。どちらの場合も、実行前にかならず仮説検証とプロトタイプ、テストマーケティングを忘れないように実施しましょう。新規サービス開発では勝つべくして勝つのが原則です。
4.2. ジャンプ
製品がある程度の機能を備えてくると、マーケティングを頑張っても、その機能で満足する一定の購買層を満たしてしまい、売上が伸びない状況に遭遇する事があります。そんな時はジャンプを検討してください。十分に仮説検証を行っているのであれば、購買層に合わせて本質的な開発の方向性を変えるピボットは十分に検討されているはずなので、本質的な開発の方向性を変えるのではなく、本質的な開発の方向性を大きく前に進める大型の機能やより多くの購買層を満足させる機能を開発します。現在の製品を買わないユーザーの声を聞いてみましょう。
4.3. 後継者の育成、採用とチームのスケール
プロダクトマネジメントを使いこなせる後継者をどうやって育成するかは、プロダクトマネージャー共通の悩みだと思います。ここまで書いてきた内容からしても、プロダクトマネジメントには少なくない知識と経験が必要で、消費財のプロダクトマネージャーならまだしも、ITサービス開発のためのプロダクトマネージャーとなると、エンジニアまたは非エンジニアとしてもそれぞれの素養が必要です。一部でそのような教育制度も検討されているようですが、それらが普及するには後数年は掛かりそうです。それまでは既存のプロジェクトマネージャーの下に、プロダクトマネージャー候補生を付けて、アプレンティスシップ・パターンで広げていくのが現実的と思われます。そのためには採用も重要ですね。また、一人のプロダクトマネージャーが複数のプロジェクトを兼任せざるを得ない状況はどこも変わらないと思いますので、チームのスケールのためにも、一人でも多くのプロダクトマネージャーの育成、採用がビジネス成長のポイントになると考えています。
4.4. 他の業界に学ぶ
本文でも触れたようにプロダクトマネジメント、プロダクトマネージャーというのは元々消費財の世界の文化です。とは言え、昨今、Web業界でも注目され、実際に役に立っているのが事実です。このように、他業界のベストプラクティスをWeb業界に工夫して適用していく例は、これまでも他に多数存在し、今後も増えていくと思います。私もエムスリーのVPoEとして、同業者のみならず、積極的に他の業界に学んでいきたいと思います。
5. 結び
いかがでしょうか？本記事ではプロダクトマネジメントと新規サービス開発についてお話しました。思いつくまま書いていたらがっつりフルペーパー並みの量になってしまいました。本記事はエンジニア向けの内容で、読者もエンジニアを想定しています。是非、多くのエンジニアにプロダクトマネジメントと新規サービス開発に興味を持って頂ければと思います。メリークリスマス！
A1. 宣伝
エムスリーでは日本・世界の医療をイノベーションするための仲間を募集しています。特にプロダクトマネージャーを含むエンジニア採用には力を入れていますので、我こそはと思うエンジニアはコメントやメッセージでご連絡ください。一緒に日本・世界の医療をイノベーションしましょう！
https://corporate.m3.com/recruit/job/engineering/
A2. 参考
たくさんあるので後で追加