SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

プロダクトマネジメントの基本を学ぼう

一気通貫したプロダクトをつくるための思考法、プロダクトの“4階層”とは?

プロダクトマネジメントの基本を学ぼう 第12回


プロダクトの4階層の活用方法

 では、プロダクトを4階層に分けると、どういったことに生かせるのだろうか。活用のポイントと、享受できるメリットを見ていこう。

意思決定の根拠が明確になる

 4階層に分けてプロダクトを捉えていると、そのアイデアをプロダクトにいれるべきか、そしてどのくらいの優先度であるのかを意思決定する根拠が明確になるだろう。例えば、競合で人気の機能を自社でも実装すべきかどうかの選択に、プロダクトマネージャーはしばしば悩まされるが、機能すなわち競合のWhatを取り入れるときに、4階層に分かれているとプロダクトのWhyに適合しないものが入らない。つまり、プロダクトのWhyに紐付いたWhatを考える状態になっていることで、自社の解決しようとしているペイン・ゲインや自社の強みを鑑みて意思決定をしなければならないことが一目瞭然になる。

意思決定者を明確にし、権限の委譲を促す

 そして、プロダクトのCore、Why、What、Howでは関わるメンバーが異なる。ときに、残念ながらプロダクトチームの中で、そのプロダクトのターゲットとしているユーザーの認識さえ一致できていない状況もあるが、このCore、Why、Whatが明文化されて共有されている環境ではプロダクトのHowに取り組むチームメンバーも仕事が円滑にできる。

 また、プロダクトマネージャーが複数いる組織でもCoreとWhyの共通認識があれば、プロダクトのWhatを各プロダクトマネージャーが別々に検討したとしてもプロダクト全体の一貫性が大きく損なわれることはないだろう。

 このように、階層を分けることで階層ごとの責任範囲が明確になり、結果として権限の委譲がしやすい状態を生み出すことができる。

仮説が間違っていたときの巻き戻り先が明確

 プロダクトをつくることは、仮説検証の繰り返しである。そのため、仮説が間違っており、せっかく開発まで実施したものが失敗してしまうことがよくある。その際に、どの階層の仮説から間違っていたのかを特定し、プロダクトを正しい方向に成長させていくための分析をすることにも有用だ。つまり、新しくリリースした機能が使われていないのは、UIが間違っていたのか、そのビジネスモデルが違うのか、それともそもそもその機能が解決していると考えていたユーザーのペインがないのかを遡ってふりかえることができる。必要な深さまで仮説の検証をすることで、次の仮説検証の成功確率は上がるだろう。

一気通貫したプロダクトにするためのFit&Refine

 この4階層では、上にあるものが下にあるものに影響すると述べたが、これは上から順番に検討することを推奨しているわけでない。この4階層は、上へ下へと行ったり来たりを繰り返しながら徐々にブラッシュアップしていくことで、仮説検証の効果を発揮できるだろう。

 そして、どの階層から考えるとしても、4つの階層に一貫性を持たせるために、1つの階層の検討が終わり、次の階層に進むときにはFitとRefineという作業を実施してほしい。

 まず、Fitとは1つの階層を検討したあとに、抽象度が1つ高いものと適合しているのかを確認する作業である。プロダクトに関わる人数が多くなると、機能についての議論が白熱すればするほど、なぜか、気付いたときにはユーザーの課題とこれから作ろうとしている機能が適合しないことが起きる。1つの階層を検討したあとには、目の前の成果物に執着をせずに、一度落ち着いて抽象度が1つ高いものと見比べることを忘れないでほしい。

 続いてRefine、つまり洗練するという作業は、1つの階層を検討したあとに、その1つ抽象度が高いものをブラッシュアップする作業だ。例えば、「What」の視点でプロダクトの機能を考えることを通してターゲットユーザーの理解が進み、「Why」を生み出すユーザー像ペルソナをより具体的に書くことができるようになることや、「Why」の視点でペイン・ゲインを検討することでマーケットの理解が進み、「Core」である事業戦略をより洗練させることができるだろう。一度、抽象度を下げたからこそ見えてきた視点を取り入れて、見える景色の解像度を上げて、ドキュメントをアップデートしていく姿勢が重要だ。

 このように、FitとRefineを繰り返す思考法を実施することで4つの領域間でのズレを取り除き、4つの領域が目指す先を定め、プロダクト全体に一気通貫した強い軸をつくることができる。

おわりに

 「プロダクトマネジメントの基本を学ぼう」連載は第11回で一旦終了としたが、追加的に第6回で述べた内容をより深めた記事を出させていただいた。このあとに、第7回で述べたプロダクトマネージャーに必要なスキルセットについても、追加の記事を出す予定だ。これらの記事がよりよいプロダクトをつくるための補助となれば幸いだ。

#PMの基本 で投稿しよう!

 本連載は、プロダクトマネージャーを目指す方の道しるべとなる書籍(執筆中)の一部抜粋です。

 本連載のフィードバックは、「#PMの基本」をつけてTwitterFacebookなどにご投稿ください! 私たちはそれを見て、より現場の悩みに寄り添った書籍を作っていきます。読者の皆さん同士でも、意見を共有する機会になればと思います。

プロダクト開発の最新情報をゲットするには、会員登録がおすすめ!

 ProductZineのメルマガに登録いただくと、定期的に新着記事やニュースなどプロダクト開発の最新情報をお届けします。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
プロダクトマネジメントの基本を学ぼう連載記事一覧

もっと読む

この記事の著者

及川 卓也(オイカワ タクヤ)

 早稲田大学理工学部を卒業後、外資系コンピューターメーカーに就職。営業サポート、ソフトウエア開発、研究開発に従事し、その後、別の外資系企業にてOSの開発に携わる。その後、3社目となる外資系企業にてプロダクトマネージャーとエンジニアリングマネージャーとして勤務後、スタートアップを経て、独立。2019年...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

小城 久美子(コシロ クミコ)

 toC向けサービスを提供するWeb系企業に入社し、その後いくつかの企業で新規事業の立ち上げなどにエンジニア、スクラムマスターとして携わる。どう作るかより何を作るかに興味関心が移り、プロダクトオーナー/プロダクトマネージャーに転身。プロダクトマネジメントについてより深めるために、2019年よりTab...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

曽根原 春樹(ソネハラ ハルキ)

 Fortune500系外資企業に入社後、SE、カスタマーサポート、マーケティングなど様々な役職を日米で従事。その後シリコンバレーでプロダクトマネージャーに転身。B2B、B2C領域で米系大企業・スタートアップの双方でプロダクトの世界展開に携わる。現在はSmartNews社米国法人にて日本のスタートア...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/13060 2020/11/05 11:45

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー