人は全行動の4割が習慣。『習慣Hack』のススメ
1月は頭をチョー柔らかくするために
刺激を求めて勉強会やら飲み会をほぼ毎日徘徊してました。
次のサービスも「習慣をHackする」という切り口で作りたいなぁと思って
勉強していたところ、良書に出会いました。
その名も『習慣の力』(まんまですね)
この分野って心理学、認知科学、脳科学、社会学とかいろんな切り口があって、
それぞれ深堀りしようとすると結局自分が探していた情報はどこにあるんだっけ？
という感じでよく迷子になってしまいます。
一方で、この本は「習慣」という切り口でまとめ上げてくれてるので、
非常にスムーズに吸収できた感じがします。
ライフハックとしてもマーケティングツールとしても
この「習慣の力」はとても強力なものになりうると確信しました。
■習慣のメカニズム
習慣とは以下３段階をループすることであると定義されます。
①きっかけ
②ルーチン
③報酬
ねずみによる検証実験では以下の感じです。
①音がする(きっかけ)
②迷路を進む(ルーチン)
③チョコレートをゲットする(報酬)
繰り返すことにより、ルーチン部分で脳はあまり労力を使わなくなります(=無意識な行動へ)
この繰り返しを続ける動機は「報酬」が得られるからです。
また、繰り返しによりルーチン部分の労力は徐々に軽減され、
脳は「きっかけ」で「報酬」を期待するようになります。
いわいるパブロフの犬ですが、
人の脳も基本原則は同じで、取り巻く環境がちょっと複雑なだけです。
「きっかけ」と「報酬」に人によって多様性があり、
本人が気づいていない場合が多いという点で
深い考察や統計的なマイニングが必要とされます。
＜煙草の例＞
①食事を終える/大事な会議が終わる(きっかけ)
②喫煙所を探して煙草に火を付ける(ルーチン)
③リラックスできる/誰かと雑談できる(報酬)
＜ランニングの例＞
①NIKEの動画を見る/ランナーを見かける(きっかけ)
②靴ひもを結んで、いつもの道に出て走る(ルーチン)
③ストレス解消、爽快感、達成感(報酬)
■習慣化に成功したプロダクト
世の中にないプロダクトは往々にして、
人の習慣の一部には組み込まれていないものです。
つまりは「きっかけ」と「報酬」を考えて売り出す必要があります。
もちろん、その過程は思考錯誤に満ちているのですが、
その過程がとても勉強になります。
＜歯磨き粉の例＞
①歯磨き粉を使えば歯が綺麗になるというコピーを見る(きっかけ)
②歯を磨く(ルーチン)
③舌がヒリヒリして、口内美化されたという感覚(報酬)
※実際にはヒリヒリした感覚は口内美化とは関係ないものの、
人は美化されたという感覚(=納得感)を報酬として見出した。
＜ファブリーズの例＞
①掃除をする(きっかけ)
②掃除が終わったらファブリーズを吹きかける(ルーチン)
③いい香りがして、清潔感が味わえる(報酬)
※最初に発売されたファブリーズは無香料で大ゴケした。
主婦の行動観察で、掃除の終わりに吹きかける人がいることから、
掃除というルーチンに組み込むことに成功した。
どちらの例も「欲求」が習慣のループを始動させ、継続させている。
どちらの例もその「欲求」を見出すために多大な労力を払っている点で、
新しい習慣を作りだすのには大きなエネルギーがいることがわかります。
■習慣の性質を利用した、ルーチンの置換
前述の通り、新しい習慣を根付かせるのはかなりのエネルギーを使います。
一方で、ルーチンの置き換えはそれに比べれば比較的容易に可能です。
(1)そのルーチンのきっかけと報酬を理解する。
(2)同じような報酬を得られるルーチンを考える。
(3)きっかけがあった場合に新たなルーチンを実行する。
(4)脳が得られる報酬が同じであれば、それは習慣化する。
＜アルコール依存症の例＞
①不安や寂しさを感じる(きっかけ)
②アルコールを飲む(ルーチン)
③安堵感を得る(報酬)
↓
①不安や寂しさを感じる(きっかけ)
②アルコール依存症の集会へ参加する(ルーチン)
③安堵感を得る(報酬)
＜爪をかむ癖の例＞
①指に緊張を感じる(きっかけ)
②爪を噛む(ルーチン)
③スッキリする(報酬)
↓
①指に緊張を感じる(きっかけ)
②ポケットに手を突っ込む(ルーチン)
③スッキリする(報酬)
■人が習慣を変えるタイミングはいつか？
「人生における大きなイベントを経験するとき」
結婚した、家を買った、子供ができた、入学した等の
大きなイベントを経験するときに人は新しい習慣を身につける必要があります。
言い換えるならばこのタイミングは新しい習慣の提案を受け入れやすい状況にあります。ルーチンは継続的なビジネスに直結するので、
世の中のマーケター達はこのタイミングを見逃すまいと躍起になっています。
例えば、今はスーパーマーケットの購入履歴から、
この人が今妊娠している確立は○○%で妊娠○カ月目と予測できたりします。
これがわかれば、継続的な消耗品であるおむつやミルクをこの顧客に
買ってもらうよう仕向ければお店は売上を伸ばすことができます。
(例えば関連するクーポンをユーザーに提供する等)
Tポイントとか、相当ゴリゴリに顧客をマイニングしてるんだろうなぁと思いますし、
リクルートが各ライフイベントのマインドシェアをとることに躍起になっていることも頷けます。
サービス提供サイドでサービスを習慣化させるという視点で
まとめてみると以下の感じになると思います。
(1)大きなライフイベントのタイミングで発生する習慣に注目する。
(2)その習慣の報酬は何なのか考察、観察して確度の高い仮説を得る。
(3)その報酬を満足させるサービス(ルーチン)を作りだす。
(4)きっかけのタイミングに焦点を当てマーケティング注力する。
どんなルーチンも最初に実行するときには脳は労力を使ってしまいます。
なので、シンプルに報酬までたどり着ける導線を用意して、
粘着性を上げる意味で、ルーチンと報酬を徐々に大きくしていくのがいいのではないでしょうか。
私自身、HALF STEPというサービスを出しましたが、ルーチンばかりを押し出して、
「きっかけ」と「報酬」の設計がお粗末であったと反省しています。
計画初期段階からマーケットとの接点が弱い(きっかけに乏しい)と指摘があり、
リリースしてから「何のためにしてるのかわからなくなる」(報酬に乏しい)という
ユーザーフィードバックを頂いてました。
ようやく次の一手を打つために動き出せる気がします。
【完結編】すでに知的生産物に国境はない。 海外クラウドソーシングで作るiphoneアプリ<part Ⅲ >
「失敗するかもしれないね」
「でも、失っても数十万円ならやる価値あるよね」
「やってみるか」
そんな会話で始めた海外クラウドソーシングで作るiphoneアプリの最終章になります。(PartⅡ：http://tanakajiro.hatenablog.com/entry/2014/12/12/185237)
■開発■
パキスタンのデザイナーHafizのデザインも終わり、
ここからはインド人開発者Mukeshがバリューを発揮します。
<Q1>開発を着手するのに何が必要か？
必要最小限なドキュメントは仕様書とUI遷移がわかるものです。
たぶんいろんな仕様書の書き方とか本があると思いますが、
開発者が困りそうなところを明確にするというのが目的で、
細かすぎて読むのダリーよってなってもいかんし、
粗すぎて考える余地を与えすぎちゃうのもよくないという思想で書いてます。
なので、こだわりがあるポイントの深度は深く、
一般的な機能の部分はさらっと書いておけばOKだと思います。
(1)仕様書
-ユースケース
ユーザー視点に加え、システム視点とスタッフ視点のものも用意しました。
結局何が出来ればいいの？ということを網羅的に見れるメリットがあります。
-機能一覧
どんな機能が必要なんだっけ？というものの一覧になります。
-機能毎のシーケンス図
その機能を実行する時にユーザー、クライアント、サーバーがどんな順番で
どんな情報をやりとりするのかを表現した図になります。
-機能毎のフローチャート
その機能が条件分岐する場合や何かアクションをして欲しいことを
表現した図になります。
-機能毎の詳細条件
例えばユーザーネームは何文字以内とか、時間はローカルタイムで表示とか、
そういった細かい設定を思いつく限り書いておきます。
ここで細かく書いておかないと、書いてないじゃんと言われちゃいます。
※セキュリティの関係でUPはやめておきます。
(2)UI遷移を表現するもの。
Prottにデザイナーが作ってくれたものをアップロードすればできます。
※こだわりのある動きはこのツールでは表現できないので、
このタイミングで文章で具体的に伝えておいた方がよかったです。
<Q2>DBとかAPIの設計とかいらないの？
本来的には設計して渡すのが親切だと思います。
でも、今回はデッドラインがあったので、エンジニアに設計をお任せしました。
ちょっとしたジョークなんですが彼の最初の設計書は手書きのノートをPDFにしたものでした。
これにはN氏と一緒に爆笑してしまいました。
でも、内容はしっかりしてたし、ちゃんと伝わりました。
相手にきちんと伝われば方法は何でもありだな、としみじみと感じさせる出来事でした。
※後にちゃんとテキストデータに落としましたが。
パートナーのN氏からは「いい仕様書はインターフェイスについて記載している」
＝「サーバーとクライアントがどんな情報をやりとりするのか明記している」
との助言を頂きました。
が、そこまではイメージが湧かず今回は出来なかったです。
※APIってなに？
よくよく出てくるこの単語、わかるようでわからないですよね。
APIはドラクエの村人みたいなものと理解してます。
主人公「アリアハンに行くにはどうすればいいですか？」
村人(API)「あの街に行くには、北にある洞窟へ行けばいい」
という感じで、答えを返してくれます。
知らない質問や異常な質問をすると
村人(API)「そんな街はありません」とか
村人(API)「4文字以上で聞いて下さい。」
という感じで回答を返すこともできます。
要するにクライアント(アプリ)が尋ねるべき村人が
インターネットの中にいて、クライアント(アプリ)が
尋ねると適切な答えを返してくれるイメージです。
※村人の場所はURLで特定されます。
<Q2>開発中のプロジェクトマネージャの役割は何か？
私はその道のプロではありませんので、
仕様バグと言われる「そのまま実装しちゃうとユーザーが困ってしまう仕様」が点在していました。
予め自覚と覚悟があったので以下の原則で動きました。
(1)質問には即レス
エンジニアの手をできるだけ止めてはダメですし、
彼らにとってストレスになってしまいます。
「プロマネからの回答が遅いのに納期を守れなんて横暴だ。
もう知らん！言われたとおりに実装したれ！」となりかねません。
些細な質問にも丁寧に即レスを心がけました。
※とはいえ時差が4.5時間もあるとタイムリーに回答できないこともあります。
なので、googleドキュメントでQ＆Aを内部で回していきました。
(2)回答には背景を添えて回答する
背景に納得してもらえれば、
周辺の疑問を一気に片付けることに繋がります。
これをきちんと説明するのは企画者の務めですし、
結果的に時間短縮につながると考えて時間をさきました。
(3)仕様バグは謝る
素直になりましょう。
そして、少しだけ時間をもらって考えてから回答しましょう。
指摘してくれたことには当然感謝します。
(4)前進と提案は賞賛する
正直、進捗を見せることは彼らにとって本質的なミッションではありません。
なので、見せてくれたら喜ぶべきだし、
モノができてくる喜びはチームで共有すべきだと思います。
ここで、細かくつついてもいいことないので、
向こうがレビューしたいというタイミングまで待ちましょう。
(5)不安なところは専門家に頼る。
ググっても出てこない個別事象やキメの問題はやっぱり経験が必要です。
ここはそう簡単に埋まらない壁があると思います。
私の場合はデザインや見せ方で困ったらDesign Directorの山本氏、
仕様や仕組みの部分で困ったらTech DirectorのN氏に相談して決めました。
予め自分のスタンスを決めて、相談すれば5秒で回答をくれます。
やはり餅は餅屋ですね。
<Q3>テストってどうやればいいの？
テストフライト(自分のiphoneにインストール)してテストします。
oDeskにはテスト専門で飯を食べている人もいるぐらい、
実はこのフェーズは奥が深いです。
でも、そんなお金がなければ自分で試すしかないです。
ただ闇雲にテストしても、モレがどうしても発生してしまうので
「機能軸」×「デザイン,動き,機能,その他」というマトリックスで、
それぞれの項目を網羅的にチェックしていきました。
(1)ver.Xをテスト
(2)不具合をエクセルに記載
(3)ver.X+1をリリース
これを10回以上まわしました。結果として20日ぐらいかかりました。
開発のMukesh氏には「ヘイ、田中、これはいつ終わるんだい？」と言われてしまいました。この部分はかなり経験が必要なんだろうなと思われます。
今回、大失敗したポイントがあります。
時間軸でチェックするのが漏れていました。
結果として、「２日目に使おうとするとフリーズする」
という目ん玉が飛び出るくらい重大なバグを見逃してしまいました。
反省です。※ver1.1で解消させました。
<Q4>開発が終わったら、何をすればいいのか？
apple developerのitunes connectでアプリ名とか説明文とかを掲載して、
作ったアプリをアップロードすれば完了です。
申請ボタンをおしてappleのレビューを待ちます。
今回はなんと奇跡的にappleから申請拒否を受けることなく通過しました。
でも結局10日ぐらいかかっちゃいました。
申請準備物は競合調査とか、画面キャプチャどうするとか以外に時間がかかってしまうので、テスト段階ぐらいから準備をはじめておくのがベターだと思います。
※法人化していないと、複数人でapple developerを使うことはできません。
派生する問題としてCertificatesをうにゅうにょ調整したり、
開発者とappleアカウントを共有しなければならない問題が発生します。
ここらへんは覚悟が必要です。
※後にpalmie(https://appsto.re/jp/rKmx3.i)の伊藤さんからDL数を伸ばすコツとして、
アプリ名とキーワードの設定が極めて重要だという話をお伺いしました。
乱暴にまとめると、ターゲットが検索しそうなワードをアプリ名とキーワードに
詰め込みまくるそうです。※ver1.1で対応しました。
■総括■
一度も顔を合わせたことのない、
しかも異国の人と仕事するわけですが、
一緒にやって感じたのは「直接合わなくても信頼関係は築ける」ということです。
これはプロジェクト始動時の会話の一場面なんですが、
私
「it will happen many problems, but I hope we can coopolate with well.」
Mukesh
「We will manage it together Tanaka.. that's why it's always called team effort.」
この一言ですっかり、私は彼のことを信頼しようと思いましたし、
何よりも彼と一緒に仕事がしたいと思いました。
「こんな言葉、アニメでしか見たことねぇよ」とか、
青臭くて小っ恥ずかしいと日本人なら思ってしまいますが、
シンプルにそう思うなら言うべきだし、言われた方は意外にその気になるものです。
以上、
まずはやってみるから始めるクラウドアウトソーシングによるアプリ開発でした。
最後にはなりますが、
本プロジェクトを一緒に推進してくれた山本氏、N氏がいなければ
100%実行されなかったことをここに添えておきます。
ご拝読ありがとうございました。【完】
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
「今日やることを一つだけ宣言するTodo管理アプリ」
apple store：http://urx2.nu/eQyU
※ご質問/ご意見等あればお気軽にお問い合わせください。
tanaka.j.tomohiro@gmail.com
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
すでに知的生産物に国境はない。 海外クラウドソーシングで作るiphoneアプリ<part Ⅱ >
前回は(2)リソース確保について書きました。
今回はその続きになるアプリケーション開発における(3)デザインについて書きます。
ベストな方法論を述べるというよりは
思考錯誤から自分にあった方法を見つけていく過程をお伝えできたら幸いです。
■デザイン■
(1)サービス企画の段階で、
仕様書とデザインのラフスケッチは出来ていました。
ここではロゴの作成からどうデザイナーとすり合わせていったかを書きます。
<Q1>ロゴのデザインどうするか？
アプリを作る上で、一番最初にすべきはロゴの作成でした。
ロゴの色がアプリ内部の配色に影響し、
ロゴの与える印象がサービスの機能や世界観を表現する必要があったからです。
私としてもここは1ピクセルも妥協したくなかったので、
クリエイティブディレクターの山本氏主導で作成しました。
少し紹介させて頂くと、
山本氏は北京にある建築事務所の建築士です。
都市設計、建築設計、店舗内装、会社ロゴ、アート・フォト等、
マルチな才能と常軌を逸したクリエイティブ精神を持っています。
当然、売れっ子なのでまともな時間には捕まらなかったです。
いつも夜11時とかから2，3時間ミーティングしていました。
初期段階のアイディア着想段階から考えると、
ゆうに100時間以上はセッションしてきたかと思います。
そもそもプロダクト自体、
彼の着想をシードに発展させてきた思い入れもあり、
ロゴだけで着地させるのに20時間ぐらい打ち合わせをしたと思います。
「田中さん、、、デザインは引き算ですよ」
「何がいいのかよくわかんなくなりましたね、競合をスタディしましょう」
と言いながらリードしてくれました。
そんな思考錯誤で出来たロゴが以下になります。
※下記は山本氏とのスタディで使った資料の一部です。
色合い毎に競合を整理してディスカッションしました。
<Q2>デザインはどんなマイルストーンで進めていくか？
常にフルタイムでそこに人がいる会社組織とは異なり、
自分の仕事が終わったらプロジェクトから離脱していくアウトソーシングは
一番最初にゴールを明確にしておかないと相手は怒ります。当然ですね。
ゴール設定で工夫したポイントは
最終成果物はエンジニアが使える形でなければなりませんので、
それをそのまんまゴールに設定したことです。
これで、自分が現時点で見えていないタスクを当事者間で吸収してくれます。
ちょっとずるい感じがしますが、
私が学習してキャッチアップするよりもその方が早いと判断しました。
そんな感じでデザイナーと握ったゴールとマイルストーンは
以下のような感じです。
Disign part goal:client enginner agree with the parts of UI.
(1)Hafiz can access all the works we alredy made.
(2)Hafiz can use prottapp
(3)Refer to the prottapp and UIigames ,Hafiz make the one option of UI
(4)yamamoto review and feedback
(5)make some option of UI
(6)yamamoto review and say Go
(7)Hafiz cut the pic and make UI in prottapp
(8)we discuss about the motion of UI
(9)make the ppt document about motion
(10)Hafiz communicate with Mukesh about the file format
(11)Mukesh get the works you made and say OK.
(1)Hafiz can access all the works we alredy made.
(2)Hafiz can use prottapp
(3)Refer to the prottapp and UIigames ,Hafiz make the one option of UI
(4)yamamoto review and feedback
(5)make some option of UI
(6)yamamoto review and say Go
(7)Hafiz cut the pic and make UI in prottapp
(8)we discuss about the motion of UI
(9)make the ppt document about motion
(10)Hafiz communicate with Mukesh about the file format
(11)Mukesh get the works you made and say OK.
<Q3>デザイナーに期待する成果物をどう伝えるか？
前提として、(1)サービス企画の段階で、
デザインのラフスケッチは出来ていました。
その際に使ったツールはパワーポイントとPrott(https://prottapp.com/ja/)です。
手書きで書く方法もありますが、
私の場合はディレクターが中国にいたので、
デジタルデータを使う必然性がありました。
ちょっと調べてみればすぐにわかりますが、
UIのプロトタイプ作成ツールは世の中にたくさんあります。
いろいろ使ってみた結果、
費用無料＋学習コストが極めて低いという点で、Prottを選びました。
デメリットがあるとすればUI遷移を詳しく表現できないことです。
「UI遷移を表現できないと後でエンジニアとトラブルよ」
という恐ろしい助言を大学時代の先輩からもらっていたのですが、
「UI遷移についてはこだわるつもりなので、よろしくね」という布石を開発者にうっておき、テスト/Bug修正段階で細かく指示を出したらトラブルなく、組み込んでもらいました。
言うまでもなくmotionは使い心地と関係が深いので、
初期段階でキメ打ちするよりはイメージだけ緩く伝えておいて、
テスト段階で実際に使いながら修正していく形がいいと振り返ってみて思います。
実際にデザイナーに伝えた成果物イメージは下記のような感じです。
<Q4>デザイン成果物へのフィードバックはどうするか？
成果物イメージを伝えたら、2・3日で最初のドラフトが上がってきました。
正直、あまり期待していなかったのですが、その質の高さにとても驚きました。
80の期待値に対して200で返してきました感じです。
山本氏とのセッションでも感じたことなのですが、
デザインとは絵を綺麗にすることではなく、
目的を表現することなんだなぁと感じた次第です。
下記は最初に上がってきたデザイナーの成果物イメージです。
これに対するフィードバックはパワーポイントで矢印を引いて、
ここをこうしてくれと指示していく形になります。
「自分はこう変えるべきだと思う」という話を山本氏に相談し、
彼からレクチャーや表現案をもらいながら進めました。
4回目のフィードバックで完了しました。
フィードバックで気を付けたポイントは
・重要ポイントや誤解しそうなポイントは「なぜ？」を入れたこと。
・アイコン等の表現は具体的にサンプルで例をしめしたことです。
もめたポイントは
「Thank youページの画像が子供っぽいから、大人っぽく変えてくれ」
と言ったところ、子供っぽいとは何か？ 大人っぽいとは何か？
という押し問答になり、完全にミスりました。
少しイラっとした彼から送られてきた提案が下記の画像です。
※確かに大人っぽいですね。
<Q5>デザインパートをどうクローズするか？
Q2でも言及しましたが、
デザインにおけるゴールは
アプリ開発者が使える形にデータを加工するところまでです。
具体的にはパーツをアプリ内で使える部品に切る必要があります。
アプリ開発者が「後は俺に任せろ」と言い、
元データ(aiファイル)をデザイナーから引き渡してもらえば、
彼のミッションは完了です。
ミスったポイントはiphone4,5,6では画面サイズが違うので、
後でiphone4用に別途画面が必要になってしまったことです。
契約段階でプロジェクト完了(ver1.0リリース)まで、
デザインに関する問題が発生したら助けてほしいとお願いしておいて良かったです。
アプリ開発者が後は俺に任せろと引き継いでくれたら、
今度は開発フェーズに入っていきます。
※今回アプリ内デザインを担当して頂いたパキスタンのHafizさんです。
イケメンですが、中身もナイスガイです。以下、再掲にはなりますが実際に作ったアプリの紹介です。
「今日やることを一つだけ宣言するTodo管理アプリ」
HALF STEP（ハーフステップ）
ご興味あればDLしてみて下さい。
▼Downloard(iphone)
※ご質問/ご意見等あればお気軽にお問い合わせください。
tanaka.j.tomohiro@gmail.com
すでに知的生産物に国境はない。 海外クラウドソーシングで作るiphoneアプリ<part Ⅰ >
8月4日からサービス企画を本格的に開始し、
12月4日にiphoneアプリをリリースしました。
私はソースコード１行も書けません、
でも作りたいサービスをロンチできたという意味で、
その方法論に需要あるんじゃないかなと思い、書くことにします。
大学時代から数えると
3回ほどプログラミングを勉強しようと試みました。
しかしながら3回とも挫折しました。
そして、私は悟りました。
『プログラミングは才能だ。私にはその才能がない。。。』
出来る人は息をするようにコードが書ける。
今回は海外のクラウドソーシングでサービス開発しました。
言いたい事はインド人の営業力、開発力、期待値コントロール、パネーっす。
※日清さん、画像がcoolなので使わせていただきます。
企画からリリースまで大きく分けて、
以下のフェーズがありました。
(1)サービス企画・・・45日
成果物：仕様書
(2)リソース確保・・・15日
成果物：エンジニア×2、デザイナー×1
(3)デザイン・・・10日
成果物：UIの画像データ、パーツデータ
(4)開発・・・20日
成果物：プロトタイプ
(5)テスト/Bug修正・・・20日
成果物：リリース可能なプロダクト
(6)apple申請/リリース・・・10日
成果物：appleからDL可能
(1)サービス企画は別途書くとして、
<Part Ⅰ >は(2)リソース確保について出来るだけ詳しく書いておきます。
■リソース確保■
フルタイムでコミットしてくれるエンジニアの友人がいれば、
それに越したことはないですが、いない場合どうするか。
雇うしかない。でもそんなにお金がないんです。
悩んだ私はエンジニアや受託開発をされている方に相談しました。
「200万ぐらいかかるんじゃないの？」とのこと。
日本だと割高になるだろうし、
知的生産物に国境はなくなるだろう未来を見越して
海外へアウトソースすることに決めました。
<Q1>海外のクラウドソーシングをどれにするか？
検索で比較検討した結果、oDeskにしました。
人が多く集まっていて、信頼性が高そうなところを選んだつもりです。
※以下のソースを参考
<Q2>英語に自信がないんですけど？
基本的にやりとりはスカイプチャットなので、
困ったらgoogle翻訳へぶちこめば95%解決します。
とはいうものの自分も英語が得意ではなく、
ちゃんとコミュニケーションがとれるか不安でした。
なので、速攻でDMM.英会話を申し込みをして翌日からレッスンを始めました。
プロジェクトを英語で説明する方法や、ユーザーに対するプロダクトの説明文とかは先生にレクチャーを受けながら進めました。
<Q3>どのくらいの予算で、どうやってオーダーするの？
初めてのクラウドソーシング、値段やスケジュールをどうするか。
そんなことわかるわけないです。
なので、プロに教えてもらうこにしました。餅は餅屋です。
何をしたかと言うとoDeskにコーチングの仕事を応募しました。
報酬は100$です。結果として4人の応募がありました。
過去に取り組んだプロダクトを比較して、
一番経験が豊富そうな台湾のエンジニアを選びました。
暫定スケジュールと必要リソース、それに対する報酬を明確にすることです。
自分が受注する立場だったら幾らなら作りたいと思うか、
どのくらいの納期ならコミットできるかという疑問をぶつけていきます。
このコーチングにより、
以下の予算とスケジュールができました。
===(一部抜粋)===
■Bujet
Designer------200~300$+bounus30%
Client side---1600~2000$+bounus30%
Server side---700~1000$+bounus30%
Client side---1600~2000$+bounus30%
Server side---700~1000$+bounus30%
■mile stone of this project(estimate)
(1)Start the own tasks 10/6
(2)design finish 10/11
(3)develop finish 11/2
(4)all done 11/10
(user can download from apple store)
(1)Start the own tasks 10/6
(2)design finish 10/11
(3)develop finish 11/2
(4)all done 11/10
(user can download from apple store)
================
※基本的に高めに見積もってる可能性を考慮して、
ちょくちょく探りを入れました。
<Q4>どうやって応募者を選べばよいか？
上記の条件で応募を出したところ応募者が10人以上きました。
サーバー＋クライアント型のアプリを作ったことがある人で
評価が高い人を選別し、スカイプチャットで要望を満たせそうか確認していきました。
情報流出がすこし怖かったですが、
そのリスクを飲んで、気軽に仕様書とUIドラフトを共有しました。
その中でチャットのレスポンスがよく、
スタッフ用にadminパネルも作るよと言ってくれたインドの方を雇うことにしました。
いろんな国の人が「俺に任せろ、俺はすごい」と言ってくるわけですが、
明確な判断基準を用意しておかないと、おしこまれると思います。
※デザイナーは過去の仕事内容を見て、パキスタンの方にお願いしました。
※ちなみに私はメインの開発費用で300$ほど、予算を押しこまれました。
<Q5>報酬体系はどうするのか？
oDeskは働いた時間に対する報酬体系と成果物報酬があります。
細かくマネージメントする自信がない人は後者の方がいいと思います。
ただし、後者の方は仕事の依頼主が成果物を持ち逃げする事象が
往々にしてあるらしく、イニシャルコストで1/3を要求されました。
基本的にoDesk内で受けた仕事数が多く、
評価も高いユーザーはoDeskで稼いで生活している人たちだと推測され、
ソースコードの出ししぶりや値上げ要求等はないだろうと踏んで、
この要求は飲むことにしました。
マイルストーンを立てて、
成果物と報酬を分散させればお互いにリスクヘッジになります。
今回の報酬額とタイミングは以下の通りです。
・報酬の1/3・・・契約時(イニシャルコスト)
・報酬の1/3・・・サーバー側ソースコード引き渡し時
・報酬の1/3・・・クライアント側ソースコード引き渡し時
・ボーナスと評価・・・すべてのミッションが完了した時
<Q6>メンバーがそろったらどうするの？
共通認識を作るために、キックオフMTGをしました。
この時ばかりはチャットではなく、
チームという共通認識を作るために音声で話しました。
簡単に各自自己紹介してもらい、
俺がリーダーだと言わんばかりに「なぜこのプロダクトが必要なのか」しゃべり倒しました。そして、今後の情報共有体制について話し合いました。
デザイナーとエンジニアとの関係もこの時に作っておいてよかったと思います。なぜなら、その後チームとしてちゃんと連携してくれていたからです。
※ちゃんと伝わるか心配だったので、
DMM英会話の先生に事前に相談してフィードバックをもらいました。
期待する成果物とマイルストーン、
その納期は<Q3>で明らかにしているので、
あとはそのスケジュールで動いてもらえばプロジェクトは進んでいきます。
<PartⅡ>へ続く。。。
<Q>どんなアプリ何を作ったか？
「今日やることを一つだけ宣言するTodo管理アプリ」
HALF STEP（ハーフステップ）を作りました。
ご興味あればDLしてみて下さい。
※質問/ご意見等あればお気軽にお問い合わせください。
tanaka.j.tomohiro@gmail.com
スタートアップが大手を倒す方法
44田寮の赤木さんから、
スタートアップが大手に噛みつく方法をレクチャーしてもらいました。
スタートアップが大手に噛みつく方法をレクチャーしてもらいました。
すごーく、納得したので整理も兼ねて共有します。
■プロダクト/サービスの型
プロダクトの型には「課題解決型」と「感動体験型」がある。
(1)課題解決型
・ターゲットユーザーの課題を解決する。
・ユーザーにとって「課題」とは何かをきちんと定義する必要がある。
※不安---漠然とした不安
問題---原因は分かっている、かつ、解決策に気づいていない。
課題---原因は分かっている、かつ、解決策に気づいている。
・ユーザーはそれが自分の課題を解決してくれるものだと、
わかったときにそれに対して対価を払う。
・そういった意味でマネタイズしやすい型と言える。
(2)感動体験型
・ターゲットユーザーに感動を提供する。
・提供する「感動」は自分が実際に体験したことが望ましい。
・自分の体験を人にも体験してもらいたいというのが基本的な動機
・実際に体験しないと、
その評価と程度が難しい点でマネタイズは難しいと言える。
■顧客開発のTips
一般的にスタートアップの顧客開発は「１人」のユーザーを見つけることから始める。そのためには仮説を立てて、ターゲットになりうる人がその仮説に当てはまるか検証/実験することが基本的な顧客開発となる。その上で、ターゲットとなりうる人とどういう接点を持つのかは大事。
(1)アンケート
メリット： 数を集めやすい、統計的なデータをとりやすい。
デメリット：アンケートの設計次第で結果がかわる。
作り手が想定しない発見は少ない。
(2)インタビュー
メリット： ターゲット候補のプライベートな領域も
知ることができる。アンケートより情報量多い。
デメリット：時間がかかる。
回答者は期待に答えようとする心理が働きやすいので
意図を悟られない質問等の技術が必要。
(3)行動観察(エスノグラフィー)
メリット： 外的なバイアスが働かないので
ユーザーの自然な行動を観測することができる。
デメリット：行動からユーザー心理やニーズを読み取るのにかなり時間がかかる。
ユーザーの自然な行動を観測することができる。
デメリット：行動からユーザー心理やニーズを読み取るのにかなり時間がかかる。
■狙うべき市場の領域
ヒト・モノ・カネのリソースに限りがあるスタートアップが
狙うべき市場は「リアルニッチ」か「潜在ニッチ」市場。
理由は最初から中堅や大手企業と戦う必要がないから。
※市場成熟度とはユーザーがその解決策に対してお金を払うという
認識度合いの高さであり、対価を払う習慣の定着度ともいえる。
※市場規模はここでは潜在市場と顕在市場の大きさの和をさしている。
(1)ビック市場(市場成熟度高い×市場規模が大きい)
市場は大きいし、顧客もそれに対する対価を払う習慣ができている。なのでマネタイズも容易であり、すでに大手企業が数多くいる。ここで戦ってもまず勝てない。
(2)成熟ニッチ市場(市場成熟度高い×市場規模が小さい)
顧客は対価を払ってくれるものの、ターゲットなる市場規模があまり大きくない。オタク向けビジネスや富裕層向けビジネスが該当し、マネタイズは比較的容易ではあるものの、中堅の企業が市場にいるので、勝ちやすいとは言えない。
(3)潜在ニッチ市場(市場成熟度低い×市場規模が大きい)
問題や課題を持っている人は多いものの、それに対して対価を払う習慣がない。初期段階のグルーポンなどが当てはまる。イジメや自殺問題もここに当てはまるものの、マネタイズからは少し遠い場所ではある。※スタートアップが狙うべき市場
(4)リアルニッチ市場(市場成熟度低い×市場規模が大きい)
お金を払う習慣もなく、ターゲットもあまり多くない。バックパッカーやスタートアップ、マニアックな楽器やスポーツ関連もここに当てはまる。※スタートアップが狙うべき市場
■その市場でどうやって事業を拡大するか。
(1)リアルニッチ市場での戦い方。
＝＞グローバル展開で市場を大きくする。
(2)潜在ニッチ市場での戦い方。
＝＞ビックに挑戦する。
マネタイズモデルを開発し、顧客の成熟度をあげることができたならば、ビックの領域に入ってくる。そうすると、大手が参入してくる可能性が高くなる。大手はその資本にモノを言わせ、広告をバンバン打ってくると考えられる。そうなると、ブランドも弱いスタートアップが勝つのは難しくなってしまう。この状況を打破する方法は２つ考えられる。
A.先行者メリットを活かし顧客理解を深め、サービスの付加価値をあげる。
B.先行者メリットを活かし顧客理解を深め、マネタイズ方法を増やす。
大手は何をされても、それを真似る戦略(同質化戦略)をとればよいので、止まったら大手に追いつかれてパイの取り合いとなる。むろん、こうなるとブランドで負けているので勝つのは難しい。つまり、大手と戦うには常に先行者である必要があり、同質化から逃げつつ、上記の方法を繰り返すしかない。事業が十分に拡大し、上場という選択肢をとることが出来れば、そのスタートアップは「ビック」の仲間入りをすることができ、大手と対等に戦えるようになれる。ここがスタートアップの１つのゴール。
＜補足＞
グルーポンは潜在ニッチから一気にビックへ行こうとした。。。でも、ここでリクルートというマンモスがポンパレを仕掛けてきた。結果、「おせち」で失敗し、残念。ポンパレの勝ち。
PDCAサイクルからの脱出
いわずと知れたPDCAサイクル。
実はこれ第二次世界大戦後の1950年頃に
「事業活動における生産管理や品質管理などの管理業務を円滑に進める手法の一つ」
として物理学者エドワーズ・デミング等が提唱した概念だそうです。
http://ja.wikipedia.org/wiki/PDCA%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB
年に数回は見たり聞いたりする気がするんですけど、「生産管理」とか「品質管理」とか、もはや関係なしにいろんな場面で使われてますよね。
何かを管理して推進するあらゆる場面でPDCAサイクルなんて叫ばれてますけど、
60年以上前の概念が現在でもフルマッチョにすべてを網羅できるとは思えなかったりするわけです。
それこそ、最近だとアジャイル、カンバン、リーンとかもてはやされてますけど、ビジネスの世界だけでなく、個人の世界に根付いたPDCAをベースとした目標管理についても再考のタイミングではないでしょうか？
■1950年代の出来事
・1951年：第1回ＮＨＫ紅白歌合戦（ラジオ）。ＬＰレコード。ソフトクリーム販売。
・1952年：カブ［ホンダ］販売。国会中継の放送開始。公衆電話が登場。
・1955年：高度成長期突入。「三種の神器」電気冷蔵庫、電気洗濯機、テレビ。
・1959年：トランジスタ・グラマー。第1回日本レコード大賞開催。
「週刊少年サンデー」と「週刊少年マガジン」が創刊。
■2000年代の出来事
・2000年：プレイステーション2発売。IT革命。出会い系サイト。iモード。ユニクロ。
・2003年：六本木ヒルズ。オレオレ詐欺。地上デジタル放送。
・2005年：愛・地球博開催。個人情報保護法。ブログ。電車男。ちょいワルおやじ。
・2008年：北京オリンピック。赤坂サカス。iPhone。リーマンショック。
■何かを始めようと思った時にどれだけ時間がかかるのか？
1950年代に思いをはせつつ、
その時代に何かをしたいと思い立ったとして、
自分だったら何をするか考えてみました。
①マンガを描いてみたーい
1950年代：週刊誌の巻末にある応募先に作品を投稿してみる・・・10時間
現在：Pixivに自作キャラを投稿してみる・・・15分
http://www.pixiv.net/
②アイドルになってみたーい
1950年代：とりあえず上京する・・・2週間
現在：募集まとめサイトで選んで応募する・・・15分
http://audition-debut.com/audition/list/contents_type=13
③マラソン選手になりたーい
1950年代：地域で開催されるマラソン大会を待つ・・・1カ月
現在：とりあえず週末に開催されるマラソン大会に応募する・・・5分
http://runnet.jp/runtes/index.html
■最初の一歩のハードルは明らかに低くなっている。
最初の一歩にかかる時間は減り、
最初の一歩の選択肢は増えている。
○1950年代
最初の一歩にたくさんの時間がかかる＝失敗した時に失うものは大きい。
選択肢は少ない＝チャンスは少ない。
つまり、入念に計画を立ててチャレンジする必要があった。
○2000年代
最初の一歩にあまり時間はかからない＝失敗しても失うものは小さい。
選択肢は多い＝チャンスは多い。
つまり、まずはやってみることが可能になった。
■Tryから始める目標達成
こんな話をしていたら、知人から１冊の本を紹介していただいた。
「マラソン中毒者」
著者の小野祐史さんは35年間運動ゼロの状態から、
Wii Fitをきっかけに3年半で80を超えるマラソンレースに出場している。
しかも、北極、南極、砂漠マラソンにも出場し、完走している。
この本のエピローグにこんなことが書かれている。
「小さなキッカケでも、『ココロの羅針盤』の針が動いたら、まずは動いてみる。
『できるかどうか』ではなく『まずは、やってみる』。
結果、コケたり失敗も増えてしまうかもだけど、その分学びのチャンスだって得られる。動かなければ、見える景色は変わらないままだけど、動いてみれば『こっちは何だか違和感がある』『こっちはひょっとしてイイかも』などと、自分の進みたい方向が徐々に見えてくる。」
うーん、わかる！すごくわかるなーっと直感的に共感しました。
この方はエントリーしたらtwitterとかで発信して、
周りを巻き込みながら話を大きくしていく方のようで、
その点はすぐに真似できないけど、やり方は参考になるなと思いました。
こういう方が近くにいるだけで、
マラソンを自分もしようと思ってしまうのは容易に想像できます。
一朝一夕では到底真似できない「偉業」を成し遂げられたということで、
この成功をモデル化すると本を参考に抽出すると下記のようになります。
①wii Fitを買って運動してみる。(Try)
②面白そうな大会にはノータイムでポチリする。
または友人/知人の参加を聞きつけ乗っかる(Join)
③大勢の前で宣言して逃げ場をなくす。(Share)
④実行して感動する(Feel)
当たり前ですけどゴビ砂漠マラソンを走ってやろうと思って、
wiiFitを買ってるわけではないんですよね。
結果的にそうなっているわけで、
PDCAとは明らかに違う「現在」の目標達成プロセスの一つだと思います。
スタートアップにマーケティングは必要か。
そもそも、スタートアップにマーケは必要ないんじゃないの？
いいえ、スタートアップはコンテンツマーケティング１本で勝負すべき。
■スタートアップのマーケティング観点
「実績なし」「知名度なし」のスタートアップはどうやって自分達のプロダクトをしかるべき人に届けるのか？せっかくいいものを作っても、それがしかるべき人に届かなければ意味がないですよね。
「あたなが作ろうとしているモノやサービスは日本で初めてかもしれない」
「あなたが作ろうとしているモノやサービスは世界で初めてかもしれない」
そんなモノをGoogleで検索する人はいません。
なぜなら、存在しないものは思いつかないから。
スタートアップ界隈では「イノベーターを探せ」「アーリーアダプターを探せ」とよく言われます。理由は彼等は大手が作るプロダクトやサービスでは満足できず、そのスタートアップが提供するたった１つの機能や提供価値を評価し、暖かく見守ってくれる存在だからです。彼らなくして、プロダクトやサービスの成長はありえないのです。そんなニッチな課題を抱える人たちを効率よく集めるにはどうしたらよいのか。そんな人達に自分たちの存在を知らせるにはどうしたらよいのか。
スタートアップのマーケティングはこの観点からスタートすべきということ。
■ゴールが決まったら、戦略を練る。
ニッチな課題を抱えている人をどう集めるのか。。。
実は課題の前段階に２つのステップがあります。
不安・・・漠然とした不安をかかえている状態
問題・・・原因は分かっているけど解決策がない状態
課題・・・原因と解決策が分かっている状態
もちろん、ある特定の分野に絞った場合、下にいくほど母数は少なくなる。
例えば、
「老後が不安だ」(不安)
→「年金がもらえないかもしれない」(問題)
→「自分で貯金して、資産運用をいくしかないな」(課題)
最終的なゴールである「ニッチな課題を抱えてる人をたくさん集める」ためには「問題」や「不安」を抱えている人にまずリーチできなければならない。
どうやって？ 彼らが知りたそうなコンテンツを作ればいいじゃないか！
これがコンテンツマーケティングの考え方。
上の例で言うと、不安層に向けたコンテンツは
「今の20代のうち○○%が老後が不安だと感じている？」とかになるし、
問題層に向けたコンテンツは
「年金がもらえない時代にどう備えるべきか？」とかになるだろう。
課題層に向けたコンテンツは
「5万円からの積立運用で年金をあてにしない」とかになるだろう。
大事なのは見込み客に徐々にステップを上ってもらうことであり、
手段であるプロダクトやサービスを前面にいきなり出さないこと。
■今日から出来るコンテンツマーケティングの始め方。
(1)自分のビジョンを明確にすること。
これから用意するコンテンツの軸になるものになるし、
イノベーターが買うのはその人の「ユメ」である部分が大きい。
(2)ペルソナを明確にしましょう。
そのモノやサービスはどんな人が使うのか明確にすることで、
その人にリーチする方法が見えてきます。
例：24歳、独身、男性、大学院生、iphone利用、雑誌は○○を購読、
hatenaや2chまとめをよく見る、TVはなく、渋谷代官山によくいく等。
(3)ペルソナがどんなコンテンツに興味を持つでしょうか？
「不安」「問題」「課題」ステージにおいて、抱く興味は違いますので、
それぞれのステージで必要そうなコンテンツを考えてます。
ペルソナが情報を得る手段もリーチするために非常に大事になってきます。
(4)コアキーワードと関連キーワードを洗い出しましょう。
そのコンテンツに関係性の高いコアキーワードと関連キーワードを洗い出す。
(5)そのキーワードの検索数を調べてみましょう。
→検索数が多ければいいというわけではありません。
月間1000～2000で十分で、その理由はそのキーワードを探すような必死な人は
ニッチな課題を抱えている可能性が高いからです。
(6)地道に、大量に、効率よく、コンテンツを作成していきましょう。
以上です。
コンテンツをたくさん作って、
モノやサービスへの道筋にちりばめていくイメージですね。
今回、コンテンツマーケティングのご講義を頂けたinnovaの宗像さんは、
「モノなし」「サービスなし」でブログを１年毎日ひたすら書いてコンテンツマーケティングインで会社を急成長させてらっしゃる方です。すごいですよね、、、
広告とは平凡なサービスをつくってしまったことに対してあなたが支払う代償である
by Amazon CEO ジェフ・べゾス
そんな言葉もあるみたいですけど、
今回、スタートアップにおける草の根を這うようなマーケティング活動は必要だと思いました。というわけで、この記事も僕のコンテンツマーケティングの一環とさせていただきました。
