新卒PMの1年間の思い出話。
新卒でコンサル会社に就職しましたが、コンサルではなく、
プロダクトマネージャー（PM）になりました。
PMが何かを知らないところから早くも1年が経過したので、
1年間を振り返りながら書かせていただきます。
初めての投稿です。
拙い文章ですが、少しでも誰かの参考になれば幸いです。
（途中完全な思い出話になっています。）
ここからは、1年間で私がぶつかったこと、参考にしたもの、得られた成果などを時系列順に書きます。
（2週間）PMってよく分からん
PMとは...?
主にMtgを進行し、タスクが遅延しないようにする人
第一印象はこれでした。
当時、上司にもらったタスクからのイメージです。
（今思えば新卒にできることからタスクを渡した良いマネジメントだったなと思います。）
すぐに勉強しました。
謎の魔法陣（例のトライアングル）を見てもそもそも各要素が何を示しているのか分からず、まさに異世界の魔方陣を眺めているような気分でした。
分かったことは、自分がやっていることがプロジェクトマネジメント（当時はそれすら出来てはいませんでしたが...）であるということでした。
（1か月）自分にできること・チームに足りないことは何か？
新卒に専門知識はない
当たり前です。でもこれを自覚し、認められる新卒って少ないと思います。
これまでの人生で活かせることはたくさんあるはず
これを認められる（＝自分を認められる）人も多くはないです。
私はゲームが好きです。
正しくは、ルールを把握し、問題解決をするのが好きです。
私が任されたプロダクトのルール（現状や勝利条件など）と問題は何か？
これを考えることにしました。
魔方陣を眺め、PMが様々な役割と連携する必要があることは分かっていたので、まずは自分が連携すべき社内の役割を羅列しました。
（以下、当時の組織図をもとに一部変更）
・エンジニア（インフラとかFEとかBEとか...当時いまいち分かってなかったですw）
・デザイナー（UI/UXの違いも当時は...）
・テクニカルサポート（顧客の問い合わせを受ける）
・カスタマーサクセス（顧客のサービス体験全体を描く）
・上司PM（主に以下の役割との接点を担っていた）
～以下、部署も異なり当時は全く把握できていなかった～
・カスタマーサポート（顧客の納品をサポート）
・コンサル（顧客のコンサル案件担当者）
・セールス（プロダクトを売る人）
・事業責任者
図にするとこうです。
（ならねーよ！！と思う方も多いと思いますが、お許しください）
開発チームをFW、PMをMF、顧客接点をDFとした図です。
（大学時代はサッカーゲームのウイイレが好きでしたw）
赤いエリアがメインのコミュニケーション相手で、青いエリアは上司が持っていたコミュニケーションラインです。
私が考えていたことは、
・目的は顧客に価値を届けること（＝得点）
・得点には、DFが拾う顧客の声をFWに繋ぐことが重要
・更には、各役割の連携がうまくいくようにパス回しを行うことが重要
そして、
・FWとDFが乖離し、連携が難しい距離感
・DFも多様な役割が乱立し、連携しきれず、誰も触れないで放置されるボールが存在する
と気が付きました。
そこで、
全体を俯瞰し、
①パスの中継地点として機能する
②放置されそうなボールを拾う
③それらによって得点に導く
これを自分の役割であると定義しました。
（当時の気分は”アンドレア・ピルロ”でしたw）
（2か月）PMFしてないかも...
専門知識がないので業務の合間を縫ってインプットをし続けました。
当時インプットしたリストからおすすめを一部抜粋
・INSPIRED
・エンジニアリング組織論への招待
・開発チーム組織と人の成長戦略
・カスタマーサクセス
・UXデザインの教科書
（当時はまだ出版されてませんでしたが、もし新卒のPMに一冊おすすめするなら、「プロダクトマネジメントのすべて」から入ると良いと思います）
その折に参加したpmconf2020で衝撃を受けました。
拝見したすべてのセッションで学びがあったのですが、Autify CEO 近澤さんの"Burning needs"の話がとても刺激的でした。
自分のプロダクトの顧客が誰なのか？
顧客のBurning needsが何なのか？
私は全く答えられませんでした。
PMF...してないってことか...と感じていました。
そして当日は聞けなかったが、日を置いて公開されたこちらのnoteも刺さりました。
プロダクトマネージャーの仕事は大きく2つに分類することができます。
プロダクトを作る仕事(プロダクトを育てる)と、プロダクトを作る"チーム"を作る仕事(ステークホルダーをまとめ、チームを率いる)です。
（上記noteより抜粋）
自分は、プロダクトを作る"チーム"を作る仕事をやろうとしている。
上司も、”チーム”を作る仕事をしている。
プロダクトを作る仕事って誰がやってるんだろう？
思い返すと、誰もプロダクトを作っていなかったかもしれません。
ただ、目の前にある受注目標や顧客要望を追っていたような気がします...
そもそも誰もPMFに向き合えてませんでした。
（3,4か月）顧客の課題を探る
PMFに向き合うため、ロイヤル顧客をターゲットにN1分析を行い、
分析結果をもとにグロースサイクルを定義し、開発を行いました。
これによって「PMFできたか？」と問われると、答えは「No」でした。
（グロースサイクルやN1分析を否定するわけではありません。むしろそれらの考え・手法は今でも利用しています。）
「最近の開発は谷埋めになっていないか？山を作ってほしい。」
事業責任者に言われました。
自分の描いたサイクルを信じ、それを回すための谷埋めをしていました。
そもそも何のためのプロダクトなのか？
ビジョンが不明瞭のまま顧客を見てしまいました。
（5か月）ビジョンから見つめなおす
「最近の開発は谷埋めになっていないか？山を作ってほしい。」
繰り返しますが、実際に何度も言われました。
「山」とは何か。
プロダクトの独自性であり、顧客への価値だと思います。
リーンキャンパスや仮説のミルフィーユでビジョン/ミッション/バリューなどをまとめ、見つめなおしました。
独自性がない。
顧客はわざわざこのプロダクトを使う必要がないことに気づきました。
改めてプロダクトの方向性を、考え直すこを決めました。
今思いなおせば、目先の行動を起こせそうなところから取っかかってしまったなと反省します。
足を止めても、現実を直視することが必要でした
（6~7か月）2つ目のプロダクト。最小の偉大さ
そんな最中、立候補によって2つ目のプロダクトチームを持つことになりました。
こちらは数年前より構想はあったものも要件定義がまとまり切らずに停止していたプロダクト...
（一部で「サグラダ・ファミリア」とか呼ばれてました...）
既に存在する過去のドキュメントすべてに目を通し、再度1から要件定義をし直しました。
巨大な建造物ではなく、顧客に価値が届く最小のスコープごとのリリースを決めると、これまで構想とドキュメントまでの存在だったものが一気に進み始めました。
スコープを切ること、最小を見極めること（＝いわゆるMVP）は今でも忘れないようにしています。
思い出話：
ここに立候補したおかげか、社内の新人賞も頂きました。
これまで個人で賞をとってもあまり嬉しくなかったひねくれ者なのですが、
この新人賞のワイプで抜かれた上司/元上司や開発チームのメンバーがとても笑顔で喜んでくれていたのが嬉しかったです。
（8~10か月）残業は遅延
プロダクトを２つ持つことは大変です。
（当たり前ですよね。正直、いけるやろと思っていました。）
2つのプロダクトマネジメントを愚直にすべてやろうとしました。
当時の記憶はややありません...気が付いたら3か月経っていた感覚です。
そんな状態だったのですべてが中途半端でした。
そしてほぼ毎日遅くまで何かをしていました。
そんな3か月の終わり頃
開発チームの外部パートナーさん2人のうち1人の方が明らかに帰りが遅くなっていたそうです。
と言うのも、恥ずかしながら私はチームメンバーの様子を確認する余裕もなく、もうひとりのパートナーさんが教えてくれました。
この2人の外部パートナーさんは月末をもって退プロが決定しており、何としても自分がいる間にタスクが完了するようにと頑張ってくれていたようでした...。
状況を教えてくれたパートナーさんに言われました。
「残業してるってことは遅延してるんですよ」
「社員さんが帰らないとパートナーも帰りにくいです」
めちゃめちゃ刺さりました。
当時これを教えてくれたことを本当に感謝しています。
以来、考え方が変わりました。
リリース予定日を決め、そこに間に合わせるように進めるのではなく、
リリース目安を変更しながらリリース予定日としての確度を高めていく
目先の期日を守るための短期的な努力ではなく、
長期的に見てより顧客に価値提供するための開発を行う
（＝チームの体調まで考えたスケジュールを行う）
プロダクト開発は長期戦であることを改めて意識するようになりました。
（約1年）やらないをやる
2プロダクトを行き来し、中途半端になってしまったこと、チームとの距離（単純なコミュニケーション時間不足）が出来てしまったことで「何考えてるかわからない」と言われ反省しました。
そこで、すべてはやらないことにし、開発チームにもプロダクトマネジメントに関わってもらうようにしました。
具体的には、開発のスケジュール管理などはエンジニアやデザイナー各自に任せました。とは言え、チームでスケジュールの認識を合わせるために共通の線表にまとめ、確認自体は行っています。
ただ「順調そうですか？」と聞くだけにしました。
そして「残業してるんだったら遅延してますよ？」と言っていますw
また、Mtgの進行もチームメンバーでルーレットで決めるようにしました。
これによってエンジニアも目先のタスクだけでなく、ロードマップ全体を意識しやすくなりました。
日々のmtgにランダム要素が加わり、少し楽しくなったのも良かったです。
（元々は少しでも自分が楽をしたいと思っていただけですw）
他にも、これまできれいにまとめた情報しか開示していなかったことをやめました。
slackに「blueprint」というチャンネルを作り、直近の要件やはたまたいつかの未来の話など私の頭の中を垂れ流すことにしました。
（"blueprint"の本来の意味とは違うかもしれませんが、未来設計の場です）
これによってPMがどんなことを考えているのか、今何に時間を使っているのかを開発チームが分かるようになり、チームとの距離もかなり近づいたと感じます。
更には、コンサル・セールス・カスタマーサポートと開発チームの仲介もやめました。自分が入ってバリューが出る場合以外は直接やり取りをしてもらうようにしました。
これらの結果、PM・PMM・デザイナー・テックリードを中心にプロダクトチーム全体でプロダクトマネジメントを行うようになりました。
図にするとこうです。
（またかよ...と思った方すみません。そのうちサッカーで説明するプロダクトマネジメントのnoteを書こうかなと思っています）
これはPMがプロダクトマネジメントのすべてはやらず、
チームでプロダクトマネジメントの意識を作った結果です。
こうして作った時間を未来に投資しています。
開発チーム内でプロダクトマネジメントが当たり前になった時、
PMは未来を考える時間に投資できます。
1年前はその日の進捗を気にしていたPMが、1年後には数年先の未来を思考することに注力できるようになりました。
（もちろんチームの協力あってのことです。）
（雑な）まとめ
・専門知識がなくとも、出来ることはある
・チーム（関係者）を俯瞰する
・現実を直視する
・MVPの偉大さ
・残業は遅延
・プロダクト開発は長期戦
・プロダクトマネジメントはチーム競技
・プロダクトマネージャーは未来に投資を
・プロダクトマネジメントはとても大変でとても楽しい
最後に
最近、開発チームで「プロダクトマネジメントのすべて」の輪読会を始めました。エンジニアが前向きにプロダクトマネジメントのために何が出来るかを考えてくれます。
1年間でチームメンバーもほぼ総入れ替えになったのですが、現在このようなチームを作ることができていることが自慢です。
もし最後まで読んでくださった方がいましたら、本当に拙い文章を読んでいただきありがとうございます。
これからnoteに少しずつ投稿していこうと思います。
よろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？