こんにちは。プロダクトマネージャー（以下、PdM）の阿部です。最近、社内のアドベントカレンダー（突撃！隣のキーボード！〜 2024年冬 ニーリー Ver. 〜 - Nealle Developer's Blog）に触発されて分割キーボードを購入しましたが、使いこなせず元のキーボードに戻ってしまいました😇
今年の1月に、一人目のPdMとしてニーリーに入社し、気がつけば1年が経とうとしています。この1年間の経験や感じたことを、本記事にまとめてみます。
はじめに
ニーリーでは、「エンジニアが事業に染み出す」というキーワードが浸透しており、課題の抽出や企画も業務範囲として定義されています。
上記の図を見ると、「エンジニアがPdMの業務をカバーしているのでは？」「PdMって必要なの？」「役割分担はどうなっているの？」などの疑問を持つ方もいるかもしれません。実際、私自身も入社時には「どのようにエンジニアと協業することになるのだろう？」と少し不安を感じていました。
とはいえ、実際に1年間働いてみると、このエンジニア文化の中でもPdMとして果たすべき役割が見えてきました。
事業に染み出すエンジニア文化とは？
以下に、私が実際に見て感じたこの文化の特徴を紹介します。
1. 案件Doc（PRD＋Design Doc を組み合わせたもの）をエンジニアが作成
エンジニアは、仕様書通りに開発を進めるだけではなく、課題の抽出から解決策の検討を行っています。具体的には、案件Docをエンジニアが作成し、それを基に関係者で議論を進め、開発を推進する体制が整っていました。
2. ビジネスサイドへの積極的なヒアリング
エンジニアが自らビジネスサイドにヒアリングを行い、現場の課題やニーズを深掘りしている姿も印象的でした。得られた情報は案件Docに反映され、チーム内で共有されることで、プロダクトの方向性に具体的な影響を与えていました。
これらの業務は、一般的にはPdMやそれに類する役割の人が担当するケースが多いのではないかと思います。しかし、ニーリーではエンジニアがこれらの業務も担い、コードを書くことに留まらず、課題解決者として開発を推進していました。
そんな中で、PdMはどう動くべきか？
前述の通り、ニーリーではエンジニアが課題の抽出から企画立案、実装まで一貫して進める文化が根付いています。その結果、多くの開発プロジェクトがスムーズに進行し、エンジニア主導で質の高い成果が次々と生み出されていました。
一方で、チーム内には「やりたいけれど、抽象度が高く、すぐに開発に着手できないテーマ」も多く存在していました。例えば、何を解決すべきかが曖昧、ユースケースが複雑である、または関わるステークホルダーが多いといった理由から、次のステップに進むための見通しが立っていないテーマです。
こうした状況を踏まえ、PdMとしては、抽象度が高くすぐ開発に着手できないテーマに対して、「なぜやるのか」（Why）を明確にし、「何をやるのか」（What）を具体化する ことで、チームに貢献できると感じました。
抽象度が高いテーマを形にした具体例：分析レポート機能
具体的に、担当PdMとして動いた例として「分析レポート機能」の開発があります。
※画面の詳細なスクリーンショットは掲載できませんが、いわゆるダッシュボードのようなものをイメージしていただければ分かりやすいかと思います。
このプロジェクトは、当初「クライアント様への導入効果を見える化したい」という抽象的なアイデアから始まりました。アイデアは共有されていたものの、具体的にどのようなレポートを作るべきか、どんなデータを見せるべきか、そもそも機能として開発するべきか、といった部分が整理されていない状態でした。
PdMとして取り組んだこと
1. ヒアリングの徹底
社内メンバーやクライアント様に30回以上ヒアリングや壁打ちを実施し、「何を見たいのか」「その情報が生む価値」を洗い出しました。
2. 目的とユースケースの明確化
情報を整理し、レポートの目的を「導入効果を可視化すること」と「パークダイレクト（ニーリーが提供するサービス）の利用を促進するための情報を提供すること」の2点に絞りました。この明確化によって、プロジェクト全体の方向性が統一されました。
3. プロトタイプの作成
SQLを書いてBIツール上でデータを可視化したり、AIツールを活用して簡易的なプロトタイプを作成し、関係者間でフィードバックを繰り返しました。これにより、具体的な画面要素やデータの構造が決まりました。
4. チーム間の調整と推進
ビジネスサイド、エンジニア、デザインの全員が共通認識を持てるよう、議論のファシリテーションを行いながら、プロジェクトを推進しました。
取り組んでみた結果と学び
結果として、分析レポート機能は無事リリースされ、クライアント様から好意的なフィードバックを得ることができました。
また、このプロジェクトを通じて、PdMとして「抽象度が高いテーマを形にする」ことで、チーム全体のアウトプットやアウトカムを最大化できることを実感しました。 曖昧な状態だったテーマを整理し、目的や方向性を共有することで、エンジニアやビジネスサイドが迷いなく動ける環境を作り、結果的にプロジェクトの成果を最大化することができたと感じています。
1年の学びを活かして、さらに挑戦したいこと
この1年を通じて、クライアント様や社内の状況についての理解が深まり、課題をより高い解像度で捉えられるようになったと感じています。その結果、PdMとしてどのように事業やプロダクトに貢献できるかを、さらに掘り下げて考えるようになりました。
また、先日開催された「プロダクトヒストリーカンファレンス2024」では、CTOの三宅が登壇し、こんな言葉を残していました：
「僕らがよく言うのは、エンジニアが事業に染み出すならPdMはもっと事業に染み出せということです(笑)。具体的にはPLや事業KPIにコミットするのはプロダクトマネージャーのミッションだよ、と伝えています。」
この言葉を改めて聞き、PdMとして事業にどう貢献するべきかを再考する良いきっかけとなりました。
※このセッションの文字起こし記事も公開されていますので、興味のある方はぜひご覧ください： 【プロダクトヒストリーカンファレンス2024 】LayerX&Nealle セッション書き起こしレポート - Nealle Developer's Blog
これまでの経験を踏まえ、今後は以下の3つの領域での取り組みに注力していきたいと考えています。
1. より抽象度の高いテーマへの取り組み
これまでの取り組みでは、「やりたいけれど抽象度が高く、すぐに開発に着手できないテーマ」を形にすることで、チームや事業に貢献できる場面が多くありました。しかし、まだこうしたテーマは数多く残っており、さらに抽象度が高いテーマやステークホルダーが多岐にわたる複雑な課題も存在しています。今後は、これらの課題にもしっかりと向き合い、推進力を発揮できるようスキルを磨いていきたいと考えています。
2. プロダクトロードマップや戦略的課題への関与
この1年間の経験を通じて、クライアント様や社内の状況、そして業界全体についての理解が徐々に深まりました。その結果、日々の課題解決にとどまらず、プロダクト全体の方向性を見据えたロードマップの策定や、戦略的なテーマの優先順位付けにも関与していきたいと考えています。
3. チーム全体で成果を最大化する仕組み作り
これまで取り組んできた抽象度の高いテーマの推進プロセスを振り返り、そこで得られた知見を活かした仕組み作りに取り組みたいと考えています。PdMとしての関与を通じて、チーム全体がより効率的に動き、一貫した成果を生み出せる環境を整えていきたいと思っています。
おわりに
というわけで、「エンジニアが事業に染み出す組織の中で、PdMはどう動くべきか？」というテーマで、私が感じたことや取り組みをご紹介させていただきました。ニーリーのエンジニア文化の中でPdMとして働く楽しさや難しさが少しでも伝われば嬉しいです。
明日のアドベントカレンダーはコーポレートエンジニアの小島さんが執筆する記事になります！こちらもお楽しみに！！
