プロダクトの強い軸を作るプロダクトマネジメントフレームワーク #pmconfjp
2019年11月13日にプロダクトマネージャーカンファレンスにて”プロダクトの強い軸を作るプロダクトマネジメントフレームワーク”というタイトルで、一気通貫した軸の通ったプロダクトを作るための方針についてお話してきました。
お伝えしたい内容が時間以上にかなり多く、濃縮された発表になってしまったので、急遽補足記事を公開することにしました。
はじめに、発表に利用したスライドはこちらです。合わせてご参考ください。
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク Tably 小城久美子 (@ozyozyo)
https://www.slideshare.net/kumikokoshiro/ss-192896028
それでは、早速、解説をはじめていきましょう🎉
はじめに: 強い軸の通ったプロダクトとは？
“強い軸が通ったプロダクト”がどのようなものであるかについてはこの記事を通して説明していくので、まずはその反例からご紹介していきましょう。この図が軸の通っていないプロダクトの例です。
最初は魚のイラストだったはずなのに、より素敵なプロダクトにしていくために、
● 競合で人気の格好良いひれを取り入れてみること
● 他社の製品は水中のみに対応しているため、独自の差別化機能として陸上を走る足を生やすこと
● 「鼻をつけるともっと可愛いと思う！」というユーザーからのフィードバックを元に鼻や眉をつけること
などのアップデートを実施して、”魚のイラスト”だったものが、1年後にもはや魚でも哺乳類でもない何かになってしまいました。
絵にすると、違和感や気持ち悪さが一目瞭然ですね。しかし胸に手を当てて考えてみると、自分のプロダクトにこういう機能がないと言い切ることはできるでしょうか？
そもそも、プロダクトがどんなものなのか(この図であれば”魚のイラスト”)、あなたは正しく捉えることができていますか？そしてプロダクトに関わるすべてのメンバーが同じように捉えていますか？
この記事では、プロダクトがどんなものなのかをきちんと定義し、プロダクトチームに共有する方法と、おすすめのフレームワークについて紹介します。
軸となるプロダクトの骨太の方針
プロダクトの軸となる方針は3つの視点からしっかりと骨太につくりあげていくことが重要です。そして、3つの視点とは、Core、Why、Whatです。これらの視点はプロダクトを捉えるときの”解像度”が異なると私たちは呼んでいます。一番プロダクトを抽象的に、すなわち低い解像度で捉えたものがCoreであり、プロダクトのミッション・ビジョン・コアバリューが該当します。1つ解像度を上げたものはWhyで、どんなユーザーのどんな課題を解決するためにプロダクトを作っているのかといった視点です。そして一番解像度が高いものがWhatで、実際の機能やユーザーストーリーといったユーザーに見えている部分です。
プロダクトのWhatに当てはまる機能やUIは、見る人によって捉え方が違ってしまうことがあるので、プロダクトをCore + Why + Whatの骨太で捉えずに、Whatだけの細い軸で捉えてしまうと、冒頭で説明したようなリアルなひれの生えた何かが生まれてくることになります。例えば、冒頭の事態が起きるとき、各担当者は同じ機能やUIを見ているにも関わらず、各々がこのように捉えているかもしれません。
● リアルなヒレをはやした担当者: このプロダクトは魚。中心に据えられている目玉機能であるヒレの性能が他社(=鮮魚)に比べて著しく劣っている。
● 足をはやした担当者: これは移動することがメインの機能であるプロダクトだ。
● 鼻と眉をつけた担当者: これはゆるキャラである。
機能やUIから受け取る情報ではどの担当者が言っていることも間違っていませんね。これはかなり極端な例になってしまいましたが、企画担当者が複数いる環境でWhatだけを議論の対象にしてしまってこのような事態を招くことは想像に難くありません。
このような悪夢を起こさないために、プロダクトの方針はCore + Why + Whatの3つの解像度できちんと骨太に定義をして、伝えていく必要があります。
骨太の方針の作り方
Core、Why、What をそれぞれ強靭に作ること、そして、3つの要素がきちんと一気通貫していることで骨太の方針をつくることができます。前者のCore、Why、Whatの各々を強靭に検討するためのフレームワークはたくさんあり、1つのnoteには書ききれないので、今回は全体の方針について解説をし、各フレームワークについては今後取り上げて行きたいと思います。発表スライドには、WhyとWhatで活用するフレームワークについて簡単に触れてありますので、ご興味ある方はそちらもご参考ください。
WhyとWhatの検討の順番については基本的には3つを並行して、解像度を上げたり下げたりしながら検討してください。上げ下げの順番は、解像度の低いものから高い方へ、Core→Why→Whatの順に解像度を上げながら作っていくと検討がスムーズかと思いますが、状況に合わせてどこから着手しても構いません。場合によってはトップダウンでプロダクトを開始するときにCoreの種となるものを与えられていることもありますし、また逆に「こういったサービスをやりたい」という思いがWhatの形で想定されていることもあるでしょう。開始はどこからでも構いませんので、3つの視点を並行して考えていきましょう。キーワードはFitとRefineです。
骨太の方針の作り方: FitとRefine
Core、Why、Whatを並行して検討していくために、1つの項目の検討が終わったら、その1つ低い解像度の項目を再検討しましょう。例えば、Whyの検討をして、ターゲットユーザーのペルソナや、そのペルソナのユーザーのペインやゲイン、それらを解決するための方法を検討したとき、あなたはより具体的にそのプロダクトを何のために作るのか、つまりミッションやビジョンにあたるものについても考えが深まっているはずです。新しい気づきを得て、より的確にCoreを見直すことができるようになっているので、Coreの項目をRefineしておきましょう。
そして、例えば新しい機能を考えているときに、機能の事だけに集中していると、あんな機能があると素敵だとか、こんな機能もあるべきだといった考えで機能が多くなってしまうことがあります。そんな時には、そのWhatはWhyを解決する手段として本当に正しいのかを振り返ってみましょう。解像度の高いものを考えているときにはつい目的を見失いがちです。1つ低い解像度の項目を満たしているのかを確認することをFit(合致)と呼びます。WhatがWhyにFit(合致)しているのか、WhyがCoreにFit(合致)しているのかを確認して、一気通貫したプロダクトにしていきましょう。
そして3つの視点は1度考えたら終わりではありません。解像度を上げたり下げたりしながら、自信を持つことができるまで、各項目の検討、Fit、Refineを繰り返していきましょう。
骨太の方針を可視化して、共有する
ここまでの方法で、骨太の方針をCore、Why、Whatの3つの視点で検討することができました。
しかしながら、せっかく骨太の方針を検討することができても、それがプロダクトマネージャーの頭の中だけにあっては勿体ありません。プロダクトはうまく行けば行くほど、必要なメンバーが増えていき、どんどんチームが大きくなっていきます。それに伴って、これまで全く違う文化で働いてきた方が参加することもあるでしょう。また、プロダクトマネージャーが当たり前だと認識していたことでも、実は他のメンバーが違う理解をしているということも少なくありません。そのために、骨太の方針は誰でも閲覧可能な状態に可視化をして、誰でもが見られるようにして、プロダクトの成長に合わせて更新をし続けていきましょう。
そのためのフレームワークとしてはOnePager、リーンキャンバス、PRD、インセプションデッキの4つが有名です。各フレームワークの説明はこちらの資料をご確認ください。
はじめてのPRD Tably 及川卓也 (@takoratta)
https://www.slideshare.net/takoratta/prd-192302662
フレームワークが4つもあると、どれを利用すべきか迷うことがあるとおもいます。プロダクトの状況に合わせて一番いいものを選んでください。以下の図は各フレームワークの検討項目をフェーズごとにマッピングしたものになります。
リーンキャンバスは”何を作るか”という今回題材にしているフェーズととても相性が良いフレームワークです。そしてPRDやインセプションデッキはその後の開発フェーズでも活用できるような項目まで含まれています。しかしながら、インセプションデッキはWhatにあたるユーザーストーリーや機能を説明する項目が”やらないことリスト”しかありませんので、Whatが決まっていない状態で実施するのは難しいかもしれません。インセプションデッキ自体はチームビルディングにも最適な手法ですので、おおよその骨太の方針を検討したあとの具体的な開発を開始するフェーズで利用するのが良いかもしれません。
リーンキャンバスとPRDを比較すると、リーンキャンバスは1枚に必要な情報をまとめ、俯瞰して全体を眺めながら検討できることがメリットですし、PRDは反対に文章のサイズに制限が無いので自由に自然言語で記載ができ、必要な情報をすべて書き出せることがメリットです。両方の良いとこ取りをして、検討時にリーンキャンバスを利用し、チームに共有する際にはリーンキャンバスを添付したPRDを作るのが一番丁寧かもしれませんが、アジャイル開発宣言にある通り”包括的なドキュメントよりも動くソフトウェア”が大切ですので、綺麗なPRDを作ることにはあまり時間をかけすぎないでくださいね。
まとめ
1. 骨太の方針はCore, Why, Whatからなり、3つは並行して検討する
2. 議論時にはどの解像度の議論をしているのかを意識する
3. 各要素は何度も繰り返し、自信が持てるまで考える
4. 1つの要素を考え終えたら、1つ解像度が低いものとFit & Refine
5. 骨太の方針をPRDなどで言語化してチームで共有し、適宜アップデート
最後までお読み頂いてありがとうございました
みなさんのプロダクトをもっと良くするお手伝いができたなら嬉しいです。
参考文献
●アジャイルサムライ−達人開発者への道, オーム社 (2011/7/16)
●バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る,翔泳社 (2015/4/17)
●走りながら考える 新規事業の教科書,かんき出版 (2016/8/26)
●正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について,ビー・エヌ・エヌ新社 (2019/6/14)
●Running Lean ―実践リーンスタートアップ (THE LEAN SERIES), オライリージャパン (2012/12/21)
●ビジネスモデル・ジェネレーション ビジネスモデル設計書,翔泳社 (2012/2/10)
●ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略,日経BP (2019/10/10)
----------------------------------------------------
＼Tably株式会社、noteはじめました／
はじめまして！
最後までお読みいただき、ありがとうございます！
私たちはTably株式会社といいます。
私たちは、最高のプロダクトはテクノロジー、プロダクトマネジメント、そしてそれらを支える人と組織から作られると考えていて、それらを三位一体に支援している会社です。
これから、プロダクトマネジメントや組織についてのnoteを少しずつ投稿していきます。
よろしければ、スキ💛やフォローでの応援をお願いします。
＼Twitterもはじめました／
https://twitter.com/tablyrocks