プロダクトマネージャーとエンジニア、プロダクトに対する視点の違い
「自分がエンジニアだった頃に知りたかったことを中心に話をしたい」
こう前置きし、小城氏のセッション「エンジニアに伝えたい！プロダクトマネージャーの頭の中 - プロダクトをもう一段階成長させる仮説の立て方」は始まった。
小城氏はミクシィでソフトウェアエンジニアとして広告系サービスや家族アルバム「みてね」の立ち上げを経験した後、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階層を使って、どこまでの仮説が正しく、どこの仮説から間違っているのかを管理することを推奨しています」（小城氏）
