今回は、こちらの『プロダクトマネジメント』を読んだので、感想をまとめていきます。
読んでよかった点
では、読んだ感想を以下の３つに分けて書いていこうと思います。
- ビルドトラップの罠
- 「なぜ」に責任をもつ
- プロダクトの「カタ」
ビルドトラップの罠
本書のサブタイトルは、ビルドトラップを避け顧客に価値を届けるですが、この本を読むまでビルドトラップという単語を聞いたことがなかったです。
ビルドトラップとは？
組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況です。
ビルドトラップ、かなり、あるあるな状況ではないでしょうか。
アウトプットとは、たとえば半期の中でリリースした機能の数だったり、こなしたタスクの量など、定量的に計れる仕事の結果のことです。アウトプットって、社内の閉じられた環境で容易に追跡でき、フィードバックのループも短いため、数値化と評価が容易ですよね。
アウトプットは定量的に評価しやすいですが、その評価がそのままソフトウェアが価値を生み出していることとイコールではなく、アウトプットを指標としてしまうとユーザーに価値を届けられておらず知らず知らずにあかん状況になるという感じですね。
では、「アウトカム」とは、なんでしょか？「アウトカム」とは、ユーザーにどれだけの価値が提供されたかという観点から仕事の結果です。
ビルドトラップの罠にハマるわけ
では、次になぜビルドトラップの罠にハマるのか？についてですが、
顧客やユーザーの問題を十分に理解していなければ、企業は顧客やユーザーにとっての価値を定義することはできません。顧客に関する情報を学習するのではなく、代わりの指標を作るような間違いをしてしまいます。すると、「価値」はリリースした機能の数となり、結果的にリリースした機能の数こそが成功の主要指標になってしまうのです。
と、述べられています。
この文章を読んで、『イシューから始めよ』の犬の道というワードを思い出しました。
解くのが簡単だが、何もインパクトがない問いを解き続けること。
リリースした機能の数こそが成功の主要指標にした場合には、リリースした数をもっと増やすには？タスクをもっと効率的にこなすには？という問いを立てることになるでしょう。
『イシューから始めよ』の犬の道とはちょっとニュアンスは違うのですが、似ているなと思いました。
では、本質的な問いである顧客やユーザーにとっての価値は？という問いに、行きづらいのはなんででしょか？
シンプルに難しいのと、解くのに労力がいるからかと思いました。
顧客やユーザーにとっての価値は？という問いに対して答えるには、開発者は学習と調査、言語化にけっこうな労力を要するはずですし、取り組んでみたとてそれがうまくできるとも限りませんしね。
また、開発者の仕事はHowに焦点を当てることが多いのもあるかもです。価値は、HowではなくWhy関わりますもんね、そこに関わることやそこを熟慮することを意識できていないのもできないのも事実。
ビルドトラップに陥った原因の所在
では、ビルドトラップに陥った原因の所在はどこにあるのでしょうか？
本書では
この問題は、誰か1人の失敗によるものでもなく、どこかの部門の失敗でもありませんでした。そもそも組織が成功する形になっていなかった
と述べています。
なるほど、、本書を読むとわかりますが、ビルドトラップの問題は、意思決定のフローから、リリース前のアクション、はたまた評価制度まで関わっている問題でした。
そのため、特定の誰かのメンタリティの問題ではなく、組織全体のマインドセットのお話になるわけですね。
「なぜ」に責任をもつ
続いては、「なぜ」に責任をもつというワードです。これは、プロジェクトマネージャーとプロダクトマネージャーの違いを述べている部分で登場します。
プロジェクトマネージャーとプロダクトマネージャー
プロジェクトマネージャーとプロダクトマネージャーについても、納得感高い定義をしていたので紹介します。
僕は本書を読むまで、この２つの違いがわからんでした。
まずは、プロジェクトマネージャーから
プロジェクトマネージャーは「いつ」に責任を持ちます。いつプロジェクトが終わるのか？全部が予定どおりか？締め切りに間に合うか？そういったことが関心事です。
メンバーそれぞれのタスクの進捗管理だったり、プロジェクト全体の進行が滞りなく進んでいるかどうか？というところに責任をもつのが、プロジェクトマネージャーです。
本書では、プロジェクトマネージャーをどうこうゆうているわけではないのですが、プロジェクト管理についてはこんな風に書いてます。
プロジェクトはプロダクト開発の欠かせない一部ではありますが、プロジェクトだけ考えるという発想は悪影響を及ぼします。
「いつ」に責任を持ってたとえ完遂できたとしても、アウトカムの問いである「顧客やユーザーにとって価値を提供できているか？」ということへの答えにはなりませんからですな。
続いて、プロダクトマネージャー
プロダクトマネージャーは「なぜ」に責任を持ちます。なぜこれを作るのか？どうやって顧客に価値を届けるのか？ビジネス目標を達成する上でどう役に立つのか？このようなことに責任を持ちます。
ここを読んでいて、プロダクトマネージャーという立場関係なしに、開発者として持っておくべき視点だなーと思いました。
機能を開発する際に、その機能が必要とされるに至った背景や課題感、具体的なお困りごとなどを理解して実装するのと、そこらへん雰囲気でしか理解せずに実装するのではクラス設計から、テストケースに至るまで質に影響を与えるはずです。
こういうの観点を一言でいうなら、「なぜ」に責任を持つ、ということになり、個人的にはしっくりきました。
本書では、こうも書いてますね
命令を上から下に流していくのではなく、それぞれの階層でなぜそれが必要なのかの認識をそろえて、どうやってそれを実現するのかは下の階層に任せて報告をしてもらうようにすべきです。このようにすれば、プロダクトマネジメントはうまくいきます。
それぞれの階層で認識をそろえろよ、と。
プロダクトのカタ
最後は、具体的なアクションについてです。
作るべき適切なものを明らかにするプロセスとして、このようなプロダクトのカタを紹介しています。
本書の中では、このプロセスをストーリー仕立てで実際にやってみせているのですが、まー泥臭いことをじわりじわりとやるんだな、という印象でした。意味のある実験に取りくんで、その結果から学習して、価値を数値に落としこんでいくプロセスが描かれてお離ました。
（あんまり、ここのプロセスじっくりは読んでない。機会が来たらちゃんと読む。
まとめ
以上、『プロダクトマネジメント〜ビルドトラップを避け顧客に価値を届ける〜』について雑記を書きました。ビルドトラップの定義から始まり、プロダクトマネージャーとは、学習とはなどなど、随所に、耳がいてぇ話があって面白かったです。
また読むかも本でした。
というわけで、僕から以上。あったかくして寝ろよ。
