こんにちは、株式会社GxPの石村です。
『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』を読みましたので、ご紹介したいと思います。
私は受託開発で顧客のプロダクトを開発しており、プロダクトマネージャーという立場ではないのですが、その立場なりに感じたことなどをお伝えします。
経緯のご紹介
この本自体は、発売されたときに私の周囲では話題になっていて、良い本なのだろうなということは事前に知っていました。
ただ、私は現状スクラムマスターについて学んでいる状況で、プロダクトマネージャーではないので、この本を読むならスクラムに関する本をもう少し読んだ後がよいかなと思い、買っていませんでした。
そこで、このツイートを発見。
10/26に発売になった当方翻訳の『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』を抽選で20名の方にプレゼントいたします。詳細は以下のページをご覧ください(他のページも是非ご覧ください)。 #アトラクタ #プロダクトマネジメント #ビルドトラップhttps://t.co/L6WrDJxqX6
— Ryutaro YOSHIBA (@ryuzee) November 4, 2020
気にはなっていたし、当たったらご縁だと思って読んでみよう！と思っていたら、当選しました！
おおむね3か月以内にブログなどに投稿することが条件で、結構ギリギリになってしまいましたが…セーフなはず！
とどいたー！ https://t.co/z7JdcyDtPT pic.twitter.com/Je4d3QeLcq
— Arisa Ishimura (@arisatirol) November 17, 2020
全体を通しての感想
この本には、ビルドトラップにどのようにはまるのか、また、そこからどう抜け出すのか。抜け出すためには組織としての対応が不可欠であることから、組織がどのように対応していけばよいのか、といったことが成功例、失敗例を交えながら書かれています。
少し私の立場と役割をご説明します。
冒頭にもご説明した通り、私は受託開発をしており、ある顧客のプロダクトを開発しています。
10～15名ほどのメンバーで開発しており、2つのプロダクト、3つのチームがあります。
その中で私は、顧客のつくりたいものをヒアリングして実現手段をともに考えていく立場であり、チーム全体のとりまとめを行う立場でもあります。
スクラムの役割である「スクラムマスター」「プロダクトオーナー」「開発者」の中でどの立場に近いのか？と考えたときには、「スクラムマスター」だろうと考えていました。そのため、「スクラムマスター」の認定研修を受け、学んでいます。
この書籍を読んでまず感じたのは、その選択が「プロダクトオーナー」には立場的に徹することができないという諦めからきているものだということです。
「スクラムマスター」と「プロダクトオーナー」の両方の立場を半端に兼務しているような状態だったため、スクラムを学んでどちらかに徹するなら「スクラムマスター」しかできないのではないかと考えていたのです。
チームの支援をするのが好きだというのもありましたが。
関係者の誰かに止められたわけでもないのに、以下のような遠慮をしていたことにも気づきました。
- 「スクラムマスター」と「プロダクトオーナー」補佐を兼務してはいけないはずだ
- 「プロダクト」は顧客のものなので、あまり口出しをするべきではない
しかし、弊社の社名である「Growth xPartners」には「お客様と共に成長するパートナーでありたい」という想いが込められています。これまでもお客様との関係性は深く親密で、お客様と同じかあるいはそれ以上にお客様のことを考えるということを大切にしてきました。
私はこの社名と理念がとても気に入っていて、私もそうありたいと思っています。
にもかかわらず、これまでの学びは内側（社内）を向きすぎていたなと気づいたのです。
私は「プロダクトマネージャー」になることはできませんが、顧客が少しずつでもビルドトラップを避けていけるように、問いかけや訴えを続けることはできます。
ときどきこの本を読み返して、私たちはビルドトラップにはまっていないか？と自分に問いかけることから初めていきたいなと思います。
この本には、どんなふうにビルドトラップにはまるかを何度も訴えてくれているので、「ぐさっ」とくる表現がないかな？と探せば容易に見つかりそうです。実際何度も「ぐさっ」と来ました。
用語の定義
「プロダクトマネージャー」「ビルドトラップ」という用語は、誤解を招きやすく、この本で1冊かけて説明しているものです。
しかし、この記事を読むうえで全く説明がないとわかりにくいので、ざっくりとご説明しておきます。
プロダクトマネージャー
プロダクトオーナーシップはプロダクトマネジメントの一部にすぎません。優れたプロダクトマネージャーは、明確でアウトカム志向の目標をもとに作業の優先順位を決める方法、本当の顧客価値やビジネス価値を定義したり見つけたりする方法、マーケットでのプロダクトの成功について不確実性を減らすためにどんなプロセスが必要かを決める方法などを学びます。
７章 優れたプロダクトマネージャー
「プロダクトオーナー」なら聞いたことがある、という人も多いと思います。
スクラムガイドでは「プロダクトオーナー」の役割については記載されていますが、それをどのように適切に遂行するかについては書かれていません。
また、この本の中で「プロダクトマネージャー」というのはキャリアであると説明されています。
そのため、プロダクトマネージャーとしてもエントリレベルのポジションから、最高プロダクト責任者まで段階的なポジションと責任範囲について説明されている章もあります。
ひとことでいうなら、プロダクトを顧客に価値を届けられるものにし続けるためなら何でもする人、という印象です。
ビルドトラップ
本書の定義によると、ビルドトラップとは、以下のような状況を指します。
・組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰っている状況
・実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況
訳者まえがき
私はここだけ読むと、かなりひどい状況を指しているように見えていました。
顧客にとっても価値を完全に無視しているような状況にも読めるからです。
しかし、全体を読んでみると実際にビルドトラップにはまっていることは想像以上に多くあるのだということに気づきました。
顧客にとっての価値、ビジネス価値を最大化できていないな、と感じる場合にはおそらくどこかでビルドトラップにはまっているのだと思います。
ピックアップ
具体的にどのあたりが刺さったのかというのをいくつかご紹介します。
たくさんご紹介したいのですが、キリがないので3つだけ。
わたしとチームの意識の違い
「最後にリリースしたもののふりかえりをしている人は手を挙げてください」と言うと、通常15～20％の人が手を挙げます。そこで「では、リリースしたものがうまくいったかはどうやってわかりますか？」と質問します。答えは、期限に間に合ったとかバグのないコードだったといったものになるのが通常です。
（中略）
戦略的になって、それに合うように組織を運営するためには、リリースした機能の数によってチームを評価するのをやめなければいけません。代わりに、価値を定義して計測し、ビジネスやユーザーのアウトカムを実現できたら称賛すべきです。そして、その実現の助けになるようなプロダクトを作るべきなのです。
２章 価値交換システムの制約
ここはとてもぐさっときました。
私は顧客と話すうちにどの機能にはどのような価値を届けたくて作っているのか、また、どれは仮説でどれが確信を持っているのか、といったことを感じ取っています。
しかし、それはチームに明確に伝えられていないことも多いのではないかなと感じました。
チームは「どの課題が次のリリースに載せられそうか」ということを自分たちで決めますが、そこで約束したことを守ろうと頑張って開発してくれているというのが実情です。
チームとしてはやるべきことに集中しているのだから、間違いではないと思います。
しかし、十分にチームに今やってもらっていることの意味を説明できていたかというと怪しいなと思いました。
受託開発ではまりがちな罠
ウェイターは問題を見つける代わりに、「何が欲しいですか？」と聞いてしまいます。
（中略）
ソリューションを考えるのは顧客の仕事ではありません。あなたの仕事なのです。あなたは顧客の問題を深く理解し、いちばん良いソリューションを考えなければいけないのです。
６章 悪いプロダクトマネージャーの典型
これはまさに自社開発ではなく、受託開発をしている場合にはまりがちな罠ではないでしょうか。
企業によってはそれが正しいスタンスなのだと思います。しかし、弊社の場合はそれだけではいけないと思うのです。
これは自分の耳にタコができるぐらい繰り返し聞きたい言葉ですし、社内の他の人にも広めたいなと思いました。
どの課題も必要だからこそはまりがちな罠
「どういうことでしょう？問題の原因を突き止めれば、作るべきものが決められるんですが。目標がはっきりしていて、それを取り巻く問題を見つけたので、今それに対処しようとしているんです」
（中略）
「これが作るべき適切なものかどうかはどうやるとわかるんですか？」
１０章 戦略とは何か？
ここはどこを抜粋するのが適切か難しいのですが…
プロダクトバックログにある課題は、どれも「必要」なものです。
解決できると誰かはハッピーになるはずだと信じられている課題が並んでいます。無価値に見えるものはほとんどありません。
だからこそ、常にプロダクトの戦略にとって、これが一番重要な課題なのか？を問い続けなければならないなと感じた章でした。
私たちは問題が何なのかがわからなくても、問題を解決しようとしがちです。私たちの脳はソリューションを考えるのが大好きなのです。
（中略）
このモードで失敗しやすいのは、機能がないのが問題であると偽ることです。
１７章 問題の探索
「こんなことに困っているんです」と言われ、その問題に共感できると、すぐに「それはどうしたら解決できるだろうか」と考えがちです。
共感できなければ「それはなぜ、どういうときに困るんでしょうか？」などと問いかけられるのですが、「たしかにそうですね」となってしまうとすぐに「どう作るか」を考えてしまうなと思いました。
そしてそれが楽しいのだから、困りものですね。
さいごに
私は最初、受託開発を行っている場合にはこの本を読んでも活かしきれないのではないか、と考えていました。
たしかにすべてはできないのですが、上記でご紹介したように、たくさんの学びが得られます。
分量的にも読みやすい本だと思いますので、是非お手にとってみてはいかがでしょうか。