小城久美子（@ozyozyo）

ソフトウェアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウェアエンジニア、スクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを活かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』（翔泳社）共著者

「エンジニアのためのプロダクト開発」連載、今回から本格的にプロダクトづくりの考え方についてお話ししていきます。第二回では、プロダクトを成長させる開発について解説します。

プロダクトを成長させない開発

エンジニアが次々に新しい機能を開発すれば、必ずプロダクトは育つでしょうか。残念ながら答えはNOです。

私はいつもこの話を以下の魚の絵（蛇足のダソくん）で説明します。もともと左側の魚のイラストだったプロダクトが一年後には良くわからない生物になってしまいます。

●SNSでエゴサーチをするとユーザーが「鼻があるとかわいい」と言っていた
●市場調査の結果、陸上対応で差別化をすると大きな市場が取れそう
●顧客に競合のような立派なヒレがないと購買できないと言われた
などと、各々の機能はしっかりした根拠に基づいて追加されています。

ユーザーの声を聞いてつくった、ダソくんの何が悪いのか？

一見、多くのユーザーの声を反映していそうな蛇足のダソくんですが、「鼻があるとかわいい」と言っていた人たちにかわいいと思ってもらえるビジュアルになっているでしょうか？ 重たいヒレがついていても、陸上で競合製品より速く走ることができるでしょうか？

いろいろな人の声を聞いた結果、大きな開発コストが掛かっている高額なプロダクトになるにも関わらず、陸上で走りたいユーザーは車を買い、かわいいイラストが欲しいユーザーは『いらすとや』さんで十分かもしれません。

ユーザーの声を聞くとはユーザーの言いなりになることではありません。プロダクトをつくるプロは私たちなので、ユーザーが欲しいと言ったものをそのままつくるのではなく、ユーザーが思いつきもしなかった解決策を提案することで多くのユーザーを幸せにすることが腕の見せ所です。

このプロダクトは何であるのか？

ダソくんにならないために、まずこのプロダクトが何であるのかを捉える必要があります。

しかし、このとき例えば「チャットツール」や「勤怠管理システム」のようなカテゴリを表す名称をつけてしまったら、第一回でもお話ししたようにその名前の範囲内の機能しか発想しづらくなってしまいます。

Slackがただ、チャットツールをつくろうとしていたら、あの「スポポ」という軽快なサウンドやリアクション絵文字のカスタマイズ性を優先度高く対応していたでしょうか？ 彼らの歴史をひも解くと、もともとはオンラインゲーム会社であり、仕事のコミュニケーションをより楽しく魅力的にすることを望んでつくったチャットツールであるからこそ、今の成功があると私は考えています。

つまり、プロダクトをつくるときは、何をつくるかと同様に、なぜそのプロダクトをつくるかも重要になります。Slackでいうと、それは「Make work life simpler, more pleasant and more productive.（仕事をよりシンプルに、楽しく、生産的に）」というミッションに現れています。

ミッションと機能をひも付ける仮説のミルフィーユ

しかしながら、ミッションは一つ一つの機能の意思決定をするには抽象的すぎます。そのボタンが赤いべきか、青くあるべきかの意思決定をするためには、ミッションだけでは検討することが難しいです。

私は、プロダクトの意思決定をするために、抽象的な概念から具体的な機能までをつなぐ仮説の連鎖を四つの階層で考えています。それを図式化したものを「仮説のミルフィーユ」と呼んでいます。

プロダクトとは、上からCore、Why、What、Howと四つの階層の階層に分割できます。これらは、上に行けば行くほど抽象的で下に行けば行くほど具体的になっています。そして、上の階層が下の階層の意思決定の根拠になる構成です。

つまり、ミッションやビジョン(Core)を噛み砕いて、「誰」を「どんな状態にしたいか」(Why)を言語化し、それを満たすユーザー体験の仮説を立てて、その体験を実現できる機能のUIを検討する、という関係です。

この流れをプロダクトチーム全員で意識することで、抽象的であっても何のためにそのプロダクトをつくるのかを忘れずに機能一つ一つの意思決定ができるようになります。

どこの仮説まで正しかったのかを確認する

仮説のミルフィーユの効果は機能の意思決定だけではありません。つくった機能が正しかったかの確認でも効果を発揮します。

プロダクトをつくることは仮説検証の繰り返しです。例えば、一つの機能をつくってそれが予想していたよりユーザーに使ってもらえなかった場合、

●Howの階層: UIが悪かったのかもしれない
●Whatの階層: 値付けが悪かったのかもしれない
●Whyの階層: その課題を解決してほしい人がいなかったのかもしれない

と、階層ごとに使ってもらえない理由を検証できます。

もし、Whyの階層で間違っているのであればその機能だけではなく他の機能にも影響を与える大問題ですが、Howの階層の問題であればUIを直して再挑戦すればよくなります。

プロダクトの仮説の中でどの階層から間違えてしまったのかを分離して考えることによって、プロダクトの成長方針の正しさを確認することもできます。

4階層は上から下に検討するのではない

このようなお話をすると、「まずはプロダクトのCoreとなるビジョン・ミッションを固めなければいけない」と考える方が多くいらっしゃいます。

しかし、この4階層はCore→Why→What→Howと順番につくっていくことはおすすめしません。上に下にと行ったり来たりしながら検討をすすめることをおすすめします。

なぜなら、プロダクトの未来の成長戦略を考えるためには、仮説に仮説を重ねなければいけないからです。

まずビジョンを定めたとしても、ユーザーがそのビジョンを望んでいない可能性も大いにあります。ウォーターフォール的に上から順番につくるのではなく、できるだけはやくユーザーが触れるような状態をつくって、目指す成長戦略の仮説検証を繰り返しながら、仮説構築を強めていくことが成功への近道だといえるでしょう。

チームで強い4階層を合意する – コンウェイの法則

エンジニアの皆さんであれば、「コンウェイの法則」をご存知の方も多いでしょう。コンウェイの法則とは、以下のようなものです。

例えば、LINEアプリにはタブが五つありますが、その中のニュースやVOOM、ウォレットなどはそれぞれ別組織ではないかと想像することができます。そして、蛇足のダソくんであれば、間違いなくリアルなヒレをつくっている組織は本体とは別部署でしょう。

プロダクトをつくるためにはチームを小さく分けることでコミュニケーションコストが下がり効率化することができます。

しかしながら、プロダクトの全体像を捉えないままに目の前の仕事のことだけを考えてしまうと、本来目指すべき全体にとっての最適とは別のベクトルに進んでしまうこともあるのです。

Howの専門家であるエンジニアこそがそのHowのゴールであるCore、Why、Whatを意識しながら開発を進めることで、プロダクトを成功に導くことができます。

そのため、自分の担当領域の階層だけを知っておくのではなく、全体を俯瞰して理解をしておく姿勢をぜひ持っていただきたいと考えています。

もしCoreやWhyをよく知らないようであれば、躊躇せずに聞いてみてください。

もしその答えが不明瞭だったなら、プロダクトチームで仮説のミルフィーユを検討してみることで、目の前の開発しているタスクもよりよくすることができるはずです。

CoreやWhyの他社事例を知るには

私はエンジニアとして仕事をしていた頃は、ミッションやビジョンはきれいな標語のようなものだと考えていました。しかし、プロダクトをつくる上ですべての意思決定の根拠となる指針だと今は感じています。

はじめてプロダクトのCoreやWhyを考えるなら、ぜひいろいろなプロダクトの事例を見てみてください。

最近では多くのプロダクトが採用を目的として、プロダクトの概要を公開しています。日本のスタートアップはCulture Deckの中にプロダクトの戦略を簡単に載せているものがいくつか見つかります。

いくつか、プロダクトのCoreやWhyが分かりやすく書かれていたもののリンクを紹介しておきます。

●Retty株式会社 中途PM向け会社説明資料（FY2022）
●Pococha CultureDeck
●株式会社スマートバンク

ぜひ、Core～Whatを可視化してみてください

プロダクトが成功に向かわない機能追加をしてしまわないために、ぜひプロダクトの全体像を向き合う時間をつくってみてください。

チームで意見が合わないときには、おそらく一つ上の階層で認識の食い違いがあります。今どの階層の話をしているのかを、仮説のミルフィーユを指差し確認しながら、議論してみることをおすすめします。

また、プロダクトのCore～Whatを初めて検討するときは、リーンキャンバスを使って可視化するのがおすすめです。ぜひ、プロダクトチームの皆さんで全体像の認識を合わせてみてくださいね。

おわりに

第二回は仮説のミルフィーユをつかって、プロダクトの全体像を捉えてプロダクトを成長させる開発についてお話ししました。

次回は、プロダクトのCoreをひも解いてどのようにユーザーの体験を提案するのか、より具体的にご紹介しようと思います。最後までお読みいただき、ありがとうございます。