you88blog

広告とかwebとかプログラミングやら

メニュー 閉じる

2ページ/3ページ

これから日本は超暇社会になると思う

これから日本でどんな産業や業界が盛り上がるのかなと考えた時、自分は趣味や趣味発のコミュニティだと思っていてそれはこれから日本が超暇社会になると思っているからです。それについてちょっと文章にまとめてみる。

日本は全体的にどうなっていくか

日本が超高齢化、少子化になるというのは散々言われているし、避けられないと思うのでそれを前提に考えていきます。ただ僕は結構悲観していなくて(経済規模的には厳しいが生活的には)テクノロジーの発達で働き手がなくなり、不便になるとは思っていないです。現に今もバックオフィスを始め、かなり仕事は楽になりました。起業していた頃、思ったのは経理をはじめバックオフィス業務はそうとうAIとツールによって楽になるため人数がいらなくなります。

現在、大企業のバックオフィスにあんなに人がいるのは人を切れないから仕事を削減していないだけで現在の世代が定年退職を迎えたらだいぶ縮小できるところも多いのではないでしょうか?

労働環境はどう変わっていくか?

上記に書いたように日本では人をきるのが難しいです。なのでコストの削減はそこまで積極的に行われませんでした。なぜならコスト削減しても人を切れないので結局社員が暇になるだけで会社のコストは減らないからです。

しかし、昨今派遣や業務委託、フリーランス、副業が多くなりつつあります。また上場企業の中には残業を取り締まる傾向が強いところも多くなりました。この残業をなくすのはワークライフバランスなどを表に出していますが会社的には人を切らずに人件費を下げるためのものでもあります。しかし、残業代で生活を成り立たせててた人もいるのでそういった人のために副業などを認め、1社で1人の生活を支えるのではなく数社で支える構図になりつつあります。

人の生活はどうなっていくのか?

ツールの発達、経済の縮小で会社が人の労働力を削っていく中で残業などがなくなり、労働時間の減った人たちはどうなるのか?その時間超暇になります。暇になった人たちがなにをするのか。おそらく創作活動やスポーツなどの趣味に移行していくと思います。創作活動は結構その中でもあついと思っていて、仕事が削られていっても人は評価されたいのでおそらく人になにかを見せて反応をもらうものに移行するんじゃないかなと考えています。

実際、今までの歴史を見ても裕福な時代に創作活動は活発になり、そのムーブメントを文化と呼びました。おそらくこれから日本はそういう時代になるんじゃないかなと思います。その中で趣味のコミュニティはまだまだ余白があるので今後活発になっていくと思います。

営業チームと開発チームが仲良くするために大切だと思うこと

広告のアドサーバーの開発を見ていると広告という分野なのでビジネス面と技術面両方見ることが多いです。うちでは営業チームと開発チームがありますが、大抵の会社ではスーツとギークじゃないですがあまり仲良くならない部署同士だと思います。結構この2つのチームのコミュニケーションの設計をどうするかはかなり悩んでいる所で今のところうまく行っているようなきがするので1事例としてまとめてみます。

なぜ仲が悪くなるのか?

いくつか要因はあると思いますが、まずは使っている用語が違うのが大きいと思います。コミュニケーションにコストがかかったり齟齬が生じるので仲が悪くなる。これはすごく分かりやすいけどなかなかビジネス側がプログラミング勉強したり、エンジニア側がクライアントの要望などを把握し切るのは難しいです。僕はつなぐ立場なのでプログラミング勉強したりクライアントとのやり取りを見たりしていますがそれを全てのメンバーがやるのは現実的ではないかと思います。僕はどちらもたまたま好きだったからできたけど。

またKPIが2チームで違うと争いの種になります。例えば営業チームは売上をKPIにしているが開発チームはcv数をKPIにして営業チームは効果とかではなく、とにかく案件を取ろうとして開発チームは効果があがりそうな案件への対応を頑張ったりしちゃいます。このKPI、目標を一致させてアプローチだけ違うという状態にしないといけないのも難しいところです。

3つ目は時間軸の違いで営業チームは直近の案件にもちろん注力しますが開発チームは中長期の効果改善に注力しがちです。直近の案件をテストで使い、新機能を試したい開発と直近の案件でそんなテストなんかせず、現在の機能で確実に効果をあげたい営業チームなんかもよくあるパターンだと思います。

どう対処していくのか?

まず前提として大切なのは別に営業と開発に限ったことではないですが相手の職種を理解しようとする姿勢が大切かと思います。(いきなりエモーショナルなところいきますが)相手チームのKPIや文化、言語の理解をすることが前提。そのうえでやらないといけないのは2チームの目標や言語を統一していくこと。1つ目の言語の違いは用語表を作り、できるだけ2チームの言語を統一する必要がある。

2つ目、3つ目の目標設定は時間軸やアプローチ方法が違っても最終的に同じになる目標を設定しないといけない。

文系職が個人でBOOSHOOというサービスを作ってみた理由

サービスづくりの動機

一番はもちろんサービスづくりが好きというのもあるが、サービスを作るプロとしてちゃんとデザインの一つ一つや仕様策定など全体の流れを一通り定期的に行うことで全体感を養っておこうと思って、最近またプログラミングを勉強し直していた。やはり一通り細部を作り込むと全体的な戦略などを考える時もより詳細に考えられるようになるので非常にいい。

今回はデザインからプログラミングまで全て自分ひとりで行っている。

サービス概要

作ったサービスはBOOSHOOというサービスでtwitterで趣味友達を募集できて応募した人同士だけ限定でおしゃべりできるというサービス。もともとtwitterで友達作りたいけどきっかけづくりむずいなあと思って作った。twitterに限らず今リアルで全く知り合いではないネット発の友達ってなかなか作りにくいなあと感じたのもきっかけ。mixiのグループみたいなのを簡易的に作るイメージ。

www.booshoo.net/

今後超暇社会がくると思っている

もっと言うと今後趣味×コミュニティは来るなと思っていて理由は近い将来人々はめっちゃ暇になると思っているからです。AIやツールの発達で雑用的なものから人が開放されて労働時間が下がるなと考えていて暇になった時間をどう過ごすのか?が重要になってくる。もう既にその兆しはあって上場企業は残業時間にうるさい。これはもちろんブラックだなんだと揶揄されるのもあるが、人件費削減の意味合いもある。人にそんなに働いてもらわなくてももう企業は十分回り始めている。(逆に人から置き換えられない高コストなビジネスモデルはきつくなってくる)

一度ピボットさせる

と思って作ったのですが最初は相互フォローを募集するサービスでした。相互フォローしてあとはtwitterでコミュニケーションしてと。でもよく考えたら相互フォローのあとコミュニケーションする場所がなく、根本解決になっていないので限定トークルームでおしゃべりできるサービスにピボットさせた。

仕様の概要

  • heroku
  • rails
  • bootstrap4

という構成で開発した。認証はtwitterのみにしました。twitterでの友達募集なのでtwitterは必須だなと考え、メールアドレス認証をどうしようか考えたがやはりプロフィールがないと話が弾まないのでtwitterと連携してtwitterアカウント見れるようにしたほうがいいなと言うのがtwitter認証のみの理由。ただ応募があったときの通知にメールがあった方がいいので悩みどころではある。今応募が来てもサービス外で通知するすべがないので。。。

もっというと今後メールで通知じゃなくてLINEで通知を送ったほうがいいんだろうなと思っている。なんかLINEでの通知ってあんま流行らないけどなんでなんだろ。。。LINE@に友達承認させてそこから通知とかどうなんだろ?今はビジネスコネクトとかじゃないとできないけどLINEさんには個人開発でも気軽にメール通知的なのがLINE@でできるようにしてほしい。(おそらくLINEアカウントとサービスIDのヒモ付が必要だが)

導線で気をつけた所

募集する人と申し込む人でフローを分けて考える

募集する人と申し込み人で大分フローが違うのでそれぞれで考える。応募する人は基本募集する人のtweetを見てくるので募集ページにランディングする。そこから応募する場合もあるし、応募に興味を示さない場合もある。示さない場合はサービスの訴求につなげて募集する側に回ることを提案する。

最もサービス訴求で大切なログイン画面

ログイン前がユーザーが最もこのサービスを使うのか迷うところなのでここでの訴求はもっと改善の余地がある。(前より大分良くなったが)

爆弾ゲームがはじまると組織は途端に高コストになる

最近組織運営で気をつけているのが、組織のメンバー同士でタスクの受け渡しをすることである。これが現場判断で適正な人間に回っているのなら良いがそうでない場合、非常に問題だと思っている。これを個人的に爆弾ゲームと呼んでいる笑

どういった事象のことかというと下記2種類あると思っている。

  • 誰がやっても良い評価につながらないタスクを他人に回すことで自分のタスクを減らす。
  • 事前に判断が必要なものを完成後に判断する

前者は分かりやすく悪いので中間管理職と部下、先輩後輩以外は実はしにくい。まあこの2箇所だけでも起こると面倒だなんだが。分かりやすい前者から説明すると基本的に従業員と会社は仕事の結果と給与で契約している。ただ、この結果に置き換えにくいタスクも存在はしているちょっとした雑用などが分かりやすいかもしれない。

こういったタスクは報酬を目的に働いている人からすると魅力的でないため後輩や部下に渡し、評価の上がるタスクを中心にやってしまうかもしれない。そうなるとコミュニケーションコストだけ高くなり、個人で見るとその人のタスク量は減るかもしれないが組織全体でみるとコミュニケーションコスト分コストが増える。

これは明確に上がタスクの割り振りを明示するかそういったタスクも評価内に入れるかをしないと解決が難しい。

ただこれはあまりやると普通に人間関係に問題が出るので実際にはそこまであからさまにする人間は少ないと思う。問題は後者だと考えている。後者がよく起こるのはデザインの発注の場を想像してもらえると分かりやすい。デザインで例えばデザイナーからボタンの位置を事前に確認され、そのときにちゃんと考えずできてから考えようと思ったことはないだろうか?これはシミュレーションするコストをデザインのコストで補おうとしている。

もちろん実際にできてみないとよく分からない案件はあるがそれに甘えて事前に考えないで発注や依頼をするのはコストを組織全体で考えられていないのではないだろうか?これは前者のものより非常に解決が難しい。それを事前に想定できるかは断言できないし、能力の問題もある。ただ自分だったらそこも能力の一つだと思うのであまりに多かったら普通に評価下げるなーという部分ではある。よっぽど評価者が現場を把握し、スキル、状況を把握しないといけないのでそれも難しいのだが。。。

またより難しいのが2部署をまたがるときでこうなるとお互いの部署のリーダーがどっちがやるべきか押し付け合うこともある。自分の部署に無駄なコストを持ち込みたくないからだ。その上で包括的に判断できる人間がいればいいが現場のタスクを2階層上の人間が判断するのは難しい。こういった場合依頼する側がどうしても主導権を握りやすくなる。

解決策としては個人的には個々のタスクで判断するのは諦め、部署ごとのミッションを具体的に制定するのが良いと考えている。どこまでをやってどこまでをしないか。その明示だけなら包括的に見ている人間に確認を促すこともできるはず。

webサービスのマネタイズ手法色々触って思ったこと(広告、プレミアムやらなんやら)

この記事について

今までプレミアム会員のチームや広告プロダクトの開発などをしてきてwebサービスのマネタイズ手法を広く勉強できた気がするのでどういった手法があるか?とそれぞれやってみて思ったことをまとめる。

マネタイズ手法

  • 広告
  • プレミアム課金
  • コンテンツ課金

広告のARPUは上がり続ける。今後もwebマネタイズの中心にいるだろう

広告はwebサービスのマネタイズのメインといっていいと思うし、今後もそうあり続けると思う。一時、プレミアム課金をcookpadが成功させて広告よりもプレミアムをという流れもあったがアドテクの発達で正直プレミアム課金で稼ぐよりもプレミアムになる率を考えると相当効率良くなっている。例えばfacebookはARPUが400円を超えており、この金額は全ユーザーがプレミアム課金しているのとそんなに変わらない収益性である。

www.cnbc.com/2017/11/02/facebooks-revenue-topped-5-per-user-for-the-first-time.html

また正直webサービスで機能制限で課金させるのは相当難しい。やはりwebサービスの大半は無料ユーザーであり、ここへのサービスを手厚くしようとするとプレミアムサービスとかち合うからだ。それはプレミアムユーザーの機能だから提供できないとまごついている間に他のサービスがそのサービスを提供して負けるというのが今後増えてきそう。facebook、google、twitterのように無料にどんどん機能開放し、回遊率、アクティブ率をあげて広告で稼ぐにより寄ってくる。

プレミアム課金はすぐに課金するユーザーとかなり使った後に課金するユーザーの二極化する

プレミアム課金で課金するユーザーは結構2極化するパターンが多いように感じる。プレミアムのサービスを目的でサービスを使い始めたユーザーはすぐにプレミアム課金をする。newspicksなどコンテンツをそもそもプレミアム課金しないと見れないと言った設計だとここが多くなる。もう一つがサービスを長期間使ったユーザーでお気に入りの個数に制限をかけるなどより多くストックさせたいなどのプレミアムサービスの場合、ここが多くなる。

投稿サービスなどで無料ユーザーの利用もサービスにとって必要な場合、無料ユーザーも使えるけどより使うにはプレミアム課金という設計が多くなりがちである。

広告でマネタイズするユーザーとプレミアム課金でマネタイズするユーザーを分けるべき

ユーザーによってマネタイズ手法を変えるべきなんじゃないかというのは最近思っていて絶対にwebの広告は踏まない。でもサービスへのロイヤリティは高いみたいなユーザーにより使いやすくなるプレミアム課金をすすめたりなどは考えるべきかなと思っている。ユーザーによって適切な関わり方をできるサービス設計をしたい。

コンテンツ課金かサブスクリプションか。サブスクはコンテンツ業界のアンバランスさを考えないと難しい。

【定義】

・コンテンツ課金→単体のコンテンツを買い切る形の課金
・サブスクリプションモデル→サービスに対して定期課金する課金形態

コンテンツを扱っている所のマネタイズは二極化してきてサブスクモデルが最近は大きく伸ばしている。音楽ではダウンロードの減り分を大きく補っている。サブスクであうなと思うのはコンテンツというよりそのコンテンツを消費する時間がほしい場合。例えば音楽はその曲を聞きたいというより、通勤時間に聞ける音楽がほしいなどライフスタイルに組み込まれるようなコンテンツは相性が良さそうだなと思う。

ただサブスクモデルで難しいのはコンテンツホルダーへの返金方法でユーザーから集めた金を視聴回数の割合で分配するという形を取った場合、ヒットコンテンツを出す側としては上限がそこに設定されてしまうので美味しくない。総取りできるコンテンツ課金の方が嬉しい。コンテンツ業界は上位数%のヒットコンテンツで売上が成り立っているためここにキャップが決められると厳しい。

そのためヒットコンテンツ以外のコンテンツでサブスクサービスには参加するコンテンツホルダーが多くなり、そのサービスの魅力が半減する。netflixなどは自社でコンテンツを作ったりヒットコンテンツには違う契約形態を設けたりして回避している。今後もヒットコンテンツへの付き合い方がサブスクモデルでは課題になりそう。

【1週間ブートキャンプ】文系職が夏休みを使ってプログラミングを覚えた話

去年の夏の話なのでかなり前だが夏休みを使ってプログラミングを覚えようと思って一週間ぐらいでプログラミングの基礎を一気に身につけられないかと勉強方法を模索した。rubyとrailsを一から勉強してどれくらい身につけられるかみたいなタイムアタックをしたくて効率性を重視したやり方を見つけられたと思うので文系職で自分でwebサービスを作ってみたいと思っている人に読んでもらいたい。ちなみにこの勉強のあと日曜大工的に毎週プログラミングしていてfirebaseとrails、vue.jsでチャット作ったり、今はtwitterで趣味友達を募集できるサービスの開発をしてたりします。

個人開発者の人とも仲良くなりたいので気軽にフォローしてください。

twitter.com/you8802

動機

僕はちなみに今までいくつかのプロダクトのディレクターやったりプロダクトマネージャーをしたりしています。現在は広告プロダクトを見ていてこういったものを作っています。

inside.pixiv.blog/yattyo/3420

もともと受託をやってたり、起業して自分でもプロダクト立ち上げたりしてて、マークアップはがっつりやってたのとwordpressやphpもエンジニアと一緒にちょっとしたものならやってたのですがちゃんと体系的に学んでいないような状態でした。それがなんで今さら勉強しようかと思ったかというと

  • 自分で小さくサービス作れたら色んなPDCAを回せるなと思った
  • ディレクション能力も上げたい
  • 単純にプログラミングに興味あった

上記の理由で一番はまあ自分でサービスまた作りたいなという興味本位。次が現在のチームが技術的な難易度が高いチームでディレクションするにあたって技術的なことを理解しないと厳しかったから。ディレクターの仕事はエンジニアの働きやすい環境を提供することも入っているので彼らが技術的なことを説明するコストをこちらが勉強することで削減できると考えたからだ。

個人的に思う文系職のプログラミング挫折ポイント

環境構築

最初プログラミング勉強しよう!と思ったらまず環境構築をすると思うのだが死ぬほどつまらないのと面倒なのでここで大分モチベを削られる気がする。今回は環境構築をしなくてもプログラミングを始められるprogateでまず勉強をはじめて回避したのとその後、環境構築する際は同僚に助けてもらった。

全体像がわからなくなる

細かい記法にばかり目がいって結局なんの機能作っているのかよく分からなくなる。一通り書いてみたがなんでこう書いたのか分からんというのもモチベをさくし、結局身につかない。

勉強に使ったサービス・本

  • progate
  • qiita
  • dotinstall
  • パーフェクトruby
  • teratail

感動したポイント

progate

2-3年前に勉強した際と大きく違うのはprogateが有るかないかと言っていいくらい感動した。まず環境構築無しでいきなりプログラミングを勉強できる点がいいし、間違った際の指摘が本当に細かい。相当パターン別に文言用意していると思う。

qiita

qiitaがいいのが間違いを指摘し合う文化が有る所で全く知らない人から指摘が来る。しかもなんで間違えてんねんって感じではなく本当に教えるみたいなテンションで来て滅茶苦茶ユーザーがあったかい。

teratail

これも本当にびっくりしたが質問してほぼ100%当日中にいい感じの回答が来る。ツールの設定など特殊なパターンなど資料に載ってなさそうな細かいつまりに対応する際には重宝する。

勉強方法

勉強サイクル

  • progateで勉強
  • dotinstallで同じ箇所勉強
  • qiitaに全体像をまとめる
  • よう分からん所はteratailで質問

忘却曲線と戦う

とにかく人は忘れる生き物なのでどう定着させるかが重要だと思った。でも本何回も読むのもだるいのでprogateを何周もすることに。毎日progateやって計4周ぐらいした。(公文式方式)

ただprogateは本当にさわりなのでdotinstallで補強しつつ、重要な部分はパーフェクトrubyを読んだほうがいい。

(星の横にあるのがやった回数)

木を見て森を見る

個人的に今回めっちゃ当たった勉強法はqiitaに都度都度まとめるでまとめると全体像を把握できるし、親切な人が間違い指摘してくれたりするので非常にいい。プログラミングは記法などに目が行きがちだが値をどこで入力してどこに溜めてどうやって出力するかを意識するといいかも。

やってよかったこと

やっぱりエンジニアとのコミュニケーションがより密になった気がする。ただ気をつけないといけないのが彼らの方がプロだということ。なにか彼らの決めたことに対して意見するための技術ではなく、彼らがビジネス職、文系職に説明するときのコストを減らすための技術であってやんややんや言うのはダメ。ちゃんと技術に関しての決定は彼らに委ねる。なぜなら彼らはプロだからだ。

もう一つは趣味ができたこと。日曜大工は材料費がかかるがwebサービスは材料費がかからない。

github.com/you88

この辺でチャット作ったりしている。

qiita.com/you88

ココにも逐一記事をあげてて非常に面白い。最近はvue.jsやAWSを頑張っている。物を作るのも楽しいし、プロダグラミング自体、パズルのようで面白い。今公開できるサービスを作り中なので自分のサービスの広げかたも研究できるようにしたい。

事業会社の開発チームの動かし方を考えてみた

受託もやって事業会社での開発もやってといろんな形態で色んなプロダクトの開発をやってきて最近色んな知見が溜まってきた気がしたのでちょっと整理してみる。開発チームを動かす上でメンバーに対してどう接するべきかなあなどなど。

全体最適をしらない者に部分最適は難しい

全体最適、つまりプロダクトをどうすべきか分からないとエンジニアも部分最適化をできない。例えばエンジニアが実装するなかでこの条件どうしようとかDBの設計をどう拡張をもたせるかなど部分部分で細かい判断が必要だがそれは全体としてどうなるかが分かっていないと判断できない。そしてそういった局所的な判断がプロダクトの質を高めていく。

この全体最適をちゃんと理解してもらうのはプロダクトマネージャーやディレクターの役割であり、責任になる。

何回言っても伝わらないは当たり前

ただそういった方針や全体の動きは何度言ってもなかなか伝わらないものだ。正直2,3回とかのレベルでも伝わらないことはあるし、すぐに忘れる。これは当たり前なんだなあと最近思うようになってきた。何回も同じテンションで説明し続けられる、プロダクトの思想を伝えることができるという精神性は意外と重要なスキルなんじゃないかなと思う。あいついつも同じこと言ってんな。しつけえぐらいがちょうどいい。

経営者マインドが!プロダクトマネージャーマインドがねえも当たり前

よくメンバーに経営者マインドが足りないとかプロダクトマネージャーのような全体感を持ってくれないと嘆く人を見るがそれは当たり前でじゃあ君はエンジニアのマインドを持っているかと聞いてみたい。別にどの職種でも言えることだが他人の職種のマインドを100%持つなんて不可能でそれは経営者やプロダクトマネージャーだけの悩みではない。また当事者意識を持とうと言っても当事者に100%なるのはできない。お互いが互いを理解するように努力するのが大切。

常に不安がちょうど良さそう

互いに100%理解するのが難しいと分かっていれば常に不安になって相手の観察を怠らないと思う。そしてマネージャー、ディレクターなどメンバーを調整する役割を持つ職種はそれぐらいの気持ちでいるのがちょうどいいんじゃないかなあと思う。自分のチームのメンバーは皆楽しく仕事をしています!とまじで言い切ってしまう人よりこいつらにちゃんと俺の考え伝わっているかな?楽しく仕事できているかなと不安で常に改善策を考えるマネージャーの方がチームに取っていいんじゃないかなと思うのです。

事業会社はどう広告を考えれば良いのか?-広告はプロダクトの一部-

プロダクトを見る人間が広告をどう考えたら良さそうか、どこまで知っていたほうが良いか、手法の選択する際に意識することなんかを個人的な偏見を存分に入れて考えてみた。なんでまとめようかと思ったかというと田端さんのこのtweetをみてホンマにそうだなと思ったからである。

僕もマーケティングは専門性が高いのにもかかわらず、日本では総合職が片手間にやることも少なくなく、ノウハウの蓄積に失敗しているところが多いなと思っている。なので逆に事業会社が最低ここは把握したほうが良いんじゃないか、こういう捉え方をしたほうが良いんじゃないかというのをまとめてみた。

広告はプロダクトの一部

広告はユーザーにプロダクトが接する最初の面なのでこことプロダクトは一貫した体験になるように設計しないといけない。ユーザーは

広告

(LP)

プロダクト

(購入や課金などのCV)

の順で体験するが広告で付いたイメージが一致していないと最後まで到達しない可能性が高い。どんなユーザーを連れてくるか?どんなイメージをもたせるかはユーザー体験の一部である。

自社にノウハウは溜まっているのか?

決して代理店を否定するわけではないが日本の事業会社では広告を代理店にまかせ過ぎな事業者が多いように感じる。上記のようにユーザー体験に大きく影響をあたえるところなのでユーザー体験を向上させるなら広告もその一部として見直していかないといけないし、ノウハウを溜めないといけない。代理店などは広告手法のプロではあるがサービスのユーザー体験などは事業会社側が把握しているべきだ。どんなクリエイティブでどうイメージさせるかをちゃんとコントロールしているか考え直してみるといいかもしれない。

プロダクトマネージャーが把握したほうがいいと思う広告手法の分類

プロダクトマネージャー(事業会社側)が最低限下記を把握して代理店と一緒に広告手法を話せると良さそうというのをまとめてみた。ちなみに分類は個人的に勝手にやったもので一般的なものではない。

pull型とpush型

pull型
SEOなどユーザーを待ってとってくる手法。ユーザーの行動の先においておくものなので基本的にはニーズが顕在化されているユーザーで継続率は高い。

push型
twitterなどユーザーにこちらからpushでプロダクトを押していくのがpush型。潜在的にニーズがあるであろうユーザーを見極めるのが大切。

具体的な広告手法

pull型

  • SEO
  • ASO
  • リスティング
    • 検索結果に広告出すやつ。検索キーワードでセグメントができ、ユーザーの層ではなく、ユーザーのニーズでセグメントできる。ぶっちゃけかなりユーザーのニーズが顕在化されているのでかなり優秀。

push型

  • UAC
  • twitter
  • facebook
    • push型は潜在的にニーズを持っているだろうユーザーをデモグラや背景で読まないといけないがfacebookはそのデモグラが最も正確な媒体と言って良い。push型において最強だと思う。

プロダクト戦略を考える上で気をつけてる情報収集法

もともと社内の新人に見せるように作ったものだが社内以外でも応用できるなと思ってブログにも書くことにした。自分がプロダクトの戦略を考える上で意識している情報収集方法をまとめてみました。もちろんひとつの考え方でむしろもっとこうした方がいいよというのがあったらどんどん意見いってほしい。

なぜ情報収集が大切か

基本的に意思決定の際に

  • 情報収集
  • 施策立案
  • 選択
  • 実行

を意識しています。大抵の人は他の人がやっている行動をしていて情報収集や、施策を自分で作る所をしない。網羅的に情報を集め網羅的に施策案を出し、それらを吟味していく作業というのは実はなかなかされていないんじゃないかという印象。でも選択肢のどれかを選ぶのは実はそこまで差がつかないと考えていて、ちゃんとした情報があれば誰でもそりゃそうだよねってことが大半です。(ただ政治的な理由でできない場合はある)そのためどんな情報をどの速度で得るか、そしてその情報からどういう施策をだすかが良い意思決定には最も重要であるというのが個人的な最も基本となる意思決定の考え方です。

情報を点で捉えず線で捉えよう

なにかの情報を見た時その情報をそのまま捉えるだけでなくそこから2手3手先を読むようにしている。2流は情報を点でしか捉えられず、1流はそこから2手、3手先を読んで線で情報を捉える。超一流は数パターンの2手、3手先を読んで立体的にものを見れる。訓練としては企業ごとにニュースを並べるというのがオススメ。それをすると一つのニュースをみて次どんな手をうつかのパターンを覚えることができる。

具体的な情報収集の方法

英語の一次情報を見るように

日本のIT業界は基本的にアメリカのパクリなのでアメリカのIT情報を英語で取っていれば予測できる。(最近だと中国もだが)一歩早く把握するために1つのメディアでいいから(techcrunchとかミーハーどころでいい)フォローしておくとよいかも。

海外のIT企業をcrunchbaseで見る癖をつけよう

www.crunchbase.com/

ここで資金調達の情報を中心に企業ごとにニュースを見れる。

IRをチェックしよう

調査対象が上場企業ならIRを見よう。

スタートアップをなめるな

IT系はつねにスタートアップの脅威を考えていないとすぐに抜かれる。しかし、スタートアップの情報は意識しないと取れない。おすすめはwantedlyを定期的に見る。wantedlyを見ればスタートアップの求人情報が見れ、求人は会社が将来やりたい事の要約である。ここを追っていれば予測ができる。

本よりSNS

本より優秀な人のSNSを見よう。anypayの木村さんは神。

twitter.com/taiga__
twitter.com/ashikagunso
twitter.com/ariyasu
twitter.com/pengin_two
twitter.com/santamariaHORI
www.facebook.com/hkunimitsu?fref=ts
twitter.com/ka2aki86
twitter.com/usksato
twitter.com/shinzizm2
twitter.com/ari_kou

本ではなく自分で調べる、研究するのが最速

本で学ぶことは半年以上前の事象であることが多い。つまり自分で日夜研究している人と本でしか物事を研究しない人では半年以上差がつく。そのためニュースやプロダクトの数字などで常に自分で研究するようにするとよいかも。逆に自分のプロ領域で本ではじめて知ることが多い場合、恥ずかしく思わないといけない。本を読んでいや知っとるわい!となるのが理想。

推薦図書

  • プロフィット
    • toBの交渉をする際にまず気をつけたいのがその会社が何を利益にしている会社なのかということ。そこを見誤ると交渉が平行線になる。この本を読めば大抵の会社のビジネスモデルを網羅できる。
  • 起業のファイナンス
    • 上にも書いたようにスタートアップを中心に競合他社の動きには常に気を使わないといけない。株主情報やファイナンスの情報は長期的な戦略をよく表しているのでファイナンスの知識を網羅し、IR、株主比率などを見れば違った見方ができる。
  • ポール・グレアムのエッセイ
    • IT企業にいるなら読んでいないと恥ずかしいやつ。ポール・グレアムの考え方でセールスについての考え方は特に参考になる。営業経験や小売経験があるとどの商材にどれくらい人が金を払い、どんな表情でどれくらい考えるかが分かる。セールスに行き、顧客の表情を見る経営者、プロマネは非常にその辺のセンスが鋭敏。
  • なぜ日本は〈メディアミックスする国〉なのか
    • 製作委員会がメディアミックスに及ぼす影響についてよくまとめられている。マンガアプリは今後どうアニメ化、映画化させるかが非常に重要な産業なのでこの辺の仕組みは勉強しよう。

プロダクトがうまくいかないときに陥りがちなこと

プロダクトは基本的にいきなりうまくいかないもので色々試行錯誤して方向性を決めていくもの。ただうまくいかないと陥りがちなことというのは結構パターンがあるなと最近感じてきた。最も多いのは社内のプレッシャーに押され、短期的な成果を上げる施策にばかりフォーカスしてしまうことだと思う。

プロダクトを作ってその方向性を決める。つまり幹となる部分を探す段階においては長期的に効く、再現性の高い施策を探さないといけない。しかし、うまくいかないと社内のプレッシャーやら何やらですぐに成果を出したいと思いがちである。そうなるとたいして再現性がないのにちょっとした成果をあげられる施策に走りたくなる。その結果、小さい成果しかあげられない小さくまとまったプロダクトになってしまう。

とは言え、社内やメンバーのまだ成果でないのかよ。。。このプロダクトは大丈夫なのか。。。という声はプロダクトマネージャーなどプロダクトの方向性を決める人間に取って死にそうになるぐらいつらい声かも知れない。でもそれの対策は小さい短期的な施策で行うべきではない。ある程度の期間そういった声をあまんじて受け、最終的に本質的な施策を行い、その成果で黙らせるべきだ。

それにはプロダクトマネージャーだけでなくて社長やもっと上の経営層の覚悟も必要かもしれない。

というのをセンゴク一統記の13巻で学べます。徳川家康が豊臣秀吉に戦い挑むんかーと尻込みしているときにここで戦わないと長期的に見たときにまた弱小大名として周りの目をきにしていきないといけない。ここで勝負しようと叱咤する場面は何千回読んでも泣ける。

© 2018 you88blog. All rights reserved.

テーマの著者 Anders Norén.