2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
ーー最近ではPMという職種について見聞きすることもかなり増えてきましたが、devPM立ち上げ当時、PMの認知などはどのような状況だったのでしょうか。
浪川:原体験的に強く覚えていることとして、エンジニアはもともとOSSみたいな文化があったり、いわゆるQiitaやZennみたいな、集合知を共有する場が自然と作られていたと思うんですよね。なので、エラーが発生して「どうしよう。解決できない」となったら、前に同じところで失敗した人のQiitaの記事とかを見つけて解決できる体験をしていました。
だけど、自分がPMになった時に「どうやってPRD(Product Requirements Document)を書いたらいいんだろう?」と思って検索をしてみても、やったことがある人の例が出てこない状態でした。
なので、私だけじゃないと思いますが、ドキュメントのフォーマット1つを取っても自己流になってしまって、どんどん属人化していってしまって。これは技術的負債と同じぐらい、後に負債になってくることかと思っています。そういう意味で、周囲に聞ける環境がなかったり、検索してもたどり着けないところにモヤモヤを感じていました。
まわりでPMをやっている人に聞いても同じような課題があったのと、「PM=辛い仕事」とみんな思っていたんですよね。例えば後輩のエンジニアに「キャリアには悩んでいるけれど、PMにだけはなりたくない」と言われたりとか(笑)。
そういうことがけっこう発生していて。PMは楽しいこともいっぱいあるんですが、PMになりたくない人が増えてしまうというところに、課題をすごく感じていました。
PMの認知については、私がdevPMを立ち上げた時は少なくとも“プロダクトマネージャー”という文脈は周囲ではほとんど聞かなかったと思っています。というのも、devPMのメディアを作った当初は“プロジェクト”という単位で解決策となる記事などを作っていたんですよね。
ただ、自分が支援する案件先などの状況を変えていく中で「これはプロジェクトだけを見ていてもダメだ。プロダクトをちゃんと見ないと」と思い、提案する範囲を広げた経緯があります。
もちろん、当時から一部のスタートアップやWeb系の企業ではプロダクトマネージャーという職務はあったと思いますが、少なくとも私の周りやSIer業界では、プロダクトマネージャーという職業は聞かなかったんじゃないかと思います。
今はだいぶ知られてきましたが、それでも採用の支援とかをしていると、募集する側も応募してくる側も、まだまだ噛み合っていないことが多々あります。
PMという文脈の中で何を求められているのか、何を求めているのかがそれぞれ違ったり、「それはプロジェクトマネージャーのスキルですね」みたいなことをプロダクトマネージャーとして募集をしていたり。そういったことはまだまだ起きているなと思います。
ーーdevPMを立ち上げられた時、周囲のPMの方からはどのような反応が届いていましたか。
浪川:知り合いもそうですし、Twitterとかで知ってもらった方に関しても、「これを待っていた」というような反響やコメントはいただきました。あとdevPMはもともとメディアとして立ち上げていたので、「記事を書きます」と言ってくれる方とか。そういった反応が多かったなというところはありますかね。
あとは、取引先の中で「プロダクトマネジメントの知見が知りたいから、ぜひ記事の更新をがんばってください」と言ってくださる企業さまもいました。その反応からも、PMが足りていないのはみんなの課題感として一致していたのかなと思います。
ーーみなさん課題意識があったところに対して「やります」と声を上げることは、ある意味怖いことでもあると思います。立ち上げ時の緊張などはありませんでしたか?
浪川:私の場合、もともとエンジニアのコミュニティも運営していて、そのエンジニアのコミュニティの中でも、何人かマネジメントをやっている方が出てくるんですよね。「これからPMをやろうと思っている」「最近PMをやることになったんだよね」という方々がいて、そのエンジニアコミュニティの人たちと一緒に「じゃあ勉強会をやってみよう」といって立ち上げたのがdevPMでした。
なので、「私1人だから怖い」とかはぜんぜんなくて。同じように困っているPMがすでに何人かいることを知った上で、仲間と一緒に立ち上げたという感じです。
ーーなるほど。devPMのサイトの中で「PMだって、周りに助けられてもいい!」というフレーズがすごく印象的でした。これはやはりPMが頼れる人を見つけられない、見つけにくい環境に陥りがちだったからこそ出てきたフレーズなのでしょうか。
浪川:そうですね。今も変わっていない業界ももちろんあると思います。私はPMをチームのロールの1つぐらいにしか思っていないんですが、一般的に体制図を書く時は、PMが上にいて、その下にエンジニアがいるように書かれることが多いじゃないですか。この状態はある意味上下関係ですよね。PMのほうが偉くて、エンジニアたちに何か教えてあげなくちゃいけない、伝えてあげなきゃいけない立場にいることがあります。
でも私は、あくまでもプロダクト開発の一員として、PMの役割とエンジニアの役割があるだけだと思っています。そういう意味で、別にPMはエンジニアに聞いていいし、エンジニアはもちろんPMに聞いていい。上の立場になると「自分は質問しちゃいけないんじゃないか」と思ってしまうところがあると思っているので、そういうところはなくしていきたいなと思います。
ーーありがとうございます。devPMではいろいろな記事が掲載されていますが、現在はどのような活動が中心になっているのでしょうか。
浪川:それでいうと今はメディアをいったん停止している状態で。というのも、運営メンバーとの話の中で「メディアに記事を書いてもらっても、そこにたどり着かなかったら意味ないよね」という話題が出てきて。2021年ぐらいからは勉強会のほうに力を入れるようになりました。おかげさまでログミーさまにも取り上げてもらって(笑)。
思っていたとおり、みんながたどり着きやすくなったのがうれしい次第です。いったん勉強会でさまざまなPMの話を聞いてもらう・話を聞ける場を作って、記事レポートとしてログミーさんなどに取り上げてもらったり、弊社のdevPMの中でもレポート記事を作ったりして、まずは勉強会を入り口に、メディアという情報発信もあることを知ってもらおうという動きをしています。
PMの方って、時間がない中でいろいろキャッチアップをしなきゃいけなくて、ピンポイントな記事にたどり着くのがけっこう難しかったりするとは思っていて。1つテーマを掲げた勉強会をすれば、1時間ぐらいで一気に4社、5社の事例を聞ける、キャッチアップできるので、いいなと思って力を入れています。
ーーなるほど。ほかにはどのような活動をされているのでしょうか。
浪川:もともとPMが孤立しない状態を作ってきたことと、PMはPMからしか学べないという思いもあって、「PMが作るPMの学びの場」というコンセプトは外さないようにしたいと思っています。
一方で、最近は企業側の課題も聞くようになってきていて、実はすごくすてきな開発事例やプロダクト開発組織を持っていても、発信することを恐れているというか、「うちなんて……」と過小評価して外部に発信していない企業さんもたくさんあります。
だからこそ採用できなくなっちゃってる、みたいな事情がいろいろあることを知ったので、開発PM勉強会という場とdevPMのメディアという場を通して、企業が表に立つ支援も最近はしています。
なので最近は、プロダクト開発に熱量を持っているけれどあまり知られていない企業と、PMのイベントの参加者との出会いを作る場のようなところに少しシフトしてきているかなと思います。
ーー企業がなかなか発信できない理由は何かあるのでしょうか。
浪川:PMという職の方が少ないところが、かなり大きいと感じていて。というのも、PMが社内では評価されないんですよ。PMが1人しかいないと、PMを評価できる人っていないじゃないですか。
経営陣は結果しか見ないわけなので、プロダクトが伸びていれば評価されるかもしれませんが、伸びていなくてもその過程でやっていることや努力していることはあるし、工夫していることはあるので。
それがすごく他社にとって必要な知見だったりするんですが、本人は周りから「それいいね」と言われたことがないから、「こんなことを人に話すほどでは……」みたいな感じになってしまう。そういうのがもったいないなと感じていて、それを発信できる場というところで今は企業側にも声をかけています。
ーー内部育成・外部採用問わず、企業内のPMを増やすことが重要なのかもしれませんね。
浪川:最近はダブルチェックができる体制にしていっている企業も、けっこうあるみたいです。今までPM1人とエンジニア多でやっていたところを、PMを2人体制にするようなところは増えている印象ですね。
私の顧問先でも何社か、もともとそういうことをしていた会社さんもあって。「『相談できる』という心理的安全性が高まるからそのように動いている」と言っていました。
具体例として今関わっているところだと、ドメイン知識があるけれどITには精通していない方と、EMに近い技術がわかるプロダクトマネージャーをパートナーとして、ドメイン知識に強いプロダクトマネージャーがメイン、そのサブとしてエンジニア兼PM、のような体制を作っているケースがあります。
タッグを組んで、片方の方はEM兼PMみたいに、PMのことも知識を身につける環境にしつつエンジニアとしても動くというかたちが今は多いかもしれないです。ある意味PMのOJT的な要素にもなるので、いちエンジニアの方がプロダクトマネジメントの方にスキルチェンジをしたい時にも、この手法は良いのかなと思います。
ーー最近ではいろいろなPMのコミュニティなどが出てきていますが、浪川さんはこの状況をどのように感じていますか。
浪川:私自身はすごく頼もしいなと思っていろいろ見ています。私は佐々木真さんが立ち上げた「PM Club」というプロダクト作りのコミュニティにも共同運営というかたちで携わったり、それ以外にも「プロダクト筋トレ」さんとか「PM DAO」さんとか、最近はいろいろコミュニティがありますが、そういったところにも一般メンバーとして参加しているんですよね。
コミュニティによって力を入れている色が違うし、視点も違うので、どのコミュニティに入っても学びはあって。それを抽象化して自分がどう使うかみたいな話はもちろん参加者次第だとは思います。
「力を入れている色が違う」というのは、例えばPM DAOはわかりやすいですが、Web3の業界とかNFTのことを学ぶPMの場を作っていたり。それ以外にも、『カイゼン・ジャーニー』を書いた方のアジャイルのコミュニティとかもあるんですが、そういったところだとアジャイル組織をどう作るか考えたり。先ほどお話ししたPM Clubでは、プロダクト開発を実際に体験するプロジェクトを中でやっていて、経験を積めるコミュニティとなっています。
たぶん、フェーズによってその人が参加したいコミュニティとかも変わってくると思うので、そういう意味ではどのコミュニティでも選ぶ余地はあるのかなとは思います。個人的に、いろいろなコミュニティを横串で見ることにデメリットは感じていないので、今後もいろいろ出てきてほしいです。
ーー先ほど、PMという職種に関してまだまだ実際の役割と企業が持つイメージに差があるというお話もありましたが、これはPMの方が人数として少ないことが影響しているのでしょうか。
浪川:それもあると思いますし、PMができる方が市場ではかなり少なく採用ができないので、企業が欲張ってしまうところはあると思うんですよね(笑)。
PMを1人雇った時に「プロダクトマネジメントはもちろんだけど、プロジェクトマネジメントもエンジニアのマネジメントもしてほしい」みたいなかたちで、どんどん範囲が広がっていってしまうというのは、募集の内容とかを見ていると思います。
ーープロダクトマネジメント、プロジェクトマネジメント、エンジニアのマネジメント、それぞれの役割は分けるべきだと思いますか?
浪川:私の個人的な考えですが、すごく規模が大きくなってきて、分けられるリソースがあるなら分けたほうがクオリティが上がると思っています。ただ、コミュニケーションが綿密にできている前提ですが。PMとEMそれぞれがぜんぜん違う方向性のことをしていたりしたら、それはちょっと別問題です。
でも、PMもEMも置けるような環境なのであれば、私は分かれたほうが思考の切り替えをしなくていいと思うので、分けたほうがいいと思います。開発マネジメントなど内向きのマネジメントをすることと、ユーザー側の外向きのことを考えるという思考はぜんぜん違ってくると思うので、分けられるなら分けたほうが生産性が高いんじゃないかなとは思います。
ーーなるほど。このギャップを埋めるためにはどうするのが良いのでしょうか。
浪川:企業側も個人も、一度専門家に相談したほうがいいと最近すごく思っていて。特に未経験でPMに転職しようとしている方もそうですが、PMという仕事の全体を想像できていないままいきなりPM募集のところにいっても、当然スキルが合わず採用に至りません。
逆に、企業側も自社にPMが1人もいないのにPMの募集を出すのは難しいことだと思うんですよね。そういう意味で、専門家に聞く機会を設けてほしいなとはすごく思っていて。
私が顧問で入っている組織ではもちろん私がアドバイスしますが、企業側の方も勉強会とかには参加できるので、参加して「あ、PMってこういう仕事の人たちなんだ」と思ってもらうことも大事だと思っています。
それでもう少し自社にカスタマイズされた細かい相談をしたい、とかだったら顧問の方への依頼を検討してみるとか。誰でもかれでも相談に乗ってくれるとは限りませんが、TwitterでPMの方に聞いてみるとか。そういうことが大事なのかなと思いますね。
ちなみに開発PM勉強会の参加者属性では、90パーセントぐらいがPMとエンジニアですが、時々経営者の方や人事の方も1人、2人参加されています。
そういう方はおそらく「自社でどういうことに活かせるか」を考えて聞いていただいていると思うので。そういった方が増えることは、ぜんぜん悪じゃないなと思っています。
ーーdevPMのようなPMのコミュニティや勉強会に参加するメリットは他にどのようなところがあると思いますか?
浪川:横のつながりは大事だと思っているし、その延長で他社のプロダクト開発事例を共有できたり、逆に発信できたりするのも実践の場ですごく役に立つと思っています。ただセキュリティや社外秘みたいなことを漏らしてしまったらダメなので、それはもちろん大前提なんですけれど(笑)。
抽象化されたTipsとかも、各社のプロダクトに応じて適合させるみたいな。自社のプロダクトに合うようにカスタマイズしつつ、1つの新しい戦術を学べるのはすごく使えることだと思います。これはコミュニティに限らず、副業でも同じことだなと思うんです。
複数の違うプロダクトを見ていくと課題を横串に捉えられると思うので、課題解決の方法をいったん抽象化して、「じゃあこっちのプロダクトにはこうやって横展開してみよう」とか、応用できるスキルが身につくのも大事なことだと思っています。
そういう意味では、コミュニティに入っていろいろな他社の事例を聞くことで、課題解決の思考スピードが上がるんじゃないでしょうか。
私自身、開発PM勉強会で4社ぐらいの事例を1日に聞いた時には「なるほど。飲食のプロダクトではこうするんだ不動産ではこうするんだ」「じゃあ自分が関わっているメディア事業ではこうやってやってみよう」とか思ったりするので。いろいろな視点の話を聞くのは大事だなと思いますね。
ーーちなみに開発PM勉強会の発表者は希望制なんですか?
浪川:先ほど言ったようにPRできていない企業を私たちが支援するということもやっているので、企業のスポンサーが付いている場合はその企業+私からお声がけした方か、一般公募かというかたちで集まっています。
よく「次の勉強会に登壇してみたいです」とメッセージをいただいたり、「会社としてPRを相談したいです」と言ってくださる方もいます。
ーー登壇したい方がいたら声をかけられる場所は一応あるということですね。
浪川:そうですね。テーマに沿った方だったら、私から後日その方にお声がけして出てもらったりはしています。
ーーdevPMは今後長い目で見た時に、どのようなことを実現していきたいと考えていますか。
浪川:1つは先ほども言っていたとおり、企業を支援をすることをやっていきたいなと思っているので、PMとして働いている正社員やフリーランスの方々と、プロダクト作りをがんばっている企業の方々がwin-winになるような場を作るのが、まずは直近の目標かなと思っています。
その先に見えてくるところでいうと、devPMというメディアは今は単なる記事発信の場にはなってしまっていますが、それをコミュニティにしたいという思いがやはりあるので、QiitaやZennのようにお互いがコメントできたり、もっとインタラクティブにいろいろなことを話し合えるような場を長期的には作っていきたいと考えています。
また、ここからは強く思ってきたわけではありませんが、特に私はエンジニア出身という背景から学べたことも多かったので、例えばエンジニア出身のPMとか、バックグラウンドに強みを持ったPMの方を増やしていけたらいいなとも思っています。
もちろんいきなり新卒でPMになる方もいますが、その中でキャリアに行き詰まりがちな方を見てきたんですよね。というのも、もともと軸となる強みがあるわけではなかったりして。営業出身であれば「自分は営業ができるPMです」、マーケティング出身であれば「マーケティングもデータも見ることのできるPMです」という得意分野がありますが、強みがないとその先のキャリアをどう伸ばしていけばいいか悩んでしまう。
そういったPMの方はいるので、1つ特化するスキルみたいなものは持ってほしいなとよく思っています。
ーー最後に、浪川さんにとってプロダクトマネージャーとは何でしょうか。
浪川:私自身が意識しているところでいうと、PMはもちろんいろんなスキルの掛け合わせがされると思いますが、ユーザーやプロダクトチームすべてを含めて「コミュニケーションの中心にいる人」というイメージがやはりあるので、「コミュニケーションを担う人」という表現がしっくりくるなと思います。
ーーそんなPMとしてがんばっている方、PMを目指していたり関心がある方の中で、devPMや開発PM勉強会に参加されたことのない方に向けて、メッセージをお願いします。
浪川:開発PM勉強会もdevPMも無料で見ることができるものになっているので、ぜひまずはポチッと参加ボタンを押していただければ(笑)。その日に4、5人のPMの方と話せる場になっているので、ぜひ気軽に参加してもらえればと思います。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには