PMは“パーティマネージャー”の略称？　成長がすべてのスタートアップにおけるPMの役割

スタートアップに転職して直面した課題

奥本照之氏：ツクルバの奥本照之と申します。よろしくお願いします。今回、「PMはパーティーマネージャー」という、ちょっと奇をてらったテーマで話したいと思います。

この中にスタートアップの方はいますか？　このプレゼンの目的なんですが、僕はスタートアップに4ヶ月前に転職して、自分がなにかバリューを発揮できるところはここかなあと思ったので、スタートアップのPMのケーススタディとなる話をしたいと思います。

僕の思うスタートアップのPM像の定義と、あとは今日この会場に、僕の前職であるエウレカの元上司が2人もここにいるので、彼らに転職して4ヶ月経った僕の報告と、自己の振り返りができればと思っています（笑）。

アジェンダとしては、スタートアップに転職して直面した課題と、その解決のためにやったこと。そして最後に、スタートアップにおけるPM像とはなにかについてお話しします。

まず自己紹介ですが、僕は今年27歳になります。株式会社ツクルバに、プロダクトマネージャー第一号として入社しました。前職は、先ほどプレゼンされた梶さんや金田さんと同じエウレカという会社で、二年間「Couples」というメディアのディレクターをしていました。最後の一年間は「Pairs」のプロダクトマネージャーです。

現職はどんな仕事かというと、場づくりをしている会社です。コワーキングスペースや不動産売買のプラットフォーム、またコミュニティサービスなどをやっています。

そのほかに変わったものでいうと、「tsukuruba studios」という、エンジニアとデザイナーと建築家がごちゃまぜになっている、実空間と情報空間を横断するモノゴトづくりの場があります。そこで僕は「cowcamo（カウカモ）」という中古物件の流通プラットフォームに携わっていて、コレは主にウェブとアプリでサービスを提供しています。

「cowcamo」の特徴は、物件ではなくライフスタイルを提案したサービスであることです。すべて社内のライターが取材をして記事を書いてたり、リアルの場で接客をする不動産営業の方が社内にいたりもします。あとはオウンドメディアや顧客管理ツールみたいなものを内製しているという感じです。その中で僕は、主に「cowcamo」のC向けサービスのPMをしています。

ツクルバという会社の4つの特徴

それではスタートアップに転職して直面した課題を話します。まず最初に、前提となるツクルバという会社の特徴について4つ紹介します。

（スライドを指して）1つ目の「tsukuruba studios」というのは、エンジニアやデザイナー、アーキテクトといった領域を超えた専門知の集まるチームのことです。実務的なことで言うと、いわゆる事業部とクリエーターの部が別になっていて、彼らがそれぞれ独立している部といった感じです。

2つ目は、オフラインでの課金がメインで、オンライン上では売上が立たない状態ということです。それにより、事業のパワーバランスにおいてリアルの場で接客をする営業が評価されやすくなっています。

3つ目。僕がPM第一号として入ったのですが、それまではエンジニアとデザイナーだけで開発をしていて、彼らがCEOや営業・編集・事業企画などのマネージャーとやり取りをしてました。

そして最後の点は、スタートアップであるということです。僕はそんな特徴を持つ会社に入社して、さっそく課題に直面しました。

Slackの事業部メンバー全員が入っているチャンネルで、エージェントの方が「受注しました」みたいな報告をしてたんです。それにスタンプの嵐だったり、社内のメンバーのコメントがたくさん来ていました。

しかし、iOSアプリに関するチャンネルでの新しいバージョンのリリースに関する報告には、「いいね」とかスタンプが一つあるぐらいでした。僕はこのギャップに非常に驚きました。

あとは、プロダクトに関しての課題が出されるチャンネルがあるんですが、そこでビジネス職、いわゆるエージェントとかライターの方が、非常に申し訳なさそうに課題をあげているというのがありました。

ビジネスとエンジニア、両サイドにある温度差

1つ目の課題は、先ほどの前提などもあって、プロダクトやエンジニアへの称賛文化がなかったり、社内受託的な体制になっているということでした。

もう1つの課題は、僕が開発マネージャーに「こういうこと実現したいけど、オペレーションコストを考えると、今はこんなことをやりましょう」と提案しても、「工数とか考えなくてもいいから、効果を最大化させられることを考えろ」と何度も何度も提案を返されました。

あとは継続改善を行うスクラムチームをつくったんですが、その中で施策についての提案をする際に、前職のエウレカで使用していたフォーマットを使っても受け入れられませんでした。細かく言うと、開発メンバーから施策の仕様を詰めすぎてもつまらないから、余白やゆとりをもって作成してきてという返しをされました。転職当時は本当にこんなことがたくさんあって、とてもつらかったですね（笑）。

そこでの僕の気づきは、「プロダクトマネジメントはプロジェクトマネジメントとは違う。Howとwhyではなく、WhatやWhyを深く考えることが必要である」ということです。とくにスタートアップの場合は、メンバーが開発やデザインだけでなく、企画の方にも幅広く入りたい人が多いので、Howはプロに任せて入らないくらいの加減の方が良いことを学びました。

ただし、時にはプロジェクトマネージャーとして開発に参加することもあるので、その加減の調整が難しいなあと思いました。

2つをまとめると、1つ目に関しては僕の会社独特の課題かもしれないんですけど、ビジネスサイドとエンジニアサイドに温度差があること。自身の型にはまったPMのスタイルを貫き通しすぎていたことでした。

PMとして行った課題解決

先ほどの課題解決として行ったことは、大きく4つあります。

1つ目は、プロダクトの定義とユーザーの特定化です。僕がPMとして一番最初だったことと、そもそも開発メンバーも10人弱ぐらいしかいなくて、各々がプロダクトに対して強い意志を持っていたんですね。ただ共通言語みたいなものがなかったので、まずはそれをつくる作業をしました。

カスタマージャーニーマップはちょっと重すぎたので、ギルドワークスさんにお手伝いいただいて、仮説キャンバスというものをつくったり、僕が営業の新人のふりして同行したり、プロダクトKPIがなかったのでそれを定義したりすることからはじめました。

2つ目はプロダクトドリブンな社内文化の醸成です。新しく入社する方が毎月10人弱いるんですが、彼らとプロダクトを触り合って課題を出したり、とりあえずリリース時にはにぎやかしをしていました。前まで15人のチャンネルにしかシェアしなかったんですけど、必ず事業部メンバー全員が入っているチャンネルでリリースのシェアをしたりとか、新しく入社する方に課題を出させて、「誰でも気軽に課題を出していいんだ」っていう文化を醸成しました。

「cowcamo」のサービスのリリース文なんですけど、エモいポエムみたいなものを添えていて、社内のメンバーでも2週間のサイクルで出すリリースが楽しみになってくるような習慣ができました。

あとは変動的なチームビルディングです。今までは完全に新規で、ゼロイチの開発が多かったんで、全部ウォーターフォール的な感じでした。それがアプリのほうで改善のフェーズ入ってきたので、僕がスクラムのチームを作ったりしています。単発的なプロジェクトもあるので、流動的な感じでいろんなチームをつくってました。

最後はちょっと抽象的なんですけど、柔軟にバランスを取り続けるということです。先ほどいったような、課題発見と問題解決の介入具合ですね。今もPMはぼくだけなんですけど、POとスクラムマスターを兼務したりだとか、プロダクトマネージャーになったり、プロジェクトマネージャーになったり、グロースハッカーになったり、UXデザイナーになったりと、なんでもしてますって感じです。

PMとは“パーティマネージャー”の略称？

そんないろいろな課題に直面してきました。先ほどあげた課題以外にも、課題は無限に出続けていて、どうしようかなって感じなんですけど。ダイエーの創業者の方が「売上はすべてを癒やす」ということをおっしゃっていて、ことスタートアップでは成長がすべてを癒やすのかなと思っています。

なので、成長ですべて癒やすために、スタートアップのPMは開発メンバーのプロダクトへの情熱を高めたり、良いときには褒めたり、それを拡張したり盛り上げたりしていくのが役割なのかなと思っています。

PMって、もっと自分が媒体主となって、いろんなステークホルダーやユーザーに対して、あらゆるかたちでコーディネートしたりするプロデューサーのようなものだと言われると思うんです。ことスタートアップにおいては、”パーティマネージャー”なのかなと僕は思っています。

（会場笑）

平成最後の夏なので、みなさん、パーティーをして最高の夏にしましょう。ご清聴ありがとうございました。

（会場拍手）