ProductZine(プロダクトジン)

プロダクトづくりに関わる全員が知っておきたい「豊かな仮説」の立て方とは?【デブサミ2021】

【19-E-1】エンジニアに伝えたい!プロダクトマネージャーの頭の中 - プロダクトをもう一段階成長させる仮説の立て方

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/05/07 11:00

 プロダクト開発に携わっていると、全員が「素敵なプロダクト」を作ろうと奮闘しているのに、議論がかみ合わなくなったり、プロダクトが事業のビジョンと違う方向に進んでしまったりすることがある。ここで重要になるのが、仮説を立て小さな失敗を繰り返しながらプロダクトを成長させていく、いわゆる「プロダクトマネジメント」の考え方だ。この視点は、エンジニアやデザイナーをはじめ、プロダクトに携わるすべての人にとって役立つもの。ユーザーによりよい価値を提供するプロダクト開発のヒントになるだろう。では実際に、どのように仮説を立てて検証していけばよいのか。エンジニアが知りたいと思う「プロダクトマネジメント」の考え方について、エンジニアからプロダクトマネージャーになり、現在はTablyにてプロダクトづくりの伴走や研修に取り組む小城久美子氏が解説した。

目次
Tably株式会社 小城久美子氏
Tably株式会社 小城久美子氏

プロダクトマネージャーとエンジニア、プロダクトに対する視点の違い

 「自分がエンジニアだった頃に知りたかったことを中心に話をしたい」

 こう前置きし、小城氏のセッション「エンジニアに伝えたい!プロダクトマネージャーの頭の中 - プロダクトをもう一段階成長させる仮説の立て方」は始まった。

 小城氏はミクシィでソフトウェアエンジニアとして広告系サービスや家族アルバム「みてね」の立ち上げを経験した後、LINEに転職。ソフトウェアエンジニアとしてLINEの開発に従事した後、スマートスピーカー「LINE Clova」開発プロジェクトにプロダクトマネージャーとして参画。

 以後、プロダクトマネージャーとしての活動がメインとなり、現在は及川卓也氏が代表を務めるTablyにてプロダクトマネジメントの研修やコンサルティング業務を担当しつつ、プロダクトマネジメントの体系化にチャレンジしている。

 プロダクトマネージャーになると、エンジニアだった頃と比べて「プロダクトづくり」や「プロダクト」に対する視点が変わったという。

 「エンジニアだった頃、『プロダクトを作る』とは、営業やディレクターから来た依頼を仕様に落として実装することだった」と小城氏は語る。だが、プロダクトマネージャーになってからは、「『プロダクトを作る』とは、プロダクトを実現するための手段を模索することに変わった。つまり考えなければならない範囲が広がった」と小城氏は言う。

 まずプロダクトづくりは「明確なゴールの設定」から始まる。「何のためにそのプロダクトを作るのか、そのプロダクトを作ってどんな世界を作りたいのかを設定することから始めます」と小城氏。

 次に「豊かな仮説構築」。「単なる仮説ではなく、『豊かな』仮説を作ることが大事」と小城氏は指摘する。小城氏の言う「豊かな」とは、ユーザーが「こういうものがあったらうれしいな」と思う目先の機能改善ではなく、ユーザー自身が気づきもしなかった、使って初めて喜ぶような仮説だと言う。その後は第3のステップの「素早い仮説検証」、第4の「市場への提供」へと続く。

 この4つのステップを下支えするのが「プロダクト志向な組織」だと小城氏は説明した。プロダクト志向な組織とは、プロダクトづくりに関わるチーム全員がプロダクトをよくするために考える状態にある組織のこと。その状態をリードする役割を担うのがまさにプロダクトマネージャーである。

 「今回は明確なゴールの設定、豊かな仮説構築、素早い仮説検証の3つにフォーカスして話をしていく。その前にまずはプロダクトの成功とは何か。この定義について意識を合わせたい」と小城氏は語り、説明を続けた。

 「プロダクトの成功」についても、エンジニアだったときと今では考え方が異なるという。エンジニアだったとき、小城氏が考えていたプロダクトの成功とは、「作ったコードにバグがなくて、ユーザーからUIが使いやすい、便利だと言われることだった」と振り返る。一方プロダクトマネージャーになってからは、「プロダクトの成功とはユーザーの価値と事業収益のバランスがとれていることと、ビジョンの実現ができていること」と小城氏は言い切る。

プロダクト開発は4階層で考える

 ビジョンの実現は言葉にするのは簡単だが、「実際の作業は地道な作業になる」と小城氏。何が正解なのかは誰にもわからない中、ユーザーが求めるものよりよいものを提供するために、大胆な仮説を立てることも必要になる。だが仮説が大胆になればなるほど、失敗する確率は大きくなる。小城氏は「プロダクトマネージャーとしては大胆な仮説を立てて、小さく失敗して進んでいくことが重要になる」と語る。

 では、ビジョンにひも付いたプロダクトをどうやって開発していくのか。そのためのコツとして小城氏は「Core(プロダクトの世界観や企業への貢献)、Why(「誰」を「どんな状態にしたいのか」「なぜ自社がするのか」)。What(ユーザー体験、ビジネスモデル、ロードマップ)、How(どのように実現するのか)の4階層で捉えることをお勧めする」と言う。

 4階層で捉え、共通認識を持つことで、チーム内のかみ合わない議論を防ぐことができるだけではない。「CoreやWhyが考えられておらず、WhatやHowだけで捉えられたプロダクトは、魚で表すと鼻が付いたり、足が付いたりと、魚かどうかもわからないものになってしまう」と言う。各担当者がプロダクトを「よりよくしよう」と頑張ったのにもかかわらず、CoreやWhyに対する認識が合っていないために、こうした事態に陥るプロダクトは意外と少なくないのではないだろうか。小城氏はこれを「蛇足のだそ君」と呼んでおり、このようなプロダクトを作らないためにも、4階層で捉えることが大事になると説明した。

 そしてポイントなのが、この4階層は上から順に考えていくことを推奨しているわけではない。「一つ上の階層と整合しているか、上下に行ったり来たりしながら検討することが重要になる」と小城氏。この整合しているか確認し行ったり来たりすることを小城氏は「Fit」と呼ぶ。そしてもう一つ重要なのが「Refine」。これは一つ上の階層の解像度を、検討していくことである。小城氏は「下の階層を考えることで、このユーザーはどんなペイン、どんなニーズを持っていたのかを、より解像度高く語れるようになることも多い。なのでその段階で、1個前の階層に戻ってもっとうまく言語化できないか考えることが大事になる」と話す。

 このように、4階層を上下に検討を深めていくことが重要になるが、階層を超えるときに注意すべきことがある。それは「仮説が正しいかどうかをチェックすること」だ。

 エンジニアなら誰もが自分が時間をかけて書いたコードを捨てられることは嫌なものだ。小城氏自身もそうだったという。だからなるべくそうならないよう事前に不確実性を下げていくことが重要になる。そのための手法として各階層で実施するのがユーザーインタビューである。Whyの階層ではペインやゲインを仮説検証するインタビューを、Whatではソリューションを仮説検証するユーザーインタビューを実施する。そして実装しリリースした後には、数字を見て仮説があっているのか、思った通りのビジネスが回っているのかを確認するという。

 「この4階層を使って、どこまでの仮説が正しく、どこの仮説から間違っているのかを管理することを推奨しています」(小城氏)


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 中村 仁美(ナカムラ ヒトミ)

     大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

バックナンバー(新着順)

連載:【デブサミ2021】セッションレポート
All contents copyright © 2021-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5