Zenn
✈️

ひよっこ PM 体験記 ✈️

2024/12/19に公開

この記事はNE Advent Calendar 2024の19日目の記事です。

はじめに

NE株式会社の ひろき です!
新規事業に奮闘中で、プロダクトの開発やプロダクトが今後どうあるべきかを日々考えております!

そこで、視座を高めたり、学びを得るために、2024年12月5日から6日に開催されました、
pmconf2024(プロダクトマネージャーカンファレンス)に参加してきましたので、参加レポートをお届けします。

🌟pmconf2024を通じて感じたこと

差別化

https://speakerdeck.com/geshi0820/da-lu-7ge-woshi-xian-suru-purodakutodeisukabarino7tunoji-yi-pmconf2024

  • 当たり前のように考える戦略ではあるとは思うし、私自身も新規事業に携わる中で、自社である必要性強みというものを意識はしているが、自社だから実現でき かつ 模倣しにくいというものを生み出すことがとても難しいと感じております。
  • 他社のプロダクトマネージャーがどのようなプロセス・思考・判断軸で企画し、戦略化しているかを知る事ができ、自社でも実践していけると良さそうだなという気持ちになりました!

集合知チャンス

https://speakerdeck.com/tomosooon/pmconf-2024-qi-teng

  • 新しく何かを始める際には、メンバーも少数スタートだったりすることが多いと思います。そのタイミングでは、意思決定も早いし、なんなら、多くのことを自分で決断してそのまま進行していることもありますよね!?
  • ちょっと実績や時間が経過すると、プロダクト自体の課題も複雑化し、それらをより迅速かつ多角的に解決するために、チーム・組織の体制も整備され、メンバーも増えてきた際に、同じ方向に向いていない状況が発生することがあると思います!
  • そうすると、本来注力すべきことや、本質の課題解決が出来なくなるだけでなく、納得感や共通認識がないことで、チーム内で自走できず、結果的に価値自体の低下と価値提供の鈍化という状況の泥沼にハマることも。。。
  • スタートアップや新規事業は、1番の武器はスピード!、だから合議なんてしてたら、意思決定遅くなるよね〜!そして、多数決は決して良い結果にはならない
    • けど、良い戦略を早く作り、実行強度も上げたい
  • 情報を広く集め、早く決め、徹底的に実行するには集合知をうまく活用(合議ではなく)し、意思決定することで、結果的に質の高いスピードで進行していけるのだと!!(納得)
PMは集合知を手に入れた!

知識:10Lv → 100Lv にあがった!
納得感:10Lv → 100Lv にあがった!
実行スピード:10Lv → 100Lv にあがった!

チームは、「ずッぱや」をおぼえた!

┏━━━━コマンド━━━━━━━━┓
┃ たたかう ▶︎じゅもん ┃
┃ にげる   どうぐ  ┃
┃   ┏━━━━じゅもん━━━━┻━┓
┗━━━┫  ▶︎ずッぱや       ┃
    ┗━━━━━━━━━━━━━━━━━┛

ノーススター

https://note.com/zigorou/n/n425d3496e498

  • 似たような考え方でアプローチはしてきているものもあるが、きちんと型にはまった根拠のある方法論では出来ていなかったので、ノーススターのようなフレームワークに沿って考え、戦略立てることは有効な手段の一つになり得る。
  • ノーススター
    • 一つに絞る
    • 顧客・ユーザーにとっての価値という指標
  • ノーススターチェックリストを覗いて、今掲げている指標と照らし合わすだけでも考えさせられるものがあるかもしれません。

単一プロダクト、マルチプロダクト

  • DAY2のパネルディスカッション『プロダクトマネージャーと仮説/戦略』でも少し触れられていたのですが、今まで単一プロダクトや単一ドメインの領域のソリューションで事業としても成り立っていたフェーズから、現状は複雑化してきており、差別化や優位性という観点でも事業ドメインの領域を広げ、コンパウンド戦略やマルチプロダクト戦略の採用が増えてきている印象がある。
    • 故に、PMの守備範囲は広くなり・難易度も高くなってきていると思うと、ゾッとしましたw

UXライティング

https://docs.google.com/presentation/d/1NHfYLalaXm0r1sknX6p7qmePALEJ-4iLHgQm_LGUnnk/edit#slide=id.g2fcb2317912_0_0

  • 今まで割とUI/UXデザイナーの方に一任してしまいがちな領域な印象でしたが、ユーザーに価値を届ける(届けきる) という視点においては、UXライティングは重要な要素のうちの一つであり、実際に数字への影響もあることを踏まえると、PMに限らず、基礎知識は学ぶ必要性と、もっとフォーカスしてこだわりを持った関わり方をしていきたいと感じました!
  • そして、プロダクトの戦略と通ずるところでもあるのですが、大事なこと・伝えたいこと(優先度)に応じて、表現する内容を絞る(削る)ってことも、改めての学びでした。
    • (ついつい親切心のあまり、補足の説明を入れがちになることありますよね!?)

🌟DAY2 "ロードマップをもっとよくするために?"をみんなで考えるワークショップ について

  • テーマ
    • 人々のフライト体験✈️ をより良いものに!
      • (そのアイデアを実現するための資金は、とある富豪が金はいくらでも出すから、というテイで アイデアを考えて実現までのロードマップを作成しようという感じ)
  • メンバー
    • 1グループ4〜5人くらい
      • 私のグループは、某有名企業のPMの方もおられました!
  • アイスブレイク
    • 自己紹介
    • ロードマップと聞いて思い浮かべる言葉は?
    • ワークショップに期待すること、意気込みは?
  • ロードマップ作成(15分〜20分)
    • 時間なくて、うまいことまとめられた感がなく(消化不良な感じ)
  • 「ロードマップを作るための(よくする)ロードマップ」(15分〜20分)
    • 最初に作成したロードマップ自体を改善するんじゃないところがミソですね!
    ✅ロードマップ作成後のチェックリスト✅
    • 不確実性の共通認識が取れているか?
      • ロードマップは生き物であり、コミットメントではない。
        その前提がなくロードマップの議論を始めるとチームはウォーターフォールになり、仮説検証ができなくなる。
      • 今作っているロードマップはガントチャートやWBSであるのか。それとも不確実性と向き合うための今後の計画表であるのかを明らかにし、チームで共通認機を持っておく、
    • ビジョンがあり、細分化されているか?
      • 思いついた機能をすべて並べたものをロードマップと呼ばない。
      • プロダクトとして目指す姿(ピジョン)があり、それが1年分のロードマップであれば1年後の成功として目指す姿として細分化されている。そのうえで、その姿を目指すために必要な物事を考え、ロードマップとする。
    • 競合と異なる戦略が反映されているか?
      • 競合と同じロードマップであれば、その事業を実施する必要はない。2つ同じ製品はいらない。
      • プロダクトが目指すビジョンに向けてどこでどんなリスクをとることで事業を成功させようとしているのか、どんな仕組みをつくり市場と向き合うのかなどの戦略があった上でのロードマップである。また、他のロードマップではなく、なぜそのロードマップを採択するのか、理由を説明できるようにする。
    • 十分に高い目標を掲げているか?
      • ロードマップを作るときに目指した以上の成功になることはない。
      • 現状の延長にある成功ではなく、もっと大きな成功を目指す。「今の10倍に成長するためにはどうすればよいのか?」のようにIssueを大きく捉える。ただ。どの方向に大きくするのかは戦略次第である。
    • 意味のある見積もりか?
      • 高い目標は必要だが、実際に手を動かす担当者の意見を聞かずに莫大なロードマップを投げつけてはならない。これは関発者に限らない。作り手だけではなく、営業やCSなどが事業目標等を達成できるかという見積もりも含む。
      • また、見積もりができないような抽象的な概念だけのロードマップは取り扱うために順次具体化が必要だ。例えば、「プロダクトリリース」とだけ書かれていて機能概要も決まっていないものや、機能だけが書かれていて事業見積もりが難しいものだ。
    • 成功に向けて、不確実性の高いところから検証できているか?
      • 誰にも使われないプロダクトを作る必要はない。
      • プロダクトの不確実性の高いところから検証できるロードマップとする。また、その検証をする相手を十分に集めるための施策を盛り込んでおく。
    • 目指す成功が達成できるか?
      • 計画時点から目指す成功が達成できないと予測されるロードマップは最初から失敗している。
      • ロードマップの節目ごとに定義している成功を達成することができるロードマップになっているか、その成功にワクワクすることができるか、ロードマップの開始前に確認をする。
    • 達成の可否を測る定量的な指標があるか?
      • ロードマップは戦略であり、あなたのコミットメントである。
      • 冒頭には「コミットメントではない」と書いたが、ロードマップに責任を持つ人はそのロードマップに書いた成功に向かうことにコミットする。途中で方向が違うと気付いたときには方針転換をする。顧客に対するコミットメントではないが、あなたのコミットメントではある。
      • そして、その達成を測る指標があり、プロダクトが目指す成功に向けて進捗しているかを確認する。
    • そして、振り返りの振り返りみたいな感じで、重要なフレームワークかもしれないと!
  • 他チームのロードマップを見に行く(5分 * 2ターン)
    • 自分のグループメンバーのうち
      • 自グループのロードマップを説明する人(空港役)
      • 他チームのロードマップを見に行く(飛行機役)
    • 他チームのロードマップを見ることで、発想の観点や考え方の違いなどがあって面白かった
      • 中でも、ビジョンがしっかり立てられているのは良かったな〜って思いました!
        • 新しい人生体験を的な
          • (フライト中に、普段経験できないようなアクティビティや学びの体験)
  • メンバーへのフィードバック
    • 短い時間ではありましたが、気持ちを伝える・伝えられるという機会はとても良いですね!
    • それぞれの個性なんかも出ていたので、最後に振り返ることができてよかったです!

ワークショップを経ての気づき

  • 現役PMな方々が、日頃意識しているようなことや観点が垣間見れる機会でした!(さすがや)
  • ワークショップとして時間とお金以外の制約はなく、自分たちで前提条件を考える・決めるという、自由度があったので、同じテーマではあるが、他のグループの内容を見ると、様々な色が出ていて面白かったです。
  • 時間全然足りなかったな〜とは思いましたが、現実の現場でも、限られた時間の中でロードマップを作るということ・戦略を考えるということは必要なので、縮図を見ているかの様でした。

🌟DAY2 OST(Open Space Technology) について

  • 参加者駆動型のカンファレンスで、「実行したいアイデア」「解決したい課題」「探求したいテーマ」などを参加者が提案しアジェンダをつくり、それに賛同する人が集まって話し合うワークショップでした。

  • "ロードマップをもっとよくするために?"をみんなで考えるワークショップと並行で開催されていたため、私は3回目の分科会にのみ、遅れての参加になりました!

  • 途中参加した3回目の分科会 エンジニアにやらなくなったことを伝えるには

    • 話の途中から参加というのもあり、全部の文脈が理解できていないですが、エンジニアに割と必要以上に気を使っている印象でした。(エンジニアこわくないよ〜)

    • 途中参加で文脈わかっていない部分もありますが、思ったことを書いておきます!

      • エンジニアに限らず、なぜを伝えるのが重要である
      • 不確実性が見込まれる状況においては、タイミングや価値の大きさ・コストバランスで、やる・やらの判断は日々変わる可能性があることは共通認識として持っておく必要がある
      • エンジニアに決まったことだけを伝えて開発してもらうのではなく、なぜの部分を一緒に理解することで、本質に対してのソリューションを自ら考えて、自走できるチームを醸成できると良い
    • (これは単純な感想です)

      • 参加されていた方(PM)の某プロダクトが20チームほどで構成されており、それぞれエンジニアもいるというお話を伺い、組織大きい〜と、素直に驚きました!!
      • (詳しくは分かりませんが)横のつながりとかも大切なのかもしれませんね〜!

最後に

  • 様々なバックグラウンドの現役PMの方がおり、カスタマーサポートやデザイナー経験者の人もいらっしゃったので、エンジニア視点では新鮮でした!
  • バックグラウンドの強みは活かしつつ、足りないところは自身でも学んでいく必要はありますが、集合知チャンスも活用していきましょう!
NE株式会社の開発ブログ

Discussion

ログインするとコメントできます