やまだもとやすのブログ

チャリ走社長@スパイシーソフト→山田元康→HTML5スタートアップ社長@Liberapp

なぜ一日四時間もTwitterをするのか? その四つの理由

Skyland木下氏におすすめされて、今年(2018)の夏ぐらいからTwitterをやっています。10月はくじけて中断していたのですがその後再開しました。11月末にフォロワー1000人突破して、先日1700人突破しました。

ちょうどその日にEntaで知り合った方とお茶した際に自分で熱く語っていた「なぜTwitterをやるのか?」についてまとめたいと思います。

理由① 壁打ちをして考えを深めたり仮説検証をする

僕は、一人で自分の考えをまとめるタイプではなくて、人と会話して議論する中で、いろいろ気づいて考えがまとまるタイプです。 なので、ビジネスの方法論、技術、競合の動き、市場の未来の可能性について、会社の中で会話してるぐらいのつもりで、気軽に人に絡んだり、ニュースに絡んでツイートしまくることで、自分の考えを深めたり、自分の考えに対するフィードバックを見て考えを見直していきます。

理由② 緩やかなプロジェクトパートナーを増やす

やりたいこと、やってること、考えていることを伝え続けることで、プロジェクトに興味を持ってもらえる人が増えて、一緒に新しい世界を作ってくれる人や、応援してくれる人を増やしていけるからです。

bosyuみたいな募集するといった目先の話ではなく、Twitterでの会話を通じてゆっくりと、緩やかなパートナーの輪が広がるイメージです。

理由③ 助走期間を取ることが大事だから

僕は、事業を開始するタイミングが市場の他のプレイヤーより少し早いことが多いようです。またそういう時に勝ったことが多いと思ってます。逆に成長期に後追いで真似して参入したケースで勝てたケースはありません。 早めに事業をはじめるので、まだ事業の形がしっかりとみえていことが多いです。その際に、早めに経営資源(ヒトモノカネ)を投入していくと、事業の形をさぐれないまま、赤を掘り続けます。

PMF(Product Market Fit)前のフェーズでは、仮説と検証をとにかく速く回したい。またそのフェーズにあった人材が必要だし、いつ金鉱を掘り当てるかわからないので、バーンレートを落とす必要がある。

さらにより人より早い段階の参入タイプであれば、いきなり会社として事業を始める前に、さらに助走期間をとったほうがいいと思っています。

4 助走するプロジェクトを持つことで、経営資源を使うのは4つだけにフォーカスする

僕はやりたいことがたくさんあるタイプの人です。気がつくとやりかけのプロジェクトが増えてしまいます。それなので、アクティブなプロジェクトは「4つまで」と決めています。4つ以上だと流石に集中しきれていない感じがします。

なのでそれ以外のプロジェクトは我慢するようにしていますが、変に我慢するよりこの間を助走期間として、Twitterで壁打ちするようにしています。

実際に人を雇ってアイディアの検証してるとコストがかさみますが、Twitterで壁打ちして検証している間はタダです。さらには、興味を持ってくれる人や応援してくれる人が増えます。

ということでお分りいただけたでしょうか?

これが僕がTwitterに毎日張り付いてる理由です!

コミュニティーマーケティングを10倍加速させるTwitter&Togetterの活用講座

このブログは、コミュニティマーケティング Advent Calender Day 12/14のエントリーです。

コミュニティーマーケティングとは、「コミュニティ」という手段を用いたマーケティング手法です。「コミュニティマーケティング Advent Calender Day 」は、CMC_Meetupさんが企画・運営しているアドベントカレンダーです。CMC_Meetupは、Community Marketing Community Meetup の略で、アマゾンウェブサービスジャパンでマーケティング本部長を務めていた小島英揮氏が手掛ける 、コミュニティマーケティング に関するナレッジの 言語化、 共有、 ブラッシュアップのコミュニティーです。

自己紹介

私、山田元康(ヤマダモトヤス)は、1999年にスパイシーソフト株式会社を起業して、iアプリ等のマーケット「アプリゲット」や、カジュアルゲーム「チャリ走・糸通し」等のゲーム配信を手がけていました。2018年からは新しい事業に取り組むために、新会社「Liberapp」を立ち上げ。HTML5アプリのプラットフォームを手掛けるスタートアップを経営しています。

最近スタートアップの経営者は初期顧客も人材も自分のネットワークから探すべしという持論を実践すべくむちゃくちゃTwitterに力を入れています。 Twitterアカウント→@MotoyasuYamada

今日のお題

CMC_Meetupの主催をする小島さんは「コミュニティーマーケティング」には「オフラインファースト」が重要性を提唱しています。しかしながら、コミュニティーを強化して拡散していくためには、FacebookTwitterなどのソーシャルネットワークの活用が重要になります。

それではまずこちらのサイトをみてください。2018/11/12に開かれた第10回目のミートアップに関してつぶやかれたツイートのまとめです。

f:id:motoyasu-yamada:20181204143718p:plain togetter.com

今回は、コミュニティーを運営するにあたり、どのようにTwitterを使うべきかを簡単にご説明いたします。

前提のお話:Twitterとは?

Twitterの特徴についてまとめます。

  1. Twitterは潜在ターゲットにリーチできるSNSです。比較すると、Facebookは、既に出会った顕在層との関係を強化するSNSです。
  2. Twitterのツイートはストック性が低くフロー型のコンテンツです。

拡散性があるTwitterのツイートをストック型に変えるには?

Twitterのツイートを集めて公開できるウェブサービスTogetter(トゥギャッター)というサービスがあります。 このTogetterを使いフロー型のコンテンツであるTwitterのツイートをストック型のコンテンツに変えます。

Twitterのツイートでミートアップのライブ感を産み出し多数の潜在ユーザにリーチすることができます。 前回のミートアップでは日本のトレンド8位に入っています。

しかしながらTwitterは流れが速いのでツイートは流れ去ってしまいます。それをTogetterでツイートをまとめることで、フロー型のツイートをストック型のコンテンツに変え資産に変えることができます。

一番大事なこと

あくまでもツイートされたものをまとめるサービスですので大事なことは、みんなに「ツイート」してもらうことです。

  1. 使ってもらいたいハッシュタグをしっかり決める
  2. 毎イベントのオープニングで「ハッシュタグ」は繰り返し伝える。
  3. 毎イベントのオープニングで主催者が「①ツイートしてください」「②エゴサーチして誰がどんなツイートしたおっています」「③アウトプットファーストがコミュニティーマーケの基本です」としつこく伝える

主催者はこの3つを徹底して、まずはみんながばんばんツイートする状況を作ってください。

Togetterまとめを作る理想の流れ

Togetterまとめを作り活用するための時系列の流れをまとめました。

1. イベントページオープン時

イベントページがオープンしたと同時にTogetterを作成しましょう。 またイベントページには過去のTogetterまとめを掲載しましょう。

2. イベント前

一週間前、三日前ぐらいでいいので、すでにツイートがされている可能性がありますので、まとめを更新しましょう。 「申しこみました」とか「参加します」といった宣言ツイートは、参加しようかどうか迷っている方の後押しになります。

3. イベント当日

スマホでほぼリアルタイムに更新します。そうすることでライブ感が見える化されます。

4. イベント終了後

イベントの翌日、三日後、一週間後ぐらいで構いませんので、イベントの余韻である感想ツイートなどをまとめます。

5. 資料の回収都度

イベントの価値を高めるためにも、イベントに登壇いただいた方は、可能な限り発表資料をスライドシェアなどで公開していただくように依頼します。 登壇いただいた方の資料を回収しだい、Togetterにまとめていきます。

現在のTogetterまとめの構成

現在CMC_MeetupのTogetterまとめはこのような構成にしています。

  1. コンテキストの説明
  2. ミートアップの説明
  3. 過去のまとめのまとめ
  4. ミートアップのアウトプット
  5. みなさんのツイート時系列

1. コンテキストの説明

まず、CMC_Meetupであれば、そもそもの「コミュニティーマーケティング」とはについて簡単な説明をしましょう。 また、CMC_Meetupというミートアップそのものについても簡単な説明をしましょう。

(例) f:id:motoyasu-yamada:20181204151306p:plain

2. ミートアップの説明

ミートアップ自体の詳細は、イベントページに記載されていると思いますので、本当に基本的な下記の情報だけでいいと思っています。

  • 概要
  • 日時
  • 場所
  • イベントページへのリンク

(例) f:id:motoyasu-yamada:20181204151400p:plain

3. 過去のまとめのまとめ

今回どうTogetterを運営すべきか整理するなかで気づいたことで現在はできていません。 過去のまとめをまとめることは大事ですので、最新のTogetterには過去のTogetterをまとめましょう。

4. ミートアップのアウトプット

ミートアップに登壇していただいた方の資料をまとめます。 イベントのアジェンダをベースに、メインの登壇者の資料、LT登壇者の資料をまとめていきます。 また、ブログ等でイベントの感想などをまとめる方がいた場合は、そちらもTogetterにまとめるのがおすすめです。

(例) f:id:motoyasu-yamada:20181204151443p:plain

5. みなさんのツイート時系列

このような形でCMCMeetupについてつぶやいてくれたツイートを集めていきます。

f:id:motoyasu-yamada:20181204151539p:plain

その他

資料をどう回収するか?

まず、Facebookに、顕在メンバー(参加した人・参加予定の人)向けのグループをつくっている前提です。 参加予定の人、参加した人、わすれてはいけないのが登壇者には、グループに参加してもらうように主催者はプッシュしたほうがいいです。 プッシュして嫌がれれるよりも、参加いただいて有益な価値を感じてもらうほうがいいです。

イベントが終わったら、Facebookのグループに下記のような資料回収専用の投稿を作成します。 f:id:motoyasu-yamada:20181204152720p:plain

登壇者にはそこに資料のURLを投稿していただいてください。

資料を投稿いただいたら、Togetterの更新担当者は、まとめおわったら次のようにシオリがわりの投稿をします。

f:id:motoyasu-yamada:20181204153038p:plain

どうツイートを検索してまとめるか?

Togetterにまとめるツイートを検索する際は、ハッシュタグそのものではなく「ハッシュ(#)」を外して検索します。

イベントでツイートを促す場合は、ハッシュタグでの投稿を促すべきです。

ただハッシュをつけずに投稿する方は多いので、Togetterにまとめるツイートを検索する際は、ハッシュを外します。

つまり、「#CMC_Meetup」で検索するのではなく「CMC_Meetup」で検索するのがおすすめです。

最後に

Facebookは、知り合いとの交流をふかめるのに素晴らしいソーシャルプラットフォームですが、マーケッターやスタートアップ経営者のように潜在層にアプローチしたい方にはTwitterがおすすめです。

私も、スタートアップのメンバーを集めたり、初期ユーザやパートナーを集めるためにTwitterをむちゃくちゃ頑張っています。

こちらのTwitterアカウント@MotoyasuYamadaですので

ぜひフォローしてください!

ぜひフォローしてください!

ぜひフォローしてください!

(笑)

ガチプログラマーがリファクタリンしたときに感じたWordpressでコーディングする際の注意点

最近、既存のWordpressを修正する機会がありました。デザインは崩れているし、ソースコードを触るのは辛い状態だったので、大幅にリライトしてリファクタリングしました。テーマを既存のテーマAffingerに切り替えて、機能を実装するために本当に必要な最小限のソースコードに書き換えた結果、メンテナンス対象のソースコード量は一桁どころから二桁ぐらい減らせた印象です。

いままでちゃんと技術的な品質の管理や指導をしていなかったと反省です。

せっかくいろいろいじったので、ガチプログラマーがリファクタリンしたときに感じた、Wordpressでコーディングする際の注意点をまとめてみました。

既存のテーマをベースにするなら既存のテーマの思想や機能を活かして必要最低限の実装をする。

フルスクラッチでWebサイトを制作する時のように、理想ベースでワイヤーフレーム、カンプを作って、開発・制作に入るならば、Wordpressのテンプレート階層などをしっかり理解して、必要十分にフルスクラッチでテーマを独自実装したほうがいいと思っています。

しかしながら本当に自分たちが作りたいWebサイトにそこまでのオリジナリティーが必要かどうかは立ち止まって考えたほうがいいです。既存のテーマを活かせば、多少独自機能をいれても数日でも終わってそこそこの見栄えになります。しかしながらフルスクラッチで書けば、しっかりやらないとデザインは残念になりますし、工数も数倍以上に膨れ上がる可能性があります。

また逆に、Stingerなどの既存のテーマを利用しているのに、既存のテーマの思想や機能を活かさずに開発や制作すると、思ったように動かすのに逆に既存のテーマの実装が足かせになって大変になります。既存のテーマを使うならば、既存のテーマの思想や機能を熟知して、どこまでカスタマイズできるかをしっかり把握すること。そのうえでそれを活かした自分たちのサイトの設計をすることが大事です。

子テーマを使う

これはやってあたりまえの話です。カスタム投稿タイプやタクソノミーなどを活用して独自機能を実装する場合は、どうしてもテーマのテンプレートファイル等のPHPファイルのカスタマイズが必要になります。

ここで絶対やってはいけないのが親テーマそのものの修正です。既存テーマは多機能なので当然コード量も多い。そこを直接様々な個所をいじるとメンテナンス対象のコード量が爆増します。また、既存テーマがアップデートされた際に、それを取り込むのが難しくなります。

子テーマを使えば、独自実装部分が明確にわかるし、また独自実装の範囲が狭くなるので、把握しなくてはいけないメンテナンス対象のコード量が劇的に減ります。

ExePHPは使わずにショートコードを使う。

これも常識の範囲の話で、とにかく ExePHPは絶対に使用しちゃダメ。プログラムを記載する部分は、ショートコードなどを使いCMSから書くコンテンツから必ず切り離して、プログラム部分はGitで管理できるようにしましょう。

テンププレートにロジックを記載しない

テンプレートには、可能な限り条件分岐などのロジックを記載しないのがベストです。例えば、新着フラグを表示したいようなケースで、下記のような記述をテンプレートに直接書くのはやめましょう。

template.php

<?php
    if (date('U', (date_i18n('U') - get_the_time('U'))) < 24 * 3600 ){
       echo '<span class="newlavel">New</span>';
    }
?>
<h2><?php the_title();?></h2>

こういった場合は、独自テンプレートタグを実装して、テンプレートは <?php the_xxx(); ?> のようなテンプレートタグを呼び出すコードを記載する。そして、functions.phpなどに独自テンプレートタグ関数を用意して、テンプレートからロジックを分離しましょう。

template.php

<?php the_new(24);?><h2><?php the_title();?></h2>

functions.php

function the_new($hour) {
    if (date('U', (date_i18n('U') - get_the_time('U'))) < 24 * 3600 ){
       echo '<span class="newlavel">New</span>';
    }
}

ショートコードの実装関数や独自テンプレートタグ関数にロジックとHTMLが混在させない

さっきの例は下記のようにするとむちゃくちゃメンテナンス性があがります。

functions.php

function the_new($hour) {
    if (date('U', (date_i18n('U') - get_the_time('U'))) < $hour * 3600 ){
       get_template_part('partials/new-labe.php');
    }
}

partials/new-label.php

<span class="newlavel">New</span>

ショートコードでも関数内にHTMLを直書きしないでget_template_partで外だししましょう。

空の固定ページ&テンプレートでHTML実装をやめる

例えばslugがhogeな空記事の固定ページを作成して、固定ページ用テンプレートpage-hoge.phpを用意して、すべてHTMLに直書きをするのは避けたいです。

絶対にダメなわけではありませんが、運用中に文章の変更などが、簡単にできなくなります。

こういう場合は、固定ページの記事に、エディターを使って静的な記述を行うこと。どうしても必要な動的な記述はショートコードに分離したほうがいいです。

ハイコンテキスト病に立ち向かう

友だちから「IQ高いひとはハイコンテクストで周りとゴールを共有できないことがあるので気をつけて!」とアドバイスを受けました。

IQ高いかどうかはさておき、「ハイコンテキストでいろいろ共有できてないことが多い」というのは、間違いなく事実です。

背景には、会社の代表である、市場・会社や事業を20年弱見続けているので、ハイコンテキストなつもりなくても、ハイコンテキストなところがあります。

ただしそこを除いても、ハイコンテキスト流に、コミュニケーションへの労力を疎かにしている自覚はあります。

いろいろ考えると理由としては、帰納法演繹法的が好きで無意識に相手に要求する。職務上の複数の立場に応じた使命・責任などを切り替えて考える癖がありそれを相手に要求してしまうところではないかと、思っています。

基本的には、相手のレベルにあわせて何をすればいいのかわかるように噛み砕く。何をすべきか考えさせるのではなくて、まずやるべきことをストレスなくできるように導く。行動して体で覚えてもらう。

その上で何故そうしないといけないかを伝える。自分が帰納法演繹法的に考えたことを簡潔に伝える。が、基本伝わらないものだと思って、根気よく話し続ける。

と、頑張ってみます(≧∇≦)

大雪対応のふりかえり

先日の大雪ですが、うちはマニュアルがあるから大丈夫でしょ(http://motoyasu-yamada.hatenablog.com/entry/2018/01/23/100751)と安心していましたが、なんとなく気になることもあり社員アンケートをとりました。

やはりいくつか大きな問題がありました。

  1. こちらのマニュアルは知っていた。(Y/N)
  2. マニュアルにのっとってオペレーションした(Y/N)
  3. 昨日の対応時に不安なことはなかったか?もしくはマニュアルに不備などなかったか?
  4. あらためてマニュアルを再度読み直してください。何か質問・提案・改善できることありますか?

それに対する社員のみなさんからのご意見

発動条件を変えるべき

よく見るとマニュアルの字面通り対応していたら、問題が起きていた可能性がありました。 しかし、みなさんが趣旨を理解してくれて、無事問題はなかったようです。

発動条件を見直す必要があります。

また、リモート対応が可能な場合は、途中帰社・出社は無駄なので、全日リモート対応できるべきかもしれません。

  1. 今回の場合は日曜の時点で警報レベルの積雪との予報だったので、出社前にリモートに切り替えるとかの対応で良かったと思う
  2. 14:30の警報に気づくの遅れた。家が近いため帰宅と業務に問題ないと判断して社内にいました。18時前後だと帰宅までに通常より時間かかると予想できたので、時間をずらして帰宅しましたがそれでも混んでいた。大雪だと翌日以降も影響大きく事故が起こりやすいので、早めの帰宅にすべきだったと思っています。
  3. 警報が出たときにはすでに遠い人は帰るのが難しくなりそうな状況だったので、警報がでなくても起きることが明らかなときは自宅勤務に切り替えなどしてほしい。
  4. 警報ではなく、「注意報」か「警戒呼びかけ」レベルで前日に判断してリモートの指示をするのがよさそう。帰りはどうしたって混む。
  5. あらかじめ大雪になると予報されている段階で勤務中に警報が出てからの行動では遅いと思いました。
  6. 警報が出てから対応すると遅いので、気象庁から「不要不急の外出を控える」呼びかけがあった場合、警報と同じとみなすなどのルールのほうがとよいかも

休業ではなくリモートワークにならないかという要望

法律の問題(参考資料)があるために、デフォルトは休業にせざるをえないと思っています。 しかしながら、仕事の種類・リモートワークの経験値から、条件が整っている場合に限りリモートワークを可能としてもいいかもしれません。

  1. 警報で帰宅した後、可能ならば作業するでよいと思います。 完全休業はせず、足元が悪くなる前に少し早めに会社を出て残件はリモートで作業しました。
  2. 大雪警報時は完全休業ではなく、リモートでの業務がありがたいです
  3. 警報が出る前に帰宅しリモート作業にしました。電車も混雑ありませんでした。出勤時に台風が迫っている時はマニュアルにのっとって行動しました。
  4. 休業で土曜日振替は負担が大きいので、リモート勤務のほうが助かる
  5. 休業した分は休日に振替出勤となっていますが、休日予定があったりするので、警報が出た日は家でリモートだったらありがたいです。
  6. リモート切り替えにするオペレーションにアプデしたほうがよいと思いました。
  7. 休日振替がうまくいかなそうなのでついそのまま業務してしまう

きっちマニュアルを作り強制させないといけない

正常性バイアス」があるので、責任者の判断任せとか、個人の判断を尊重すると、大きな被害がでます。

  1. 思ったよりみんな帰らなくて不安になった。
  2. 早めに帰ったほうがいいのでは?みたいな感じが僕と杣さんくらいだったので、不安というかみんなそんな感じなのか...と思った
  3. 大雪警報なので災害時より緩く考えていました。マニュアルは確認しましたが業務のきりが良くなるまで会社を出ませんでした。
  4. 警報で休業は見落としていたが、近いので支障はなかった
  5. オペレーション事項を失念していたのもあるが、家が近いとなんとか行ける&帰れると思ってしまっている。

大雪などの場合の対応もマニュアル化して各自が自主判断できるようにする

上司の仕事の一つが、日常的ではない出来事が起きた場合の判断です。

日常的ではない出来事が、上司がいるときに発生する、また上司が経験豊富だったらいいのですが、 上司が現場におらずに現場の状況を把握できなかったり、経験不足のまま判断を迫られたりで、適切な判断ができないことがらいます。

とはいえ、日常的ではないことの大半も、毎日起きないというだけで、年に何回かは起きることが想定されます。

なので、大雪などの場合の対応もマニュアル化して各自が自主判断できるようにしています。 大概の判断は、条件式をきっちり記載すれば、自動化できると信じています。

昨日はとくに判断を仰がれませんでしたが、なのである程度みんなが自主的に判断して動いていました。 うちのマニュアルでは次のようになっています。

基本的な考え方

  • 出社が非効率的になるときは、出社しないで在宅で勤務する。天災・交通災害、育児・介護が原因の場合は特に。
  • ルールを整備します。ルールをもとに各自が自主判断できるようにします。
  • 追加のルールが必要な場合は、提案してください。

災害時(台風等)への対応

台風等により、気象庁から本社の所在地域に「暴風警報」が発令された場合、以下の基準により勤務の基本時間の変更措置をとります。 所在地: 東京都新宿区 警報の確認先: 気象庁

通勤時の判断について

  • 通勤経路で、警報がでている場合は、上記警報と同様に考えてください。
  • 余波・影響により、通勤経路の公共交通機関が運休している場合は、上記警報と同様に考えてください。

<考え方>

  • 準備を含めた通勤のために3時間が必要とする。
  • 勤務時間帯の3時間前までに警報が解除されなければ、その時間帯は休業とする。
  • 12:00を超えても警報が解除されなかった場合は完全休業とする
  • 勤務時間中に警報が発令された場合は即時その日を完全休業とする
  • 一部時間帯が休業の場合は終業時間を22:00まで延長する。
  • 勤務可能時間が、4時間未満になる場合は、その日は完全休業とする。
  • 一部時間帯休業の場合は、その月の他の営業日の基本勤務時間を延長する。
  • 完全休業の場合は、「次の土曜日を出勤日にふりかえる」。月末で振り替えられない場合は、その月の他の営業日の基本勤務時間を延長する。
  • 各部門での管理者が指示に従い、警報の発令や解除をふまえた対応をすること。
  • 管理者からの指示がない限り、原則、一部時間帯休業または完全休業とする。出勤や自宅勤務は、控えるものとする。
  • 管理者が緊急かつ重要な業務があると判断して指示があった場合に限り、一部時間帯休業または完全休業を自宅での勤務にすることがある

<時間帯と警報解除期限>

営業時間帯 警報解除 9:00-12:00 6:00まで 13:00-15:00 10:00まで 15:00-18:00 12:00まで

いま見ると気になるところが二点。

  1. 台風を軸に記載されている(もちろん限定されていないがわかりづらい)
  2. リモート勤務がなかったころの名残でリモート勤務ではなく休業となっている。

今回は何もありませんでしたが、これを機会に来年へ向けて改善しておきます。

プロダクト愛

「プロダクトへの愛」が大事。

プロダクト作りや運営のおいて、たまに「作りたい病」にかかってしまうことがある。

作りたいという想いがダメではなく、プロダクト愛に欠けるのがよくない。

ゲームならば、プロダクト愛とは、「遊んでくれる人に楽しんでもらいたい」が、とにかく重要。

「遊んでくれる人」に楽しんでもらおうという気持ちと無関係に、俺の自由に作りたいというだけのオレオレ病になってはいけない。

次に大事なのは、遊んでくれる人を理解するために、ターゲットとするユーザーが使っている競合や代替プロダクトの研究をすることだと思っています。

ちゃんと楽しんでもらうには、実際に遊んでくれる人をイメージして、どのような気持ちで何をしているのかを理解していく努力が必要だと思っています。