見出し画像

デザイナーからPdMに転身してみた話|PROBASEアドベントカレンダーDAY8|菅野真吾

こんにちは。株式会社サーキュレーションのすがのといいます。PROBASEチームでデザイナー兼プロダクトマネージャー(PdM)を担当しています。2022年アドベントカレンダー8日目です!

投稿スケジュールはこちら!

ということで、今回はずっとデザイナーとして働いていた僕がプロダクトマネージャーにトライすることになり、そこで起きたことや得た学び、気づきなどを書いてみます。誰かの参考になればいいなーと思います。

自分について

自己紹介をざっとします。
先述のとおり僕はこれまでずっとデザイナーを生業としていて、DTPのデザイナーからキャリアをスタートし、世の中にスマホが普及し始めたタイミングでUIデザインに完全にシフトし、スマホのゲームやSNSなどエンタメ系におけるサービスの立ち上げや運用でデザイン全般に携わってきました。
サーキュレーションには2019年に入社、そこから新規事業開発におけるUIデザインをメインにコーポレート系のデザインのお手伝いなどをしていました。

趣味はもっぱらキャンプで、暇を見つけてはしょっちゅうキャンプ場に行き焚き火を嗜んでいます。今の季節のキャンプは空気は澄んでいて焚き火は暖かくご飯は美味しい最高のシーズンです!

テントがちょっとシワ寄ってて恥ずかしい(ピン張りしたい派)

PdMになった経緯

ある日事業責任者のむーさんこと村上さんから、「PdMをやらないか」とお声がけいただきました。意思決定のスピードを早めることと、自走ができるチームを創ることを目指していく上で、僕のミッションをデザイナーからPdMへと拡大してほしいとのことでした。

えっ…できるのか??

このようにお声がけいただいた意志はありがたい...でも最初はは自信がなかったですし、メンバーは納得してくれるのか?という不安が怒涛の如く湧き上がりました。
結果的に挑戦してみることにしたのは、僕は元々デザイナーという職種に関わらず、「サービスやプロダクトに対してもっと価値を提供できるようになりたい!」と思っていたからです。これも一つのチャレンジと思い踏み切りました。

右も左もわからぬままスタート

僕のPdMとしての最初の役目はプロダクト開発における優先度の管理や要件定義、仕様策定などを行うことから始まりました。それに並行して従来から行っているUIデザインや仕様を詰めたりテストを行ったりと現場の仕事と管理を行き来するという具合だったと思います。

実際にやってみての課題・悩み

PdMをやっていく上で様々な悩みや分からんが立ちはだかりました。一日中うーん…と唸っている日もありました(今もかもしれない)。自分から見えていた課題や悩みはこんな感じでした。

答えがない、難易度が高いタスクしかない!

今まで自分がやっていたUIデザインはある程度の条件の中での最適解を出すという形が多かったので、そのようなやり方は慣れていたんですが、PdMになってから自分が担当すべき課題はチームについて・プロダクトについてなど様々であり、答えなんて無いのでは?!というものが多くなりました。

意思決定って難しい…

上述のような答えのない問いに対し決定をしなければならない。でもどう考えれば?考慮する要素はめちゃくちゃ広い、関係者も多い、参考になる情報は少ない、でも時間は迫ってくる、といった感じで常に意思決定をしながら先導を切る人の凄さを改めて実感しました。

整理力・ファリシテーション力が足りない!

問題を解決していくには起こっていることを整理し、原因を特定し、問題を切り分けて優先すべきことを配慮しながら決定をしていくことが必要です。それを実行するには課題を整理する能力と同時にファシリテーションの力も必要なんだと痛感しました。総合的な立ち回りのうまさというのは、今まで自分が積んできたスキルの外にあったものでしたので、現在も勉強中です。

計画して「伝わる」ことの重要さ

短期・中期の計画を考えて共有しても、そのプランが実際に回らなければ「伝わった」ことになりません。施策や考え方をどううまく根付かせていくか、という「人に動いてもらうこと」の難しさを改めて実感しました。ビジョンを創る試みをしてみたり、計画が見える場所を工夫したり、施策を考えてみたりなど大小様々なトライと失敗がありました。

変わったこと・気づいたこと・面白いこと

そんなこんなで悩み、考え、メンバーに助けてもらいながら夢中でやってきているうちにあっという間に時間が過ぎ、改めて分かった大切なことや気づいたこと、やりがいがある面白いこともありました。

育てるのは「チーム」と「プロダクト」

ぼんやりと大事だなとは思っていたのですが、改めて大事なことだと認識しました。良いプロダクトは良い(強い)チームからではないと生まれず、プロダクトと同じくらいチームを育てることが重要になります。風通しを良くし、視座を上げ、小さく失敗を繰り返し、垣根を超えたコラボレーションが必要です。我々のような小規模のチームはなおさら無視できない要素だと実感しました。
チームのコラボレーションを促進するためにgatherやmiroはかなり有効な手段としてワークしています。

働く場所の遠さを感じさせないgather
思考を視覚化してリアルタイムで共有できるmiro

自分が誰よりも先を見る

これも当たり前の話なのですが、PdMになった当初は足元の課題や仕様を整理するのに夢中になっていました。PdMである自分が足元ばかりをみていると、一緒に走っているメンバーも先が見えない状態になってしまうということをいろいろ問題が見えてきてから改めて認識しました。
半年先、1年先、3年先を見て自分がやるべきことを考えて行動し、足元のタスクになるべく囚われないように心がけています。

アンバサダーを見つける

PdMは責任が重く、気を張って全てが自分の肩にかかっているような気概でやっていく必要があります。ただ、実際には自分にはまだまだ足りないスキルも多く、一人でやれることにも限りがあります。大事なのは「自分が頑張ること」ではなく「チームとプロダクトが前に進むこと」だと考えました。
ではどうするのか?色々やり方があると思いますが、僕の場合「自分と近い目線で走ってくれる仲間」を上手く見つけることは有効な手段なのかなと思いました。気持ちや思考の負担も減りますし、複数の角度からものを見ることによって抜け漏れや新しい気づきを得られやすくなります。

流れを作るのが仕事

元来の仕事的に全部自分でやりたくなってしまうのがデザイナーのさがですが、上述の通り自分ができる範囲は限りがあります。なので、大事なのは計画したことが上手く動くように「流れを作る」ことに専念することなのだなと学びました。
プロダクトや開発上の課題を見つけ、整理し、メンバーが迷いなく走れるか、ということに可能な限り時間を割くようになり、前より意識が向けられるようになったかなと思います。

やってみよう精神!

我々が取り組んでいるプロダクトはSaaSです。SaaS答えが見えないことが多く、実行してみた結果を見ながらその先をどうするか考える側面が多いです。ですので、良いと思ったらまずは「やってみる」精神が大事なのだなと思います。失敗は早い方がいいですし、やってみないと良いも悪いも答えが出ないものも多いです。また、「チャレンジや失敗に寛容」という土壌がチームを強くする要素の一つなのではないかなと考えました。
そもそも僕がPdMに挑戦したのも「やってみよう」精神だったし。

デザイナー→PdMの道はアリ?

こんな感じトライしているPdMですが、プロダクトを成長させてユーザーに「うれしい」価値を届けるということに難しさとやりがいを感じています。そして、やりがいを感じられるのは理解があり一緒に思考し、共に汗をかいてくれるチームがいるからこそだと思います。

世のPdMを見るとスキルも視座も高い人が多く、自分にはまだ足りないことばかりです。これからも学び続けることは必須だなと思いますが、元々「受け手の気持ちを考えて作る」「BizDev両方の話をまとめてアウトプットする」という側面を持つデザイナーがPdMをやることは可能性としてはアリなのでは?(自分のスキルはさておき)強みを活かせる場面もあるのでは?と思っています。

さいごに

サーキュレーションや我々PROBASEチームには、このような形でPdMにチャレンジをさせてくれるような、挑戦する人を応援する風土があります。そこが魅力だと思っています。この記事を読んで興味を持っていただけたら嬉しいです。その際はぜひお話ししましょう!

ここまでお読みいただきありがとうございました!

次回はPdMの経験も豊富なスペシャルゲストのよしいけさんです!おたのしみに!