プロダクトマネージャー オフ会#4 @GMOペパボ イベントレポート

プロダクトマネージャーのコミュニティ、Product Managers Japan (PMJP)のオフ会レポートです。

今回も80人の参加枠が告知後数十分で埋まってしまいました。前回と比べて女性の参加者が増えたかも？会場提供いただいたGMOペパボ株式会社さん、ありがとうございました。

前回からプレゼン/LTタイムが設けられましたが、第4回目になる今回も充実したプログラム内容でした。チームの作り方、開発プロセス、PMの役割、グロース実例、など一線で活躍するPMの皆さんならではの発表内容で、とても勉強になりました。

以下は皆さんの発表資料です。

Fablic ninjinkunさん『スマートフォンアプリ開発における共創的な開発チーム』

GMOペパボ 山本としやさん 『強いプロダクトを生み出すチームづくり』

Increments 及川卓也さん 『PM++ 〜QiitaにおけるPMの役割〜』

ヴイエムウェア 桂島航さん 『プロダクトマネジメントとプロダクトマーケティングの違い〜米国インフラソフトウェア企業の経験から』

GMOペパボ 千葉誠さん『チーム全員でお申し込み数を2倍にした話』

当日のツイートのまとめはこちら。
▼ pmjp.slack.comオフ会#4 - Togetterまとめ 

pmjpではslack上のコミュニティでプロダクトマネジメントに関する情報交換をしています。プロダクトマネジメントに関わる方は誰でも参加可能ですので、下記からご参加ください。オフ会情報もこちらで告知されています。
▼ Product Managers Japan (PMJP)

前回のオフ会レポートはこちら。

プロダクトマネージャーのための注目記事まとめ（2016年6月号）

プロダクトマネジメントに関する記事で、6月に話題になったものをピックアップしてご紹介。

課題発見、アイデア創出

広告会社出身の方の記事ですが、プロダクトマネジメントを含めてあらゆるジャンルの課題解決に共通のアイデア発想法が紹介されています。

自分自身がプロダクトのターゲットユーザーではない時にどうやってインサイトを発見すべきか。社内もしくは距離の近いところに日常的なユーザー接点をつくる、というやり方は最近よく耳にする気がします。

「当然これはあるべきだ」と誰もが暗黙的に考えているものを取り払ってしまうこと、制約を設けることでイノベーションが生まれる。ブルーオーシャン戦略と共通する考え方かもしれません。

開発プロセス、チームづくり

クリエイティブディレクションのエクセキューションに求められるのは進行管理だけではない、ということ。記事後半で紹介されている失敗ケースでは、ミッションの発見、コア・アイデアの発見、アウトプットのクオリティ・コントロールなど複数のポイントでミスがあったように見受けられます。
 

スマートフォンアプリ開発における共創的な開発チーム // Speaker Deck

Design Sprintの実践例のようにみえます。PMはこういうチーム文化づくりを目指したいですね。

PMには議論を交通整理して物事を前にすすめるファシリテーション能力が必要とされます。論点が整理しつくされており、あとは実行して仮説検証するしかない、というフェーズで役に立ちそうなフレーズが紹介されています。

エンジニアの方の採用面談をすることがありますが、確かにこうしたことを聞かれるし、話すことが多いですね。

UXデザイン、UIデザイン 

理想的なUXを実際のプロダクトとして実現するには大きなギャップを超えなければならない。そのためには企画、エンジニア、デザイナーのチーム全員がUXに向き合う必要がある。全員でUXを考える組織でデザイナーに求めれれるのは、最新の技術で実現できる実現イメージを提示すること。
 

フリーランスデザイナーの「つくること、はたらくこと」 // Speaker Deck

デザイナー視点から見た良いプロダクトを作るための要点。デザイナーとコミュニケーションするPMはきちんと理解しておきたいポイントが整理されています。

ワーディング一つで誤解が生じたり、サービスの使い方をスムーズに理解できたりするのでライティングは重要。PMがプロダクトのレビューをする際にはボタンのラベル含めたワーディングの一つ一つにこだわる必要がありますね。スペースを消費せず端的な表現で意図を伝えるための言葉選びは、UIデザイン作業の結構な割合を占めている気がします。

PMの仕事と共通する部分が多く、とても勉強になる内容です。PMは市場調査やユーザー調査など通じて市場機会やミッションを発見し、UIデザイナーに正しいインプットをする必要がありますね。

プロダクトマネージャーに訊く #5：GMOペパボ山本さん（後編）

良いチームが良いプロダクトを作る

― minneに異動してから、PMとしてまずどんなことをしたのでしょうか？

去年の9月にminneチームに異動して最初に気がついたのは、規模が大きくなって全体感が見えづらくなっていることでした。minneチームではGitHub Enterpriseを使っていてWebやiOSアプリ、Androidアプリなどの単位でリポジトリが分かれているんですが、リポジトリごとにイシューが山積みになっていて、ステータスやタスクの粒度が見えづらくなっていました。

イシューをもう一段上のレイヤーで整理する必要があることに気づいて、全体観を見れるものをプロダクトバックログとしてTrelloにまとめることにしました。GitHubのイシューはどんどん埋もれていってしまいますし、良いアイデアが各リポジトリのコメント欄に眠っていたり、壮大な野望みたいなものがどーんと書かれていることもあります。目茶苦茶時間が掛かりましたが、全リポジトリのイシューを全部チェックして、全体観を見れるものをプロダクトバックログとしてTrelloにまとめました。僕は情報を全員にオープンにすることが重要だと思っているので、Trelloに色々な情報を集約して自分が普段考えていることや優先度がわかるようにしています。

― メンバーそれぞれが自分のタスクだけでなく、サービス全体の状況がわかるようにしたということですね。

一時期、壁に付箋を貼って、振り返りで出たアイデアや実施が決まった施策、終わったタスクなど、なんでも共有するようにしていました。各チームで話し合ったことが、GitHubのイシューのようなデジタルなところだけに保存されるのではなく物理的な壁に貼ってあることで、チーム全体の空気感や、誰が何をやっているのかがより見えやすくなります。

― minneは何人ぐらいのチームで開発してるんですか？

minneでは東京と福岡に60名ほどのメンバーがいますが、開発チームはサーバーサイドエンジニア、アプリエンジニア、ディレクター、デザイナーを入れて合計で20名程度です。

東京のメンバーは主にアプリとAPIの開発、福岡のメンバーはインフラやWebの開発がメインです。ディレクターが東京に1名、福岡に2名います。拠点が分かれているので、コミュニケーションの取り方やプロダクトマネージャーとしての立ち回り方については色々と試行錯誤しました。

― ディレクターと山本さんの役割分担はどうなっているのでしょうか？

minneチームではスクラムを導入しているので、ディレクターと僕でプロダクトバックログをみて、エンジニアやデザイナーと個別にやりとりをして技術的な判断をしながらスプリント計画を作っていきます。

僕がプロダクトバックログを整備して次に作るべきものを決めて、各ディレクターがディレクションや全体の進行管理をして開発を進めます。僕が開発メンバーと「こうしたほうがいいんじゃないの？」と直でやりとりするとディレクターが混乱してしまうので、一度任せたらあまり口を挟まないというスタンスをとっています。

― 良いプロダクトを作るためにどんなことを意識してやっていますか？

東京、福岡と開発拠点が分かれていることもあって、チーム作りはすごく意識しています。

僕自身が手を動かしてプロダクトを作れるわけではなく、解決したい課題をチームに伝えるのが僕の役割で、実際にその課題を解決するためのプロダクトを作るのはチームです。だからこそチーム作りとプロダクト作りは切り離せないですね。

― よいチームを作る上で具体的にどんなことをやっていますか？

事あるごとにメンバーと喋るようにしています。毎月一回、プロダクトチームの全メンバーと20分間の面談をするようにしています。福岡にも度々出張して、福岡の開発メンバーと直接話すようにしています。

定期的に面と向かって話すことで、修正コストが大きくなる前に問題を把握できます。「困ってることない？」とか、「最近、仕事楽しい？」とか、お父さんのような感じでコミュニケーションをしながらメンバーがフィットできるように環境を整えたり、チームの中で障壁になっていことがあればなるべく早い段階で取り除くようにしています。

PMがチーム作りに時間をかけることで、結果として良いプロダクトをより早く出せると思っています。僕はお節介焼きが好きなのかもしれません。チームのために工夫したり、メンバーのフォローしたりすることが苦にならないタイプなんです。

他のチームとの情報共有も積極的に行うようにしています。僕はプロダクトチームのマネジャーなんですが、作家支援、マーケティング、サポートの各チームにそれぞれマネージャーがいます。毎日夕方6時になるとSlackに通知が来て、定例のマネージャーミーティングを始めるんです。そこでその日の出来事とか、直近で困っていることや迷っていることを相談して、なるべく問題を翌日に持ちこさないようにしています。マネージャーという役割は孤独な側面があると思うんですが、お互いに相談しあえる場が毎日あるのはすごくありがたいですね。

― それはいいですね。マネージャーミーティングを始めたきっかけは？

別の部署で同じようなMTGをやっていたんです。傍から見ていてもマネージャー同士の連携が強くなって、部署の雰囲気がよくなったのを感じていました。それならうちもやらない手はない、人数も多いしマネージャーは福岡にもいて普段同じ場所にいない、だからこそ話す機会を意識的に作ったほうが良い、ということでminneチームでもやることになりました。

自分の「熱量」を維持し続けること

― チーム作り以外で気をつけていることはありますか？

プロダクトマネージャーがその分野を好きでも本気で取り組めないと、どんなに良いビジネスモデルのサービスであっても成功しないと思っています。なので、チームの中で一番熱量が高いように自分を維持し続けることが大事です。

― ちなみに過去に「熱量が足りなかったな」というプロダクトはありましたか？

僕は幸いやりたいことをやらせてもらえているので、そういうプロダクトはほとんどなかったと思います。自分から手を上げたり、適任だからとアサインされたり、やりたいと思えるプロダクトを任せてもらえて、運が良いんだと思います。

ただ、以前2つのプロダクトのマネジメントを同時に担当していたときに、割ける時間と熱量がどうしても半分ずつになってしまい、フルコミットしている開発メンバーの熱量を超えられなくなって、チームと良い関係を築けないという時期がありました。

― やりたいと思えるプロダクトを担当し続けられているのはとても幸せなことですね。

そうですね。僕は会社が好き過ぎて長期の休みが苦手なんですよ（笑）。
子供も大分大きくなって手が掛からないので、3連休以上になると会社行きたくなってしまう。なので週末に「一人振り返り」をやっています。一週間を振り返って、Keep、Problem、Tryを洗い出しながら、次の一週間でやらなきゃいけないことをリストアップして、GitHubのプライベートリポジトリにイシューとして登録しておきます。

― すごいですね。どれくらい続けてるんですか？

minneに異動してからもうずっとやっています。頼まれていたことを忘れてた、みたいなことがすごく嫌なので、そういうミスを極力なくそうと思って一人振り返りをやっています。チームのメンバーからすれば、途中から突然来た人間なので、そうした基本的なことができていないと信頼を得られないだろうな、と。

― それはやはり熱量がないとできないことですね。

そうですね。実はminneで買い物をするのが大好きなんです。普段シャツにつけられるようなブローチとか、色々とminneで買い物をしています。自分で作品を作ってminneに出品したこともあります。プラバンを加工してレジンという樹脂で固めたアクセサリーを作ったんですが、別の部署のスタッフが「それ、かわいいですね」と言って買ってくれました。自分が作ったものが売れた時の喜びや、買ってもらえるものを考える大変さなどを実感できました。

実際に自分でやってみると、作品を出品することの大変さに気づくんです。買うのも出品するのも実際に体験してみるだけで、自分の意見に説得力が出ます。こういうところがすごく大変なんだよ、と推測ではなく実体験を元にした意見として、サービスの課題をメンバーに伝えることができます。

山本さんがminneで購入したハンドメイド作品

― このシリーズでは毎回聞いてるんですが、PMを目指す人におすすめの本があれば教えて下さい。

「スクラム」を定期的に読み返しています。僕はPMとしてチームでのプロダクト開発をすごく重要視しているのですが、スクラムで言うところのプロダクトオーナーとして自分がどう立ち回るべきか、といったことを意識しながらこの本を読んでいます。  

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術 (早川書房)

  この本ではマルチタスクの無駄が辛辣に批判されているのですが、普段マルチタスクになりがちな自分を戒めるためにも繰り返し読んでいます。 

― 最後に読者に伝えたい事はありますか？

ペパボではプロダクトマネージャーやプロダクト開発のディレクションができる人を随時募集してます。minneはCtoCハンドメイドマーケットという注目を集めている分野のサービスですので、興味がある方はぜひご連絡ください。

また、エンジニアの方向けの制度になるのですが、ペパボにはペパランチョンという制度があり、一緒にお昼ごはんを食べながらカジュアルに会社の話ができます。もちろん無料ですので、遊びにいく感覚で来てもらえると嬉しいです。

― こういう人に来てほしい、という人物像はありますか？

エンジニア経験や技術力などのスキル要件以上に、自分の考えに共感してくれる人や、チームで良いプロダクトを作るんだっていう熱量を持っている人がいいですね。「なんでも吸収するぞ」という気持ちのあるフットワーク軽い人が合っているんじゃないかなと思います。

うちの会社はスタッフ同士の仲が良く、飲みに行ったり休日にみんなで集まってどっか行ったりすることもよくあるんです。そうした、仕事の垣根を超えた人付き合いが好きな人はペパボのカルチャーに合うと思います。

― ありがとうございました。

プロダクトマネージャーに訊く #5：GMOペパボ山本さん（前編）

― まず山本さんご自身について教えて下さい。

GMOペパボ株式会社の山本です。ハンドメイドマーケット『minne（ミンネ）』のプロダクトマネージャーを担当しています。

2003年にまだ社員数が非常に少ない時代のペパボにデザイナーとして入社しました。まだ10人くらいの頃です。当時は主なサービスがレンタルサーバーの『ロリポップ！』ぐらいしかありませんでしたが、それからどんどんサービスが増えていきました。ブログサービスが流行り始めた頃で、ブログサービス『JUGEM』の立ち上げにデザイナーとして関わりました。

ペパボは3社目なんですが、ペパボに入る前は紙媒体のデザインをやっていました。新卒で福岡の印刷会社に入社してデザイナーとして働いて、1年ほどでフリーペーパーやWebサイトを手がけるデザイン会社に転職しました。

当時、趣味の写真をテーマにしたホームページを運営してたんですが、ホームページの掲示板に創業者の家入さんを初めペパボの人たちがコメントしてくれていたんです。それがきっかけで家入さんと家族ぐるみで遊ぶようになりました。前職を辞めた足で人数分のジュースを手土産にペパボのオフィスに行ったんですが、その時に誘ってもらって転がり込むような形でペパボに入ることになりました。今では考えられないような選考ルートですね。その後2004年の本社移転に合わせて、僕も転勤組として東京に移りました。

30days Albumをきっかけにデザイナーからプロダクトマネージャーへ

― もともとデザイナーだった山本さんがプロダクトマネージャーになったのはどういう経緯でしょうか？

2008年に社内で新規事業の公募イベントがあり、個人的に写真を撮るのがとても好きだったこともあって、『30days Album』という写真を共有するウェブサービスを提案して事業化しました。プロダクトマネージャーとしての役割を担うようになったのはその時からです。その後、PaaSの『Sqale（スケール）』というサービスを立ち上げたあと、昨年の9月からminneに携わるようになりました。

― デザイナーから企画側にシフトしていく過程で苦労したことはありますか？

最初は結構苦労しました。30days Albumの立ち上げは3人ぐらいのチームでしたので、自分でデザインしながらエンジニアと一緒にプロダクトの企画や設計をしていました。事業責任者として数字も見ていたので、開発現場のディレクションをしながら数字を管理するという二足のわらじ状態が大変でした。

また、ずっとプロダクト開発に関わってはいましたが、デザイナーとしての経験がベースなので、プログラミングのことはやっぱりわからないんです。なので、エンジニアに「これはできる？」といったやり取りが繰り返し必要で、今振り返るとロスが多かったと思います。実装が難しい突飛なアイデアを押しつけようとしてしまったこともあります。

― 「プログラミングのことがわからない」という弱点をどのように克服したのでしょう？

30days AlbumはRuby on Railsで作っていたので、せめて読めるようになろうと思って独学でRuby on Railsを勉強しました。自分でプログラムを書かかないとしても、エンジニアと会話はできないと信頼関係は生まれません。エンジニアとクロスする領域を増やしたいという思いがありました。

『Ruby on Railsチュートリアル』という、Railsを学ぼうとする人が一度は通るチュートリアルサイトがあります。12章まであって結構ハードなんですが、それをとにかく最後までやろうと決めてやりきりました。エンジニアに話したら「あれ本当にやったの？」と驚かれました。

チュートリアルで一通り学んだことで、インターネットサービスがどうやって動くのかというおおよその仕組みがわかったんです。実際のサービスのコードも「こういうことをやろうとしてるんだな」というのが少しずつわかるようになってきました。そうするとエンジニアからも「こいつは話せばそれなりにわかるやつだ」と思ってもらえるようになって、物事がスムーズに進むようになりました。

― やっぱり自分でやってみるって大事ですね。

本当にそう思います。

― 数字を伸ばしていくうえでは、プロダクトだけでなくマーケティングやプロモーションも必要になってきますが、その辺りはどうされていましたか？

30days Albumの時は、なかなかマーケティングにコストをかけられませんでした。ただ写真を誰かと共有したい時に使うサービスなので、写真をアップロードした人が誰かに必ず宣伝をしてくれる構造になっていました。そのサービス構造に助けられて、ほとんどプロモーションせずに一定数のユーザーを常に獲得できていました。

― ユーザーがユーザーを呼ぶ構造は最初から狙っていたんですか？

最初はそこまで考えてはいませんでした。期間限定で写真を共有できたらプライベートな写真でももっとオンライン上でやり取りできるんじゃないか、みたいなアイデアからスタートでしたサービスでした。

ネットにアップされる写真は氷山の一角でしかなくて、水面下に眠っている部分、ローカル保存されている写真をオンラインに引き上げたい、という思い先行で企画したサービスだったので、事業としてどう成立させるかという点は、色々と試行錯誤しました。

― 試行錯誤しながらPMや事業責任者としての振る舞い方を学んでいったんですね。

そうですね。minneに異動する前の部署の上司は、事業責任者としてロールモデルになる人でした。ロジカルに物事を捉えて正論をズバッと言って周囲を納得させたり、ビジネス視点を正しくメンバーに伝えたりする姿を見て、「こういうやり方をすればいいのか」と事業責任者として振る舞い方を学ぶことができました。さらにプログラミングを学んだことで、技術とデザインとビジネスの３つに関してはメンバーと最低限の会話ができるようになりました。

― 元デザイナーとしてつい自分で手を動かしてデザインしてしまう、なんてことはありますか？

いえ、基本的にAdobe製品は起動しないことにしています。30days Albumを始めて2年ぐらい経ったときに、専任のデザイナーをアサインしてもらえたんですが、彼がすごくできる人だったので「この人にお任せすれば僕はデザインをしなくてもPMとしてやりたいことができるな」と思ったんです。自分のデザイナーとしての引き出しにもそろそろ限界を感じていたので、マネジメントにシフトすることに決めてそれ以来デザインは担当者に任せることにしています。

― 自分でデザインしないことについては葛藤はなかったんですか？

そうですね。むしろデザイナーが入ってくれて本当にありがたいなと思っていました。自分一人でデザインしている限り、アウトプットは自分の想像の範囲を超えられません。「こういう課題があるので、もっと良い解決策を考えて欲しい」とデザイナーに依頼すると、僕が考えた解決案を超えるアイデアが出てくるんですね。メンバーが自分の想像や期待を超えるアウトプットを出してくれるのは、自分自身でデザインする以上に楽しい体験です。

minneで作り手個人にスポットライトが当たる場を作りたい

― minneについて教えて下さい。

minneはハンドメイド作家と購入者をつなぐCtoCのマーケットプレイスで、2012年にスタートしました。作家人数は2016年5月の段階で23.3万人、作品点数は2,970,000点という、国内最大のハンドメイドマーケットサービスに成長しています。もともとWeb中心のサービスだったんですが、去年からアプリにシフトしています。

― ユーザーはどんな人達が多いんですか？

ユーザーの9割以上が女性です。趣味でモノづくりをしていた方や、主婦や育児をしている方も、家にいながら活躍できる場としてminneを使っていただいています。モノを作ることが好きな人が世の中にはこんなにいるんだなと実感します。

― 作家の方はminneでどれくらいの収入を得ているんでしょうか。

一番多い方で、月に400万円近く販売している方がいます。

― えっ、すごいですね。

先日テレビでminneをご紹介いただいたんですが、作家さんが2名出演されていて、どちらの方も月に30万ぐらいの売上があるとおっしゃっていました。

材料費などコストがかかる部分はあるので利益率は作家さんによって異なりますが、主婦の方が趣味で作っていた作品が、minne主催のコンテスト「ハンドメイド大賞」で賞を受賞したことをきっかけに、メーカーから声をかけられ、キットが販売される事や、本を出版された作家さんも中にはいらっしゃいます。作家活動のステップアップの場としてもminneを使っていただいています。

― まさに新しい働き方を作っているのですね。

そうですね、個人の作り手に光が当たって活躍できる場になるといいなと思っています。作家さんから「これからは制作を本業にしていきます」という報告をいただくこともあって、すごく嬉しいです。

ユーザーとリアルに接することで、ハズレのないプロダクト改善を実現する

― 山本さんはデザイナー出身で写真が趣味ということで、ハンドメイドの作り手の方の気持ちがよく理解できるのではないでしょうか。

もともとデザイナーなので手を動かすのも好きですし、モノを作って誰かに認められることの楽しさをずっと実感してきたので、作り手の気持ちはよくわかります。

僕はminneの立ち上げメンバーではなく、後からminneチームに異動してプロダクトマネジメントをすることになりました。そうした場合にはサービスの世界観やユーザーにどれだけ共感できるかが重要になると思いますが、自分自身がデザイナーとしてモノを作る仕事をしてきた経験から、「やっぱりこういうサービスは必要だよね」と自然と思うことができました。

― PMとしては主観的な思いと客観性のバランスをとる必要があるかと思いますが、その点は何か工夫をしていることはありますか？

そのプロダクトが好きかどうかというのはPMを務める上での最低条件だと思いますが、自分の思いが強すぎると周りが見えづらくことがあります。僕も何度か失敗を重ね、一歩引いて客観視できてるか、自分の後ろ姿を見ることができているかを意識的に確認するようになりました。

以前別のプロダクトで、自分の強い主張でエンジニアを説得して作ってもらった機能が、思ったほど使われなかったということがありました。やはり思い込みでモノを作ってはいけないなと戒めになった出来事でした。人を巻き込んでうまく行かなかった時の心理的なダメージを思い知りましたね。

今では成功確率を上げるために、リアルな場でのユーザーインタビューなどを通じて自分の仮説が本当に正しいのか客観的に検証してから取り組むようにしています。

― 実際にminneのユーザーさんと接する機会は多いんでしょうか。

はい。東京の世田谷と兵庫県の神戸に、作家さんが気軽に遊びに来れる「minneのアトリエ」があって、minneのスタッフが作家さんとお会いしたり、作家さん同士が交流する場にもなっています。

アトリエでは定期的に勉強会を開催していて、minne上で自分の作品を魅力的に見せる写真の取り方や、紹介文の上手な書き方などを学ぶことができます。「自分の作品をネットで売る」という行為は作家さんにとって最初はハードルが高いので、アトリエではつまづきやすい所を一つ一つフォローしています。作家向け勉強会は、募集をかけると募集枠の何倍もの申込をいただきます。

― 本社から遠い神戸にもアトリエがあるんですね。

はい、神戸市と提携し、デザイン・クリエイティブセンター神戸／KIITOに「minneのアトリエ」を開設しました。神戸市は重点施策として『働き方改革の推進』をおこなっていて、若者が活躍できたり、それぞれの才能を活かして多様な働き方ができる環境作りに力を入れています。神戸で活躍する作家さんが増えるように、さらに現在関西方面で活躍している作家さんに活用頂けるように「minneのアトリエ 神戸」の開設を提案しました。

― ユーザーの声を活かしたサービス改善のサイクルができているのですね。

たくさんの方にご利用いただいていますがもちろん課題もあります。アトリエでは作家さんとお会いしてインタビューしたり、座談会を開いたりもしています。

事前にユーザー課題について仮説を立てて作家さんに投げかけると、「いや、それは全然困ってないです」と言われることもあります。逆に「そうそう、そこが使いづらいです」と全員が共感してくれることもあります。どちらも作家さんから直接聞ける生の声なので、サービスを運営している僕たちにとって大変貴重な意見で気付かされることがたくさんあります。

また、日頃からminneではカスタマーサービスのチームが作家さんの色々な要望を受け取ってくれています。共有された情報を参考に、実際に作家さんに会って話を聞くと「これは確かに改善が求められているな」ということがわかります。サポートのメンバーは電話やメールで直接作家さんと日々接しているので、要望の温度感を一番把握してくれていますね。

チームで共有しているminneユーザーのペルソナ

― アトリエで得られたユーザーの声を活かした改善例を教えてもらえますか？

minneは作品の並び替えが大変だと以前からユーザーさんの声がありました。僕らもそれをなんとかしたいと思っていたんですが、大量の作品リスト上の作品をドラッグ＆ドロップで自由に並び替えるような機能は実装コストが高くてなかなか着手できませんでした。そこで「ユーザーが本当に困っていることは何なのか」ということに立ち戻って考えることにしました。

実際にアトリエに作家さんにお越しいただいて、どういう時に並び替えができないと困るのか聞いてみたところ、実はそこまで高機能なものは求められていないことがわかりました。例えば、「去年販売した季節物のアクセサリーを同じシーズンになった時にもう一度作品リストの手前に持ってきたい」とか「多くの作品を出品していると10回くらいクリックし続けないと先頭に持ってこれない」「一旦売り切れてしまったオーダー作品は一番後ろに持ってきたい」という声を実際に聞くことができました。

作品を自由に並び替えたいのではなく、先頭や一番後ろに移動させたいだけなのにすごい数のクリック操作を強いられることがストレスになっていることがわかり、適正なコストで必要十分な機能改善を行うことができました。

― プロダクトの改善はユーザーの声を元にすることが多いんでしょうか？

長期的なビジョンの実現や半期ごとの方針に沿った開発もあれば、短期的な改善効果を期待する開発もあります。新機能開発も既存機能の改善も、最終的にはサービスの成長にどうつながるかという観点で企画します。

▼ 後編に続く

2016年5月の注目記事まとめ

プロダクトマネジメントに関する記事で、5月に話題になったものをピックアップしてご紹介。

Inspiredで紹介されているフレームワークを、eurekaでは実際にどのように使っているか解説されています。

プロダクトマネージャーの思考をブラッシュアップする9つのカード – aomeganeビジョン | 五反田で働くプロダクトマネージャーのブログ

freeeのPMチームで利用している９つのカード。企画の妥当性を検証するためのチェックツールが紹介されています。冒頭のInspiredの「10の質問」がベースに。

ちなみに私の個人的なチェックリストには、
・当社の製品が存在しないと困るのはだれか
という項目があります。ターゲットとその課題を言語化するときに便利です。

いわゆる「ハマる仕掛け」のネタばらし。ビジネスとして継続させるには使い続けてもらう工夫も必要。とはいえ行き過ぎれば依存した結果燃え尽きてしまい離脱に繋がるのでは。

実は曖昧に使っていそうな言葉。個人的にはスケッチしながらコンセプトを考える派です。

PMとしては利用頻度の高いツールではないかもしれませんが、基本は理解しておいたほうがいいですね。

プロダクトマネジメントTOYOTA起源論をさらに遡り、徳川家康起源論に。「最新事例を知りたければ海外ではなく三河をみるべし」

プロダクトマネージャーに訊く #4：Kaizen Platform瀧野さん（後編）

チーム開発を成功させるためのプロダクトマネジメント

― 最近、日本でもプロダクトマネジメントが注目されていますが、その理由はなんだと思いますか？

小さいチームでも大きな影響力を持ちうることや、チームの力を最大化することで新たな価値を生み出せることに、皆んなが気づき始めているのでしょう。その手段の一つとしてプロダクトマネジメントが注目されているんじゃないかというのが個人的な見立てです。

チームの重要性はスタートアップであれ大きな会社であれ変わらない。少し前に「ビジョナリー・カンパニー」がトレンドになったことががありましたがビジョンやイノベーションの重要性が先行して注目されて、それを実現するチームを支える役割としてプロダクトマネージャーが必要とされるようになったのではないでしょうか。

― もともと個人でビジネスをしていた瀧野さんがチームの重要性に気づいたのはどんなきっかけがあったのでしょうか。

GREEの時の経験が大きいですね。GREEに入って最初の仕事は、売上が下がるトレンドにあったソーシャルゲームをリニューアルすることでした。売上目標と撤退期限が決められているプロダクトをエンジニア2人と新卒一人の4人のチームで立て直すことになったのです。

普通にやっていたら達成できない高い売上目標が設定されていたので、「どうやったら売上を伸ばせるか」ではなく、「どうやったらゲームチェンジを仕掛けられるのか」ということをチームで議論しました。

どういうゲームが流行っているのか、ユーザーはどういうものに興味を持つのか、どういうメカニズムでソーシャルゲームにハマるのか、など色々なことを調べてプロトタイプを作り、テストを繰り返した結果、売上を大きく伸ばすことができました。目標から逆算してやるべきことをチームで知恵を絞って考える。そうしたら見事に目標を達成できた。コラボレーションが生む力を実感できた成功体験です。

ただ、その頃は「プロダクトマネジメント」という言葉は知りませんでしたし、意図的に仕掛けられてはいなかったです。エンジニア、プロジェクトマネージャー、マーケターといった、違うスキルセットを持った人たちを集めてチームにし、目標に向かって自立的に稼働するようにする。こうしたマネジメントを意識的にやったのはやはりアメリカの子会社でプロダクト開発の組織作りをしたときですね。

本質的な価値を見極めてチーム全員が腹落ちする状態にすること

― 良いプロダクトを作るためにはこうすべき、という定石があれば教えて下さい。

「本質的なプロダクトの価値を考える」ということです。我々が作るプロダクトはなぜ価値があるのか、なぜ買ってもらえるのか、ということを突き詰めて議論します。開発期間の3割はそうしたディスカッションに時間を割いています。
その際に主観ではなく客観的に価値を捉えることが大切です。toCならコンシューマーの心理や行動、toBなら構造を客観的に理解する必要がある。そのためにはユーザーインタビューや市場調査、統計調査を通じてマーケットを見ることです。

自分の頭の中の仮説だけでプロダクトを作ると大抵ダメですね。思い込みを外すのはすごく難しいんですが、自分に対して正当な批判を行って主観を外すことがPMには求められます。

もう一つは、本質的な価値は何かということについて、チームが腹落ちしている状態にすることです。いくら要件定義を細かくしても、何を達成するために作っているのかわからないと、拘りや熱量も生まれませんし、なにより良いアイデアも出てこないんですよね。

それだけでなく、実装のしやすさを優先して要件を修正するような、訳のわからないことが起きてしまいます。本質的な価値を実現する上で、これは完全にアウトです。価値を提供するために何が一番良い選択なのか、チームのメンバーひとりひとりが判断できるようにすることが良いプロダクトを作るための必須要件です。

― 逆にこういうやり方をすると失敗するというアンチパターンはありますか？

目的が本質的でないオーダーを安請け合いすると失敗しますね。そういうプロジェクトでは大抵スケジュールが先に決まります。例えば、決算までに何らかの成果を言えるようにしなければならないから何か出してくれ、といったように、何を成すべきかという議論が無い中で、いつまでに何かを出してくれ、という期日だけが決まるようなケースです。

プロダクトマネージャーは真意のわからないオーダーに“YES”と言っちゃいけない。「なぜやるのか」「その時に達成しなきゃいけないことは何か」ということを経営に対して問わなければならない。そういうコミュニケーションをきちんとしないでただ受け入れてはいけません。

そういうわけのわからないプロジェクトでは、期日に近くなるとチームメンバーが「デスマーチだ」と言い始めます。目的が明確で一生懸命やっているときは忙しくてもデスマーチだとは言わないんですね。目的を達成できるようにスケジュールは自分たちで決めるし頑張るんですよ。なぜやるのか、ということを皆が強烈に自分ごと化しているときは、良いプロダクトができます。

― これからPMをめざす人とか悩んでる人におすすめの本とか、こういう本を読んでおいた良いよとかっていうのはありますか？

このインタビューシリーズの以前の記事でも紹介されてましたが、Inspiredは実例を交えた良い本ですね。あれに加えて“CRACKING THE PM INTERVIEW”という本がおすすめです。プロダクトマネジメントについて広く浅く書かれた本なので、この本の後にInspiredを読むとよく理解できると思います。 

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

 “TEAM OF TEAMS”という本もこれからPMになる人にはお勧めです。ちょっと前に「チームが機能するとはどういうことか」という本がエンジニアの間で話題になりましたが、“TEAM OF TEAMS”のほうは読み物として単純に面白い。機能しないチームと機能するチームの対比がすごくわかりやすく描かれています。 

TEAM OF TEAMS (チーム・オブ・チームズ)

 もう一つはマーケティングベーシックセレクションシリーズにプロダクトマーケティングという本があります。この本ではプロダクトマーケティングについて広く浅く体系的にまとめられています。 

プロダクト・マーケティング(マーケティンク゛・ヘ゛ーシック・セレクション・シリース゛) (DO BOOKS―マーケティング・ベーシック・セレクション・シリーズ)

 PMの仕事の中でもプロダクトマーケティングは特に重要です。プロダクトマーケティングを理解することで自分たちのプロダクトの価値を俯瞰的に捉える能力が身に付きます。

経験や知識以上に重要な「情熱」や「我の強さ」

― 記事の読者に伝えたいことはありますか？

もしKaizen Platformがやってることを見て「いいな」と思ったらぜひ話聞きに来て欲しいです。PMが僕を含めて2人しかいないんですよ。30人エンジニアいるので、あと二人ぐらいPMがいてくれると助かります。

― こういう人に来て欲しいという人材要件はありますか？

我が強いことですね。さきほどの「主観は外せ」という話と矛盾しているように聞こえるかもしれませんが、「主観を外せるけど我が強い」みたいな人が理想ですね。

Kaizen Platformはすごくディスカッションが多い会社なんです。アジェンダが決まっているミーティングは短時間で終わらせるべきですが、答えがわからないことを話すときは何回でも何時間でも話すようにしています。だから突き詰めて考える力や、拘りや我の強さがすごく大事です。

諦めないでロジックを突き詰めることができる人は、すごく楽しく一緒に仕事できるんじゃないかと思います。

― PMとしての経験や知識よりも、我の強さを求める、と。

私自身が叩き上げでプロダクトマネジメントを学んだということもあるんですが、あんまり方法論に囚われないほうが良いと思っています。経験はないよりあったほうがもちろんいいんですが、手法は常にアップデートされますし、時流を捉えて世の中が求める新しい価値を発見する上では、経験が役に立たないこともあります。ですから経験よりも本当にやりたいと思っているか、情熱を持っているか、ということがすごく大事です。

PMになる人には、「自分が本当にそれをやりたいと思っているのかどうか」を大事にして欲しい。PMは誰よりもその事業やプロダクトについて考えないといけないポジションです。だから心からやりたいと思えないと考えきることができません。

僕はやりたくないことはやりたくないタイプなので、職業的なPMは向いていないと思います。「これはすごい価値がある。ぜひやりたい」という強い衝動が生まれたときは良い物を作れるんですが、そうじゃない時は難しい。僕自身はそうだし、他の人を見ていてもそう感じます。

― 情熱や衝動以外に必要なものはなんでしょうか。PMはコードを書けるべきか、という点が議論になることがありますが、PMにエンジニア経験は求めますか？

書けたほうがいいんでしょうが、要は自分の強みをどこに持つかです。自分の弱点を認識して、それをどう補うか。メンバーが弱点を補ってくれて、チームとして成果を担保できるのであれば問題ありません。ただそのためにはコミュニケーション能力や、思考のオープン性が求められます。

とはいえ、出来ることと出来ないことは知っておいて欲しいですね。実現性のないアイデアに価値はないと思っています。僕が自分でコードを書いていたのはもう十何年も前ですが、その後もずっとエンジニアがやっていることを横で見てきたので、最低限の概念や仕組みは理解しているつもりです。

もしコードが書けないことを弱みに感じているのであれば、1回勉強して何か作ってみるのはどうでしょう。「こういうプロダクトを作りたい」というアイデアがあるのであれば、自分でプロトタイプを作ってみて誰かに触ってみてもらうぐらいのことはした方がいい。それぐらいの情熱がないと、「作りたい」という気持ちは嘘だと思う。自分で作るのが難しければ、知り合いに頼んでもいい。自分のアイデアを何らかの方法で実現してみるという経験は、PMを志す人とって必ずプラスになると思います。

― ありがとうございました。

プロダクトマネージャーに訊く #4：Kaizen Platform瀧野さん（前編）

― 自己紹介をお願いします。

Kaizen PlatformのSVP of Productionの瀧野です。現場のプロダクトマネジメントをしながら、プロダクト開発組織のマネジメントを行っています。

Kaizen Platformは現在日米あわせて100名ほどの組織ですが、2年前に10人目の社員として入社しました。

創業当初から変わらない世界観に対して、仮説検証の結果をみて戦略をアップデートすること。新たに明らかになったイシューに対して優先順位をつけて解決策を考えること。なぜ解決すべき問題なのか組織内で共有すること。こうしたことが僕の仕事です。

マーケティングに関わる人のプラットフォームを作りたい

― Kaizen Platformさんはサービスを通じてどのような価値を提供しようとしているのでしょうか。

Kaizen Platformは「A/BテストのSaaSで、テストパターンの制作をクラウドソーシングできるサービス」と認識されていると思います。実際にこれまでは「マーケティングのROIを最大化できるプロダクトです」と訴求していました。A/Bテストはコンバージョンゴールに近いところでやったほうがレバレッジがされるので、色々な人の案でテストすることで効果を最大化できる、と。

ただ、顧客が求めているのはA/Bテストツールでもないし広告の運用ツールでもない。必要なのは、自社の状況に合わせて、学習サイクルを回しながら事業を健全な方向に伸ばしていけるソリューションです。

クライアント企業のマーケッターであれ、グロースハッカーやクリエーターであれ、マーケティングに関わる人たちが改善活動を続ける上でなくてはならないプラットフォームを提供したいと思っています。

― マーケティングの改善活動を続けるためのプラットフォーム、ということですね。

そうです。マーケティングのソリューションは導入するだけで効果が保証されるわけではありません。「競合があのソリューションで上手くいったらしい」「何でうちの会社はやらないんだ」といったやり取りの中で新しいソリューションに飛びついて失敗するのは不幸なことです。マーケティングソリューションの分野は一度試して期待した成果を得られないとすぐ止めてしまうというケースがすごく多いんです。

約束された効能をお金で買う感覚だとうまくいきません。不確実性が高いなかで、自社やマーケットの現状やあるべき姿を正確に捉えるのは難しい。だからこそ仮説を立て、実行し、結果を分析する、というイテレーションを回すしかない。ただそうした改善のサイクルを回せる人がまだあまりいません。Kaizen Platformのサービスによって、マーケターが現状とあるべき姿を正しく定義でき、マーケティング戦略を自信をもって立案できるようにしたいと思っています。

― A/Bテストを効率的にできる、ということでなく、マーケティング活動を正しく行うことができることが価値である、と。

はい。プロダクトが提供すべきなのは機能的な価値だけでなく、使う人にとっての情緒的な価値を提供すべきです。機能性だけで売っているプロダクトはいつか別の何かに駆逐される。顧客が愛着を持つようなユニークなバリューを提供する必要があります。

提供したいのはA/Bテストで売上が上がるという機能的価値だけではありません。「自分たちでマーケティングをコントロールしている実感を持てる」ということが僕らが提供したい情緒的価値です。なぜ施策が成功したのか理解できて、別の状況でも再現できるようになればマーケッター個人としての幸せに繋がるはずです。「マーケティングに関わる人のためのプラットフォームになる」というのは、そういうことなんじゃないかなと思っています。

― クライアント自身が仮説検証のサイクルを回せるようにするために、Kaizen Platformさんはどのようにサポートしているのでしょう。

カスタマーサクセス部隊が、解決したい課題はそもそも何なのかというところから一緒に考えて伴走します。ビジネスモデルやサービスデザイン、KPIを再整理しながら、課題を一緒に洗い出して、課題に優先順位をつけていきます。この一連の作業の結果をオリエンテーションシートに落として、クラウドソースするクリエイターが確認できる状態にします。

この時点で僕らのサービスに対する満足感を感じてもらえることが結構多いんです。日常の運用業務に忙殺される中で忘れていたことを改めて一緒に棚卸しして整理することで、これまでよりも正確に現状を捉えられている感覚を持つことができる。課題のマッピングもできて、事業上の問題を構造的に理解できる状態になります。

そして、実際にA/Bテストを実行した後にカスタマーサクセスチームの担当者が訪問して、クライアントと一緒に結果を分析します。このサイクルを一緒に回すと勘所がわかってくるんですよね。お客さん自身でPDCAサイクルを回せるようになると、それをベースにして色々な施策を自ら試し始めるんですよ。これがKaizen Platformの価値はなんだと認識しています。

実は、顧客満足度と改善度合いの相関は決定的という程には強く無いんです。自分たちで改善サイクルを回すことができるようになったお客さんの場合、仮に10パーセントしか改善してなくても契約を継続してくれます。一方で代理店まかせにしているクライアントの場合、何倍もコンバージョンが改善していても契約が継続しないこともあります。

高校時代に始めたWeb開発の仕事でプロダクトの世界へ

― これまでのキャリアについて教えて下さい。

ガイアックス、GREEを経てKaizen Platformに入りました。

高校生の時に独学でHTMLやPHPを覚えて、個人事業主としてWeb制作の仕事をしていました。最初の仕事は父親の紹介でしたが、それ以降は顧客からの紹介で仕事が広がっていきました。15年ぐらい前のことで、Webを使ってどうビジネスをするかという定石が全然無かった時代です。

オープンソースのCMSをベースにカスタマイズしてWebの在庫管理システムを作り、中古車販売の会社に卸すといった仕事をしていました。

― 高校生の時に始めたWeb開発の仕事が、プロダクトマネジメントに関わるきっかけになっているのでしょうか？

今になって振り返ればそうですね。ただ当時は動機がすごく不純で、普通にバイトするよりも断然お金も良いし、自分ができることがお金に変わるっていうことが単純に面白かったんですよね。

コンテンツをWebに掲載するために、同じようなHTMLを何度も書くのも馬鹿馬鹿しい。どうやったらコンテンツの数を効率的に増やせるか色々考えた末に、今で言うCMSのようなシステムを作ったんです。

これをどういう業態で使ってもらえるか考えました。多品種で流通量も多い業種で求められるような大規模システムは作れない。それなら小売りの中でも流通量が限られていて単価が高い商材を扱っているところがいいだろう、ということで、フェラーリやランボルギーニの個人仲介売買をやってる業者に、在庫管理システムとして売りに行ったんですよ。そしたらめちゃくちゃ受けました。

今考えるとプロダクトのProduct Market Fitのようなことをやっていたんですね。ユーザーインタビューやマーケットリサーチのようなことをやりながら、どんなシステムが売れるか考えていました。ビジネスや新規プロダクトの開発がどういうワークフローで進むのか一通り体験できたので、良い経験をしたんじゃないかと思っています。

プロダクトマネジメントのようなことを最初に考え始めたのはその頃ですね。何が市場で望まれていてどうやったら顧客に価値提供できるのか、どれくらい対価を払ってくれて継続利用してもらえるのか、といったことを考えるようになりました。

― その後、個人事業主やめて就職されたということでしょうか。

大学に入学したものの、Web開発の仕事が順調だったので辞めてしまったんです。そのときに「面白いベンチャーがあるよ」と友人に誘われて、自分の仕事を続けながら業務委託として手伝うことになったのが当時まだベンチャーだったガイアックスでした。

プロダクトマネジメントというよりもプロダクトマーケティング的な仕事で、どういうものをどうやれば売れるのか、といったコンサルティングをしていました。その事業が順調に成長して、自分が作った仕事を引き受ける形で社員になりました。

ガイアックスが上場したあとに退職して、しばらくまたWebの分野でコンサルティングなどの仕事を一人でやった後に、当時まだ100人ぐらいだったGREEに入りました。

GREEではソーシャルゲーム開発のプロダクトマネージメントや、横断的にプロダクトを分析をするBIチームを作って戦略立案を支援するといった仕事をしました。その後、海外戦略チームを立ち上げて担当役員とアメリカの子会社をつくり、しばらくその会社のプロダクトマネジメント部門のディレクターをやっていました。

GREEでのミッションが終わり、次は起業しようと思っていたタイミングで須藤と知り合ってKaizen Platformに入社しました。

プロダクトマネジメントの重要性を認識したGREEでの経験

― 自覚的にプロダクトマネジメントをするようになったのはいつごろでしょう？

GREEに入ってしばらくしてからですね。最初の頃は本当に若かったんで、プロダクトで世の中にどうインパクトを与えるかなんて考えたことが無かったんですよ。インターネットでお金が稼げるということを純粋に楽しんでいましたね。

GREEに入社した際には、内製ゲームの担当になりました。GREEではプロダクトマネージャーが「Webディレクター」という肩書で呼ばれていて、ロードマップを作ったり事業計画やマーケティング戦略を作ったりとプロダクトマネジメントに相当することをやっていました。

その後、国際展開戦略の担当になってアメリカに行くのですが、国内での肩書と同じように「Webディレクター」という役職を名刺に書きました。そうしたらアメリカではDirectorは取締役とか重役という意味なので、会う人にやたらと経営に関するハイコンテキストな話をされるんですよ。そんな中、たまたまそのときに日本人でGoogleやTwitterでプロダクトマネジメントをやっている人たちに会って、自分の役割はディレクターではなく「プロダクトマネージャー」と名乗るのが正しいと教えられました。

当時は向こうでもまだプロダクトマネジメントは一般的ではなかったんですが、「『プロジェクトマネジメント』と『プロダクトマーケティング』があって、両方やるのが『プロダクトマネージャー』だ。」といった話を聞いて、「ああ、なるほど自分の仕事はプロダクトマメジメントだったのか」と理解しました。帰国した際に、GREEにもプロダクトマネージャーという職責を作るべきだと提案しました。

― アメリカでは具体的にどのような経験をされたのでしょう。

当時GREEは影響力が大きかったので、GoogleやFacebookにいたような人たちが沢山集まったんです。めちゃくちゃ優秀だし、キャリアもあるし、MBAや大学でマーケティングやデジタルインダストリーや経営を学んできた人たちが多いんですよね。彼らが部下として入ってくるんですよ。

これは全然マネージできない、日本のいた時と同じやり方では通用しないと思って、とりあえず全員と毎日1on1で話すようにしたんです。そうしたら彼らからすごく色々な質問をされました。「GREEはどういうマーケットポジショニングでいくのか？」とか、「なにが価値なのか？」とか、面接の時にするような表面的な話じゃなくて、ディスカッションが始まるんですよね。

「お金があるからゲームを出したい」ではなくて、なぜやる価値があるのか明確でないとシリコンバレーでは響かない。「GREEのミッションやビジョンは何で、そこに向かうための戦略や目標は何か」という、いわゆるVMSO（Vision/Mission/Strategy/Objective）を示す必要があります。「お前にはビジョンが全然感じられない」と部下に言われて相当ショックでした。

なりたい姿や信じている価値があって、そこに行き着く道としてストラテジーがある。それをエグゼキューションするのが日々のプロダクトマネジメントなのだ、ということを強く認識しました。

振り返ると、あの頃はマネジメントについて沢山学ぶことができたなと思います。最初は皆毎日夕方の4時とか5時になると帰ってしまってたんですよ。でもミッションやビジョンをちゃんと伝えてからは、価値を実現するまでやりきろうと頑張ってくれるようになりました。いくつもアイデアが出てエグゼキューションの手数も増えて、学習のサイクルが回り始めるのを目の当たりにしました。プロダクトマネジメントの重要性を実感しましたね。

― メンバーとの対話のなかでプロダクトマネジメントを学んだということでしょうか。それとも、本を読んだり、誰かに聞く機会があったのですか？

当時はシリコンバレーでもプロダクトマネジメントはまだそれほど体系化されてなかったと思います。GoogleはこうやってるけどFacebookは全然違うやり方やっている、Twitterの場合はこうだ、など、オフィスが近かったのでカジュアルに情報交換してました。他社がどうやっているのかという実例をよく見ていました。

投資家や現地にいる有名なプロダクトマネージャーと話す機会もたくさんありました。たとえば日本人だと、GoogleからTwitterに行かれてその後現地で起業された上田学さんや、Ingressを作り、今はアジア統括本部長をやられている川島さんから、「こういう苦労がある」「こういう時はこう」といった話を伺うことができて、自分の解釈を日々の業務に持ち帰り試してみて、自分なりのやり方を作っていきました。

後編に続く（5月27日公開予定）