メンタル的に潰れる起業家、潰れない起業家
私は、悲しいことに、メンタル的に潰れてしまってうつ病になった起業家だ。ちゃんとした起業家になりきる前に潰れてしまったので、正確にいえば起業家でもないだろう。最近ようやく、まあまあ元気になってきたので、これから起業しようとしている人や、起業して間もない人、さらには今後の自分に向けて、どのようなマインドになればメンタル的に潰れてしまうのか、そして潰れないようにするにはどうすればいいのか、自分の考えをまとめてみようと思う。
私のうつ病のきっかけ
私は、大学を卒業してから、大手IT企業にエンジニアとして就職した。7年間勤務後、自分の作りたいサービスを開発することに専念したくなったため退職した。その後は、初めてリリースしたアプリがちょっとだけ話題になり、2つめにリリースしたアプリも（流行らなかったものの）TECHWAVEやイケダハヤトさんなどの有名メディアに取り上げられ、3つめに企画したアプリでKDDIのスタートアップ支援プログラム（KDDIムゲンラボ）に選出された。上り調子だった。
しかし、その3つめアプリの企画や開発が難航し、KDDIからの資金調達もフルコミットできるメンバーが自分以外にいなかったため断念（資金調達には事業計画書の作成などでまとまった時間が必要）、その間に生活資金が尽きてしまった。そこで昼間にエンジニアとして副業しながら、夜に自分の開発を進める生活を続けるも、思ったように時間が確保できず、焦りや自責感のため何も手につかなくなり、人にも怯えるようになり、最終的には布団からも出られなくなってしまったのだ。
私のうつ病は、精神的な無理が続きエネルギーが枯渇している状態で、自分の力ではどうにもならない困難が起きたときに発症した。後にたくさんの本を読んだのだが、これは典型的な発症のパターンだった。
そもそもの原因は「思考の癖」
うつ病が発症したきっかけは人によって違うが、そもそもの原因は共通している。うつ病の人や、うつ病になるリスクが高い人は、みんなだいたい同じ思考の癖を持っている。『心が晴れるノート うつと不安の認知療法自習帳』では、以下の9つを挙げている。（カッコ内の説明は一部私の言葉に置き換えた。）思い返せば、私は子どものころから、太字にしている思考の癖が強かった。
- 根拠のない決めつけ（根拠が少ないままに悪い思いつきを信じ込む）
- 白黒思考（あいまいな状態が我慢できない）
- 部分的焦点づけ（自分が着目していることだけに目を向け、やはりそうだったと思う）
- 過大評価・過小評価（失敗したことばかり思い出して、成功したことはすぐ忘れる）
- べき思考（こうすべきだと思うことと異なる現状にストレスを感じ、ああすべきだったと過去を悔やむ）
- 極端な一般化（少数の事象を取り上げ、自分はいつもこうなってしまうと考える）
- 自己関連づけ（悪いことが起きると自分のせいだと考える）
- 情緒的な理由付け（そのときの感情にもとづいて、ダメだと判断してしまう）
- 自分で実現してしまう予言（否定的な予測を意識しすぎるために、予測通り失敗してしまい、さらに予測を信じ込む）
思考の癖は長所にもなるため隠れやすい
困ったことに、これらの思考の癖は裏を返せば長所になることもあるため、修正されないまま大人になっていく。たとえば、2の白黒思考は本質を追求する、5のべき思考は理想を高く持って努力する、7の自己関連づけは責任感があるというように、それぞれいいように言い換えることができてしまう。
思考の癖に気付いたときはもう遅い
また、運よく思考の癖に気付いたとしても、起業した後だともう遅い。数十年にわたって染み付いた思考の癖を修正するには、最低でも数年の時間がかかるといわれている。投資家やチームのメンバーが、それが終わるまで待ってくれることはないだろう。
起業家のマインドの分類と危険ゾーン
これまでで書いたように、うつ病を防ぐ最強の方法は思考の癖を修正することだが、「よし、思考を変えよう」と思うだけで変えることはむずかしい。
幹線道路の工事中に迂回路を作るのと同じように、思考の癖の修正が完了する間、取り急ぎ潰れないようにすることも大切だと思う。そこで、自分の過去を振り返ってみて、即効性がありそうな方法を考えてみた。
まず、起業家のマインドを、下の図のように2軸で分類する。
「事業アイディアへのこだわりが強い」人は、もし自分のやりたい事業ができるなら独立せず社員でも十分だと思っている。自分がそれをやることに社会的な使命感を感じているようなマインドである。逆に、独立ありきで、何かお金になる事業をやりたいというのであれば、事業アイディアへのこだわりが弱いということになる。
「失敗は許される」は、関係者（投資家やメンバー）が失敗を許容している、かつ自分でも失敗を許容している状態である。関係者がどう考えているかわからない場合は、自分自身で失敗を許容しているかどうかが指標になる。
図の左上のゾーンは、典型的なスタートアップ起業家のマインドだ。ユニークなアイディアや技術を売りにしていて、サービスの内容が簡単に変わることはない。そのアイディアに人生を捧げるほど熱中している人もいるが、失敗が許されるこのゾーンにいるうちはメンタル的に潰れることはない。
左下のゾーンは、ロケット・インターネットに代表される、儲かるなら他のサービスのパクリでもOKという起業家のマインドだ。こちらもメンタル的に潰れる心配はない。
右下のゾーンは、大きな失敗はできないので、ローリスクな事業で起業しようとする人たちのマインドだ。脱サラしてフランチャイズへの加盟を検討している既婚男性や、○○講師や○○カウンセラーなどの複数の資格を持っている「ママ起業家」などが該当する。失敗するリスクを恐れているため、メンタル的には少し窮屈ではあるが、状況が悪くなると他の事業に切り替えることも可能なので潰れることは少ない。
問題は右上のゾーンだ。危険ゾーンと名付ける。最初は左上のゾーンにいたのに、気付いたらこのゾーンに入っているケースが多いはず。事業アイディアへのこだわりが強いために、状況が悪くなっても他の事業に切り替えることができずストレスがたまる。さらに、失敗は許されないと思い込んでいるので頑張りすぎて疲弊してしまう。もし危険ゾーンに入っていたら、すみやかに回避行動をとらないといけない。
潰れることを回避するためにやるべきシンプルなこと
潰れることを回避するためにやるべきことは「失敗に気づき、清算する」ことだ。上記の図でいうと、横軸の右に振り切れた状態を、左に戻すことである。縦軸は心の問題なので修正はむずかしい。一方、横軸は行動で修正可能だ。以下の2つの行動を起こしてみるといい。
1. 失敗に気付くため行動
失敗が許されないと思っている心理状態では、進捗が思わしくなくても、自分ではなかなか失敗と認めることができない。そこで、「スケジュール」というチェックポイントを使って、失敗しているのかどうかを客観的に判断してみる。
事業の進捗が予定より遅れて、スケジュールを引き直すことがあれば、それはひとつの「失敗」とカウントする。遅れた理由は関係ない。品質の向上であれ、ユーザーの動向を分析した結果であれ、ピボットであれ、スケジュールを引き直せばそれは失敗だ。
スケジュールの引き直しが許されている間は、「失敗は許される」状態ということになる。しかし、度重なる失敗で、関係者（投資家やメンバー）に、これが最後だと通告されたとき、もしくは自分でこれが最後だと思ってしまったときは、「失敗は許されない」状態である。
2. 失敗を清算するための行動
もし「危険ゾーン」にいることに気付いたのなら、いますぐ「清算」の行動に出るべきだ。ここにいる状態で、最後のひと頑張りは絶対してはいけない。あなたは、もう十分やってきた。これ以上頑張ると潰れてしまう。心理的に大きな抵抗があると思うが、最後のひと頑張りをするエネルギーは、ここで使ってほしい。
やることはシンプルだ。それは、関係者（投資家やメンバー）に謝ること。メンタルが「危険ゾーン」に入ってしまったことをていねいに説明すればよい。事業を副業などしながら細く長く続けていく方向に切り替えるとしても、「いつまでにはできそうです」などとコミットしないで、あくまで失敗で終わらせる。いったんすべてきれいに清算する。謝って、許してもらうことで、強制的に「失敗は許されている」状態に移行するのだ。
その後、個人的に野心を持ち続ける分には問題ない。別の本業があるなかで、今度は副業として事業を進めることになるので、なかなか進まないことにストレスはたまるが、他人に迷惑をかけることはないのでメンタル的に潰れるまではいかない。もちろんその間に思考の癖の修正することは忘れずに。
iOS + PHPでPush Notificationを実装する
Morning Relayという目覚ましアプリで、iOS + PHPでPush Notificationを実装してみた。公式ドキュメントを読むと複雑で難しそうだが、じっくりやれば大丈夫。サーバー側の実装は公式ドキュメントには実例が載っていないのだが、「apns-php」というPHPのライブラリを使うことでラクにできた。
環境
概要
- 準備
- iOS側での実装
- サーバー側での実装
準備
1. App IDを作成する
※ すでにApp IDがあるときは、これらの操作は不要
(1) iOS Dev Center > iOS Provisioning Portalを開く。
(2) ウインドウの左メニューの[App IDs]をクリック
(3) [New App ID] をクリック
(4) Descriptionにアプリ名（App IDを説明する名前）を入力、Bundle Identifierにドメイン名を逆にするなどの一意の値を入力して、[Submit]をクリック。App IDが新規に作成される。
2. プロビジョニングファイルの作成とローカルへのコピー
(1) iOS Provisioning Portalにアクセスして[New Profile]からプロビジョニングファイルを作成する。App IDは、1で作成したものを選択する。
(2) 作成したプロビジョニングファイルをダウンロードして、~/Library/MobileDevice/Provisioning Profilesにコピーする。ファイル名は、MorningRelayDev.mobileprovisionなど、開発用か製品用か区別できるようにしておく。
3. ローカルでCSR(証明書署名要求: Certificate Signing Request)ファイルを作成、それをAppleのサーバーにアップロードして証明書と鍵を受け取る
(1) ローカルでキーチェーンアクセスアプリケーションを起動して、キーチェーンアクセス > 証明書アシスタント > 認証局に証明書を要求…をクリック、ユーザのメールアドレスはAppleに登録したメールアドレスを入力、通称は開発者の名前や会社名などを入力、要求の処理でディスクに保存をチェック、続けるをクリックして、適当な名前を付けてファイルを保存する
(2) iOS Provisioning Portal > App IDsから先ほど作成したアプリのConfigureリンクをクリック、Configure App ID ページで「Enable for Push Notification Services」ボックスにチェックを入れて、まずは開発版のDevelopment Push SSL Certificateの[Configure]をクリック、[Continue]クリックで次に進む。
(3) (1)で作成したキーファイルを設定して、[Generate]をクリックする。なぜかGoogle Chromeでは反応しなかった。Safariを使えば数秒で認証が完了する。
(4) 完了すると「Download & Install Your Apple Push Notification service SSL Certificate」の画面が表示されるので、[Download]ボタンで証明書をダウンロードする。ここで、App IDsの画面で、アプリの「Push Notification」が「Configurable」から「Enabled」になったことを確認する。
(5) ダウンロードした証明書（aps_development.cer）は開発用なので、aps_development_dev.cerなどにリネーム後、ローカルでダブルクリックしてMacのキーチェーンに登録する。
※ 「Development Push SSL Certificate」に続き「Production Push SSL Certificate」も同様に上記の手順を実行する。
MEMO:
> 公式ドキュメントにはもう少し詳しく書いてある：CSRの生成時に、キーチェーンアクセスは秘密暗号鍵と公開暗号鍵のペアを生成します。秘密鍵 はデフォルトでログインキーチェーンに組み込まれます。公開鍵は、CA(認証局)に送信され るCSRに含められます。CAから証明書が戻ってくると、その証明書の項目の1つが公開鍵になっています。
4. 自分のサーバーに配置するためのSSL証明書と鍵を作成する（2種類のpemファイルを作成）
(1) キーチェーンアクセスからSSL証明書と鍵を取得する。左側のペインの自分の証明書 > Apple Development IOS Push Services: *** をクリックして展開して、証明書と秘密鍵の両方が表示させる。
(2) 証明書と鍵の両方を選択して、ファイル > 書き出す」を選択、それらを「個人情報交換(.p12)」ファイルとして書き出す。
(3) サーバーで使えるように、以下のコマンドで.p12形式を.pem形式に変換する。AppNameDev.pemファイルが作られる。（「AppNameDev」部分を書き換える。）
$ openssl pkcs12 -in AppNameDev.p12 -out AppNameDev.pem -nodes
(4) Entrust Root Certification Authorityを作成する。キーチェーンアクセス > 左下ペインの「証明書」 > Entrust Root Certification Authority > 右クリック > 「"Entrust Root Certification Authority"を書き出す...」 > ファイル名を「entrust_root_certification_authority.pem」にして保存する。これで、entrust_root_certification_authority.pemファイルが作られる。
iOS側での実装
1. RemoteNotificationを登録する
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
...
// アプリケーションが起動するたびに、デバイストークンを要求してそれをプロバイダに渡すことで、
// プロバイダが最新のデバイストークンを持つことを保証
[application registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge|UIRemoteNotificationTypeSound|UIRemoteNotificationTypeAlert)];
return YES;
}これで、アプリ初回起動時にRemoteNotificationを許可するかどうかのダイアログが表示されるようになる。「didFinishLaunching」内だと「didFinishLaunchingWithOptions」メソッドが存在すれば呼ばれないので注意。
2. デバイストークン（Device Token）を取得する
- (void)application:(UIApplication *)app didRegisterForRemoteNotificationsWithDeviceToken:(NSData *) devToken
{
NSLog(@"deviceToken: %@", devToken);
[self sendProviderDeviceToken:devToken]; // 自分のサーバーに送信する
}
- (void)application:(UIApplication *)app didFailToRegisterForRemoteNotificationsWithError:(NSError *) err
{
NSLog(@"Errorinregistration.Error:%@", err);
}
3. デバイストークンを自分のサーバーに送る
- (void)sendProviderDeviceToken:(NSData *)token
{
NSMutableData *data = [NSMutableData data];
[data appendData:[@"device=" dataUsingEncoding:NSUTF8StringEncoding]];
[data appendData:token];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://morning-relay.com/push"]];
[request setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];
[request setHTTPMethod:@"POST"];
[request setHTTPBody:data];
[NSURLConnection connectionWithRequest:request delegate:self];
} この例ではNSURLConnectionクラスを使っているが、自分のサーバーにデータをポストするだけなので、どんな方法でもOK。
サーバー側での実装
iOSから送られてきたデバイストークンを受け取る処理は省略。以下は、Apple Push Notificationサービス(APNs)のサーバーにPUSHする処理。
1. apns-phpをダウンロードする
(1) apns-phpというライブラリ（ApnsPHP-r100.zip）をダウンロードする。
(2) ZIPファイルをサーバー（ローカルホストでもOK）に展開して、ブラウザからアクセスできる場所に配置する。
(3) サーバープログラムのルートディレクトリ（CakePHPの場合はapp/webroot）にcertificatesというフォルダを作り、その中に上記で作成した「AppNameDev.pem」と「entrust_root_certification_authority.pem」ファイルを配置する。※ 本番では適切なアクセス権を設定する
2. apns-phpのファイルを修正する
(4) sample_push.phpを以下のように修正する。
...
// Instanciate a new ApnsPHP_Push object
$push = new ApnsPHP_Push(
ApnsPHP_Abstract::ENVIRONMENT_SANDBOX,
// 修正前
// 'server_certificates_bundle_sandbox.pem',
// 修正後
'certificates/AppNameDev.pem'
);
...
// Set the Root Certificate Autority to verify the Apple remote peer
// 修正前
// $push->setRootCertificationAuthority('entrust_root_certification_authority.pem');
// 修正後
$push->setRootCertificationAuthority('certificates/entrust_root_certification_authority.pem');
...
// Instantiate a new Message with a single recipient
// 修正前
// $message = new ApnsPHP_Message('9e1791742ce6658f0d04128ec05ae4ed9858e534ff6ae6e8e18c68ded547ba0b');
// 修正後
$message = new ApnsPHP_Message('iOSで取得したDeviceTokenを記入。NSLogで出力したものから半角スペースを除くだけでOK。');
3. Apple Push Notification サービス(APNs)にプッシュ
(1) ブラウザでsample_push.phpにアクセスする
これでOKと思いきや、ブラウザでsample_push.phpにアクセスすると、以下のエラーが表示される。
Mon, 27 Aug 2012 08:22:13 +0200 ApnsPHP[4102]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Mon, 27 Aug 2012 08:22:14 +0200 ApnsPHP[4102]: ERROR: Unable to connect to 'ssl://gateway.sandbox.push.apple.com:2195': (0) Mon, 27 Aug 2012 08:22:14 +0200 ApnsPHP[4102]: INFO: Retry to connect (1/3)... Mon, 27 Aug 2012 08:22:15 +0200 ApnsPHP[4102]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Mon, 27 Aug 2012 08:22:15 +0200 ApnsPHP[4102]: ERROR: Unable to connect to 'ssl://gateway.sandbox.push.apple.com:2195': (0) Mon, 27 Aug 2012 08:22:15 +0200 ApnsPHP[4102]: INFO: Retry to connect (2/3)... Mon, 27 Aug 2012 08:22:16 +0200 ApnsPHP[4102]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Mon, 27 Aug 2012 08:22:17 +0200 ApnsPHP[4102]: ERROR: Unable to connect to 'ssl://gateway.sandbox.push.apple.com:2195': (0) Mon, 27 Aug 2012 08:22:17 +0200 ApnsPHP[4102]: INFO: Retry to connect (3/3)... Mon, 27 Aug 2012 08:22:18 +0200 ApnsPHP[4102]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Unable to connect to 'ssl://gateway.sandbox.push.apple.com:2195': (0)
回避方法は、Stack Over Flowのページにあった。
// Abstract.php
$streamContext = stream_context_create(array('ssl' => array(
// この行をコメントアウト。なぜこうすれば動くかは不明。
// 'verify_peer' => isset($this->_sRootCertificationAuthorityFile),
'cafile' => $this->_sRootCertificationAuthorityFile,
'local_cert' => $this->_sProviderCertificateFile
)));
(2) リトライ！
これで、再度ブラウザからアクセスすると、以下のようなデバッグメッセージが表示されて...
Mon, 27 Aug 2012 08:59:35 +0200 ApnsPHP[6999]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Mon, 27 Aug 2012 08:59:35 +0200 ApnsPHP[6999]: INFO: Connected to ssl://gateway.sandbox.push.apple.com:2195. Mon, 27 Aug 2012 08:59:35 +0200 ApnsPHP[6999]: INFO: Sending messages queue, run #1: 1 message(s) left in queue. Mon, 27 Aug 2012 08:59:35 +0200 ApnsPHP[6999]: STATUS: Sending message ID 1 [custom identifier: Message-Badge-3] (1/3): 177 bytes. Mon, 27 Aug 2012 08:59:36 +0200 ApnsPHP[6999]: INFO: Disconnected.
無事Remote Notificationが送られてきた！
Morning+の流入率 − リーンスタートアップを始めてみました
Morning+（モーニングプラス）というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。2週間の検証実験が終わりましたので、公式サイトへの流入率をまとめまておきます。
流入率は、ブログ記事、ソーシャルメディアのタイムラインなど外部サイトの情報を見たユーザーが、どのくらい公式サイトへのリンクをクリックしてくれるかを示すものです。この数字が低ければ、頑張ってメディアへの露出を増やしても、なかなか集客につながりません。
スタートアップの評価指標は以下のようなものがあると思いますが、流入率以外は別のエントリーでまとめます。
- 公式サイトへの流入率（大手メディアの記事、Facebook、Twitterから）
- ダウンロード率（公式サイトのダウンロードバナーのクリック率）
- 1度使う率
- 定着率
- 紹介率（口コミ率）
流入率の計算方法
Morning+では、大手メディアの記事、Twitterのタイムライン、Facebookのタイムラインのそれぞれで流入率を算出しています。
1は、大手メディアの記事を見た人における公式サイトへのリンクをクリックする人の割合です。2は、TwitterのタイムラインでキャッチコピーとURLを見た人におけるクリックする人の割合です。3は、Facebookのタイムラインで投稿を見た人におけるクリックする人の割合です。
結果
| 番号 | 指標 | 結果 | 備考 |
|---|---|---|---|
| 1 | 大手メディアから公式サイトへの流入率 | 10-11％ | リリース初日の昼間に記事を書いてくださったのは、TechWaveとイケダハヤトさんのブログです。これらの記事を見た人のうち、公式サイトへのリンクをクリックした人の割合は、それぞれ11%と10%です。どちらの記事も、AppStore、Google Playへの直接リンクが貼られていないため、アプリをダウンロードするには公式サイトを訪れる必要があります。 |
| 2 | Twitterから公式サイトへの流入率 | 0.7% | リリース初日に、morning-plus.comを含むツイートをした人はリツイートを含めて25人、その25人のフォロワー数の合計はのべ23,774人。Google Analiticsで調べたTwitterから公式サイトへの流入は39人。単純にするためフォロワーの1/4にリーチしたとすると、フォロワー5944人のうち39人がリンクをクリックした計算になります。 |
| 3 | Facebookから公式サイトへの流入率 | 7% | 公開初日のFacebookページの「リーチ数」は824人、「話題にした人」は38人です。このFBページの「いいね！」数は当時48人でした。僕の個人の友達は約200人ですが、Morning+のFBページを「いいね！」してくれた人よりは「話題にした人」の割合が下がることを考慮して、FBページと同数のリーチ数があるとします。すると、初日のFBでのリーチ数は1648人あったことになります。Google Analiticsの分析では、Facebookから公式サイトに流入してきた人は108人でした。Facebookの投稿を見た人1648人のうち、108人が公式サイトへのリンクをクリックしてくれたということになります。 |
考察
僕は「流入率が悪い＝アプリのコンセプトが悪い」というのが成り立つのではないかと考えています。アプリのコンセプトそのものが悪いと、いくら機能を改善してもユーザー数が大きく伸びることはありません。
この流入率が高いか低いかは、他のアプリがどうなのかわからないので判断できませんが、期待していたよりは低いです。
お礼
記事を書いてくださっただけでもありがたいのに、検証のためにと記事のPV数まで快く教えてくださった、TechWaveの本田様、ブロガーのイケダハヤト様、本当に感謝しています。
Morning+のダウンロード率 − リーンスタートアップを始めてみました
Morning+（モーニングプラス）というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。2週間の検証実験が終わりそうですので、ダウンロード率を計測してみました。
ダウンロード率は、ブログ記事、ソーシャルメディア、広告などの外部サイトから公式サイトに流入したユーザーが、どれだけ実際にダウンロードしてくれるかです。この数値が悪いと、せっかく集客してもユーザー獲得にはつながりません。
スタートアップの評価指標は以下のようなものがあると思いますが、ダウンロード率以外は別のエントリーでまとめます。
ダウンロード率の計算方法
Morning+では、以下の計算方法でダウンロード率を出します。
公式サイトのダウンロードバナーをクリックした人の数 ／ 公式サイトを訪れた人の数
のはずだったのですが、アクセス解析（Google Analitics）の設定がうまくいかず、「App Store, Google Playでのダウンロード数 ／ 公式サイトを訪れた人の数」で計算しています。
ただ、このアプリに限っては、後者の計算方法でも結果はあまり変わりません。現状のDL件数ではApp Store, Google Playで目立つことはないので、マーケットで直接ダウンロードされることはほぼないと考えられます。また、アプリを紹介してくださったブログのなかにはマーケットへの直接リンクが含まれているのでダウンロード数の方が多くなる可能性はありますが、このアプリでは公式サイトでのブログがコンテンツの一部になっていますので、アプリを１度でも使ったユーザーは、ほぼ100%公式サイトを開いているといえます。
結果
初日：40.0%
(iPhoneDL数105 + Android DL数48) / 公式サイトUU数382 = 40.0%
13日間：26.2%
(iPhoneDL数319+ Android DL数100) / 公式サイトUU数1600 = 26.2%
なお、13日間に比べて初日にAndroidのDL数が多かったのは、Androidアプリの方が9時間ほど先にリリースされたことも影響していると思います。
ご参考までに、iTunes Connectのダウンロード数のグラフをアップしておきます。
考察
ダウンロード率を上げるには、公式ページのデザインを改善する方法あるかもしれません。
公式ページのデザインが悪くないと仮定した場合、ダウンロード率はコンセプトのよさに左右されるのではないかと思っています。アプリがダウンロードされるのは、公式サイトを見ておもしろいと思ってくれた場合だけからです。
前作の目覚ましアプリMorningBombのときは、3日間でダウンロード数が474、公式サイトのUU数が1085でしたので、割合は43.4%です。ただ、DL数に大きく寄与したGIGAZINEの記事では、記事だけで公式サイト以上のことが伝わるクオリティーがあったこと、マーケットへの直接リンクがが含まれていたことから、単純に今回と比較することはできません。
Morning+の定着率 − リーンスタートアップを始めてみました
Morning+（モーニングプラス）というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。2週間の検証実験が終わりそうですので、定着率を計測してみました。
定着率は、イケダハヤトさんのブログ記事、重視すべきは定着率―バケツに穴は空いていないか？でも書かれているように、スタートアップにおける最も重要な評価指標といえます。評価指標は以下のようなものがあると思いますが、定着率以外は別のエントリーでまとめます。
定着率の計算方法
Morning+では、以下の計算方法で定着率を出します。
1週間で50%以上（3.5日以上）使ったユーザー数 ／ これまでに１度でも使ったユーザー数
土日はアラームを使わない人が増えるのを踏まえて、週3.5日以上の利用で定着していると定義しました。1度でも使ったことがあるユーザー数は、第1週で170人、第2週で252人です。
結果
第1週：18%
第2週：17%
定着率が高いかどうかは、比較するものがないのでわかりません。どなたか、ご存知でしたら教えていただければうれしいです。連絡先は、Twitter、Facebook、monte.cut[アット]gmail.comです。
定着率を上げる手段
ユーザーへのアンケートを行っている途中ですが、定着率を上げるために、今後以下の問題を改善するとよさそうです（優先度順）。なお、アンケートはまだまだ絶賛募集中ですので、ご協力よろしくお願いいたします。
- 毎日同じ時間に鳴るリピート設定がない
- 複数の時間を設定できない
- マナーモード中だと音が鳴らない（iPhone版のみ）
- アラームの音がイマイチよくない
特に「1」は実装が簡単な割には効果的なんじゃないかと予想しています。
コンセプトはよいのか悪いのかを判断する − リーンスタートアップを始めてみました
Morning+（モーニングプラス）というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。リリースから数日経ち、データが集まってきましたので、アプリのコンセプトがよいのか悪いのかを考えてみようと思います。
コンセプトが悪いままプロダクトを小手先で改良しても、今後ユーザー数が大きく伸びることはありません。開発に使える時間は限られているし、ユーザー数が伸びないアプリを改良し続けるのは精神的にも疲れるので、見込みがない場合はできるだけ早く方向転換する、つまり、現在のアプリの開発を中止して別のコンセプトのアプリの開発を始める必要があります。
以下、次のことをまとめます。
- 判断指標
- 各指標の成績
- 結論を出すのに十分なデータが集まっているか
- 結論
１．判断指標
スマホアプリのコンセプトの良し悪しを判断する指標として、次のものを定めました。
- 記事から公式サイトへの流入率（記事を見た人が公式サイトを訪れる割合）
- Twitterから公式サイトへの流入率（ツイートを見た人がリンクをクリックする率）
- Facebookから公式サイトへの流入率（Facebookでリンクのシェアを見た人がクリックする率）
- 公式サイトからのダウンロード率（公式サイトを訪れた人がダウンロードをする率）
アプリのユーザーを増やすために重要な指標としては、ダウンロード率、定着率、紹介率などがありますが、コンセプトがいいか悪いかは、ダウンロード率がいいかどうか、つまり、アプリの紹介を見ただけでをダウンロードしてくれるかと同じと考えます。この数字が悪ければ、既存ユーザーがいくらブログ、Twitter、Facebookなどで情報を流してくれても、新規ユーザーはダウンロードをしてくれないのでユーザー数は伸び悩みます。
２．各指標の成績
以下、公開初日のMorning+の実績です。
| 番号 | 指標 | 結果 | 備考 |
|---|---|---|---|
| 1 | 記事から公式サイトへの流入率 | 10-11％ | リリース初日に記事を書いてくださったのは、TechWave、イケダハヤトさんのブログ、K'confの3つです。初日の昼間に公開されたTechWaveとイケダハヤトさんの記事を見た人のうち、公式サイトへのリンクをクリックした人の割合は、それぞれ11%と10%です。本当はその後ダウンロードバナーをクリックした人の割合をまで調べるべきでしたが、Google Analiticsの設定に失敗したため計測できていません。ただ、どちらの記事も、AppStore、Google Playへの直接リンクが貼られていないため、アプリをダウンロードするには公式サイトを訪れる必要があるという条件です。 |
| 2 | Twitterから公式サイトへの流入率 | 0.7% | リリース初日に、morning-plus.comを含むツイートをした人はリツイートを含めて25人、その25人のフォロワー数の合計はのべ23,774人。Google Analiticsで調べたTwitterから公式サイトへの流入は39人。単純にするためフォロワーの1/4にリーチしたとすると、フォロワー5944人のうち39人がリンクをクリックした計算になります。 |
| 3 | Facebookから公式サイトへの流入率 | 7% | 公開初日のFacebookページの「リーチ数」は824人、「話題にした人」は38人です。このFBページの「いいね！」数は当時48人でした。僕の個人の友達は約200人ですが、Morning+のFBページを「いいね！」してくれた人よりは「話題にした人」の割合が下がることを考慮して、FBページと同数のリーチ数があるとします。すると、初日のFBでのリーチ数は1648人あったことになります。Google Analiticsの分析では、Facebookから公式サイトに流入してきた人は108人でした。Facebookの投稿を見た人1648人のうち、108人が公式サイトへのリンクをクリックしてくれたということになります。 |
| 4 | 公式サイトからのダウンロード率 | 23% | 初日に公式サイトを訪れたユーザーは382人。それらのうち、翌日の昼の12:00までにアラームを使ったユーザーは87人。（なので、この数字は正確にはダウンロード率ではなく利用率ですね。） |
３．結論を出すのに十分なデータが集まっているか
初日の公式サイトのPVは419、ユニークユーザーは382人でした。あと数日データを見て同じ傾向だったらデータは十分と判断していいのではないでしょうか？
４．結論
開発を続けるべきか中止するべきか結論を出したかったのですが、これらの数字がよいのか悪いのか比較する基準がなく、また指標そのものが妥当なのかどうか判断できませんでした（汗） 皆さんでしたら、どうお考えになるでしょうか？ この記事のコメント欄、Facebookページ、Twitter、メール(monte.cutアットgmail.com)などでご意見をいただければ幸いです。なお、今回の論点は「このアプリを多くのユーザーに知ってもらえれば順調にダウンロード数が増えるといえるのか」ということです。定着率、紹介率については別に議論することにさせてください。
お礼
記事を書いてくださっただけでもありがたいのに、検証のためにと記事のPV数まで快く教えてくださった、TechWaveの本田様、ブロガーのイケダハヤト様、本当に感謝しています。
MVP（実用最小限の商品）と挑戦の要 − リーンスタートアップを始めてみました
Morning+（モーニングプラス）という目覚ましアプリでリーンスタートアップを始めました。まずは、MVP（実用最小限の商品）と挑戦の要を定義しようと思います。
MVP
当初は次のような機能を入れることを検討していたのですが、MVPではなくなるため、初期バージョンには含めていません。
- アラームの音をもっと気持ちのよいものにする
- 家を離れたかどうかをGPSで判定するなど、ちゃんと早起きできたか判定するための仕組み
- 寝た時間を記録する仕組み（起きた時間は寄付の実績として初期バージョンでも記録されます）
- 口コミでアプリを広めやすくするために、起きたこと（＝寄付されたこと）を自動でツイートする
挑戦の要
- アプリをダウンロードしたくなるほど、ユーザーが興味を持つ（ダウンロード率）
- ユーザーが長期にわたってアプリを利用する（定着率）
- 積極的に利用するユーザーが、友だちにアプリを紹介する（紹介率）
参考：リーンスタートアップ ヴォスティズンの例（p203）
