『プロダクトマネジメント』を改めて読んでいた
GW前半後半に分けての家のワックスがけ作業（90%は床を黙々とこする作業）が終わったので、昨日今日は『プロダクトマネジメント』（オライリー・ジャパン）を読んでいた。
もともと本書は前職時代にRe:VIEW制作でのDTP・EPUB制作を私が担当しており、内容もざっくり読んではいた。先月に入社された方が本書を愛読書にしているとお聞きし、そういえばそれ作ったな！と思い出して読み返すことにした（吉羽さんのファンでもあるそうですヨ）。
原題は『Escaping the Build Trap』。手元でコードビルドしてリリースしていると変なものが紛れ込んだり、コミット/pushし忘れをするのでCIを使いましょうね、という話……ではない。
「ビルドトラップ」は著者のメリッサ・ペリが提唱している造語で、「組織がアウトカムではなくアウトプットで成功を計測しようとして行き詰まっている状況」「実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況」のことを指す。このようなビルドトラップを避けるために、PdM（プロダクトマネージャ）や組織が「プロダクト主導」で考えることが必要ですよ、というのが本書の主旨となる。
プロダクト主導の組織になるために、役割（PdMが果たすべきこと）、戦略（意思決定を助けるフレームワーク、ビジョン）、プロセス（プロジェクトのカタ）、組織（アウトカムを中心とする組み立て）の同心円を据えて説明が進む。
そして、アウトカムを向上させるためには顧客を深く理解することが核心であり、ビルドトラップを抜けるにはプロダクト主導として組織全員の参加が必要だと述べている。
たとえば、顧客の問題を理解するため、「なぜ」から外れないよう問題に集中しながら、調査し、観察し質問する。そして顧客が苦痛に感じる箇所と問題の根本原因を特定する。プロダクトやサービス自体に価値はなく、それによる問題の解決や要望の達成、ニーズの満足が「顧客にとっての価値」となる。
私自身はPdMではないけれども、Mackerel CRE（Customer Reliability Engineer）チームのカスタマーサクセスユニットに身を置いており、顧客の要望を伺い、真に解決したいことを探り出し、開発チームと協力しながら「顧客にとっての価値」の向上に寄与することも職務の1つとなっている。
その点で、本書で紹介されているさまざまな手法は、今後実施してみると良さそうなことがいろいろありそうだと感じた（すでに実施している手法を見返すのも含め）。
なお、自身を鑑みると、本書中で登場する「ウェイターになってはいけない」（目標・ビジョンに照らさず、評価することなくそのまま作ってしまう）の行動はときどき指摘されていた。前職で1人フルスタックエンジニアとしてソリューションをスピーディーに出して対処していたのが歪みになっているのもあるし、そういうのは検討や実験をすっ飛ばして「まずコードを見ます」から始められることが多くてつい「楽しい」んだよね。楽しい自体は良いことではあるけれども、顧客にとっての本当の価値を考え、ビジネスのアウトカムとしないとね、いうことを改めて。
