最新情報をお届けします！
コスメクチコミアプリ『LIPS』グロースの立役者、松井友里さん。立ち上げメンバーとして「自ら手を動かす」から「PM」へと役割をシフトした彼女。いかに自分より優秀なエンジニア、デザイナーとコミュニケーションを図るか。彼女が取り組んだのは「全員がPMマインドを持つチーム」づくりだった。
全2本立てでお届けします！
［1］ひとりで何でもやりたいマンだった私へ。LIPS 松井友里のPM奮闘記
［2］コードを書く、デザインもする。自分でプロトタイプをつくれるPMに。AppBrew 松井友里の原点
国内最大級のコスメ・化粧品のコミュニティアプリ。リアルなクチコミから魅力的なコスメや、おしゃれな子・有名人のメイク方法を知ることができる。コスメランキングやコスメに役立つ記事も充実。ダウンロード数は450万、総クチコミ数は100万を突破（2020年2月時点）運営会社「AppBrew」は総額16億円の資金調達を行ない30名規模の組織になった。
もともと現場でバリバリと手を動かしていたと伺いました。PMへとシフトしたわけですが、すぐ慣れていきましたか？
最初はPMを名乗ることに自信がなかったですね。グロースの知見もないし、「全員がPM的な動きをする組織が理想」という組織観を持っていたので、PMとしての自分の役割はなんなんだろう、と迷う気持ちがありました。
でも、PMを任せてくれた代表の深澤は私が実務上何をするかにはこだわりがなく、ただプロダクトの成長に対して責任を取ることを期待してくれていたので、その期待に応えるために何でもやろうと思うようになりました。
PMになったばかりの頃はどちらかというと、深澤やチームに対して「私はこう思うんだけど、みんなはどう思う？」と提案していましたね。ただ、それだと意思決定のスピードが遅くなってしまう。間違えることもあるかもしれないけど、必要なときは自分の判断で決めるようにもなりました。最初は自分で意思決定するのが不安で、すごく消耗したんですけど。2年間PMをやっていくうちに慣れました（笑）
PMになって強くなった部分でいうと？
心のバランスの取り方は学びましたね。昔はネガティブなユーザーレビューを見たり、グロース施策に失敗したりするたびに落ち込んでいました。悪い面ばかりを気にしてしまっていたんです。
でも最近は、ポジティブなレビューや上手くいった施策も事例として社内に共有するようにしていて。そこは昔に比べると成長したかな、と思います。
プロダクトが成長していくにつれてPMとしての役割が大きくなっていったと思うのですが、自分が手を動かす時間が減ることに対してどう感じていたのでしょうか？
自分で手を動かしてつくること自体はすごく楽しくて、手放したくない気持ちはありました。
ただ、自分よりコードが書ける方やデザインができる方が入ってきてくれた。そこは彼らに任せて自分ができることをやった方がプロダクトにとってはいいこと。割り切って任せることができましたね。
最終的には自分が立ち上げたプロダクトがグロースして、多くの人に使ってもらうことが目的なので。私はチームやプロダクト全体の成長にコミットしたほうがいい。
同時に、開発やデザインを任せることで「自分でつくる力」がなくなっている焦りは感じていので、腕が鈍らないように常に現場に必要な情報のキャッチアップは続けています。
「いい結果が出たらSlackで共有して賞賛し合うように心がけています。最初は成果が出るまで粛々とやるつもりだったんですけど、なかなか目に見える成果って簡単に出るものでもない。わかりやすい結果だけを求めすぎてしまうとだんだんしんどくなっていくので。小さなアウトプットでもまずはお祝いして、みんなのテンションが下がらないようにしたいなと思っています」
ちなみに取り入れた機能が多い一方、取りやめた機能もあるかと。見極める目安についても教えて下さい。
新機能でいうと1週間ぐらいデータを観測し、そこである程度の判断を一旦します。うちでは、新機能を実装したエンジニアさんが分析のためにSQLを書いて、毎週の定例で「この数値がこれくらい上がりました」と発表していくんですけど。そこで、数値が改善していなければ、機能自体を改善するか、取りやめるかを定例で決めています。
一方、新規事業で新しいプロダクトを立ち上げた場合はもう少し長いスパンで観測をします。だいたい2〜3ヶ月は様子を見て見極めることが多いですね。
そもそも「サービス思考」で技術力の高い方を採用していく。なおかつ全員が機能の提案から仕様詰めから分析までやる体制を大事にしています。
エンジニアさんも、デザイナーさんも、一人ひとりがPM視点を持ち、全体感を把握しているので、コミュニケーションコストが少ないんですよね。
たとえば、PMがユーザーから話を聞き、仕様をつくってエンジニアに依頼すると遅いし認識が揃わない。さらに修正の時間もかかる。
でも、エンジニア自身がユーザーの行動や数値を把握していれば、自ら機能をつくるときに背景が理解できていて、実装しながら仕様を決められる。すると、開発スピードが格段に早くなりますね。
ユーザーに使い続けてもらえるよう「クチコミ投稿者」と「閲覧者」それぞれに向けた施策を打っているという『LIPS』。投稿者向けには投稿のハードルを下げる投稿フロー改善、ベネフィットを設計。閲覧者向けには、プッシュ通知の細かい時間の設定などを日々検証しながらチューニングしている。
>>>［2］コードを書く、デザインもする。自分でプロトタイプをつくれるPMに。AppBrew 松井友里の原点
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
