はじめに
株式会社Relicにてプロダクトマネージャー（以下PdM）をしています田代です。
4月の中旬よりエンジニアからPdMになり、課題の策定やロードマップ作成を行ったりと奮闘しています。
プロダクトマネジメントを行う中で、エンジニア経験が活きていると感じたことが多々あり、今後エンジニアからPdMを目指したい方や現在PdM領域を担当していてエンジニア目線が欲しい方に読んでいただけると嬉しいです。
またエンジニア経験がある故の注意点についても書いていきます。
エンジニア経験が活きた点
エンジニアとのコミュニケーションが容易である
エンジニア出身ということもあり、共通言語でのコミュニケーションがとりやすいです。
具体的には、ミーティング時にエンジニアが何を話しているのかを理解できる点は非常にメリットであるなと感じます。
ロジックを確認する際でもコードを貼り付けてもらえれば何をやっているのか理解しやすく、認識違いが発生しづらい状況をつくれます。
私が現在のプロダクトチームへ参画時は、ビジネスサイドからエンジニアへ質問を行っていたのですが、開発サイドとしては何を調べてほしいのか、また緊急度も不明であったため、コミュニケーションコストが高い状態となっていました。
現在進行形で、このコミュニケーションコストを削減するため、質問フォーマットを作成し、類似する質問を何度も行われることがないよう情報を集約することにも取り組んでいます。
以下が作成した質問フォーマットです。
## 解決したい課題
- 回答者が理解しやすいように画像や動画など貼り付けてもらえると尚良しです。
## 何を解決したいのか
- 質問内容
- 何を知りたいのか
- 背景
## 回答が欲しい期日
- 起票日
-X月XX日
- 期日
- [ ] 緊急度：最高（起票日当日）
- [ ] 緊急度：高（起票日から3日以内）
- [ ] 緊急度：低（起票日から7日以内）
- [ ] 緊急度：最低（起票日から8日以降でも可）
こちらの期日は確約するものではありません。開発チームの手が空いていない場合は回答期日が遅れる場合もございます。
## 該当顧客
- 顧客名
株式会社XXXX
- 顧客ID
xxxxxxxxxxxx
## 補足
## 回答
このような質問フォーマットを作成することで、ロジックや仕様の確認を依頼する際でも緊急度や何を知りたいのか明確になるため、調査する側の人間からすると助かります。
意識しないと抽象度が高い形での質問やお客様からの質問をそのまま質問してしまうため、質問の仕方については意識していきたいです。
課題の解決策が実現可能かどうか判断がつきやすい
私が担当しているのはtoB向けのSaaSです。
PdMの重要な仕事としてユーザーヒアリングがあります。私の場合、事業者様との商談に同席し、現在抱えている業務での悩みや課題はないかヒアリングを行っています。
ヒアリングの中で将来的に、こういう機能がほしい。という声を頂くことも珍しくありません。
このような声をいただいた際に、課題を明確にすることや有効な解決策を考えるのですが、その思考プロセスの中で優先度決めや課題解決のための実現可能性がどれほどあるのかという点を早いスピード感で出すことができます。
これはエンジニア経験が活きる強みであり、開発側と認識のズレが少ない開発スケジュールをひくことも可能です。
一方で、実現可能な思考の枠に囚われ過ぎるのも良くはないため、解決策が整理できた時点で事業者様に近いビジネスサイドのメンバーに共有することで課題の解決に繋がっているのか確認を行うことも徹底しています。
銀の弾丸はプロダクトマネジメントにおいても存在していないため、地道な思考と検証の積み重ねがプロダクトの成長/成功につながると考えています。
エンジニア経験がない場合でも、普段から開発サイドとコミュニケーションを密に取っておくことでスケジュールの大きなズレや現実的ではない要求を行うことは少なくなると思います。
エンジニア経験があるが故の注意点
開発することで課題を解決しようと考えてしまう
課題の解決策を考える際に、オペレーションや既存機能でカバーできるのではないかという視点を飛び越えて、どうやって開発するか。を考えてしまうことがあります。
この要因はエンジニア時代のどのように実現するか(How)に責務を負っていたことが関係していると思います。
PdMはWhyとWhatに責務を持ち、Howからはエンジニアに責務を委譲し、プロダクト開発を推進していく必要があります。
オペレーションや既存機能でのカバーについてはビジネスサイドとのコミュニケーションをとりつつ、現在の仕様で解決できないのか・以前にも同じような課題がなかったかの確認を行いつつ、有効な解決策を導いていきます。
実際に機能を開発する必要があると確定した場合にPdMはPRDといわれるプロダクト要求仕様書を作成し、課題や達成したい状況をエンジニアへ伝えることでWhy/WhatからHowの責任委譲を行います。
具体的にはPRD（プロダクト要求仕様書）で以下を記載します。
## 解決したい課題（Why）
*ユーザーが持っている課題を簡潔に書いてください。*
## 達成したい状況・KPI（What）
*このプロジェクトで実現したいことは何ですか？また、その達成をどのように確認しますか？*
## 必要な機能・解決するための仮説
*どういう機能があれば、どのようなことをすれば課題は解決しますか？*
## 制限・注意事項
*この製品を作る際に、何か考慮する必要がありますか？（工数・影響範囲など）*
## 関連タスク
上記のPRDをエンジニアに共有し、エンジニアは要件定義を進めます。
どのように達成するのかについては、技術のプロであるエンジニアに任せることを意識する必要があります。
PRDを詳細に書くことで、エンジニアが何故つくるべきなのか、何を解決したいのかが明確になり、手戻りが少なく開発フェーズまで円滑に進むことが可能になります。
PRDを書く技術 = 言語化する力と定義もできます。私自身まだ足りてない力なので今後伸ばしていければと考えています。
まとめ
エンジニアを経験したからこそ分かる「開発することで何を解決したいのか」というモヤっとした気持ちや「実際にリリースした後のお客様の反応が知りたい」という気持ちを現在のチームメンバーには味わってほしくないというのが私の考えです。
まずは自分ができる範囲から無理なく進めていきますが、将来的には社内全体や社外にも良い影響を出せるよう精進していきます。