料理は至高のPMエンタメ! 身近でできる疑似プロダクトマネジメント体験
1/1にPM入門講座をリリースして以来、いろいろと相談をいただくようになった。多いのが、「どうしたらPMになれますか？」、「自分はXXというバックグラウンドがあるんですが、PMに合っていますか？」というもの。まずは「僕の講座で思いっきりカバーしていますんで、ぜひ受けてみてください」とはご案内するものの、ふともっと身近にPMを体験できることがあるじゃないかと気がついた。今日はそれをまとめてみます。
料理はPMだ
先日何気なくツイートしたことがプチバズした。
プロダクト作りの責任分界点。
— Haruki Sonehara | 曽根原 春樹 (@Haruki_Sonehara) January 8, 2019
プロダクトマネージャー
→WhyとWhat
プロジェクトマネージャー
→WhenとHow much(社内でのコスト面)
エンジニアリングマネージャー
→WhoとHow
混ぜるな危険 https://t.co/rjDb4BWSm1
多くの共感があったこのツイート。自分がこういう結論に至ったのには、実際に各々の役割を兼任したりして、試行錯誤の繰り返しがあった。この一連のプロセス、実行は上記のプロフェッショナル達に任せるものの、プランニングの段階ではPMもかなり絡む。そして、実は面白いことに「料理」でこの流れを追体験できる。各々のステージでPMが考えていること、そのステージを誰かに任せるということはどういうことかが、体験として透けて見えてくる。
具体的には、
Why: なぜ料理をつくるのか？
腹減った（けど食べに行くのが面倒）。持ち寄りパーティーに参加する。彼の胃袋掴みたい。彼女に料理男子ぶりをアピールしたい。
なぜ料理を作るのか、料理を通して何を達成したいのか？まずPMとしてWhyに対して明確な答えを用意する必要があります。
次にWhat
料理を作る目的を決めたのなら、次は「何を」作るのか。
和食、中華、イタリアン、大皿料理、小鉢、一汁三菜などいろいろあります。
ここで「誰に食べてもらうのか」という観点が必要になってきます。そう、PMの世界でいう「ユーザー」です。作った料理（プロダクト）は食べてもらう人（ユーザー）に満足してもらってナンボです。そうなって初めてプロダクトとしての価値を理解してもらえることになる。
When
その料理をいつまでに作るのか。それは今日の夕飯？週末のイベントとして？
タイムラインを決めないと、いつまでたっても料理たるプロダクトは出来上がらない。
How much
冷蔵庫の中のものですますのか、買い出しに行く必要があるのか、予算はいくらまで出すのか、オーブン料理（USのほとんどはガスオーブン）だとガス代かかるし、煮込むなら圧力鍋を使ったほうが1時間も煮続けるより経済的。
Who
自分で作るのか、誰かと作るのか、外注するのか。シリコンバレーではよく"Build or Buy"と言ったりします。
How
どのレシピを参考にして作るか、レシピ通りにつくるのか、アレンジするか、それとも独自にレシピを考案するか。盛り付けはどうするか？作り手のスキルレベルや、食べ手の期待値、要求の高さ、予算やタイムラインの関係でこのあたりが決まってきます。
いざ調理開始！
これで料理（プロダクト）のScope of work (SOW)が決まりました。いよいよ作っていきます。決められた時間内で作るのはスプリントと一緒。
スプリントが走り出すといろいろな障害にぶつかります。それはバグであったり見積もり違いであったり、ビジネス要件の変更であったり。料理で例えるなら、調味料の分量を間違えたり、レシピ通りにつくったのになぜか薄味、といった感じです。
期待してた食材がイメージと違ってた時なんかは、3rdパーティーのAPIが期待どおりに動かなかった時のがっかり感とそっくりだ。
また、時間が決まっているため複数のことを同時並行で進めなければいけない。パスタを作る時、お湯を沸かし麺を茹でている間にソースを作るというように。かといって、茹ですぎてしまってはおいしくなくなる。
プロダクトマネージャーとしてはこうした困難に直面しても逃げられない。何をして、何をしないか決断をする必要がある。プロダクト開発と料理の関係でいうと、
バグを直す -> 作り直す
Workaroundを当てる -> 調味料や別の食材を追加して味を調整する
Backlogにして後回しにする -> 今回はあきらめ、次回再チャレンジ
運用で回避 -> 完成後、食べる直前に何かを一味加える、つけダレやソースでなんとかする。
当然それぞれのオプションにはPro/Conがあり、PMならばどの選択肢が失敗のリスクを最小化しベネフィットを最大化するかについて頭をめぐらさないといけない。
そして実食
こうして様々なプランと実行の積み重ねでできあがった料理を食べてもらうことになります。食べた人から「おいしい（これは便利）」と言ってもらえればPMとしてはひとまず及第点。「また食べたい（また使いたい、誰かに薦めたい）」と言わせて初めてナンボです。これはUser retentionやNet Promoter Scoreの考え方と同じ。
料理にはプロダクトマネジメントのエッセンスがつまっている。もちろん料理ができるからといってPMにすぐなれるわけではないが、少なくともPMがどんなことを気にしながらプロダクトを作っているのかを疑似体験できる、至高のエンタメだ。
実際には
冒頭で紹介したツイートのように、本当のプロダクト開発となると一人ではなく多くの人と連携しながらおこなうことになる。PMとしてWhy/Whatをどう決めるかは会社の命運すら左右する決断。Why/Whatが決まるためには、ユーザーだけでなく、会社の上層部やマーケ、営業、サポート、BizDevといった部署とも話しビジネス要件を決めなければいけない。一度決まればPJMやエンジニアリングマネージャーと議論してどう作っていくかを決める。一人で料理を作る時にはなかった、他のプロフェッショナル達との高度なコミュンケーション能力やビジネスセンス、取捨選択の決断力が要求されることになる。
（また、子育て家庭や共稼ぎで忙しい家庭では、正直言っていちいちこんなことは考えていられない。あくまでPMという観点で料理を噛み砕くと、という記事なのであしからず。）
料理教室イベントはチームビルディングに最適！
シリコンバレーのスタートアップ界隈でも実はCooking Classがチームビルディングのイベントとしてよく行われたりしています。 複数名でやると、PMの観点だけでなくチームプレイの観点も入ってきてなかなか頭使うんですよね。Googleだとビルによっては社員食堂にCooking Classの施設があって、社員なら自由にスケジュールして使えたり。
これまでPMってどんなことを考える人なのかわからなかった、という人にこの記事を通して伝われば幸いです！
