PdMになってやらかした失敗談
=======
Product Manager Advent Calendar 2019 12日目の投稿です。
はじめての投稿になります。ドキドキです。
=======
こんにちわ、FABRIC TOKYOでプロダクトマネージャーをしているこむと申します。PdMになってから、11か月目のぺーぺーです。
社内でCSやSCM（サプライチェーンマネジメント）を経験した後にPdMになった、オペレーション出身のPdMです。
基本的に何かプロジェクトに参加する時は、CSやSCMとして参加してきたので、いざPdMになった時に「PdMとして参加するってどういうこと？」や、「PdMって何すればいいの？」で悩まされておりました。今回はそんな悩まされていた時に失敗したお話を書いていきたいと思います。
同じように、オペレーション出身でPdMなりたての方や、そういった部下を持っている方に参考になるものが書けていれば幸いです。
1. インセプションデッキは俺が作る！
PdMとして参加した最初のプロジェクトは、元々いたCSに根深い「お問い合わせ削減のためのUI改善」のプロジェクトでした。とにかく職種が変わって初めての施策で張り切りまくっていた私ですが、「PdMって何したらいいん？」状態だったので、純粋に当時の上司に相談することにしました。
「今までCSとして参加した場合は、お問い合わせの中身を分析してみたり、解決できそうな手段を考えて実行してみたりしてたと思いますが、PdMって何したらいいんですか？」と。いろいろ話したのですが、その時の結論は「まずはインセプションデッキを作ってみたらどうでしょう？理想はそれをやるだけですね。」でした。
これを聞いた私は「そうか！PdMはインセプションデッキを作るのが仕事なのか！」と思います。これ、何を思ってこの発言をしているのかで、大きく意味が変わってきます。この時、上司の認識と、私の認識に差があり、両者解釈に違いが生まれていました。
上司の認識
・PdMはROIの最大化が最大のミッションである
・そのために、なぜやるのか？なにをやるのかに責任を持つ人である
・「なぜ」はリターンであり、「なに」はインベストである
・HOWの部分はタッチしない
・今回の施策は「なぜやるのか？何をやるのか？」が、まだ不明瞭である
なので、「インセプションデッキを作ってみたら？」の意図としては、
・なぜやるのか？なにやるのか？が、明らかになってないと作れないインセプションデッキをつくったらよいのでは？
・インセプションデッキはHOWまで明らかにするし、HOWに責任をもつステークホルダーと一緒じゃないと作れないだろう。
といった文脈が隠されています。一方、
私の認識
・PdMは、なぜやるのか？なにをやるのかに責任を持つ人である
・「なぜ」は、課題であり、「なに」は解決策である
・仕事とはHOWを実行することである
なので、「インセプションデッキを作ってみたら？」と言われた時、
・課題は明らかになってたけど、解決策は未確定だな。それを考えるのがPdM、私の仕事。
・そのためにやることが、インセプションデッキ。確かに、インセプションデッキを埋められたら全部わかってるから、ゴールだ！
・私のこの仕事でのアウトプットはインセプションデッキだ！
と、考えました。
PdMになる前、主にオペレーションにいた私は、「HOWを実行しない仕事」をしたことがなかったわけです。そのため、「仕事＝HOWの実行」ということが身に染みていました。それ以外の仕事があるという発想がなかったんです。かつ、ROIの最大化というミッションが全く頭に入っていなかったわけです。（実際に言われてはいましたが、よくわからんけどそうなんだくらいの認識でした。）というわけで「インセプションデッキをつくる」というHOWの部分だけを自身の仕事だと解釈してしまったわけです。そして自分の仕事なので、自分だけで完結させるべきとも考えたんですね。
その結果、「ステークホルダーがプロジェクトを自分事化できない」という事態が発生し、せっかく作ったインセプションデッキはうまく機能せず、さらに自分が作業をすることが多かったのです。最終的にプロジェクトとしては、目標を達成できましたが、PdMとしては失敗です。
（ちなみに当時は目標を達成したので、大成功☆と思ってました。役割を全うできていないけど、作業した物量が多かったので、やった気持ちになってしまったパターンです。）
元々CSにいたとはいえ、離れたら最新の情報をキャッチアップできているわけではありません。私が実行してしまったHOWの部分を、当時のCS担当者が実行することができていれば（実行するのは自分だと思ってもらえていれば）、作業時間は半分に短縮できていたかもしれませんし、もっといいHOWが生まれていたかもしれません。また、私は別の施策の「なぜ」「なに」を考えることに集中できたかもしれません。その結果、事業としてのROIはもっと大きくできた可能性があります。そう考えるとPdMとしては失敗だったなぁと、思う案件でした。
2. ユーザーストーリーは俺が作る！
今度は「在庫管理システムを作る」というプロジェクトに参加したときの話です。
このプロジェクトは、「業務がスケールしてきたので新たな受け皿が必要」というきっかけで開始されたプロジェクトです。すでに「なぜ」「なに」が確定した状態での参加でした。また、「新たな受け皿」についても、そもそも自社で全部開発するのか？それともどこか既存のサービスとうまく連携するのか？が、事前に検討完了しており、「どこか既存のサービスとうまく連携する」の方針ということも決まっていました。
そのため、私の役割としては「オペレーション」と「エンジニア」の間に入り、スムーズにシステム開発を行うこと。なので、この時は「よし、ユーザーストーリーを書こう！」となったわけです。
ここまではよかったのですが、例のごとくこれも一人で書き始めていました。「一旦、ユーザーストーリーを書いて、全員で読み合わせ的なMTGいれたらバッチグーだべ」こんな感じの思考です。だがしかし、ここで問題が発生しました。業務を知らな過ぎてそもそも一人ではユーザーストーリーが作れなかったのです。
というわけで、在庫管理の業務を行っている担当者とともにユーザーストーリーを作ることにしました。で、どうにか作り上げたので、そのほかのステークホルダー達や、エンジニアにそのユーザーストーリーを共有します。実はここまで約1か月かかりました。
と、ここからが大変だったのです。まず作成したユーザーストーリーが地味に大きかったです。数で言うと70個ほどではありますが、弊社の在庫管理のフロー自体が複雑だったということや、更に登場人物が13人いたことが拍車をかけ、ユーザーストーリーはもちろん、構造を理解するのがとても大変なものでした。そのため、作成したユーザーストーリーだけで他のステークホルダーやエンジニアに理解してもらうために、思っていた以上に時間がかかりました。
ようやく理解してもらえた！となったら今度は「そもそもこのユーザーストーリー叶えるためには、自社で全部開発しなきゃだめだ。いま選定してる既存のサービスじゃ連携できないよ。」ということが発覚。この時点でジョインして約2か月。
なんて無駄な2か月だったんだというお話です。これって最初からステークホルダー集めて全員で、コスト承知でガッとユーザーストーリーを作ってしまえば、全部1か月で発覚できたのでは？と。なんなら2週間で終わったかもしれない。
【まとめ】なんでもかんでも自分でやりがちだった
PdMになるまでは、「HOWのプロになる！」と頑張っていたわけで、「HOWをしない人」のマインドに切り替えるのが本当に大変でした。というか大変です。まだ切り替わってないのだと思います。何か問題を見つけたときに、ROIの検討よりも先にHOWを考えることが今だに多いですし、やりたいHOWがあり、このHOWがやりたいのってなんでだっけ？と、そこから課題を見つけにかかるというアプローチが多かったりします。
また、「自分が詳しいこと」であれば、課題発見や課題解決を考えることができるし、実行もできるが、「自分が詳しくないこと」だった場合、課題発見も課題解決もできないというか、いままでそんなことしたことなかったのか。ということがわかりました。
でもPdMって、「自分が詳しくないこと」に対して、課題発見、課題解決を行うことが多い気がしています。なので、そこが一番自身のボトルネックなのだろうなと、最近ひしひしと感じています。
人間て、体験したことが一番残るので、きっとオペレーション出身の方は、同じような苦労をしている方が多いのではないでしょうか？社内でオペレーションに詳しいからPdMにというジョブチェンジを行う会社も多いと思います。そんな時、こんなことに躓く可能性があるんだな～と、少しでも参考になればうれしいです。
この記事が気に入ったらサポートをしてみませんか？