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

前回 、優先度の考え方わからねーーーって決められねー書いていたが、掲題の本に「ウェイター」という例で、プロダクトマネージャーのあるあるな落とし穴と書いてあった（もう一個の例はミニCEO）。ウェイターはなんの思想もないため顧客あるいは社内ステークホルダーのいうがままに機能を作っている人であると、思想がないので何から手を付けるかという優先度の問題が最大の心配事になってしまう。顧客に価値を届けるのが仕事なのに！

これに関連して、スクラム批判もある。スクラムの文脈だと、POがビジネスアナリストやステークホルダーと話して優先度を決めますとあるが、どうやって決めればいいんだよってウェイターと同じ問題。ステークホルダーが作るものを知ってるっていうのは現実世界の製品開発とかけ離れすぎてないですかね…。そういうとこから受託開発臭がするんだよなー、、アジャイルマニフェスト。ちな、More Effective Agile の要件ぎめ（どうやってプロダクトバックログに追加するのか）をめちゃ詳しく書いたのが本書のテーマだと思ってる。スクラムは""どう""作るかは教えてくれても誰に何をまで教えてくれないよね。

話がそれた、その記述がある時点で（かなり序盤）はっとしたのだが、本書後半の事業戦略とかの話からトップダウンにプロダクトマネジメントするという話が eye opener であった。 企業のビジョンと戦略的意図（たとえば成長率年率50%、事業目標って感じする。。語感がダサい。料理をおいしくするでもよい）があり、そこからプロダクトに目標（本の中ではプロダクトイニチアチブ）がおりてくるという考え方をするといいのだ。本書の例だとIPOのために売上あげるという事業目標があり、エンタープライズ分野の開拓とかパートナーシップの構築とかあった。これらは上位概念である戦略的意図と整合でないといけない。てか、自分には機能という単位で降りてくるのだが、それも事業戦略！につながってたんだねー全然知らかなったよ。

たまにトップマネジメント（社長とかです）から話を聞いても、いまいち理屈がわからんかったとか前提がわからん？？？ってなってただが、こういうコンテキストがあったのね。偉い人はこういうことはしおりがち。

しかし、こういう話って基礎の基礎だと思うんだけど会社員だったら知ってるもんなんですかねー。 よく聞く話で、新機能 OR 新サービス OR 作り直しを経営陣に提案する機会があったけど全然わかってくれなかった！大人はわかってくれねえー！！みたいなcomplaintや discomunication も、これで説明できるね。よく聞くってことはみんな知らないんだろうなー。経営陣やマネジメントの人らは事業としてしか見てないわけだから話通じないのもそうよね、、ってか見えてる世界が違うという話。はっこれが事業がわかるエンジニアって話（2020年にそういうブログが一瞬バズったのです）か、、、事業がわかるってなんやねんって思ったけど。こういうことね。昨今のエンジニアリングの buzzword である機械学習にしろkubernatesにしろ事業に対するインパクトって観点から説明できるわけじゃん（やっぱ事業がわかるエンジニアじゃん…）。そういう説明するのが技術系の経営幹部の仕事なのかも。「エンジニアのためのマネジメントキャリアパス」という本の後ろの本にも技術系幹部って章があった。

で、優先度の話に戻すと事業の目標に貢献しそうなやつからやればいいんじゃないですかね。なにすればわからなかったらユーザーインタビューするなりレポート読むなりログ見るなりして問題を探せばいいんじゃないですかね。それでも見つからないならコスト削減すればいいんじゃないですかねと、立派な事業貢献だ。 ちゃんとしたカイシャだったら、ブレークダウンされたKPIがありKGI（だっけ？）がありOKRがあり、、なんでしょうか、、、ないものはないので。個人的に、そういうのがない autonomy なほうが自分にあってるというのもあり嫌いじゃない。

しかし、自分の日々の仕事も事業につながってたのかーっていう発見があって、事業にかかわりたいなーという気持ちになってきた。さいわい今の仕事はお金、会計システムも守備範囲なので結構かかわってる、そしてさらにさいわいなことにこういうことに興味がありそうな人が少なそうなのでワイワイできそう。こんご数年のテーマは事業の継続性のためのエンジニアリングにしたらいろいろおもしろいんじゃないかなーと。これは自分の市場価値をあげるという利己的な副作用もありそうであるとともに、勉強すること多そうで楽しそうだ。