いづいづブログ

アジャイルコーチになりたい札幌在住SEです。アジャイル札幌スタッフ&ScrumFestSapporo実行委員。Like:パクチー/激辛/牡蠣/猫/初期仏教

「プロダクトマネジメント」を読んで、ビルドトラップから抜け出そう

本日は「プロダクトマネジメント」を読んで私にとって大きな気づきだったことや大事だなと思ったポイントをまとめてみました。「この本気になる!」と手に取ってもらうきっかけになればうれしいです。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)

ビルドトラップ

❞ ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰っている状態のことです。

これはほんとわかりみが深すぎて辛い。

スクラムガイド2020ではプロダクトゴールが追加されましたね。今回の改定でこれを追加したのはなんでだろうと思い読み合わせの会で質問してみたところ、こんなようなお話をしていただきました。

  • スプリントバックログを消化することでスプリントゴールが達成される。そして、本来はそのスプリントゴールを達成することの積み重ねでプロダクトゴールを達成しなければならない。

  • でもそうなってないスクラムチームが多いと思う。つまりスプリントバックログは消化しているけどプロダクトゴールに近づいていないチーム。プロダクトゴールということを考えられていないチーム、もしくは間違ったプロダクトゴールを設定しているチーム。

  • だから今回プロダクトゴール追加されたのは新しい考え方が増えたんじゃなくて、今まで意識できていなかったことを「おまいらちゃんと考えよ」と明示的にしたということに近いと思う。

これってビルドトラップと同じことだ、と思いストンと腹落ちした瞬間でした。

「プロダクト」とはなにか

プロダクト=価値を運ぶもの。

出来上がったプロダクトに価値が付加されているわけじゃなくて、プロダクトが使われることで価値が生まれる。

その料理を誰かがたべて美味しいとか幸せを感じることが価値で、料理という「調理された食材」そのものに価値が備わっているわけではない。

ここ混同しないように気を付けないとと思いました。「プロダクト=価値」って考えちゃうと、 ビルドトラップに片足突っ込むことになりそう。

プロダクトとプロジェクト

プロジェクトはプロダクト開発の一部。プロジェクトには終わりがあるけどプロダクトは永続的に続く。プロダクトに「いつ」という概念はないんだな。

まず大事なのはプロダクトとプロジェクトを混同しないことだと思いました。*1

スクラム導入あるあるなのが、「プロジェクトリーダーをやっていた人がプロダクトオーナーをやるとプロジェクト管理になりがち説」。ここを曖昧にしたまま、アウトプットを出してさえいれば価値があると思っているなら、ビルドトラップへまっしぐらだと思う。

プロダクトオーナーをやる人は必ずプロダクトとプロジェクトの関係性を理解して、自分の役割はプロダクトへ責任をもつことなのだということをきちんと理解しておくことが大事。

既知と未知

f:id:izumii-19:20201226130019p:plain:w400

ちょうど要件定義での悩みが多かったので、要件を明らかにするときに使えると思いました。「既知の既知」以外、つまり「未知」を減らしていくようにしないとならないんだけど減らし方のアプローチが違う感じですね。

「既知の未知」は質問することが解決の糸口になりそうだけど、「未知の既知」は違和感を探ることが糸口になるんだろうなぁ。「未知の未知」を減らすのは自分にしらない情報を仕入れたり他者との接触が役に立ちそう。

戦略

良い戦略とは計画のことではありません。戦略とは意思決定を下すのに役立つフレームワークのことです。

結論、この1行にめちゃくちゃ大事なことが凝縮されていると思いました。

戦略の章は、似たような用語がたくさん出て結構理解が難しかったので多分4回くらい読んでいて、ミルフィーユの層が厚くなるように少しずつ理解していったんですが、結果この1行に戻ってきた感じ。

何かを判断する時に「これをやることは価値を生むだろうか?戦略から外れていないだろうか?」ということを、企業のどのレベルにいても、どの部門でなんの仕事をしていても、照らし合わせて答えを導き出せるものであるということだと理解しました。

登山で迷わないための方位磁石のようなもので、この道を行きなさいと教えてはくれないけど、方向があっているのかを確かにしてくれるもの*2

そして「戦略は計画ではない」というのも意識するべきことだと思いました。「戦略=計画」と理解してしまうと「いつ」と切り離せなくなってしまうし、「なぜ」より「いつ」にフォーカスするとアウトカムよりアウトプットを優先してしまいがちになるから。

こう考えるとビルドトラップっていろんなところに仕掛けられてるんだなぁ、こわい。

顧客価値とビジネス価値

これはこの図が全てを物語っていますね。2つで1つ、相互的に働く価値交換システム。

f:id:izumii-19:20210111132736j:plain

感想

「本書への推薦の言葉」を読んで共感する部分が多い人は読んでみるとかなり発見があると思います。

私の場合は、過去にいたSIerスクラムチームがプロダクトとプロジェクトの違いをわかっていない状態で進んでいたチームだったなぁということを本書を読んだあとにふりかえってみて感じました。

アウトプットは出せていたと思うけどアウトカムは出せていたのだろうか。そもそもアウトカムはなんなのかということもチームでしっかり話したことがなかったなぁという記憶です。

SIerの場合は納期やスケジュールがお金に直結しているのもあり、プロダクトとプロジェクトを混同しちゃっていることに気づかないまま進めているところは多そうだなと感じているので、なおのことここをしっかり区別しないと簡単にビルドトラップにはまってしまうと思いました。

ビルドトラップの怖いところは、組織や開発プロセスなどのいたるところに罠があって、けっこう簡単にハマってしまうところと、痛みに気づかないままある程度進んでしまえるところだなと思いました。

そもそも会社がビルドトラップを誘発するようなビジョンを掲げている場合もあるかもしれませんし。

色んなところで「この本を読んでビルドトラップにハマっていたことに気づけました」という書き込みを見ますが、それってそっと罠にハマっていた人が多いということなんだと思いました。

いろんな方もおっしゃっていますが、本当にハッとするような事がたくさん書かれています。特にプロダクトオーナーをやっている人は自信をもってお勧めしたいです。

お礼

本書は株式会社アトラクタ 様の企画で当選し献本いただきました。

素晴らしい本をありがとうございました。

www.attractor.co.jp

*1:特にSIerの場合、納期やスケジュールがお金に直結しているのもありプロダクトを開発することよりもプロジェクトを遂行することに一生懸命になりがちだな、というのは以前から感じていたのですが、この本を読んでいると別にSIerに限った話でもないのか、という印象。

*2:我ながらすごくよい例え!