読者です 読者をやめる 読者になる 読者になる

Insight of my life

ITベンチャーにつとめる人のInsghtを残すブログです

Inspired: 顧客の心を捉える製品の創り方 を読んでみた


スポンサードリンク

 
プロダクトマネージャ向けのバイブルになっている書籍。
どんなものだろ?と手に取る機会があったので、読んでみました。
 
結論、もっと早く読んでいれば良かった… と感じるぐらいの本でしたね。
さすが、バイブルと言われるだけある。ほんとに、そう思う。読んでて耳が痛いことがいっぱいあったw
 
書いてあることは、特段、斬新なことがあるのではないです。
ただ単に、プロダクトマネージャという役割を明確に定義して、その役割から何をすべきなのか?を簡潔に記述してあることです。
 
その簡潔さ、分かりやすさがこの本の売りでしょう。
 
そもそもプロダクトマネージャってなに?という話がよくありますよね?
例えば、こちら

d.hatena.ne.jp

Freeの坂本さんBlogも参考になりますね
 
組織というか、マネジメント層の意識、考え方に依存するものでもあるので、いる、いらないというレベルから、役割の定義などがもの凄く曖昧なものです。
一方ではその肩書きって必要なの?という意見もあるし、他方では、逆にこれからのあるべき姿、必須ですみたいな論調もあったと感じてます。
 
その中で本書は、その役割の定義、必要性と何をすべきか?どうあるべきなのか?を纏めています。
それも腹落ちする内容です。
 
では、まずはその定義の内容から。

プロダクト開発での役割には、何があるのか? 

役割は大きく3つです。
人に寄っては同じことじゃないか?と言ってたり、実際に重複して担当している人が多い部分と思います。
 
■ プロダクトマネージャ

プロダクトマネージャーの役割は、エンジニアリングチームが作り上げるべき製品を詳細に定義することで ある。 

 つまり、What(何を作るのか?)を決めることですね。
 
■ プロダクトマーケティング
プロダクトマーケティングの役割は、世界に対して製品を語ることである。

どんな製品であるのかを発信することになります。

 
■ プロジェクトマネージャ

プロジェクトマネージャの役割は、市場に製品を送り出すこと

つまり、How(決められたスケジュール、予算の中で、どのように作って行くのか?)ですね。

 
プロダクトマネージャが、What/何を作るのか?であり、プロダクトマーケティングは、発信して認知させて行くこと、プロジェクトマネージャは、How/どのように作るか?を突き詰めて、プロダクトを市場に提供して行くことが役割になる。
 
ここで言いたいのは、役割の定義をして、人の担当範囲を分けるのが必要なこと、ではなく、
そのような役割があることを理解することが大事であること、です。
 
当たり前のことだが、上記役割を複数こなしている人もいるでしょう。
全てこなせている方もいると思いますし、全部やろうとしてうまくいっていない人もいると思います。
 
私は出来ていない1人でした。一時期は、プロダクトオーナー兼プロダクトマネージャ兼プロジェクトマネージャみたいな感じだったと思います。
 
センスがある訳でもないのに、闇雲に役割を担いまくってました。まあ、うまくいくはずがないw
その役割の定義を理解もなく、ただ、やるべきことをやるという感覚でいたでしょうか。
 
その役割、それに求められることを理解すること。
その定義がプロジェクト内で共有されることから、権限と責任の所在が明らかになり、かつ、プロダクト開発に必要なリソースや、対応しうる時間軸が見えてきます。
 
そこが第一歩。その一歩を踏み出せるのかが大事です。
 
■ 番外編としてデザイナの役割
本書では、大きく分けると以下の4つに分けている。
○ インタラクションデザイン
インタラクションデザイナーの役割は、対象となるユーザー を深く理解し、ユーザー にとって作業効率のいいタスクやナビゲーションやフローを考案することである。通常、インタラクションデザイナー は、製品要求をワイヤーフレームという設計図にマッピングし、これをビジュアルデザイナに渡す。
 
○ ビジュアルデザイン
ワイヤーフレームを肉付けをして、実際のページやユーザインターフェースの見た目と雰囲気(正確なレイアウト、色、フォントなど)を制作することである。ここで最も大事なのは、製品のビジュアルデザインというのは、ユーザの感情に語りかけたりユーザの感情を呼び起こしたりする、ということだ
 
プロダクトマネージャやデザイナーのアイデアを反映したプロトタイプ(試供品)を作っては実際のユーアでテストする、という作業を繰り返すことである。
 
製品のユーザビリティ(使いやすさ)の検証を担当する人は、もっぱらユーザの調査と分析をやる。製品やそのプロトタイプによって、ユーザのやりたいことが容易に達成出来るかどうかを判定するのである。この仕事は、検証に参加してくれるユーザとして適切な人々を集めること、検証作業を行うこと、検証結果を評価すること、そして代替案を提示することも含まれる。
抜粋なので冗長的な部分もあるが、言いたいこととしては、デザイン1つでも求められることは変わってくることになる。
 
それぞれ役割が違うので、自ずと求められる経験、スキルが違う。 
特にインタラクションデザインは、ビジュアル化が出来るというのではなく、ユーザを深く理解し、何を提供すべきか?を考えだすこと、になる。ワイヤーフレームから見栄えを良くするものではない。
 
ここを同じ土俵で語ってしまうため、そもそも出来ないことを要求してしまう、必要なスキルを見間違えてしまうことに繋がってしまうだろう。 

プロダクトマネージャは何をすべきなのか?

細かいことを言い出したら、正直きりがない。
 
その中で、一番求められているのは、製品の市場性を評価することと、 それと開発すべき製品を定義することと考えている。
 
本書の該当箇所を引用すると以下の通り。
どういう製品にするのか (必要とされる特性と機能、 ユーザーエクスペリエンス、 発売の基準 など) を「見つけ出す」こと
開発されるソフトがどういう機能を備えて何をするものかということであり、 どのように動くかではない
 
どの市場で、誰に、何を提供していくのか?を定義することですね。
 
この判断軸についても、示唆に富む軸を提供しています。その内容は以下の通り。
1.製品化によって具体的にどんな問題を解決するのか? (バリュープロポジション)
2.だれのためにこの問題を解決しようとしているのか? (ターゲット市場)
3.市場の大きさは?(市場規模)
4.製品化の成功をどうやって評価するのか?(指標、収益戦略)
5.現在、他に競合する製品はあるか?(競合の見通し)
6.なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか?(差別化要因)
7.なぜ 今なのか? (市場投入の時期)
8.どうやって製品を市場に出すのか? (市場投入戦略)
9.成功のために絶対に必要な要素は何か? (ソリューションの要件)
10.これらを前提とした上で、最終的な提案は何か?(やるかやらないか) 
これ、本当に役立つ。迷いが出てきたとき、改めて見直すと判断が出来きます。
もちろん、このまま使う必要はない。業界、プロダクト、会社のフェーズ、規模に寄って変わってくるだろう。カスタマイズして、プロダクトの判断軸にアジャストしていくプロセスが有益です。
 
以上が、本書から大事だと感じたことです。しかし、読み直すとまた違う視点が見えてくる本ですね〜。
 
私が上げたポイントに限らず、プロダクト開発について、多くの気づきを与えてくれる書籍です。
プロダクトマネージャを目指す、実際にやっている人だけでなく、プロダクト開発に関わる人全員が読むべき1冊です!