自己紹介と本LTの概要
小西裕真氏：自分からは「意思から始めるプロダクトマネジメント」というテーマで話をします。
始めに少し自己紹介をさせてください。名前は小西と言いまして、エンジニアバックグラウンドでプロダクトマネージャーをしています。経歴としては、いくつか会社を務めた後、2022年末に独立をして、約1年間フリーのPMとして仕事をしてきました。
今回のLTのテーマは「育成」に近いものになります。仕事をする中でPMの実務もしているのですが、それに付随するかたちで若手の方や新人の方とかのサポート・育成を求められることがあり、その中で「みんながどういうところで引っかかるんだろう」とか、「それに対してこういうアプローチをするとこんなリアクションがあったと」いうものの知見がいくつか溜まってきたので、そういう話をしようと思います。
新人PMが感じる2つの難しさ
はじめに、そういった方々がどういうところに難しさを感じるのかを、今回のLTに際してあらためてヒアリングをしてきたので、そちらの話をします。
（スライドを示して）この2つが大きかったかなと思っています。前者は想像に難くないというか、「PMをやります」となった時に、調べると膨大な知識ややることとかが求められて、もうそれだけで圧倒されてしまうというか、何から始めたらいいのかわからない。
ロードマップ、開発プロジェクト、アジャイルみたいなところで、けっこうごちゃごちゃしちゃって、何が正しいのかわからない。今自分がやろうとしていることが本当に適切なのかもわからないといったことを言う方が多い。「それはそうですよね」とほぼ全員言っていました。
もう1つのほうは本人の口からあったわけではないのですが、先輩だったり経営者だったり、誰かが正解や勝ちパターンみたいなものを持っていて、その人に聞けば最適なものができる。「プロダクト開発には絶対的な、普遍的な解がある」と期待しちゃうような発想を持っている人もいて、このあたりは心構えの変化としてやはり必要だよなと思う機会がちらほらありました。
大胆かもしれないが、いったん手法は置いておく
このあたりは「わかるな」という悩みである一方で、「じゃあどうしたらいいんですか」ということも自分の仕事として求められることがあります。
（スライドを示して）ちょっと大胆かもしれないですが、こういうことを伝えることが多いです。「手法」と言っているのは、いわゆるロードマップやキャンバスなどという、ドキュメントを作る細かい話です。
最終的には必要なのですが、「優先順位というか、物事の順序ってあるよね」みたいなことを思っています。それはいずれ必要になるけれど、それよりももっと先に必要なのは、顧客課題とかプロダクトの向かう先とかですね。そういうことに対しての理解を深めて、自分の意見や意思を確立すること。
「自分はこうしたい、なぜならこうだから」みたいなことを人に説明できる状態になっておく。その際にキャンバスが必要になったり、きちんと人に伝えるためにツールが必要になったりするので。
ドキュメントの達人とか、ワークショップの達人みたいな、謎の……。大事ですが、そういう知識を先に入れなくてもいいのでは？ 入れ過ぎなくてもいいのでは？ ということをよく伝えてます。
というのも、そのドキュメントはあくまでその物事を伝える媒体とかツールです。今回は「原料」という表現をしていますが、そこに載せる情報とかアイデアの質が高いことのほうがよほど重要だろうという意図から、こういうことを伝えています。例えとして適切かはわからないのですが、「すごくきれいなお皿の上においしくない料理が乗っても良くないよね」という感じかなと思っています。
結局、情報で良いものがあれば、体裁はあとからどうとでもできたりするという意味で、順序の概念をすごく強調して伝えることが多いです。
「意思から始める」とLTのタイトルに入れていますが、自分なりの考えを固めて、それをベースに何かをやっていくことをおすすめしています。
巻き込みや社内調整みたいな話においても、いろいろな人の話を聞いてなんとなく折衷案を出すといったかたちではなくて、自分なりの見解、顧客の声に基づいた道筋があって、それを軸にいろいろな利害調整をすることのほうが建設的かなと思うので、社内調整においてもそういう進め方をできるのが理想だと、いろいろな方に話しています。
ここはもう本人の能力じゃなくて組織の影響とかもあるので一概には言えないのですが、個人的におすすめしているのはそういう方法になります。
おすすめのプラクティス「ペアロードマップ」
ここまでで、「自分の意思を持つ」とか「顧客理解を深める」みたいなことをすごく推奨してきているわけですが、「自分の意思を持て！」と言って、いきなりみんながそれをできるわけじゃありません。それをやるための手法として、自分がやっていて手応えがあったものがあるので、それを少し紹介してこのLTを終わろうと思っています。
ロードマップでなくてもいいのですが、ペアで何か考えながらドキュメントを起こすということ。これはやってみておすすめしたいものになります。良いなと思っているところが2つあって、1つが試行錯誤しながら書いているということが伝わる。
これはどういうことかというと、最初の「みんな正解を求める」みたいな話にも通じるのですが、美しい成果物だけを見ると、論理的で熱くなるストーリーが書かれていて「すげぇ！」となったりします。
でも作っている過程は平坦ではなくて、あっちこっちいろいろなことを考えて「ああでもない、こうでもない」というプロセスを経て、最終的にこれ（成果物に出ているもの）が残っているというかたちのものがほとんどなので、良いドキュメントを書く人も、最初から正解を知っているわけじゃない。
いろいろと試行錯誤して、当てが外れてみたいなのもありながら、最終的にみんなが納得できるようなものに落とし込んでいるんだという、それ自体を伝えることができるのは良いかなというのが1つ。
もう1つはコーチングみたいな話に近いかもしれないのですが、「僕、実はこういうことがやりたいんですよね」とか「なんかみんなこう言うけど、僕はちょっと違うと思うんです」みたいなことは、オープンな場ではやはり言いにくい。だけど、自分なりの気持ちとして抱えている方はけっこういる。
そういうことを後押ししたり、深掘りする。「なぜそう思うのか」だったり、「それが合っているのか間違っているのかをどうやって確かめるのがいいんでしょうね」みたいな話をすることで、1人だとワッと打ち出すことが難しいですが、応援してくれている人がいるとか、妥当性について健全なツッコミを入れてくれる人がいるということによって、その人が勇気を持って進めるようになるみたいなこともすごく良いところで、そういうところをアシストするという意味で、人が書いたロードマップの成果物をレビューするのではなく、書いているプロセスから一緒にやって、人もドキュメントも一緒に育てるみたいなことをやるのは、けっこうおすすめのプラクティスです。
まずは自分の意思を持ち、顧客理解を深める
最後にまとめになります。学ぶべきことは多いし学習自体は必要ですが、でも、もっとも根源的で、何事にもつながるのは、やはり顧客課題を知り、自分なりの意見をまとめること、自分なりの意思を持つことかなと思います。
ここを自分の意思で固めるのかどうかを、PMになった方が初めの目安にするのがいいんじゃないかなと思っています。それがないと社内調整とか、ものを作る時にワークしないでしょう。それがあったら、フレームワークはそれを加工したり、乗せたりする場所なので比較的うまくいきやすいというか、ちゃんと適切にツールを使えるようになるのかなと思います。
「そういったPMの方を育成したい」みたいな方向けの話で言うと、成果物とか結果を後からチェックするのではなく、思考の過程、いろいろな人が書いたモヤモヤとか葛藤みたいなものに寄りそうみたいなところまで入り込むと、サポートとしてワークすることがあるのかなと思っています。
自分のLTは以上になります。ありがとうございました。
