プロダクトマネージャーに訊く #6：スマートニュース渡部さん
― まずご自身について教えて下さい。
スマートニュースの渡部です。SmartNewsにはニュースと広告という2つのプロダクトがあります。それぞれ開発体制もサーバーもコードも全く別のプロダクトで、私は広告プロダクトの『SmartNews Ads』の責任者としてプロダクトマネジメントを行っています。
私がスマートニュースに入社したのは、2年ほど前の2014年9月です。当時のスマートニュースはこれからマネタイズをしていこうというフェーズで、私を含めて5人ほどの開発チームで広告プロダクトをゼロから作りました。現在は10人ほどのメンバーでSmartNews Adsを開発しています。
SmartNews Adsの最大の広告配信先はSmartNewsですが、その他の媒体にも広告を配信しています。
― スマートニュースに入社するまでの経歴を教えて下さい。
新卒でNTTコミュニケーションズに入社しました。もともとエンジニアとして採用されたのですが、最初の配属先は営業部門でした。営業の仕事はとても楽しかったのですが、エンジニアのキャリアを歩みたいと思い、転職することにしました。
転職先のグラファイトでは、エンジニアとして受託開発の仕事をしていました。当時グラファイトはまだ規模が小さかったこともあって、自分で営業して案件をとってくるところからが私の仕事でした。その後、ニフティに転職してエンジニア専業の仕事につきました。ニフティ時代にとても良い先輩に出会い、「良いコードとは何か」「チームで良いコードを書くにはどうすべきか」といったエンジニアとしての基礎を叩き込んでもらいました。
ニフティはエンジニアとして成長できる環境だったのですが、インターネット業界の盛り上がりをみて自分もそこで戦いたいという思いが強くなり、GREEに転職しました。
GREEには4年間在籍して、前半の2年は現場のエンジニア、後半の2年はマネジメントを経験しました。最後の1年間は事業責任者兼開発責任者として、新しいブランドのゲームスタジオを立ち上げました。新スタジオではモノづくりとビジネスづくりを両方やらせてもらい、一定の成果をあげることができました。
― スマートニュースに転職したのはどういう理由だったのでしょうか？
マネジメントポジションになると、どうしても複数のプロダクトラインを見る必要がありました。その職務の中で各プロダクトへの予算配分やP/Lのポートフォリオを組むようなことはあっても、自分でゼロからプロダクトやビジネスを作っていくという、GREE創業期の頃のような体験をしてみたいと思うようになりました。
自分でビジネスを作っていきたい、そして、どうせやるなら「私が稼がないと会社が倒産してしまう」というくらい強いプレッシャーを感じて仕事をしたい。そうしたチャレンジができる環境を探している時に出会ったのがスマートニュースでした。
― 渡部さんの役割の範囲を教えて下さい。渡部さんがプロダクトマネージャーで、他に開発マネージャーやスクラムマスター的な人がいるのでしょうか？
全て私が兼任しています。大きな会社だとプロダクトマネージャーとエンジニアリングマネージャーとスクラムマスターを別々にアサインすることが多いのかもしれませんね。SmartNews Adsはプロダクトの立ち上げフェーズだったこともあって、自分がそうした役割を全て引き受けることにしました。
広告もニュースもエンジニアリングが差別化要素になるサービスだというとこともあって、スマートニュースではエンジニア出身者がプロダクトマネージャーをやる方針にしています。私は現在進行形でエンジニアのつもりですし、エンジニアだからこそプロダクトマネージャーもエンジニアリングマネージャーも兼務できます。
― そうすると、今でもコードを書かれているのですか？
プロダクションコードは書いていません。エンジニアリングマネージャーはタスクをアサインする権限があるので、自分自身に技術的にチャレンジングなタスクをアサインしたくなります。ただマネジメント業務とエンジニア業務を兼任すると、どうしても自分がボトルネックになりがちです。
特にインターネットサービスはリリース後に運用しながら改善を繰り返して成長させていくものですし、障害が発生したときに即応できない人間はプロダクションコードを書かない方がいいのです。ですから、プロダクトマネージャーなどマネジメントロールに付いている時は、基本的にプロダクションコードを書かないようにしています。
ただ、コードを書きたいという欲求は強いですね。
― それはエンジニアとしてジレンマを感じてしまいますね。
プロダクションコードは書きませんが、プロトタイプは自分で手を動かして作ります。
最近のインターネットサービスは、カバーしなければいけない技術分野が非常に幅広い。一つのサービスが、AndroidやiOSなどのアプリからサーバーサイドやインフラ、さらには機械学習をはじめとしたデータサイエンスなど、複数の技術によって一つのサービスができあがっています。
私の立場ではそれぞれの技術についてエンジニアと対等に議論できる必要があります。そのため、最新の技術やスマホOSの新仕様にキャッチアップできるように自分でプロトタイピングして、新しい技術で未解決課題を解決できるか確認するようにしています。自分でもうまくいくか確証がないR&D的要素が強い試みの場合は、サーバーとクライアントの両方のコードを書いてみます。プロトタイプが期待どおり動くことを確認した後で、エンジニアチームで開発してサービスに取り入れます。
また、専任のアナリストがいるわけではないので、プログラムだけでなくSQLも自分で書いてデータ分析しています。
― 役割の範囲が広いですね。
プロダクトの成功確率を上げるために必要なことであれば何でもやる、というスタンスです。仕事の範囲を限定せず、良いプロダクトを作るために自分はどういう役割を担うべきか、と考えるのがプロダクトマネージャーの役割だと思っています。
「コンテンツとしての広告」で価値ある情報を届けたい
― SmartNewsというプロダクトを通じて、どのような価値を提供したいと考えていますか？
ニュースサービスとしてのSmartNewsについてはご存知だと思うので、広告プロダクトについてお話ししますね。SmartNews Adsのステークホルダーは大きく分けるとメディア、広告主、ユーザーの三者がいます。それぞれに価値提供できるプロダクトを作っていきたいと思っています。
各メディアにコンテンツを提供いただくにあたり、レベニューシェアの仕組みなども用意していますので、メディアさんに高い収益をお返しできるようにしたいです。今月や来月といった短期的な収益ではなく、長期で見た時のトータル収益ではどこにも負けない、と言えるようにしたいと考えています。
広告主に対しても当然成果でお返しする必要があります。簡単に言うと、広告に1万円投資して1万1000円の利益があがったら出稿し続けてくれますよね。広告費のROIが可視化できて、かつ高いROIを実現できる広告サービスを提供する必要があります。
そしてユーザーに対する価値提供も大切にしています。広告はユーザーから嫌われることも多々あり、特にインターネット広告を邪魔だと思う方が多いように感じます。これは広告に関わる人間として非常に悲しいことです。スマートニュース社内では『Ads as Content』と言っていますが、私たちは広告もコンテンツだと思っています。SmartNewsはユーザーに価値ある情報の発見機会を提供したい。それは広告であっても同じです。もちろん広告であることは表記しつつ、新しい発見に繋がるコンテンツとして捉えていただけるような広告を提供したいと思っています。
ハッとするほど面白くて見入ってしまうような広告クリエイティブもたくさんありますし、広告を通じて「ああこういう商品やビジネスがあるのか」と知ることが個人的にもよくあります。コンテンツとしての側面を伝えつつ、かつユーザーの操作を邪魔しない形式でどう広告を表示するのか、という点には特にこだわっています。
良いプロダクトを作る秘訣は、成功から逆算すること
― 良いプロダクトを作るための定石として意識していることがあれば教えて下さい。業界や分野を超えて、良いプロダクトを作るために共通する考え方はありますか？
一番大事なことは『成功から逆算すること』です。チームにはいつも「当たったら勝てることをやろう」と話しています。麻雀の例で説明すると、「最終局で一発逆転して1位とりたい、でもトップと1万点差がある」という時に5000点で上がっちゃダメですよね。スタートアップ企業だと切実な問題としていつまでに成功していないと事業を継続できない、という期限があります。例えば、１年後に1億円の売上が必要であれば、それを実現するために今何をしなければならないのかを考えます。
ゴールから逆算せずに、「できること」を積み重ねていってしまうと失敗します。「最終的にこういうタワーを作りたい」というゴールから逆算して計画せずに、下から積んでいくとジェンガになってくるんですね。「倒れそうだからここに積もう」「次はこっちに積もう」となって最終的には崩れてしまいます。
マクロな視点で市場を見て、どんなプレイヤーがどれくらいの事業規模で、どれくらいの売上なのかといった調査をすると、目標達成のために１年後にその市場で目指すべき事業規模やポジショニングが見えてきます。そこから逆算してどんなプロダクトが必要なのか明らかにする。これが一番大事なことだと思います。
― でも収益というのは自社にとってのゴールですよね。
もちろん自分たちが作りたいものを作っているだけではうまく行きません。「誰のどんな課題をどう解決するのか？」を明確にすることが大事で、その結果として収益が生まれます。
「広告主はなぜSmartNewsに出稿するのか」「ユーザーはなぜ他のニュースアプリではなくSmartNewsを使うのか」といったように、誰のどんな課題を解決するのか、各ステークホルダーに最終的に提供したい価値を定義することが重要です。
SmartNewsの広告事業の場合、広告配信事業者、メディア、アプリユーザーの三者がいて、さらに広告代理店や広告主がいる。短期的には各プレイヤーの利害相反が起きる場合があります。短期的には三者の利害が相反するようなケースがあっても、自分たちが最終的に提供したい価値が決まっていれば、ステークホルダーの皆さんの理解を得ながら多くの人が満足できる解に近づいていくことができます。これはBtoBでもBtoCでも同じことだと思います。
― ユーザー課題を理解するために日常的に心がけていることはありますか？
色々な人の話を聞きに行くようにしています。例えば「今度こういう機能を考えているんだけどどうだろう？」と自分のアイデアを広告のセールス担当に話すと、「最近はこういう広告商品の方が人気がある」「それならこういう見せ方に変えればどう？」といったように何らかのリアクションがあります。とにかくステークホルダーをアクティブソナーだと思ってPingを打ち、帰ってくるものを確認しながらプロダクトマーケットフィットに近づく方向を模索します。もちろんインターネット上でも情報収集はしますが、そうしたオフラインの声を集めながら、業界やプロダクトを俯瞰して見ることがとても大事だと思っています。
― そうしたアイデアをプロダクトとして実現するために、開発チームとはどのようなコミュニケーションをしていますか？
「成功から逆算する」ということと通じるのですが、「1年後にこうなっているためには、この四半期でここまで到達する必要がある」「こういう機能があればその状態に到達できる可能性が高いと思っている」というように、ゴールから逆算して今何を作るべきかを開発チームに正しく伝えるようにしています。
そのときに大事なのが「How、WhatじゃなくてWhyを書く」ということです。エンジニアはコードのコメントには「Whyを書け」と言われます。何をするか、どうやってやるかはコードに書かれており、良いコードはコメントで説明しなくてもそれは分かります。一方で「なぜこの処理をここで必要なのか」という背景情報はコードからは読み取りにくい。
同様に、プロダクトマネージャーは「なぜこの機能をつくるのか」を説明する必要があります。例えば、「売上を10％上げる必要があって、この機能は売上を5％上げる可能性がある」「その理由は、○○というお客様のニーズが増えていて市場のトレンドともマッチしている。」「だから☓☓というサービスを提供すれば対価を支払ってくれるだろう」といったロジックを整理してドキュメントにして共有します。その上で「本当にそうなのか」「仮説が間違っていないか」などエンジニア全員で納得行くまで議論します。
― 議論の過程で渡部さんがたてた仮説が変わることもありますか？
仮説は頻繁に変えます。エンジニアにも「朝令暮改を恐れないようにしよう」と言っています。「ここまで作ったのだから」とか「ここまで議論したのだから」という『サンクコストの呪縛』にとらわれてはいけません。
今日の自分は昨日の自分が知らなかった情報を得ているのですから、少し賢くなっているはずです。決断した翌日に問題に気づいたとして、その時すぐに方針を変えれば1日分しかロスで済みません。これが1週間様子を見て「やっぱりダメだった」ということになると、1週間分のロスになってしまう。だからダメだと思ったらすぐに変えるようにしています。
判断ミスをしたら減点されてしまうカルチャーの組織もあるかもしれませんね。でも私たちのようなスタートアップは、プロダクトが成果を出さなければ、会社が立ち行かなくなるかもしれない。そういう緊迫感のある環境を求めてこの会社に集まっています。より良いプロダクトを作るためであれば、方針を変えることに納得してくれます。
ただ、自分の判断ミスについては素直に謝ります。昨日の自分がベストな答えを出せなかったのは事実ですから。もちろん失敗続きだと「また変えるのか、この前も途中で変えたじゃないか」と信頼を失ってしまいますから、成功確率をあげていく必要はあります。
プロダクトでビジネスを成功させることでエンジニアを幸福にしたい
― 渡部さんがマネジメントの重要性を意識するようになったきっかけは？
GREEでマネジメントを経験したことが大きな転機になりました。
昔は「技術で食っていくんだ」という強い拘りがあり、頑張って技術を磨いていました。「技術で突き抜けていくのが一番格好いいんだ」と思っていたのです。そんな中、GREE時代にアメリカに赴任してグローバルなゲームプラットフォームの開発に携わった際に、向こうのエンジニアと一緒に机並べて働いてみて大きな衝撃を受けたんです。
日本にいた時はシリコンバレーに対して漠然とした憧れを持っていて、「アメリカのエンジニアはきっと相当レベルが高いんだろう」と思っていたんですが、私の目からみるとあまり大きな差がない。日本にもシリコンバレーのエンジニアより優秀な人材がたくさんいるんだということを再発見して、「あれ？」とちょっと拍子抜けしました。
ただ、プロダクトがリリースされた後に商売がうまく回る確率はアメリカのチームのほうが高いように見えました。これは何なんだろう、と不思議でした。アメリカ人の同僚や友人でマネジメントに関わる人達と話してみると、エンジニアとしての能力は負けていなくてもマネジメントのスキルがすごく高い人がいることがわかりました。彼らと話すなかで、「一部の優秀なエンジニアが頑張れば、良いプロダクトを作れる」と考えていた私も、組織として成果を出すにマネジメントが重要であることに気づきました。
― 技術力以外の要素の重要性を実感したのですね。
はい。GREEで痛感したことが2つあります。一つは、エンジニアリングによるアウトプットで商業的に成功しなければ、関わったエンジニアはハッピーにならない、ということです。頑張って作ったプロダクトでも、事業としてうまく行かなければ努力は評価されないし、悔しい思いをすることになる。エンジニアリングやプロダクト・アウトで勝負するのは、事業としてはオプションの一つでしかありません。プロダクトで成功できなければエンジニアを取り巻く環境は悪化していきます。
もう一つは、エンジニアが商売を作れないとエンジニア組織の代弁者としてエンジニアの主張を通すことはできない、ということです。インターネット業界はダイナミックですごく面白い業界です。そのインターネット業界を支えるエンジニアをもっとハッピーにしたい。でも「エンジニアがより良いものを作れる環境にしよう」と主張しても「それでどれだけ売上があがるの？」という問いに答えられないと会社を動かすことはできません。
― プロダクトによるビジネスの成功とエンジニアの幸せは直結しているということですね。
そうです。プロダクトによってビジネスを成功させた体験の中でこそ、エンジニアは成長できると思っています。ですから一緒に働くエンジニアのためにもプロダクトを絶対に成功させたい。
私のチームのエンジニアは皆んな優秀ですから、フリーランス・エンジニアとして興味を持った案件だけを選んで稼ぐこともできるのです。だからこそ、個人で仕事をするよりも成長に繋がる環境を提供して市場価値を高められるようにしないと、彼らにとって私の存在価値は無いと思っています。
エンジニアのキャリアとしてのプロダクトマネージャー
― 渡部さんは何度かの転職を経て、大きくキャリアが変遷して行ってますね。
そうですね。エンジニア出身のプロダクトマネージャーとして、私がエンジニアの皆さんに伝えたい事は「積極的に次のキャリアを考えてみませんか？」ということです。私がエンジニアを始めた頃は、Webの申込フォームを作る仕事でお金を稼げていたんですが、そういう仕事ってもう存在しないですよね。エンジニアが生き残っていくには、専門的で高度な技術を突き詰めていくか、事業会社の中で事業貢献に繋がるアウトプットが出せるか、どちらかの方向で成長し続けるしかないと思っています。
事業貢献志向のエンジニアの方は、プロダクトマネージャーを目指してみてはどうでしょうか。私は今でも本職はエンジニアのつもりですし、自分の一番得意な分野は技術マネジメントだと思っています。得意領域でさらに成果を出すためにプロダクトマネージャーや事業責任者をやっています。
― 渡部さんご自身はプロダクトマネジメントをどう学ばれたのですか？
プロダクトマネジメントはまだ体系的に整理された分野ではないので、実際のプロダクト開発のプロセスの中で身に着けていきました。GREEで幸運だったのは、エンジニアがプロダクトを考える文化だったことです。エンジニアは企画されたものを作れば良いというわけではなく、どんなゲームがユーザーに受けるのか考えながらプロダクトを開発していました。尊敬できる優秀なゲームデザイナーと議論しながらプロダクトを開発していたので、そうした過程でプロダクトマネジメントについて色々と学ぶことができました。
また事業責任者として企画をレビューするために、競合プロダクトについて相当研究しました。GREEのプロダクトはゲームでしたから、有名タイトルは一通り徹底的にプレーしました。ユーザー視点でプレーしつつ、作り手の視点でそのゲームの戦略や技術的に優れている点を分析するのです。
新規プロダクトは不確実性が高く、どれが当たるかはわかりません。ただ、企画の評価や競合の研究を繰り返していると、「こういう方向性は失敗する」とか「この企画は絶対うまくいかない」といった避けるべきパターンは見えてくるようになります。
― プロダクトマネージャーにはそうしたパターンを見抜くためのセンスが求められますね。
私は「センスとは磨くものだ」と思っています。ゲームであれば上位タイトルを全てプレイする、メディアサービスであれば良いコンテンツに触れ続ける。こうしたことを続けていく中で、センスは磨かれていきます。業界が変わればユーザーの要求も変わるので以前と同じパターンは適用できませんが、新たなパターンを勉強すればいいのです。
― エンジニアのなかでもプロダクトマネージャーに向いている人と向いていない人はいるのでしょうか？
できない人はいないと思いますが、できないと思い込んでいる人は多いかもしれませんね。
エンジニアは知識を積み重ねていくことでスキルを向上させることができます。ある程度は努力に比例した見返りがある。一方で、知識量ではなくクリエイティビティで勝負しなければいけない分野になると「自分にできるだろうか」「自分にはセンスがないんじゃないか」と不安に思うエンジニアも多いんじゃないかと思います。ただ先ほども言いましたがセンスは磨けばいい。
エンジニアとして難しい技術を体得するための頭脳があって努力ができる人であれば、プロダクトマネジメントも当然できると思っています。もちろん、その人が最終的にどういう立ち位置で仕事をしたいのか、という価値観によるところはあります。
― 渡部さんのアメリカでの経験のように、価値観が変わるタイミングがあるのかもしれませんね。
エンジニアリングのアウトプットでビジネスに貢献することが、事業会社におけるエンジニアの存在価値です。ただ、エンジニアとしての実力が一定以上になると、1年後に倍のエンジニアリング力を身につけるというのは現実的に難しくなってきます。そうした時、上位のエンジニアになればなるほど、エンジニアリングの力を最大限活かして良いプロダクトを作るにはどうすればいいのか、という発想をするようになる。より事業に貢献するにはどうすればいいのか、と考えるようになります。そうした人にはプロダクトマネージャーを次のキャリアの選択肢として考えてみてもらいたいですね。
ただ、エンジニア出身のプロダクトマネージャーは、実装方法にばかり意識が向いてしまいがち、という弱点もあります。だから私は、どういうフィーチャーを作るべきかをて考える際には、逆に一切技術的な実現方法を考えないようにしています。さもないと自分の技術の幅がプロダクトの幅になってしまう。
とはいえ「技術的にはこんな事もできる」という知識の積み重ねが新しいサービスのアイデアを生むことはあるので、技術に関する勉強はし続けるべきです。プロダクトマネージャーはゼネラリストであることが求められますが、自分の強みを磨きスペシャリティを持ち続けることも重要です。
― これからプロダクトマネジメントに関わる人におすすめの本があれば教えて下さい。
マネジメントに関するお勧めの本を聞かれた時に紹介するのが、『プロフェッショナルマネージャー』という本です。今日僕が話したことは、だいたいこの本に書いてあります。
プロダクトを考える上で勉強になったのが『ライト、ついてますか―問題発見の人間学』という本です。私の師匠であるGREE CTOの藤本さんがお勧めされていたので読んだのですが、とても良い本です。同じ現象でも見る角度によって異なる解釈ができます。複数の視点で問題を理解することの重要性が分かる本です。
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (190件) を見る
― 最後に告知などがありましたらお願いします
当社では技術を突き詰めたいエンジニアも事業を作りたいエンジニアも募集中です。また、エンジニアとして実績を積んだ後でプロダクトマネージャーになりたい、という方も大歓迎です。
私のポジションを奪ってくれるような人が来てくれたら頼もしいですね。私は「こいつには敵わないかもしれない」と思う相手がいると闘志がわくタイプです。自分のポジションを脅かすような優秀な人が来てくれると、さらに仕事が楽しくなるだろうなと思っています。
― ありがとうございました
2016年7月号：注目記事まとめ
プロダクトマネジメントに関係する記事で、7月に話題になった記事、気になった記事をピックアップしてご紹介。
コンセプト・メイキング
↑ クリエイティブ・ディレクションのIdeationプロセスを分解して解説。こうあるべきという哲学や情熱がスタート地点になるわけですね。
要件定義
↑ 開発要件のフォーマット例。開発の背景やゴールを最小限の工数で適切に伝えられるように工夫されたフォーマットです。
チーム開発、組織
↑ 開発プロジェクトのマネジメントを外部に依託することでエンジニアがコードを書くことに集中できるようにした、という事例。この発想は面白いですね。同じ発想で考えると、プロダクトマネジメントを受託するフリーのプロダクトマネージャーというのも需要があるかもしれませんね。
↑ チケットキャンプのリニューアルをケースとしたデザイナー主導のチーム開発について。ある意味、ひとつ前のスライドにあったようなマネジメントの外部依託の事例のようにも見えます。
↑ こちらもひとつ前のスライドと共通するものが多く、合わせて見ておきたいスライドです。
↑ デザイナー主導のチーム開発からスクラムまで色々なスライドが紹介されています。どれも一見の価値あり。
↑ 職能別組織にするのか、事業別組織にするのか。これはデザイナー以外のエンジニアやPMの組織にも共通する話ですね。
PMの役割
▼ pmjp#4に出席して分かったPMとPMMの違い – aomeganeビジョン | 五反田で働くプロダクトマネージャーのブログ
↑ プロダクトマネジメント担当とプロダクトマーケティング担当は兼任すべきか、という問題。これは担当する人の能力次第ではないかと思う。プロダクトマネジメントのExecutionとプロダクトマーケティングのExecutionを同時に担当するのは結構大変なんじゃないかという気がしています。
↑ PMはSQLを使えるようにすべし、というのは私も何度か言及していますが、その理由が明確に示されています。
SQLを覚えて仮説設定し分析することは、エンジニアリングのバックグラウンドのないPMが計算論的思考を身につけるきっかけになるのではないかと個人的には思っています。
ところで記事中で紹介されているre:dashは本当に便利。
成長企業が知っている人材採用の秘密
ウィルス進化論という学説がある。ウィルスの遺伝子が感染した宿主の遺伝子に逆転写され、それが生物の非連続な進化をもたらす、というものだ。一般的に認められた学説ではないが実に興味深い。
ウィルス進化説とは異なる話だが、生物の細胞内のミトコンドリアは、原始真核生物が細胞内に取り込んだ細菌だといわれている。ミトコンドリアは酸素や糖をエネルギーに変える。太古の生命はミトコンドリアの取り込みによって、大きなエネルギーを獲得しより活発な運動が可能になった。
急成長するネット企業に2年と少し在籍して、強く意識するようになった事がある。それは「成長する企業は、外部から優秀な人材を積極的に採用し、新たな組織のDNAとして取り込みながら進化する」ということだ。まさにウィルス進化説やミトコンドリア取り込みと同様である。
ただ、多くの企業はその事実に気がついていない。採用とは、たまたま求人に応募してきた求職者を企業が「選考」するプロセスだと考えている。
採用とは自社に関心を持っていない、もしくは存在すら認知していない優秀人材を発見し、自社への共感を獲得していくプロセスに他ならない。もちろん選考が不要なわけではない。ただ、自社の発展に貢献する人材であるとひとたび見極めたならば、働く者にとっての自社の価値（Employee Value Proposition）をアピールし、意向と共感の獲得に全力を注がなければならない。
採用を担う人事の仕事は、マーケティング業であり、セールス業であり、接客業なのだ。それに気づいていない企業は、人材獲得競争の勝者になることはできない。
ネット企業では、カスタマージャーニーマップを作成して自社のサービスに対してユーザーがどんな体験をしているのかトレースし、サービスの問題発見と改善に役立てる。昔、初めてジャーニーマップを作った時、あまりの負の体験の多さ、離脱ポイントの多さに愕然としたものだ。
「良い人材が集まらない」と感じている経営者の方は、求職者の視点で「採用プロセスのカスタマージャーニーマップ」を作成し、優秀な人材を獲得できるプロセスになっているかチェックしてみてはどうだろうか。初めてサービスのジャーニーマップを作った私と同様に、負の体験の多さに愕然とするかもしれない。
人材採用に対する考え方を変えた企業が勝つ。もしかしたらそれは経営者の能力や事業モデルよりも、企業にとって重要な要素かもしれない。
ウォー・フォー・タレント ― 人材育成競争 (Harvard Business School Press)
- 作者: エド・マイケルズ,ヘレン・ハンドフィールド=ジョーンズ,ベス・アクセルロッド,マッキンゼー・アンド・カンパニー,渡会圭子
- 出版社/メーカー: 翔泳社
- 発売日: 2002/05/18
- メディア: 単行本
- クリック: 6回
- この商品を含むブログ (5件) を見る
プロダクトマネージャー オフ会#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としてチームでのプロダクト開発をすごく重要視しているのですが、スクラムで言うところのプロダクトオーナーとして自分がどう立ち回るべきか、といったことを意識しながらこの本を読んでいます。
スクラム 仕事が４倍速くなる“世界標準”のチーム戦術 (早川書房)
- 作者: ジェフサザーランド
- 出版社/メーカー: 早川書房
- 発売日: 2015/06/30
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
この本ではマルチタスクの無駄が辛辣に批判されているのですが、普段マルチタスクになりがちな自分を戒めるためにも繰り返し読んでいます。
― 最後に読者に伝えたい事はありますか？
ペパボではプロダクトマネージャーやプロダクト開発のディレクションができる人を随時募集してます。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回くらいクリックし続けないと先頭に持ってこれない」「一旦売り切れてしまったオーダー作品は一番後ろに持ってきたい」という声を実際に聞くことができました。
作品を自由に並び替えたいのではなく、先頭や一番後ろに移動させたいだけなのにすごい数のクリック操作を強いられることがストレスになっていることがわかり、適正なコストで必要十分な機能改善を行うことができました。
― プロダクトの改善はユーザーの声を元にすることが多いんでしょうか？
長期的なビジョンの実現や半期ごとの方針に沿った開発もあれば、短期的な改善効果を期待する開発もあります。新機能開発も既存機能の改善も、最終的にはサービスの成長にどうつながるかという観点で企画します。
▼ 後編に続く
