Product顧客の心を捉えるためのサービス開発についての本。役割について掘り下げられている。自分は普段PM兼エンジニアをすることが多いので、PMの役割そのものよりも、他の役割を持つ人(特にデザイナー)との関わり方について、なるほどなと思うところが多かった。あとこの本は1→100の成長フェーズでの話が多く、自分自身は0→1の事業立ち上げフェーズにいま居るのもあり、その温度感の違いから、この本を読んでいて刺さる部分が他の人と違うかもしれない。前に読んだので、Kindleに線を引いたところから拾ってメモ。見るプロダクトマネージャーの仕事とは何なのかこの本のなかで言い回しを変えつつ繰り返し述べられてるけど、冒頭で出てくる以下の定義に収まると思う。プロダクトマネージャーの仕事は、価値があって、使いやすくて、実現可能という目的を満たす上で必要最小限の(余計なものが一切そぎ落とされて洗練された)製品を特定することである。これによって、製品化までの時間と製品の複雑さを最小限にするのである。この定義のもとで、製品の市場性を評価することと、開発すべき製品を定義することがプロダクトマネージャーの役割になる。ただの仕様定義ではなく、「価値があって使いやすくて実現可能な製品の、必要最小限の仕様」という部分が大事だと思う。ここに全力を尽くすのがPMってことなんだろうな。機能を足すことは簡単でも、削ぎ落とすことって難しい。必要最小限の機能で、製品の価値を最大化することが大切だな(そこが難しいし面白い)、と改めて思った。サービス開発における役割の棲み分けこの本の中で述べられていることをざっくりまとめると以下のような感じだった。職種ではなく、あくまで役割なので、一人の人間が複数の役割を兼ねることもありえる。潤沢に人が居ない限りは、何かしら兼任するのがほとんどだろうなあ。何を開発すべきなのか、製品を特定することに責任を持つプロジェクトマネージャープロジェクトのスケジュールや進捗管理に責任を持つプロジェクトが大きくなると専任者が必要になるプロダクトマーケティング製品を世界中に知らしめることに責任を持つプロダクトマネジメントとの兼務になることが多いが、この2つの役割には別の技能が必要で、本当は兼務するのは難しい。(後述)プロダクトマネジメントとデザインこの本でも明言されてるが、サービス開発においてユーザー体験をデザインすることは必要不可欠だし、それこそがサービス開発そのものだと思う。デザイナーとの協同が必要不可欠になると書かれていた。いい製品にするには、優れたユーザーエクスペリエンスが必要なのである。優れたユーザーエクスペリエンスを実現するには、プロダクトマネジメントとユーザーエクスペリエンスデザインがしっかりかみ合っていなければならないのである。本の中では、UXデザインをさらに細分化して、以下の4つの役割が重要とされていた。インタラクションデザインビジュアルデザインラピッドプロトタイピングユーザビリティテスト大規模製品の場合は、このそれぞれに専任の担当者を置くのが必須と書かれていた。実際のところそんな潤沢なリソースがあるプロジェクトとは無縁だ。本当に言いたいのは、専任の担当者が必要になるぐらい、同じ「デザイン」でもそれぞれ全く違うスキルが必要になる、というところだと思う。本の終盤には以下のように書かれていた。インタラクションデザインとビジュアルデザインはまったく違う技量が要求される分野である。サイトを使いやすくて魅力あるものにするためには、デザインチームに両方のスキルが必要だ。両方のデザインをこなせるデザイナーがいてくれるという、ものすごく幸運なチームもないことはない。多くの場合、「デザイナー」と称する人を雇ったからどっちもできるはずだ、と期待してしまうだけで、実は両方共できるわけではないのだ。同じような趣旨のエントリを前に書いたが、やっぱそうだよねー...と超同意。前述の4つの役割を全てこなせる神みたいな人は、めったに居ない。いって、専任の人を置く余裕もスタートアップには無い。この本には、ビジュアルデザインやユーザビリティテストのような(重要だけど)比較的外注しやすい部分については、外注するのもありだと書かれていた。事業立ち上げフェーズにいる他のスタートアップの人たちが、実際ここをどうしているのかは凄く気になるな。ちなみに自分自身は、自分でUXDのスキルを勉強し、この役割を兼ねるという選択肢を取っている最中。製品を見つけ出し定義することと、正しく作りあげることソフトウェア製品を開発するプロジェクトは、まったく別々の2つの段階に分けることができる。作るべきものを決める(正しい製品を定義する)段階と、それを作る(正しくその製品を作り上げる)段階である。ここがこの本を読んでいて、一番はっとした部分かもしれない。この本では、この2つの段階を明確に分けるべきと書かれていた。多くの製品開発チームはこの頭の切り替えができていない。できたとしても、切り替えるのが遅すぎるのだ。結果として、プロジェクトは「かき回される」のである。あるあるすぎる...。自分がプロダクトマネージャー兼エンジニアとして、企画と開発を兼ねてしまっているのもあり、ついこの切り替えを忘れてしまう。その結果、製品を定義することに集中すべきなのに、いつの間にか作り上げること(エンジニアリング)だけに集中してしまうことがよくある。発案力(売れる製品のアイデアを発案するためのスキル)と実行力(アイデアを実際に顧客の手元に届けることを実現するためのスキル)の両方を高めることは、絶対に必要である。エンジニアとして後者については経験を積んできているけど、プロダクトマネージャーとして前者についてはまだまだ経験が足りない。前者の経験を集中的に積む期間を作りたいなと、この本を読んで思うようになった。製品理念を決める製品理念とは、製品開発のための一連の原則を定めたもので、両立させるのが難しいものがうまく折り合うところを見極めて何を優先させるか決めるときに大きな拠り所となる。製品理念は、信念や目的を社内の人たちに宣言するものである。Amazonが製品開発の際には、プレスリリースを最初に書くという話は有名だけど、プロダクト定義ステートメントはサービス開発にとって重要だと改めて思った。重要なのかについては、この本の中でも色々と語られているが、個人的には以下がポイントなのかなと思う。製品開発チーム内で意見が大きく食い違うのは、事実関係の捉え方が食い違っているのではなくて、製品化の目標についての解釈や、それぞれの目標の優先順位の付け方が、メンバーの間でまちまちであることが原因になっている。ため、常に不確実性を含んだ状況下で仕事が進む。企画にしろエンジニアリングにしろデザインにしろ、常に細かい意思決定が連続する。いうのがサービス開発の一番難しいところだと思っている。0→1のフェーズならなおさら。その中で、チームで仕事をする以上、チームメンバーそれぞれがその意思決定をする必要がある。すると先に引用したとおり、製品の目標についての解釈や、優先順位の付け方がチーム内で統一できている必要があるんだよなーと再認識した。これをするためには、ただステートメントを書くだけではなくて、それをメンバーに浸透させるところもセットになる(なかなか難しい...)。おわりこのエントリでは取り上げなかったが、この本はその他にも以下のようなトピックが書かれていた。読むといいのかなと思った。この本はプロダクトマネージャーを実際やっていたり、これからやる人に凄くオススメできそう。7引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。