今回は@ryuzeeさん翻訳のこの本！

偉そうに書評ができる立場でもないので、印象に残った文を引用しつつ、感じたことをつらつらと書いていこうと思います。

印象に残ったこと

　プロダクトマネージャーはテクノロジーとビジネスのあいだにて、ビジネスを維持して成長させながら、顧客のニーズをプロダクトに変換するという役割を担っている

・プロダクトマネージャーという役割を端的に表現した一節。これは今後引用させてもらいたいフレーズでした。

　アジャイルさえあればソフトウェア開発が成功すると多くの企業が思い込んでしまい、前提の部分が失われてしまったのです。

　これは最近とても思うこと。

うちはアジャイルじゃないから・・・。

　↓

教科書通り、アジャイルを真似てみる

　↓

うまくいかない！

　↓

うちにはアジャイルは合わない

という決めつけをよくみる。センスない。

この辺りはこの記事にもまとめています。

一方で、プロダクトマネージャーは組織のCEOほど多くのことを変えることはできません。特に人に関する権限は持ちません。

「PdM=ミニCEO」という表現をよく聞きます。これを真っ向から否定しているのが印象的。確かに、「PdM=Engineering Manager」という中央集権的な組織であれば、ミニCEOと言えるかもしれませんが、プロダクトの責任とヒューマンマネジメントの責任が分かれている組織だと、ジトに関する権限は持たないし、そんな組織の方が健全な印象。

プロジェクトマネージャーは「いつ」に責任をもちます。プロダクトマネージャーは「なぜ」に責任を持ちます。

よく、PdMとPjMが混同していたり、そこに上下関係を表現していたり、組織によって捉え方は様々。いつの間にか「いつ」への責任に押し潰されて「なぜ」が疎かになってしまうのは避けたい。これもビルドトラップのひとつかもしれません。

プロダクトマネジメントはシステム全体を見ます。要件、機能コンポーネント、価値提案(バリュープロポジション)、UX、ビジネスモデル、価格モデル、全体の統合などです。

「PdM≠開発PO」を明確に示した一節。ビジネスモデル、価格モデルなどに責任を持てている真のPdMになれているかはポイントの一つだと思いました。

なぜこのプロジェクトをするのか？達成したい結果は何か？成功とはどのようなものか？どうやってリスクを減らすか？

特に「成功はどのようなものか？」は重要だが、忘れてしまいがち。完了(完成)の定義が明確でないとプロジェクトのWhyが霞んでしまうと実感。

どうやって価値を判断するのか？マーケットでのプロダクトの成功をどのように評価するか？適切なものを作っていることを確認するにはどうしたらいいか？プロダクトの価格とパッケージはどうやって決めるか？どうやってプロダクトをマーケットに投入するか？自分たちで作るのとありものをかってくるのでは、どちらごよいか？新しいマーケットに参入するために、サードパーティのソフトウェアと連携するにはどうすればよいか？

　特に「どうやって価値を判断するのか？」は難しいけど、目を背けてはいけない。ここを疎かにすると、後から取り戻せない。ビジネス価値がなぁなぁになって、提供価値の有無が見えなくなってしまう。

SAFeはこの点において違うことをおしえていて、そこがSAFeの最大の弱点です。SAFeでは、プロダクトマネージャーはプロダクトオーナーのマネージャーであり、外部との対話や作業に責任を持ちます。

　これは少し思っていたことを代弁してくれた印象。スクラムが定着してきて、より大きな範囲に適応するための方法はいろいろあるけど、まだ発展途上で議論の対象になっているのがある意味面白いフェーズ。

代わりにNetflixのグリフィンプロジェクトは別会社としてスピンオフしむした。それが今日のRokuです。

仕事柄興味があった。海外のマーケティングをしている中で日本に少なくて海外にある市場がSTB(セットトップボックス市場)この市場の勝者とも言えるRokuがNetflixからのスピンアウトとは初めて知って個人的にびっくり！

自分が耳にしたストーリーにもとづいて行動できるようにするには、慣れている時間軸と大きくかけ離れたストーリーであってはいけません。

　何事も自分の言葉で語れないとしっかり理解したとは言えない。「人に語ることで知識は広がるよね」というラーニングピラミッドとも通ずる印象。

制約のないチームは、組織内で行動するのをいちばんおそれます。選択肢が多すぎて何も決められないと感じてしまうのです。

「自由にやっていいよ」の暴力を痛感した一節。(ポジティブな)制約があることでイノベーションが加速するのは、スポーツにルールがあるから面白いのと通ずることがある。そう言えば、最近この辺り語った気がする。

現代において、ユーザーを収益化するのにすべての企業が同じ道を歩むわけではありません。

　教科書をコピペして実行するだけではなく、工夫が必要なことの現れ。如何に考え、実験していくかの大切さを感じる。

「なるほど。でも、それはなぜですか？なんでボタンが必要なのでしょう？なぜボタンが適切だと思いますか？」

　ステークホルダーとの対話の中で私自身も気にして実行していること。質問の質が共通理解の質であり、少し「うっ」となる質問だが、このために心理的距離感を詰めておくことが大切でもある。

MVPは単に機能を早く手に入れるためだけにつかうというのは、途中にある素晴らしい体験の部分を手抜きでやってしまうことになります。

　ここは私自身も忘れてしまいがち。自戒の念も込めて、身に染みた言葉。

ウォーターフォールのプロジェクトであっても実験が含まれることはよくあります。スペースシャトルの開発を例にして考えてみましょう。

これも最近すごく思う「アジャイル vs ウォーターフォール」の構造への違和感を代弁してくれた印象。スペースシャトルで例えるのは分かりやすく、これから引用させてもらおうと思った。これについてもここで書いている。

プロダクトロードマップは常時更新する必要があります。

狂気の沙汰です。年間ベースの予算のせいで、チームがその年の途中で方向転換する能力を完全に奪ってしまっています。

　これは偉い人たちにずっと伝えているけど、伝わらない・・・。企業の中期計画を立てることの重要性はわかるが、それ年間で何回見直して修正してるよ？と思う。

　成功をアウトカムで判断しなければ、決してアウトカムを達成することはできません。

　これは周りでよくみる構図。「年間どのくらいデプロイしたか」「リリースをいくつ打てたか」というKPIってわりとどうでも良くて、実際にそこからどんなアウトカムが得られたのかが重要。

　アジャイルであること、顧客中心であること。これはすでに企業文化に組み込まれています。

　もはや、「アジャイルが向いている/向いていない」という議論はダサい。不確実性が高い世の中、それが普通。未来が予知できるエスパーなら別だが、かのマークザッカーバーグですら、「ファクトを大事にせよ」と言っている。

まとめ

というわけでこの書籍では、「ビルドトラップ」という言葉であらゆる引っ掛けポイントをリアルに表現して、警告してくれています。

　PdMの心構え、仕事ぶり、組織構造など含めて網羅的に捉えることができます。

　是非みなさんも手に取ってみてください。

---------

この記事を書いた人はこちら

「この記事いいね！」「この人、気になる！」と思ったら、是非各種SNSのフォローをお願いします！