
エヴァンゲリオンに見るプロダクト初号機リリースで気をつけたい3つのこと
こんにちは、外資系IT企業でプロダクトマネージャーをしていますハヤカワ( @kzkHykw1991 )です。
今回はプロダクトを初めてリリースする時に気をつけたいことを『新世紀エヴァンゲリオン』の汎用人型決戦兵器 人造人間エヴァンゲリオン、通称EVAを例にして、紹介したいと思います。
残念ながら、「シン・エヴァンゲリオン劇場版」の公開が再延期されてしまいましたね・・・
このnoteの3行まとめ
①気合を入れすぎてしまい、広告やプレスリリースにお金をかけたり、バグを徹底的に無くそうとして、マーケットインが遅れ、機会損失になる
②機能をつけすぎてしまい、機能過多でプロダクトが本当に価値を生み出せるのかを検証できなくなってしまう
③何を検証するか定まっておらず、とりあえずリリースをしてしまい、あとからデータが取れなくて困る
①気合を入れすぎてしまう
初めてのプロダクトをリリースする時は、やはり1st Impressionが大事だ!最初のアナウンスメントでいかに顧客認知度を上げるかが勝負だ!プレスリリースや広告に高いお金を払って爆発的にユーザーを獲得するぞ!と力み過ぎていませんか?
Google やFacebookのリリース日をどれだけの人が覚えているでしょうか?
プロダクトリリースは単なる通過点です。始まりでもゴールでもありません。確かにリリースに至るまでの労力を労い、開発チームにピザを振る舞うのは良いことです。しかしそれは社内のチームに対するお祝いであり、顧客にとってはまだ価値はありません。
有名な話で「プロダクトには価値がない。それを顧客が使ってジョブを成し遂げた瞬間に価値が出るのだ」ともよく言われます。つまり、プロダクトはあくまでも価値を届ける媒体でしかないのです。
EVA零号機(EVA-00 PROTO TYPE)もプロトタイプ(試作機)として開発され、実際の戦いでは使う予定はなく、肩部ウェポンラックもついていないのが特徴です。
零号機は作中でも他のEVAシリーズよりも情報が薄かったり、本編では語られないことが多いモデルになります。(NERVとしても大々的にプレスリリースはしていないんでしょうね)
もちろん、実際の開発の世界では"プロトタイプ"は仮説を検証するためのワイヤーフレームやインターナルでのテスト版のことを指すので、少しニュアンスが違うと思います。しかし、サービスリリースした場合でも初期のプロダクトはあくまでも市場の検証、顧客の検証、製品価値の検証をするために、MVP(実用最小限の製品)としてリリースするべきです。
その中でプロダクトを初めて世の中に出す時に気合を入れすぎると、「あれ?思ったより反応がないな?」と落ち込みチームの士気が下がったり、「徹底的にバグをなくすぞ!」と重箱の隅をつつくように時間をかけ過ぎてしまい、マーケットインが遅れ、機会損失に繋がります。
プロダクトの初期リリースは野球で言う、1回表です。まずはプレイボールするところから始めましょう。
②機能をつけすぎてしまう
気合を入れすぎるがあまり多くの機能をつけていませんか?
最初が大事ということで、思いつくあらゆる機能をつけてしまうとプロダクトの本当の価値が見えにくくなってしまいます。CEOや創業者の熱い思いやアイデアを全て作りたいという気持ちもありますし、プロダクトマネージャーや開発者たちもできるだけ多くの機能を出すことが評価に繋がりやすいです。その結果、初期のリリースでは不要な機能をたくさん付けてしまうこともよくあります。
EVA初号機(EVA-01 TEST TYPE)は、名前の通りまさにテストタイプ(実験機)にあたります。エヴァの運用データを取得するための試験用として開発されており、本機の運用データが後のエヴァシリーズに反映されているそうです。
リーン開発やMVPの考え方としても、この開発思想は完璧です。運用データ取得のために初期リリースをするというのは、データドリブンの開発であり、初期のプロダクトには必要最低限の機能を持たせ、プロダクトが本当に価値を生み出せるのかを検証することができます。
そしてこれを高速で繰り返すことで、市場の検証、プロダクト価値の検証を行う、これこそがリーン開発の考え方になります。
一方で、たくさんの機能を付けてしまうと、うまく行ったときに何がうまく行ったのか?、失敗したときには何が悪かったのか?がデータからも分かりづらくなってしまいます。そこで初期リリースは最小限の機能だけをもたせ、プロダクトが価値を生み出せるかを検証しましょう。
EVA初号機のようにまずはシンプルな機能にし、多少暴走したり、活動限界時間が短くても大丈夫です。市場(使徒)を観察し、顧客(パイロット)が製品(EVA)を使うことで、価値を見いだせる(使徒を倒せる)かどうかをデータをもとに考えることができます。
③何を検証するか定まっていない
さて、ここまでの内容で、初期リリースをいち早くすることが大事ということがわかったと思いますが、ただ闇雲にリリースするだけではいけません。
前述のように初期リリースはMVPによる市場やプロダクトの検証が目的であり、そのためのデータを集めるためのものになります。つまりリリースすることで何を検証したいのか、どう検証すればよいのかをリリース前から決めておく必要があります。
場合によっては開発段階から成果を計測するためのトラッキングツールや機能開発をする必要があるかもしれません。つまり開発に入る前から何をどう検証するのかをビジネス側と開発側が双方で理解する必要があります。
EVA弐号機(EVA-02 PRODUCTION MODEL)はエヴァンゲリオンの量産化を前提として開発された、先行量産機にあたります。アスカが「本物のエヴァンゲリオン」というように、零号機や初号機にはない武器や装備を持ち、高い性能を持ちます。
つまり、初号機のリリースによって、使徒との戦いを通して運用データを集め、戦いを検証した上で、本体性能の改善や追加の装備(機能)を増やすという改善を行えました。実際にどのような運用データを使い、弐号機を開発されたのかは分かりませんが、適切なデータドリブンでの開発体制がNERVにはあったのではないでしょうか。
検証の仕方
では実際に何を?どう?検証するべきなのかを考えてみたいと思います。そこで使えるのがジョブ理論です。
プロダクトの成功指標というと、アプリのダウンロード数やログイン数、DAUや滞在時間などを見てしまいがちです。
これらはパルスメトリクス(PULSE)と呼ばれ、定量的に評価はできますが、初期のプロダクトリリースにおいては、「価値を生み出せるかの検証」が目的なです。したがって、これらの指標ではユーザー体験の品質を計測しづらかったり、ビジネスの改善に繋げられる測定基準を設けられないため、不十分になります。
P: ページビュー(Page views)
U: 滞在時間(Uptime)
L: 待ち時間(Latency)
S: 7日間のアクティブユーザー数(Seven-day active users:週に1回以上使用したユニークユーザー数)
E: 収益(Earnings)
これらの指標はあくまでも結果(アウトプット)に過ぎません。プロダクトの検証では「価値を生み出せるのか」を検証するため、アウトプットではなくアウトカムを成功指標とするべきです。
アウトカムの計測方法はいくつかあります。
上ビルドトラップについて語った著書では、AARRR(海賊指標)や
AARRR指標
A: Acquisition (獲得)
A: Activation (利用開始)
R: Retention (継続利用(定着率))
R: Referral (紹介)
R: Revenue (購入)
HEARTフレームワーク(Happiness/Engagement/Adoption/Retention/Task Success)を提唱しています。
これらの指標は顧客の満足度を定量的に評価することができますが、UXの評価指標がベースになっていることや、初期のプロダクトリリースにおいては、まだユーザー数が少なかったりして、計測が難しかったりします。
そこで、初期のプロダクトリリースにおいて、何をアウトカムとして評価すべきか?それは、ジョブ理論におけるプロダクトが成すべきジョブ、これをどの程度満たすことができたのか?をプロダクトの成果指標とすることができます。
ジョブ理論については下記noteで詳細に説明しているので、ぜひ読んでみてください。
上記記事から引用した、例を見てみましょう。
ここでは英語の学習アプリを例に "When..., I want to..., so I can"の構文でジョブを考えています。
ジョブパフォーマーを学生としたときのジョブの例を見てみます。
When: 時間がある時に
I want to: 英語の学習に費やしたいので
So I can: 隙間時間で手軽に自分のレベルにあったやり方で英語を学べるようになりたい
このようにジョブを捉えると、顧客がプロダクトに何を期待しているか(Expected Outcome)が分かります。たとえば、今回の場合はあえてシンプルに捉えるとこのようになります。
① 学習時間の増加
② 語学力の向上
つまり、顧客は英語学習アプリ自体を欲しいわけではありません。英語を学びたいというジョブがあります。
ちなみに、もっと上位レイヤーのジョブを考えると、英語が喋れることで旅行先で現地の人とコミュニケーションができるという社会的ジョブや、なりたい自分や今まで知りえなかった世界や情報にアクセスできるようになるなどの感情的ジョブがあると思います。が、今回はシンプルに捉えてみます。
すると、この英語アプリをリリースした時に、プロダクトの成功指標として追うべきは
①ユーザーあたりの平均学習時間
②ユーザーの学習コンテンツの難易度の増加率
というような計測可能な成功指標を考えることができます。この2つが向上すれば、ユーザーのジョブが満たされるという前提にたっています。
このようにプロダクトの初期リリースはシンプルかつMeasurable(計測可能)にすることが、今後のプロダクトの方向性、ロードマップ、ひいてはビジネスの成功を左右することになります。
最後にエヴァンゲリオンのたとえで締めるとすれば、
ジョブパフォーマーを EVAパイロットとすると、ジョブは以下のようになるのではないでしょうか。
① 機能的ジョブ: 使徒の殲滅
② 感情的ジョブ: 誰かに認められたい・守りたい
③社会的ジョブ: リリスと使徒の接触によるサードインパクトを防ぎ、人類を守るため
このジョブを満たすために汎用人型決戦兵器 人造人間エヴァンゲリオンが開発され、碇シンジやアスカ、綾波レイがジョブを達成するためにEVAを"雇っている”と解釈することができます。
ジョブ理論に従えば、彼らにとっては、それがEVAだろうと、ガンダムだろうと、ジョブが達成できれば基本的には何でも良いわけです。
さて、プロダクトの初期リリースをエヴァンゲリオンで例えてみました。分かりやすくなったかは別ですが、EVAの開発方針が現代のソフトウェア開発にも通ずるところがあり面白かったです。NERVには優秀なプロダクトマネージャーがいたんでしょうね。
私もそんなPMになれるように、これからもより良いプロダクト作りのために色々発信できればと思いますので、Twitterのフォロー、noteのスキをお願いします!🙇
⚡️ “プロダクトマネージャーのあれこれ”https://t.co/o4Ki7dMhRB
— Kazuki Hayakawa | AI製品のPM (@kzkHykw1991) July 23, 2020
エヴァの例えについてはテレビ版と映画を普通に見ていただけなので間違いや表現の違いがあるかもしれませんが、ご容赦ください🙏
参考