若手PMは「カメレオン力」を磨こう｜サイバーエージェント 上野千紘

全2本立てでお届けします！
［1］相談さえ億劫だった、あの頃の私へ
［2］若手PMは「カメレオン力」を磨こう

藤田晋の一言一句は全てメモ。

PMという職種は一緒にやるメンバーや、プロダクトのフェーズによって自分のあり方や動き方を変え、「いつでも誰とでも成果を出せる」ことが重要なスキルだと思っています。

カメレオンのように、自分の色を変えてどんな環境でも溶け込んでいく。そんな「カメレオン力」の大切さを、これまでの経験から痛感してきました。

たとえば、「FRESH LIVE」というサービスのPMをしていたときは、「経営層と開発メンバーのハブになる」ことに注力していました。

そのために、まず大切なのは「経営層の伝えたいことの本質を理解すること」。とくに当時のPOが社長 藤田晋だったので、基本的に彼の意向を軸にカタチにしていくことが求められていました。

藤田からは細かい指摘ではなく、「こういう感じにしたら？」とフワッとしたフィードバックで。具体的な機能や施策は、開発に任されることも多かったです。

なので、議事録も完結にまとめるのではなく、あえて彼の発言を一言一句文字起こしして、ニュアンスごとメンバーに展開。私の勝手な解釈によって、社長の伝えたかったことの本質からブラさないようにしていました。

【プロフィール】上野千紘（うえの・ちひろ）
2011年サイバーエージェント新卒入社。アラサー向け・大学生向けのコミュニティサービスや、生放送配信サービスの「FRESH LIVE」など、入社後幅広いドメインに渡り、複数のメディア立ち上げを経験。2017年6月〜社内新規事業会議にて自ら提案したコスメのクチコミサービス「Lulucos by.S」のプロダクトマネージャーを担当。また、社内では次世代経営者育成プロジェクト「CA24」の第一期メンバー、女性活躍推進プロジェクト「CAramel」の幹部としても活動している。

開発状況を把握し、経営側に頼られる存在に

もうひとつ、当時意識していたことがあります。それは、開発に関して頼られる存在になること。

当初「FRESH LIVE」は開発メンバーの数だけでも約30名という規模だったので、経営層は開発状況を細かに把握するような状況ではありませんでした。開発側も、経営側からの要望が振ってきたときに、優先度が分からず混乱がおきていました。

なので、私がパイプ役となり、経営側からは「上野と話しておけば大丈夫」と信頼して任せてもらえる。エンジニアからは、経営側から直接指示があったとしても、気軽に私にパスを出してもらい情報が私に集まるようにする。そんな空気をつくろうと、開発メンバーと密にコミュニケーションをとって、誰よりも開発状況を把握するようにつとめていました。

入社4年目 「FRESH LIVE」の立ち上げを担当していた当時の様子

少人数のときは、あえてハブにならない

これまでは、関係者や開発メンバーの規模が大きかった「FRESH LIVE」でのケースをお話してきましたが、現在のプロダクト（「Lulucos by.S」）では、PMとして全く異なる役割を担っています。

いまのチームは、全部で20名ぐらいで、開発メンバーも10名弱ぐらいしかいないんです。プロダクトのフェーズも立ち上げたばかり、スピードを優先して動くのが重要です。そのためには、事業責任者とチームメンバーの距離は近いほうがいい。私はハブになりすぎず、実行部分や小回りの聞く開発はチームにゆだねて頼る割合を意識して増やしています。

私の役割としては、プロダクトマネジメント（PdM）の割合を増やし、プロダクトの未来や方向性・戦略を考えることに重心を置いています。

「エンジニア」ではなく、「●●さん」として接する

プロダクトのフェーズやチームの人数規模だけでなく、一緒にやるメンバーの特性によっても、PMの役割は変わってきます。

たとえば、メンバーがどんなふうに仕事をもらいたいのか。今のチームで言うと、自分で考えて色々自走したいタイプの人が多いので、任せきれている部分がある。逆に、決めてから話してほしいタイプのメンバーだったら、それに沿ったコミュニケーションや仕組みが必要になる。

なので、最初の段階で「メンバーを知る」ことはすごく大切にしていますね。社内の若手のPMによく話しているのが、「エンジニアをエンジニアとして見すぎないほうがいい」ということ。開発知識がなくて分からないから、「エンジニアを違う言語で話す人達」って思い込んじゃってる人が多い。

エンジニアにも色んな人がいますし、1人1人をちゃんと人として見ていかないと信頼関係は築けません。「エンジニア」と一括にするのではなく、「●●さん」として接する。そうじゃないと、その人の得意なこと、嫌いなことが見えてこない。お互いに知ったほうが、もっと仕事がしやすくなると思います。

月イチKPTで「ワンチーム」をつくる

開発側も事業側もお互いに「ワンチーム」として連携していくため、毎月実施しているのが全員参加のKPTです。

チームの状況やタスクは、私一人では把握しきれていないことが絶対あるし、逆に私がすごい気にしていることがあったとしても皆にとっては大したことなかった！なんてことも全然ある。

プロブレムの数が出ないのであれば、今の状態がいいんだなと思えるし、数がいっぱい出るのであれば、改善しなきゃならないことがいっぱいあるんだなと思える。

それに、良かったところを皆で話すという機会もなかなかないじゃないですか。「この機能出て良かった」とか、「●●さんのここがすごかった、おつかれさま」とか。称賛する場としても活用しています。

KPTを盛り上げるために、私はいつも「レベルの低いコメントを率先して出す」ようにしています。たとえば前回出したのは、プロブレムで「皆の問題じゃなくて私の問題なんだけど、1月と2月の営業日が少なすぎて悲しいです」みたいな（笑）「こんなこともいっていいんだ」って、なんでも言いやすい雰囲気つくれるのでおすすめです。

もちろんプロブレムに真摯に考え、解決に向けて皆で一生懸命考える。でも、KPTの空気が固くなりすぎてしまうと発言が億劫になってしまうので。ちょっとゆるい話題でも出せるような空気は作っています。

誰とでも、いつでも、成果を出すために。

チームやフェーズによって自分の振る舞い方が最適かどうか。答えがないからこそ、毎回試行錯誤の連続です。

そのときどきで求められる役割は変わるけれど、いつも変わらないのは「プロダクトの責任者として成果にコミットする」こと。

PMには幅広い知識やスキルが求められますが、それらは自分の責任として納得して世に出すためにあると思っていて。エンジニアとのコミュニケーションができることが必要だったり、ちゃんとスケジュールが引けることが必要だったり、タスク管理ができることが必要だったり。あらゆるテクニカルスキルは成果のための手段だと思うんです。

スキルの足りないところは得意な人に教えてもらったり、逆に任せてタッグを組んだら良い。最後に世に出す責任を持つところは、PMじゃないとできない。その部分だけは、持ち続けていきたいと思っています。

>>>［1］相談さえ億劫だった、あの頃の私へ

取材 / 文 ＝ 野村愛