you88blog

とあるPMの開発日記

Menu Close

PdMになるならどんな会社が良いんだろうか?

プロダクトマネージャーとしてキャリアを積みたいと思ったとき、会社選びは本当に重要だと思う。僕は

  • 起業
  • pixiv
  • nanamusic

とキャリアをすすめてきた。それぞれ実は結構違っていて

  • 起業:0→1フェーズ
  • pixiv:100→1000フェーズの会社の1事業、1周辺サービス
  • nanamusic:50→100フェーズの会社のメインサービスを幅広く

という感じ。

プロダクトマネージャーというのは面白い職種で会社やプロダクトのフェーズや会社の定義の仕方で全く違う職種になるし、必要なスキルも変わってくる。まだ言葉の定義もあいまいで会社によって違うし、組織の状態によって必要スキルが変わるからだ。プロダクトマネージャーとしてキャリアを積みたい場合、自分はどういう方向のプロダクトマネジャーになりたいかとその方向性を目指す場合、どの会社に行くべきかを考えたほうが良いと思う。

そもそもプロダクトマネージャーの定義とは?

プロダクトマネージャーという仕事は結構会社によって定義が違うと思う。根本的にはプロダクトをうまく運営するためになんでもする人なんだがこのうまく運営するためにやることが幅広い。が、おそらく下記の2つがメジャーな役割なんじゃないか?

  • 実行:プロダクト開発のディレクション
  • 方針、戦略:プロダクトの成長のための戦略、施策立案

多くのプロダクトマネージャーが前者のみになっているきはする。また後者をやっても細かいPDCAになってしまっている。ビジネス戦略をもって大風呂敷な戦略を描けるプロダクトマネージャーというのは結構少ないように感じる。ここまでくると事業部長という呼ばれ方をしているというのもあるが。

フェーズごとに必要なスキルはCEO、COOとの役割分担で変わる

と、プロダクトマネージャーの定義をしたがあまりにあいまいである。特にフェーズによって役割は変わってくる。というのもフェーズ、会社の規模によって特に戦略立案、施策立案は社長(CEO)、COOがやる場合もあるからだ。その場合、ディレクションがメインの業務になってくる。フェーズによって分けると

  • 起業フェーズ:このフェーズでは社長がむしろ戦略立案、施策立案をすべき。会社とプロダクトがほぼイコールの時期だからだ。逆にプロダクトの戦略立案任せてたら社長のやることなくなるwこの時期の場合、ディレクション業務にプロダクトマネージャーは終始することになる。むしろディレクター、もしくはプロジェクトマネジャーと呼ばれる方が適切かもしれない。
  • プロダクトが10→100フェーズで会社が30人以下。ワンプロダクトの会社:この時期はもっとも役割分担が会社によって変わる。ワンプロダクトと言っても戦線が広がり、2−3チームに分かれる場合もある、その際に社長がすべてを見るのは難しくなりチーム単位で部分的に方針、戦略を立案する人間ができる場合がある。また社長にない専門領域をカバーする場合もある。例えば広告のマネタイズを担当するなど。CEOが現場の業務から離れ、プロダクトマネージャーがCOO的に現場を回す場合もある。転職する際にCEO、COOとどういう役割分担で仕事をするか話したほうが良いフェーズ。
  • 100→1000以上で複数のプロダクトが動いている会社規模も100人以上:新規や周辺サービスで大胆に権限を与えられる可能性があるので起業したいテーマがないけど自分で事業を回したい、起こしたい人にはいいフェーズな気がする。

それぞれどの会社を選ぶべきか?

もしプロダクトの戦略を練りたい、施策立案をしたいと言った場合、起業フェーズにいっても最終的な主導権はほぼ確実に社長にある。というよりない会社は社長を解任したほうが良いと思う。そのため戦略づくりをしたいなら最も確実なのは複数プロダクトを展開しており、プロダクトマネージャーがプロダクトを任されている会社にいくパターンだと思う。いわゆる事業部長のような立ち位置である。

自分の経験だとピクシブは複数サービスを展開しており、各プロダクトマネージャーにまあまあ権限があった。ここで0→1ではない、10→100を学べた。起業時はそこまで事業を大きくできなかったのでここでの10→100は初めての経験だったし、0→1とは全く違うスキルが必要なことがわかった。

逆にメインのサービスに入っていたら社長に主導権があり、大きな戦略に頭を巡らせる機会を持てたか怪しい。ここでプロダクト全体の視野を養い、その後でnanamusicにてメインのサービスを担当するという順番はある程度意図したキャリア設計だったけど本当に良かったと思う。

ディレクションも重要スキル

ディレクション面を極めたいと言ったときはまた違ってくる。

ちょっと話が変わるがディレクションスキルというのは軽く見られがちなスキルである。単純に伝言、スケジュール管理と見られているがプロダクトにとって何が必要かの理解度も求められるし、開発を円滑に進めるという意味でいうと突き詰めると人事マネジメントにも関わってくる。またどの順番で意思決定して物事を進めるかというのを複数人束ねながら行わなければいけない。例えばあの人スキル的にはもうちょい時間かかりそうだなとかどこから仕様を決めていったらいいか、クライアントサイドからかだとしたらあの人に先に相談しようとか。

完全ウォーターフォールで仕様を決めてから開発する場合、たしかにスケジュール管理は単純になりがちだが、現代の自社サービスの開発では仕様は作りながら柔軟に変わっていく。なにを先にすすめ、どう決定していくかもディレクションに含まれるようになったのとそれをどう周知するかも入ってくるため複雑怪奇になっている。

正直、難しい上に意識的にここを伸ばそうという意識の人が少ないため人材が少ない。今僕自身、ディレクションをお願いしたいと思う人材は社内外含めても限られている。

非エンジニアPMが開発フローを四苦八苦して考えてみた

最近開発フローを一新する機会があり、非エンジニアプロダクトマネージャーながら四苦八苦していろいろ考え、開発フローを作り直していた。2−3ヶ月たち、一通り回ってきたタイミングなのと次のフェーズに移る段階だったので備忘録がてらまとめてみた。ちなみに次どうしようかという課題点もあるし、正直完全理想形態です!みたいな感じでもない。あと僕は非エンジニアで開発組織を作った経験のある人と接点が少なく、こここうしたほうがいいよなど指摘があったらぜひ受けたいし、なんならランチしてもらいたいので気さくな方はご連絡いただけると幸いです。(という募集ポストでもある)

状況

もともと開発責任者(VPoE)を頂点に書くプラットフォームごとにリーダーをたてていた。各チームでスクラムを組み、それを横串で開発責任者中心に各チームの定例を毎週やるという形。すごくオーソドックスかなと思う。人数もまあまあいてすべてを1チームにするには大きくてかといって分けるのもなあみたいな微妙な規模。

この状態で回していたが急遽開発責任者、リーダーがほぼ全員抜けるという自体になり、開発に一番近いという理由で非エンジニアPMが開発フローについて考えることになった。ちなみにコードはある程度書けて趣味でサービスを作れるぐらいではあったが実務でコードを書いた経験はほぼなく、チーム開発もエンジニアとしては参加したことがなかった。20人近くのチーム開発もそこまで経験はなかった。技術力も趣味程度なので大したことはない。

技術力、エンジニア経験がない人間がどうやって開発組織を考えればいいのかから考えた。

なぜそもそもエンジニア経験があったほうがいいか?

やってみて開発を統括する人間はエンジニア経験があったほうがいいなとは思った。ただないとできないというわけでもなかった。しかし、他の開発統括と同じやり方はできない。まず技術的にそれがいけそうなのかをぱっと思いつけば誰にふればいいのかわかるし早い。これは趣味でコード書いてるから自分はまあまあわかる方な気がするが基本非エンジニアだとむずい気がする。

またエンジニア文化の理解も差が出ると思う。めちゃくちゃ感覚的だがそれがイケてるかどうかの感覚はエンジニア文化独特のものがある気がしていてその感覚があうかは重要。そこはゆるくやりたいよね、そこはちゃんと決めようよ、そのフローダサいなどなど。まあでも一番はエンジニアを特別視しすぎないところかもしれない。エンジニアじゃない人間からするとエンジニアがそれ技術的に難しいですとかいうのがようわからんとかなんかなにを話したらいいかわからないなど気が引けちゃってる人もいるんじゃないかなと思う。よくエンジニアは〜みたいな職種で人をかたる人がいるがエンジニアという名前の人はいないわけで変に壁を作らなくなるというのがエンジニア経験あることの一番のメリットな気がする。それは個人で一応コード書いているのと文化尊重をちゃんと意識するようにしている。

受託と自社開発の組織としての違いはなにか?

開発組織を考える上で受託と自社開発で大きく違うと思う。(別にどっちがいいとか悪いとかではないです。もちろん)受託は基本クライアントが作る仕様をどれだけスピードと正確さをもって実現するかが重要であり開発途中で仕様が変わることを前提にしなくていい。(ちなみにここでの受託はクライアントが仕様をきめて渡すウォーターフォールを前提にしているが最近月額制とかも出ているし例外ももちろんあると思います)

対して自社開発は作りながら仕様を検討していきたい。やはり実物を触った際に違うなと思ったら変えたい。また内製でエンジニアを抱える理由としてはエンジニアやデザイナーなど実装者がサービスの文脈を理解して細部の調整をできるところにある。例えば仕様策定者が思いつかない裏のデータの持ち方をエンジニアが文脈を理解し、のちのちに備えDB設計しておくこともできるし、作ってみて動きに違和感を感じてプロダクトマネージャーにアラートを上げたりできる。この実装者の文脈理解が自社開発の開発組織において大きな資産だと思う。

対策

できないことをリストアップしてみた

開発統括者の役割は会社によって結構違うと思う。やる可能性があるものに関して言うと

1.人的マネージメント:人の配置を考える。採用も含め
2.開発フローのマネージメント
3.ディレクション:チームをまたいだ進捗を管理する
4.アーキテクトの設計、仕様策定

3と4は密接に関係しており、設計、仕様策定するものがそのまま工数を計算し、ディレクションしたほうがいい。ここは非エンジニアには無理なので後述するプロジェクトマネージャーを案件ごとにたて権限を移譲した。案件のリリース単位ではディレクションするがサーバーが〇〇のAPIをいつまでに作ってなどの詳細なディレクションはプロジェクトマネージャーに一任した。

プロジェクトマネージャーにほぼほぼ権限を渡す

このプロジェクトマネージャーという制度が今回非エンジニアが開発フローを考えるにあたって大事なところだと思っていて今まで一人が見ていたものを案件ごとに分散させた形になる。あくまで僕は1と2に終始し、3と4は案件ごとに分散させることで開発統括の役割を組織で補おうとした。できないことに関しては完全に移譲し、1個人でカバーするのではなく複数人でカバーするというのが大きな方針でもあった。

チームごとの管理もそうで各プラットフォームの定例、スクラムも各チームに移譲した。

全体MTGの復活

とはいえプロジェクトリーダーもそれ専任ではないのでチームをまたいだコミュニケーションは漏れる可能性もある。そこで全員を集めたスクラムMTGを2週ごとにするのを復活させた。ここでissue単位で進捗を共有し、ぬけもれと他チームとの連携を行った。意外と共有したらこれはほかチームに影響あるなとかサーバーで実装したら大変そうだったけどクライアントに処理持ってったら楽かもなどもここで拾う。

技術的な可否の検討

これはまだ悩ましいところで正直非エンジニアPMに技術検討は難しい。ここは文殊の知恵じゃないがエンジニア全員の知恵をどう出させるかにかかっており、slackでのコミュニケーションをどう活発化させるかにかかっていると思っていてチャンネルの目的など運用を試行錯誤しているが完全な解は見つかっていないような気がする。本当はめちゃくちゃ技術力のある人間がCTOとかの役職でバンバン決めれるといいのかもだけどただアプリ開発は複数プラットフォーム絡むのでどんな案件も全プラットフォーム網羅して技術可否を考えたりとか設計できる人間っていない気がするし、どちらにせよ文殊の知恵は必要な気がする。

エンジニアとのコミュニケーション方法は実物をもって

実装内容について議論することは非エンジニアPMには難しいので実装物をもとにコミュニケーションを取れる組織を目指した。具体的には毎週実装物を一緒に触る会を設けてそこで途中でもいいので触りながら実物を媒介にコミュニケーションする。それが一番確実だし、細部の認識を合わせるのにも役立っている。

わからんことは一任して疑わないようにする

今回1人でできないことを組織でカバーする方針でいったので複数人ですすめ一個人で管理、観測できなところも正直出てくる。その際気をつけないといけないのがわからんのになんか不安だから大丈夫か〜?って聞くことだと思っている。課題感を相談する際に具体的に話せて対策を出せない場合、ただ不信感を伝えるだけでなにも意味ない。具体的に話せ、対策まで持っていけないならもう任せてからは疑ってはいけないと思う。正直不安になることもあるがその不安感は不信感ともとれるのでそれを組織を束ねる人間が出すとただ共有コストだけあがって話が進まない。大丈夫か〜と聞かれたらエンジニアもある程度ちゃんと説明せざる負えないが他職種に実装内容を伝えるのは高コスト。任せたら疑わず、助けを求められたときに対応できるような組織にすることにリソースを割く。

人材配置において経験、知識の重要度はどんどん低くなる

今の会社に入り、大きく組織で変えていったのは広告運用(媒体として)やSEOのインハウス化だと思う。ツール郡が発達し、運用コストが低くなる上で社内に運用をできるだけ巻取り、ノウハウの蓄積をはかった。もちろんすべてをインハウスするわけではなく外部コンサルも必要になる場合がある。イメージとしては外部コンサルから専門知識、外部での事例を収集し、それを独自に活用するためにインハウスで担当者を用意するという形。外部コンサルをいくらいい人に頼んでもそれを独自化できないと意味がない。両方必要なのである。

ちょい話がそれたけど上記の体制を構築するため社内の人材配置を変えてきた。ちなみにもともと広告運用やSEOの経験者が社内にいなかったため0から知識をつけてもらった。よく他社の人にその話をするとなぜ経験者を採用しなかったのかなど未経験者に1からやってもらうことに関して驚く声が多い。こういう話を聞くと人材配置において世の中では経験が重要視されすぎている気がする。正直個人的には経験とか2-3ヶ月もすれば身につくし、もっと重要な事があると思っているのでさほど気にしていない。

適正の職種は経験ではなく人間性で決まる

適正職種は

人間性との相性×経験値×モチベ

で決まると考えています。人間性との相性というのは例えば分析計の職種ではちゃんと客観的にものを考えられるかなどです。人間にはそれぞれ思考の癖や仕事の仕方などがあります。その人間性と職種の相性が悪いと成長できない。しかし、この人間性は正直先天的なものが大きく、あとから変えるのは相当難しい。対して経験値は基本後天的に身につけられるものです。ある意味どうとでもなる。またモチベも目標のもたせ方などでコントロール可能な分野です。

経験の差は後天的にどうとでもできる

採用のときにもいえるけど世間では経験を重要視し過ぎな気がする。前述したように経験は後天的にどうとでもできるが人間性はどうしようもない。確かに経験値があり、なおかつある程度結果も出している人は人間性の相性も証明できている場合が多いのでうまくいく可能性は高くなる。ただやはり結果にはいろいろな要因が重なるので人間性の適性の見極めはどちらにしろ必要だと思う。

相対的に専門知識の経験値は価値が低くなり、学習能力の価値が高まっている

また、昔より知識の価値は下がっている。と思う。特にIT業界では変化が目まぐるしいので3ヶ月前の知識がもういらなくなったりする。専門知識自体の賞味期限が短くなっており、本質的なもの以外は相対的に価値が低くなっている。

リニューアルの成果と学んだこと

担当するサービスでwebのリニューアルを行いました。結果としてこのsite経由のDLが1.6倍になったり滞在時間1.2倍になったりなかなかの成果がでました。仕事をしているとほとんどが失敗で成功はわずかしか体験できない。失敗はよく反省という形で振り返るが成功は浮かれてしまい振り返りなかなかできないのでちょい振り返ってみる。

やったこと、戦略

今回webのリニューアルをした理由はCGMのコンテンツを利用してオーガニック集客を強化するため。web全盛期は特にそうだが多くのCGMはCGM+SEOで伸びてきた。

  • コンテンツをユーザーに投稿してもらう
  • そのコンテンツが検索エンジン上の入口になる
  • 更に多くのユーザーがコンテンツを投稿する

のループが作れるかがでかかった。cookpadやpixivもそれ。(多分)現在はSNSにシェアされるかなども大きい。webをDLの集客装置として定義しそれに特化した設計にするというのが今回の戦略だった。nuxtによるSPA化もでかいがページの構成をDLにとにかくつなげるようにしており、特にコンテンツを媒介にサービスを知ってもらい、DLさせるというのに注力している。その結果コンテンツページの回遊が130%になり、DLは160%になった。

いいチームからしか良い成果は生まれない

昔、仕事の成功は時の運なので良いチームだからといって必ずいい成果が出るとは限らない。ただ良い成果が出るのはいつだって良いチームからと言われたことがあった。今回も良いチームだからこの結果がでたんだがチーム組成から行っており、かなり意識的にチームを作った。うまくいったなと思ったところをまとめとく。

チーム運営方針

チームの運営方針は前に投稿した下記の方針に則って行った。

https://you88.space/240

  • 大きな方針、施策に関してはPMが決める
  • 専門的、中規模以下の施策は各担当者が決める
  • 施策をそれぞれ立てやすい人間に立案させ、その領域を具体的に割り振った

上記をやることで各人が自律的かつ深掘りして進められたのが細かい部分のクオリティにつながった。

些末なことにとらわれない

また今回半年以上のプロジェクトになるのだがそんだけ長い&リソースをぶっこむと問題も起こるし、社内からも本当に大丈夫?という空気が流れる。ちょっとした問題でもそれ見たことか突っ込まれる場合もある。そういうとき本質的な問題かどうかを見極めて些末なことであればビビって方針を変えないというのがチームの練度を継続的に上げる上では大切。

プロマネがどう長期戦略を成すか。経営陣とのコミュニケーションについて

とは言っても半年以上、数人のリソースを割くのは一介のサラリーマンがどんだけ心折れなくても経営陣が心折れれば途中で頓挫する。この決断はPMの僕よりむしろ経営陣のほうがすごいかもしれない。僕が今の会社に入ったのは自分を信頼してくれそうというのもでかい。

僕は長期的戦略をたてるのが好きで半年から数年スパンの戦略をたてる。ただそれを立ててもそこまで待ってくれるには経営陣が相当そのPMを信頼していないとできない。この信頼してくれそうが的中したのも今回の成果に大きく影響を与えている。

プロマネの方も自分がどのスパンで最も成果を出しやすいか。もし長期型の場合、経営陣との信頼が重要なので転職などの際はよく見たほうが良いと思う。あと時々PMを小CEOなんて言ったりするが個人的には経営陣と信頼しあって長期スパンの戦略を練れない短期PDCAしか回せないPMは小CEOではないよねと思っている。

ニーズはどんどん満たされて娯楽とサブスクとブランドもので溢れ出す

最近読んだ本で面白かった本が

https://www.amazon.co.jp/%E3%80%8C%E6%AC%B2%E3%81%97%E3%81%84%E3%80%8D%E3%81%AE%E6%9C%AC%E8%B3%AA%EF%BD%9E%E4%BA%BA%E3%82%92%E5%8B%95%E3%81%8B%E3%81%99%E9%9A%A0%E3%82%8C%E3%81%9F%E5%BF%83%E7%90%86%E3%80%8C%E3%82%A4%E3%83%B3%E3%82%B5%E3%82%A4%E3%83%88%E3%80%8D%E3%81%AE%E8%A6%8B%E3%81%A4%E3%81%91%E6%96%B9%EF%BD%9E-%E5%A4%A7%E6%9D%BE%E5%AD%9D%E5%BC%98-ebook/dp/B077V785PW/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=%E3%82%A4%E3%83%B3%E3%82%B5%E3%82%A4%E3%83%88&qid=1554593543&s=gateway&sr=8-2

この本でいろいろ面白かったけど特に「昔は課題が明確でどれも満たされていなかったのでひたすら明確なニーズを叶えていればよかったが今はほとんど解決されているのでユーザーのインサイトを見ないといけない」(引用ではなく意訳)という部分があって本当にそうだなと思った。多分4-5年前に比べて多くのものがニーズを満たしつつあるような気がする。例えばテレビで5年前より明確に良くなっている部分ってどこだろう?解像度とか良くなっているだろうけど圧倒的に変わっているところってない気がする。僕は冷蔵庫を古く安いのをもう10年使っているんだが壊れなければ別にこのままでいいなあと思っている。

多くのものが便利になっていく中で人のニーズの限界まで良くなってしまったものが世の中には多い。また人はめちゃくちゃそれで困っていない限り新しく探そうともしないので少しいいのが出てもなかなか普及することはない気がする。不便を解決する解決型の商品で多くのものは今コモディティ化されて価格競争になってしまっている気がする。

日本という貧乏でも幸せな国

吉野家があの価格であの味を提供している国では色んな良くてしかもいいものが溢れている。僕は最近給料が変わっても生活レベルが変わらなくなってきた。別にめちゃくちゃ高いものを食べたいと思わないし、高級ブランドを身に着けたいとも思わないので節制しようと思わなくてもお金を使い切れなくなってきた。(別に特段給与が高いわけではない。多くの人がそうなっていると思う。)もちろん貯金が増えるのはありがたいがこれだけお金あれば十分という金額が下がってきているんじゃないかなと思う。

スマホアプリによりものを作るツールのコスト減やバーチャルで楽しめるものが増えることでの娯楽のコスト減も大きい。

国というくくりだとやっぱり新興国のほうが広がりがでかい

先進国においては上記のようにすでにニーズが満たされつつある分野が多い。新興国はまだこの余白が大きいので今後の市場の余白は新興国が先進国に追いつく部分と先進国の下記の需要だと思う。

  • 娯楽(特にものを作る系)
  • サブスク
  • ブランド

新興国もニーズは結局ほぼ同じで大きい流れでいうと先進国の辿った道と変わらないと思う。世界中の国が進めば進むほど同じような都市になっていくのと同じである。

残るのは娯楽とサブスクとブランドもの

そんな中で先進国で今後も市場が伸び始めるのは

  • 娯楽(特にものを作る系)
  • サブスク
  • ブランド

だと思う。一つ一つ理由を

娯楽(特にものを作る系)

娯楽は人の余暇時間があるほど必要になってくるし、人はあきるのでニーズが満たされ続けることはない。常に消費されていく。ここが満たされることはないので伸び続ける。

また娯楽の中でもものを作るという趣味はなくならないと思うし、今後仕事によって自己を表現する機会が少なくなっていくなかで重要だと思う。個人が世界に対して発信しやすくなっているのもでかい。労働時間が少なくなっていく中で個人が余暇にものをつくり世界に発信、表現するながれは大きな流れだと思うし、そのツール、表現するプラットフォームは伸び続ける。

サブスク

サブスクが伸びているのは2つの文脈があると思っていて

  • 決済がめんどうな商材(spotify、netflix)の決済をなくす
  • ハードウェアの入れ替えが起こらないため売上維持のためにサブスク

前者はユーザーに対してのわかりやすいメリットで現在すでに起こっているので説明はいらないと思うけど音楽や映画など都度コンテンツを買うという行動をしていたものが決済の動作をなくすことで違うニーズを叶えている。例えばspotifyでなんかおちつく音楽流してとgooglehomeを通して音楽を流すのは都度決済する世界ではあり得なかった。

もう一つの文脈としては上記のニーズが満たされつつある中でハードウェアの買い替えが起こりにくくなることへの危機感があると思う。iphoneを買い替えたいと思う欲求ってもうだいぶなくなってきていると思っていて、多くの人は壊れたとき買い換えると思う。これはハードウェアの会社にとっては死活問題で今後買い替え時に売上が立つのではなく、そのハードウェアを使用している時間に売上を立てさせないと成長できない。

そのためハードウェアの会社がそれを利用する時間になにかしらの方法でサブスク課金させる動きが強くなると思う。iphoneはすでにアプリ収益から手数料を抜いているからこれを達成しているし、任天堂もswitchを買ってnintendoonlineに加入させることでこれを達成している。

ブランド

三点目もすでに来ているけどブランドで特に個人のブランドが来ると思う。わかりやすいニーズは満たされつつあるのでそれを身につけることでなにかの考えへの共感を示せたり、仲間意識を持てるブランドがより求められる。これがSNS、ツールの発達で個人から起きるパターンが増える。ここにはまだまだ余地があるし、時代の流れとともになくなるものではない。

toC PM Nightに行って組織論について考えてみた

https://retty.connpass.com/event/122719/

rettyさんのオフィスでやってたtoC PM Nightに行ってみました。PMのイベントってあまりないし、あっても結構一般論になりがち。プログラミングとかみたいに共通の話題とか場面が少なくて会社の数字とか施策の話になっちゃうんでなかなか記事やイベントで具体的なことが話しにくかったりする。。。ただ今回のイベントはこじんまりとして結構深く話せる感じだった。下記色んな人と話しして思ったこと。

OKRの難しいところ

OKR前はやってたけど今はやってないってところが多かった。一概に悪いとは言わないけど目標(O)が変わりやすいITサービスにおいて毎度それにKRをあわせていくことのコストがネックになってそう。評価を決めるのが業務の多くの部分占めるだと確かに意味はない。目標がある程度定まってなおかつ腰据えてそれに向かっていく場合は良さそうだけどそうじゃない場合見送った方がいいんじゃないかなーと個人的には思った。

立場によって向いている意思決定が違う

チームごとにあがる施策はそこに部分最適されたものが多く、細かいタスクになりがちという話があった。細かいタスク自体は必要なので問題はこれに組織全体が終始してしまうことだと思う。個人的には下記を気をつけている。

  • それぞれのポジションで出しやすい施策が違うことを意識する
  • 最終的には優先順位を一人の人間(PM)が決める

前者は各人に深掘りしてもらいたいテーマを与えてその分野のスペシャリストになってもらう。ただここでもスペシャリストがその分野にのみいいことをして全体では結局良くなっていないというのはあるので

「全体最適を意識した部分最適」

をしてもらうことが重要。これは全体最適をちゃんと伝えることが大切。PMとメンバーの持っている情報が違うとそもそも話が噛み合わない。

チームの分け方について

ミッションごとにチームを分けるが上記のテーマを深掘りさせるためにもいいかなーと色んな会社の組織を聞いてて思った。KPIの率と母数など対立するものをもたせるのはNGでミッションって括りにしたほうが本質的な施策が打てそう。

KPI設計と開発組織の一貫性について考えてみた

KPI設計について最近色々考えたり調べたりしたので考えをまとめてみた。ここではKPIの決め方と運用の仕方、それを開発組織にどう落とし込むかを考えていく。規模的には30-40人ぐらいの開発体制で自社サービスの組織という前提で考える。

KPIの決め方

KPIの目的

KPIを設定する目的を下記においてまとめていきます。

  • 施策を本質的なものに集中させる
  • 戦略を明確化することでメンバーがなにをすればいいか考えられるようにする
  • チームのモチベを上げる

本質的な価値と経済的な価値を分ける

KPIのその先の目標には二種類あると思っていて経済的な指標と本質的な指標があると思います。KGIは企業でやっている以上、最終的には大体が利益になるのかなと思います。ただ利益というのは短期的には本質的な価値でなくても上げれます。例えば極端にいうとアプリへの広告掲載を2倍にしたら短期的には2倍とまでいかなくても1.数倍にはできるでしょう。ただこれってアプリの本質的な価値を上げているわけではないので長期的に見ると大きな損をしています。経済的な指標、利益のみを短期で追うと本質的な価値を下げかねません。

そこで本質的なそのサービスの価値と経済的な価値を分けて考え、

  • それぞれをどう上げるか
  • 本質的な価値を通じて経済的な価値をあげれているか

を考える必要があるのかなと思っています。

因数分解して率と母数どちらかにKPIを設定するのは危険

多くのKPIが因数分解をすると実数×率になると思う。例えば

CV数=リーチ×CVR

みたいな。

この場合、各チームにリーチとCVRをそれぞれ上げてもらうとすると質の悪いリーチを片方のチームが集めてきてCVRのチームの目標を下げるなんてことが起きがち。それが起こらないように両チームに全体のKPIも持たせたほうがいいかなーと思っています。つまりチームのKPIを通してちゃんと全体のKPIもあげようと設定することになります。

それをKPIにおいて意味があるのか?実際にコントロールできるのか?

KPIの目的にチームのモチベを上げるを入れています。これはKPIがチームの努力で上げれるものであることが前提になります。どんだけ努力しても上がらない数値をみるのは気が滅入るものです。実際にコントロールできる数値まで因数分解して落としていくことが重要になってきます。

実際に運用してみよう

上記で決めたKPIをどう運用していくかを考えてみた。

チームとのコミュニケーション

KPIを上記のようにチームのモチベアップなどを目的にしている場合もちろんチームが納得するものでないと意味がない。そのためにはどこをチームと握ってどこを経営陣が決めないといけないかの線引きをちゃんとすることが重要なのかもしれない。今のところ経営陣が事業全体のKGI、それを達成するための途中経過としてKPIを決め、そのKPIの達成する数字と手法をチームと決めるがベストだと思う。

どの時点で達成するのかとその共通認識をメンバーと確認する

KPIはかならず時間軸とセットにして考えないといけない。100年後だったらどんなKPIもいつか達成してしまうので。

チームへのKPIのもたせ方、振り返り方

ある程度大きい目標を達成しないといけないので3ヶ月単位ぐらいで目標は設定すべきだけど振り返りは細かいほうがいいだろう。週や隔週で振り返ってそのKPIにどれくらい近づいているかをちゃんと確認したほうがいい。プロマネはチームのメンバーに進捗や効果測定をちゃんと伝えるのが義務。基本数字をメンバー全員が追って正確に効果測定をするのは難しい。ちゃんと噛み砕いて伝えるのが重要。

またKPIは運用していく中で修正する必要がある。例えば思ったよりリソースが足りない、思わぬ要因でKPIが動かないなど確実と言っていいほどある。ちゃんとその修正の振り返りもする。

開発組織はどう目標を持つのが良さそうか?

自社サービスの会社の場合、受託ではないのでエンジニアがコードだけ書きたいと言う人のみの場合きつい。受託ではなくなぜ自社でエンジニアを持っているかというとエンジニアにそのプロダクトの文脈を理解し、それを仕様に落とし込むところを求めているから。KPIもエンジニア、開発組織も一緒に考えていく組織こそ自社サービス会社の開発組織のあり方だと思う。

プラットフォーム、機能でのチーム分けは機能しなさそう

開発組織に目標をもたせる際によくやるミスはプラットフォームごと、つまり開発組織のチームごとに目標をもたせてしまうことだと思う。KPIはプロダクトの目標に紐付いていないといけない。開発組織としては同じ言語、プラットフォームでの連携が多くなるためそのチーム分けでもいいけどもしプラットフォームごとにKPIを設けると例えばandroidをリファクタするなど技術に向いた目標になりがち。これではプロダクト自体の進捗は無い。

連携を図るためにプラットフォームごとに分けてもいいが目標はプロダクトの目標ごとに持たせるべき。

仕様ぎめのメンバーとできれば一緒に

じゃあ目標をもたせるチームはどういう構成になるのかと考えたときに仕様ぎめをするチームとイコールになったほうがいい。例えばアプリの滞在時間を伸ばすチームにKPIを滞在時間をもたせた場合、アプリの仕様を決めるサーバー、android、iOSからそれぞれ連れてきてそのメンバーに目標と仕様を考えてもらう。目標を持つ人と実際に仕様を考える人が別だと頭と体が別なのでコミュニケーションコストが発生する。またモチベもわかない。

そのチームで仕様ぎめが完結するようにプラットフォームを横断したチームを作るのが良いかなと現時点で思っている。

エンジニアにKPIを担当させるべきか?

そもそもエンジニアにプロダクト側のKPI、例えば滞在時間などをもたせるべきなのか?という議論もあると思うけど基本的には持たせるべきだと思う。上記にも書いたように自社サービスの会社の場合、求められるエンジニア像はユーザーに価値を与えるために行う施策を技術面で実現することで技術だけで完結することはない。ただ、技術力と施策を考える力は別で技術に特化した人もほしい。これは人によって向き不向きがあるのでエンジニアとちゃんとコミュニケーションを取って決めるべき内容だと思う。

技術負債を貯めないためにすべきこと

と上記でプロダクトの目標をどう開発組織で実現するかを書いてきたがこれだけだとその目標からはずれたものは対処できない。そうなると例えば技術的な負債がそのままになったりする。これの対処は正直まだいい案が見つかっていない。強制的にリファクタの期間を用意するなどいろいろあるが根本的には技術を理解した人間がちゃんと経営陣に影響力をもって発言し、経営陣が正確に天秤にかけられるかが重要な気がする。

【読書感想】ブランディングの科学を読んでみた

ブランディングの科学すごい良かったです。周りですごく話題になったので流されて読んだくらいだったけど非常に良かった。

どんなこと書いてたか?

今までなんとなく信じられていたマーケティング、ブランディングの手法を科学的に分析してみた内容を書いている。下記にその一部をちょいまとめてみました。

ダブルジョパティの法則

今までマーケットのシェアと継続率、プロダクトのロイヤリティは別として捉えられていた。つまりシェアの低いものでもロイヤリティの高い商品はあるのでそこに相関はないと考えられてた。しかしマーケットのシェアとロイヤリティは様々な業界で比例していた。これはそういうパターンもあると考えたほうがいいと思っていて、相関はあるけどシェアの低いプロダクトがロイヤリティを高められないというわけでは無いと思う。実際、appleはあれだけのロイヤリティを昔も持っていたがiphone以前はシェアはとんでもなく低かった。

ただ相関は見られていてその理由はあるのかなと思っていてパッと思いつくのはシェアが高まることによって口コミなど目につくことが多く、第一想起を取りやすい。店頭などで並びやすくすぐに購入しやすいなどの理由があるのかなと思う。

クロスセリングは起こせるのか?

この本ではクロスセリングの成功例はほとんど見られないとしているがこれは見つかっていないだけで否定まではちょっとむずかしいかなと思う。逆にクロスセリングがうまくいくとしたらどういうときかを考えてみた。以下がクロスセリングのほうが普通に売るより良さそうだなと思ったところでここを活かせばありえるんじゃないかなと思う。

  • 購入タイミングを把握できる。なにかの購入がキーになる購買行動の場合、一番いいタイミングで訴求できる。例えばスマホ買った瞬間にスマホケースの訴求とか。
  • 同じ会社のサービスならではの連携。webサービスだとよくあるけどデータ連携などで同じ会社のプロダクトだからこそできるサービス内容を用意する。

なぜ自然独占が起こるのか?

上記のダブルジョパティの法則でも挙げたように個人的にはシェアがロイヤリティに効くのはシェアの大きいプロダクトのほうが口コミと物流も広げることができるからだと考えている(これは本に書いてあることじゃなく勝手に思っていること)自然独占の法則と言ってシェアトップが新規顧客を取りやすいのもこれが原因なのかもしれない。

webサービスと一般消費財の違い

シェアの大きさが物流シェアや口コミを広げて更にシェアを上げるというのは一般消費差剤など物流が必要なものなら想像しやすいけどwebサービスの場合、それに当てはまるのは何なんだろうと考えたとき、SNSなのかなーと思った。口コミはリアルよりもSNSのほうが顕在化されるのはわかりやすいけどデリバリーの面で言ってもSNS投稿ですぐにアクセスできること、想起を取れることなどがwebサービスにおけるシェアがシェアを呼ぶ仕組みだと思う。

サブスクの価格販促は意味があるのか?

ブランディングの科学では価格販促(価格を下げることでの販促)についても挙げていて効果がないとは言わないがデメリットが大きいとしている。単純にもともと買おうとしているユーザーの先取りをした場合はむやみに利益を減らしただけで長期的にみると売上はむしろ下がるだろうと言う考え。価格販促した場合に獲得できるユーザーは

  • もともと買おうとしてたユーザーの先取り
  • 今まで価格が理由で買っていなかったユーザーのブランドスイッチ

だけど前者は確かに意味がない。あるとしても担当者が無理矢理今期の目標達成させたいとか些細なもの。後者をスイッチさせるというのとやはり人は購入するタイミングに最も製品について調べると思うので認知をそこで強烈に植え付けることだと思う。なので今まで他のブランドを買ってたユーザーに購入検討させて自社製品を認知させることができたら十分メリットがあると思う。

これとサブスクの場合、離脱しないで続けるユーザーのことも考えるとより意味が見えてくると思う。

施策立案を仕組み化する

よくありがちなメンバーからも施策をあげよう

チームでプロダクトを開発しているとよくメンバーみんなが納得する施策をとか、メンバーみんなで施策をあげようと出ます。一見きれいなことに見えますがこれは個人的には危険な状態だと思います。メンバーの方に施策が向いているからです。開発チームが施策を行うのはユーザーのためであり、チームメンバーのためではありません。そういう意味ではメンバーの納得は必要ないです。

またプロダクト開発は不確実なことの実証実験でもあるので全員納得したのがいい施策とは限りません。むしろ誰か一人の突飛押しもない施策が意外な成果を出したりもします。

僕は昔、こういうみんなで施策をあげようとかの意見が出るとどうも民主主義的な、かつ自分たちがユーザー自身と勘違いしているんじゃないかとちょっと抵抗感がありました。ただ最近は

  • 各人が集中的に施策を出す範囲を分類する
  • 施策出しと優先順位決定を分ける

をし、メンバー全員で施策を出しながら全体ロードマップを逸脱しないで圧倒的な個人が施策を考えるより良い施策立案ができるんじゃないかと思うようになりました。ちょっと今考え、最近うまく言ってるなと思う運用をまとめてみました。

いい施策はgoodな施策でもbetterな施策でもなくbestな施策

まず前提としていい施策とはなにかについてここでの個人的な見解をまとめてみます。単体で見たときたしかにあったほうがいいよねという機能、施策はめちゃくちゃあります。ただプロダクト開発のリソースは限られています。プロダクト開発における施策立案は施策を出すこと自体よりもこの限られたリソースでどの順番で開発していくかのほうが実は選択肢がたくさんあります。

プロダクト開発は便利機能をつけることではない

またプロダクト開発ではユーザーの声などを吸い上げて便利機能をつけていくのが理想ではありません。ユーザーは眼の前のニーズしか気付かないし、プロダクトは何年にも渡って運用されます。プロダクトの開発は事業として捉えて将来的にどういうプロダクトになったらよりユーザーに価値を提供できるかから逆算していくように心がけています。より便利にしていくことと長期的どういうプロダクトにするかから逆算していくのは重なるところもありますが=ではありません。逆に直近の声に偏りすぎると時代の動きに乗れずに時代遅れのプロダクトになる可能性もあります。例えばPCからスマホにwebサービスがシフトしていく中でPCの既存ユーザーの声を聞きすぎて新スマホ発サービスに市場を取られたサービスはこれに当たるかもしれません。

PMとメンバーの見ている情報の差

となったときにPMはより広く、そして長く視野を持たないといけません。そして各実装者、メンバーのやっていることを把握しているPMのほうが各メンバーよりもこの視野は広くなりがちです。逆に視野の深さは各メンバーのほうが良くなります。ここにギャップが生じがちです。例えばプレミアム会員を伸ばすKPIをもったメンバーからはもちろんプレミアム会員を伸ばす開発施策が上がると思いますが新規ユーザーを伸ばすのが全体の優先順位的に高い場合、後者を優先したほうがいいでしょう。しかしプレミアム会員を見ているメンバーがその全体戦略を把握していないときに自分の施策が不当に却下されたように思います。これはどちらが悪いということではなく、全体の中でなにを任しているのかをコミュニケーションできていないからです。

全体像を伝える

なのでPMとメンバーが施策立案で互いに不満を感じるパターンの一つに戦略と戦術で視点が違うというのがあると思います。施策は優先順位が重要で単体で良くてもより良いもの、今やらないといけないことをやります。そしてそれは全体像の見やすいPMの意見と専門分野で深く見やすいメンバーで視点や情報が違うため齟齬が生じます。ここを埋めるためにはPMはメンバーに全体像がなにで今なにを優先順位上位に持ってきているか、他の施策の進捗がどうかを伝える必要があります。

施策の分類とそれぞれどこの人間が一番出しやすいか

どちらが優れているという話ではなくそれぞれが見やすい分野の施策をあげ共有することが大切です。このへんのほうれんそうの大切さは脱出ゲームをするとよりわかりますwまとめると

  • 施策立案は優先順位ぎめが大切
  • その優先順位は全体像が見えている人間がスピーディーにやるべき
  • しかしその全体像、優先順位をメンバーに共有するのも必要
  • PMが戦略、優先順位を各深い施策立案をメンバーにと分ける
  • メンバーに対してどの分野の施策立案をしてほしいか明確に伝える
  • その施策が全体の中でどういう位置づけと考えているか明確に伝える

が大切なのかなと思っています。もうちょい具体的に言うと僕はゴールとなるKPIとその構成要素を書き出し、どの数字、分野の施策を立案してほしいか提示しています。そして各人があげたものを優先順位付けし、開発のロードマップに起こしています。圧倒的な個人がいてもSEOで細かい施策やデザイン面でのUX改善など一人で全部をカバーするのは現実的ではありません。この施策立案はメンバー各人に任せたほうがより詳細に詰めれますし、PMのスキルセットに依存しないので常に専門的なロードマップをしけます。よくみんなで施策立案するとなるとこのプロダクトの施策何がいい?となげがちですがちゃんと全体像と意図を伝え、どこを集中的にお願いしたいかを明確化することによりそういうことじゃないんだよなーを防げます。

以上最近思っていて僕も気をつけなきゃなーという半分自戒でした。

中小メディアが自由にターゲティング情報を送り、広告主も自由にそれを使えるアドプラットフォームがほしい

facebookやgoogleを始め、webサービスは広告技術にその拡大のほとんどを依存していたなあと思う。実際webの広告は今までの広告と違ってかなり細かく取捨選択できて今までの大量に広告をうちどれがあたっているのかよう分からないというのを多少なりともなくしてきている。(まだもちろんあるけど)〜を見たことある人に広告を出すなど今までの看板やCMではほぼできなかった。ただfacebookやgoogleのやっている広告ビジネスとその他の中小メディアのやっている広告ビジネスは全くといっていいほど違う。そしてこれからもこのままだと差が開く一方だし、支配的ですらある。

ここでいう広告の技術とは?

ここで言う広告の技術には大きく分けて2種あってユーザー情報とアルゴリズムに分ける。基本的にはターゲティング広告はAなユーザーにBという広告をあてる技術としたときにAなユーザーと把握するのにはユーザー情報を多く持っていないといけない。次により効率的に当てるためにアルゴリズムがある。技術的なことのプロじゃない素人の意見としてはアルゴリズム自体はすぐにスタンダードになって大きな競争要因になりにくいと考えている。それよりもその媒体がもっているユーザー情報の方が競争優位性になりやすい。例えばamazonが持っている石鹸の購入履歴をもとにタオルの広告を出したいとしたときにamazonで石鹸を買った情報は他のサービス事業者は持ちえない。(持ってたらやばいw)これは技術云々ではないので今後も変わらないと思う。

facebook、googleが今後も広告業界を牛耳る理由

facebook、googleはそもそも持っているユーザー情報をさらに買収先のメディアと連携できる

facebookとgoogleは今後もwebの広告業界を支配していくと思う。理由としては彼らは商業的、金融的にも成功しており、自身の媒体が廃れても買収してそのメディアと連携させることができる。上記でのべた最大の競争優位性を継承させつづけることができる。M&Aをよほど失敗しない限り、今後も媒体をいくつも渡り歩いてそのユーザー情報をどんどん広げていくことができる。instaとfacebookはまさに象徴的だと思う。

中小メディアがfacebook、googleに買収されないでより利益率を高めるなら

中小メディアでもっとも広告のターゲティング精度を高め、利益率をあげるのは2社に買収されてID連携されるのが最もてっとり早いと思う。これ以外の方法でこの2社に対抗できるくらいターゲティング精度を高める方法はあるのかを考えてみた。アドプロダクトにはいくつかパターンがあるが今回は普通のバナーなどの広告をターゲティング精度でどう利益率を上げるか考える。その場合、その媒体のユーザー情報をどう使うかが要になってくる。自分はこれを媒体ごとにカスタマイズして送り、広告主側もこの情報をもとにターゲティングを設定できるプラットフォームがあれば、その媒体でしかできないターゲティングができ、利益率が上がるんじゃないかと考えている。できれば複数媒体が一つのDMPにユーザー情報を送り、公開されたプラットフォームで広告主が複数の媒体のユーザー情報を設定し、使えると良さそう。

 

  • 任意のユーザー情報をDMPに送れる
  • 複数の媒体からの情報をcookie、IDFA、ADIDで串刺しにする
  • 広告主がどの媒体のどのユーザー情報を使うか指名できる
  • 管理画面が公開されている

現在もDFPのキーバリューで似たことはできる。ただし純広告のみ

現在もDFPで媒体がキーバリューという形でユーザー情報を送ることはできる。ただ純広告でしか使えず、プログラマティック広告に送ったりできない。営業力のあるところならまだいいかしれないが営業力をそこまで持たない中小メディアだときつい。

重要なのは買い付けもできるプラットフォームであること

そのため買い付けを公開されたプラットフォーム上でできないと厳しい。facebookやgoogleのように営業を介さず、自由に小規模事業者も複数のメディアのユーザー情報をもとにターゲティングできるプラットフォームでないとgoogleやfacebookではなくそのプラットフォームを選ぶ理由が思い浮かばない。現状もgoogleの管理画面経由でgoogle以外の媒体にももちろん掲載できる。ただどの媒体のどの情報を使うというところまでは指定できない。ここをちゃんと正確に送らせ、指定できるようになることで広告の幅がまた広がる。またその媒体を指名する理由ができる。

PMPとDMPを足したターゲティング情報も公開されたプラットフォームが重要

いわばPMPのターゲティング情報を自由に設定できるプラットフォームとも言える。

  • 営業を介さない
  • 複数メディアのユーザー情報を同時に使用できる

この2点を実現しないと今後インハウスや中小企業の広告費を取ることはできない。

freakoutさんあたりに作ってもらいたい。。。

こういうことができるのは

  • 自社ですでに大きな媒体を持っているところが開放する
  • メディアではない広告技術を持っているところ

のどちらかでないとできないと思う。facebook、googleが似たことをDFPやFANでやっているがターゲティング情報を公開するのが重要なんじゃないかなと考えている。もっと広告で活用できるユーザー情報はあると思っていてそのへんをfacebookやgoogleが技術で取得や推測するよりも各媒体から送らせるようにしたほうがいいと思うんだが。。。ううむ。あとは後者だとfreakoutさんがred for publishersというのをやっていて少し近い。

自分の観測範囲だと上記の仕組みをできるプラットフォームはなさそうだけどこういう形ならできるという人がいたら教えてもらえると助かります。

© 2019 you88blog. All rights reserved.

Theme by Anders Norén.