プロダクトマネージャーはBTC（Business / Technology / Creative）のハブとなる立ち位置と言われることがあります。BTCそれぞれの領域の様々な知識を求められる職種でもあります。

ただしBTCすべての領域において潤沢な知識・経験を兼ね備えている「スーパーPM」みたいな方は本当に稀だと思います。本当に存在するのかも怪しいかもしれません。
しかしプロダクトマネジメントを行っていると、自分の経験のない領域や、持ち合わせていない知識に直面すると、歯がゆい思いを抱いたり、ヘコんだりもするわけです。

私は現在「デザイナー兼プロダクトマネージャー」としてスタートアップで働いています。デザイナーのキャリアは20年ほどになりますが、プロダクトマネージャーとしては半年ほどの初心者🔰です。
さらに所属しているのがエンジニアのチームなので、Technologyの知識・経験が不足していることを痛感することも多く、正直私にとってコンプレックスのひとつにもなっています。

（「Technologyの知識」という表現はかなり抽象的すぎますが、なんとなくニュアンスが伝われば幸いですmm）

自分自身の強みを活かし、チームを巻き込む

ただそんなことを言っていても仕方ありません。知識や経験がないものはない！のです。だからこそ「どうやったらエンジニアやステークホルダーの知識・経験を引き出して、共創しながらベストな要件を決めていけるか」を考えるようにしています。

@shin_sasaki19 さんのツイートにあるよう「プロダクト開発はチームでやる」という発想です。いかにチームとしてプロダクトマネジメントしていくのか…そのなかで私が意識していることは、自分自身の強みを活かしながらチームメンバーを巻き込んでいくということです。私の場合、

• 読みやすいドキュメントが書ける

• デザインができる。プロトタイプとしてアウトプットできる

• ファシリテーション力がある

のような強みがあると思っていますが（実際ホントかどうか、まわりがどう思っているかは別として😝）、これらを活かしながら、いかにしてチームメンバーの意見・知見を引き出せるか…を考えています。

いくつか具体的にあげていきます↓

1.PRDは読まれないものと思い、プレゼン資料のように簡潔に書く

プロダクトマネージャーがPRD（製品要求仕様書）を書いても、みなさん読まないでしょ😭？

いやもうちょっと丁寧に書くと、PRDが読まれるのは、実際に開発に着手するときとか、仕様を確認したいときとか…たいていは必要に迫られたときだけだと思っています。

要件をみんなで決めよう！フェーズで、PRDのURLを投げつけて「読んでおいてねー💌」って言っても、ほとんど読まれません。

またチームで議論する際は、Zoomで共有したり会議室のプロジェクタに投影することが多いと思います。
なので要件をみんなで検討するフェーズでは、PRDなどのドキュメントはプレゼン資料を作るくらいの意識がちょうどいいのではないでしょうか？

デザイナーなので、見やすい会議資料・ドキュメントを書くスキルはある程度備わっていると思っています。箇条書きを多くしたり、見出しや配色を意識したり…画面越しでもアタマに入ってきやすいドキュメントを意識しています。

ちなみに、弊社ではConfluenceというブラウザベースのオンラインドキュメントでPRDを書いていますが、会議の時はブラウザの表示比率を125%〜150%にして共有するので、そのあたりも考慮しています。

2.スムーズな理解のためにデザインやプロトタイプを用意する

プロダクトマネージャーがワイヤーフレームを書いたり、ましてやデザイン・プロトタイプを用意するということについては、様々な意見があると思います。むしろ「やらないほうがイイ」というのがマジョリティです。

ワイヤーフレームやプロトタイプがあることで、思考がそれらに引っ張られ、それ以外の良いアイディアが生まれなくなるというリスクがあるからだと認識しています。

しかし私は、要件がかなり複雑になりそうで文字ベースのPRDだけだとなかなか理解できない案件の場合に限り、デザインやプロトタイプを用意しています。あくまで課題や要件をスムーズに理解をしてもらい、議論を活性化するために用意するものです。

私もこのフェーズで共有しているデザインに固執することはありません。気を遣ってもらわないためにも、2〜3案用意してそれぞれのPros / Consを伝えるなど、議論を促す工夫はしています。

（このような意識もあって、過去に手書きのワイヤーを提示したこともありましたが、逆に理解されませんでした。そのあたりはチームやプロダクトの特性によって変わるかもしれません）

ちなみに、プロダクトマネージャーがデザインつくるの？についてですが、これは私が会社のなかで「唯一のデザイナー 兼 唯一のプロダクトマネージャー」であるから成り立っているのかもしれません。このあたりは組織の規模や構成・文化によって変わってくるところだと思います。

3.要件定義に入り込んでもらい“自分ごと”にしてもらう

プロダクトマネージャーに求められるスキルやコンピテンシーには諸説あり、その要素も様々です。

私が一番兼ね備えているものはなんだろうと考えたとき「ファシリテーションスキル」ではないかと思いました。「ファシリテーション」と言っても幅広いですが、GLOBISさんでは以下のように定義がしています。

チームで要件定義を考えるMTGにおいて、いかにその場に入り込むことができ、その案件・プロダクトを自分ごととして感じてもらえるかが大事だと考えます。

参加している各メンバーからコメント・意見を求めること、合意を得ることはもちろんですが、

• 迷っているところや悩んでいるところを素直に打ち明ける

• 知らないことは知らない！わからないことはわからない！を伝える

というのも大事な要素です。

私の場合、要件定義のMTGへは「現状や課題」だけではなく、要件のタタキを用意します。（さすがに手ぶらだと議論もスタートしないので。）
これを「私が考えた要件」から「チームで考えた要件」に変換させるか。そのひとつの糸口として、迷っている点・悩んでいる点を共有し、みんなで解決していくことで巻き込んでいきます。

別の例だと、私が考えた要件のタタキがとんちんかんで、ツッコミが入ることもあります。「あー、やっちゃったなぁ」と冷や汗かくのですが、これも「私が」→「チームで」へのスイッチになります。

エ「この案だと現状のプロダクトの仕様とマッチしないかもしれません」
私「ごめんなさい、そこの仕様あまり意識してませんでした。詳しく教えていただけますか？」

…みたいな。
私の至らない点などを起点に議論をしていき、要件をブラッシュアップしていければ、結果として巻き込むことになっています。

冒頭でも挙げましたが「プロダクトマネジメントはチーム戦である」と言われることが多くなってきました。

自分に足りない部分を自ら補うことももちろん大事なのですが、まずはチームで補うことを考え、そのなかでも自分の強みを活かして、プロダクトマネジメントをしていくことが求められているような気がしています。