Hatena::ブログ(Diary)

モンテカットの開発日記

2017-04-16

メンタル的に潰れる起業家、潰れない起業家

私は、悲しいことに、メンタル的に潰れてしまってうつ病になった起業家だ。ちゃんとした起業家になりきる前に潰れてしまったので、正確にいえば起業家でもないだろう。最近ようやく、まあまあ元気になってきたので、これから起業しようとしている人や、起業して間もない人、さらには今後の自分に向けて、どのようなマインドになればメンタル的に潰れてしまうのか、そして潰れないようにするにはどうすればいいのか、自分の考えをまとめてみようと思う。


私のうつ病のきっかけ

私は、大学を卒業してから、大手IT企業にエンジニアとして就職した。7年間勤務後、自分の作りたいサービスを開発することに専念したくなったため退職した。その後は、初めてリリースしたアプリがちょっとだけ話題になり、2つめにリリースしたアプリも(流行らなかったものの)TECHWAVEイケダハヤトさんなどの有名メディアに取り上げられ、3つめに企画したアプリKDDIのスタートアップ支援プログラム(KDDIムゲンラボ)に選出された。上り調子だった。

しかし、その3つめアプリの企画や開発が難航し、KDDIからの資金調達もフルコミットできるメンバーが自分以外にいなかったため断念(資金調達には事業計画書の作成などでまとまった時間が必要)、その間に生活資金が尽きてしまった。そこで昼間にエンジニアとして副業しながら、夜に自分の開発を進める生活を続けるも、思ったように時間が確保できず、焦りや自責感のため何も手につかなくなり、人にも怯えるようになり、最終的には布団からも出られなくなってしまったのだ。

私のうつ病は、精神的な無理が続きエネルギーが枯渇している状態で、自分の力ではどうにもならない困難が起きたときに発症した。後にたくさんの本を読んだのだが、これは典型的な発症のパターンだった。


そもそもの原因は「思考の癖」

うつ病が発症したきっかけは人によって違うが、そもそもの原因は共通している。うつ病の人や、うつ病になるリスクが高い人は、みんなだいたい同じ思考の癖を持っている。『心が晴れるノート うつと不安の認知療法自習帳』では、以下の9つを挙げている。(カッコ内の説明は一部私の言葉に置き換えた。)思い返せば、私は子どものころから、太字にしている思考の癖が強かった。

  1. 根拠のない決めつけ(根拠が少ないままに悪い思いつきを信じ込む)
  2. 白黒思考(あいまいな状態が我慢できない)
  3. 部分的焦点づけ(自分が着目していることだけに目を向け、やはりそうだったと思う)
  4. 過大評価・過小評価(失敗したことばかり思い出して、成功したことはすぐ忘れる)
  5. べき思考(こうすべきだと思うことと異なる現状にストレスを感じ、ああすべきだったと過去を悔やむ)
  6. 極端な一般化(少数の事象を取り上げ、自分はいつもこうなってしまうと考える)
  7. 自己関連づけ(悪いことが起きると自分のせいだと考える)
  8. 情緒的な理由付け(そのときの感情にもとづいて、ダメだと判断してしまう)
  9. 自分で実現してしまう予言(否定的な予測を意識しすぎるために、予測通り失敗してしまい、さらに予測を信じ込む)

思考の癖は長所にもなるため隠れやすい

困ったことに、これらの思考の癖は裏を返せば長所になることもあるため、修正されないまま大人になっていく。たとえば、2の白黒思考は本質を追求する、5のべき思考は理想を高く持って努力する、7の自己関連づけは責任感があるというように、それぞれいいように言い換えることができてしまう。


思考の癖に気付いたときはもう遅い

また、運よく思考の癖に気付いたとしても、起業した後だともう遅い。数十年にわたって染み付いた思考の癖を修正するには、最低でも数年の時間がかかるといわれている。投資家やチームのメンバーが、それが終わるまで待ってくれることはないだろう。


起業家のマインドの分類と危険ゾーン

これまでで書いたように、うつ病を防ぐ最強の方法は思考の癖を修正することだが、「よし、思考を変えよう」と思うだけで変えることはむずかしい。

幹線道路の工事中に迂回路を作るのと同じように、思考の癖の修正が完了する間、取り急ぎ潰れないようにすることも大切だと思う。そこで、自分の過去を振り返ってみて、即効性がありそうな方法を考えてみた。

まず、起業家のマインドを、下の図のように2軸で分類する。

f:id:MonteCut:20170415203004p:image


「事業アイディアへのこだわりが強い」人は、もし自分のやりたい事業ができるなら独立せず社員でも十分だと思っている。自分がそれをやることに社会的な使命感を感じているようなマインドである。逆に、独立ありきで、何かお金になる事業をやりたいというのであれば、事業アイディアへのこだわりが弱いということになる。

「失敗は許される」は、関係者(投資家やメンバー)が失敗を許容している、かつ自分でも失敗を許容している状態である。関係者がどう考えているかわからない場合は、自分自身で失敗を許容しているかどうかが指標になる。

図の左上のゾーンは、典型的なスタートアップ起業家のマインドだ。ユニークなアイディアや技術を売りにしていて、サービスの内容が簡単に変わることはない。そのアイディアに人生を捧げるほど熱中している人もいるが、失敗が許されるこのゾーンにいるうちはメンタル的に潰れることはない。

左下のゾーンは、ロケット・インターネットに代表される、儲かるなら他のサービスのパクリでもOKという起業家のマインドだ。こちらもメンタル的に潰れる心配はない。

右下のゾーンは、大きな失敗はできないので、ローリスクな事業で起業しようとする人たちのマインドだ。脱サラしてフランチャイズへの加盟を検討している既婚男性や、○○講師や○○カウンセラーなどの複数の資格を持っている「ママ起業家」などが該当する。失敗するリスクを恐れているため、メンタル的には少し窮屈ではあるが、状況が悪くなると他の事業に切り替えることも可能なので潰れることは少ない。

問題は右上のゾーンだ。危険ゾーンと名付ける。最初は左上のゾーンにいたのに、気付いたらこのゾーンに入っているケースが多いはず。事業アイディアへのこだわりが強いために、状況が悪くなっても他の事業に切り替えることができずストレスがたまる。さらに、失敗は許されないと思い込んでいるので頑張りすぎて疲弊してしまう。もし危険ゾーンに入っていたら、すみやかに回避行動をとらないといけない。


潰れることを回避するためにやるべきシンプルなこと

潰れることを回避するためにやるべきことは「失敗に気づき、清算する」ことだ。上記の図でいうと、横軸の右に振り切れた状態を、左に戻すことである。縦軸は心の問題なので修正はむずかしい。一方、横軸は行動で修正可能だ。以下の2つの行動を起こしてみるといい。

1. 失敗に気付くため行動

失敗が許されないと思っている心理状態では、進捗が思わしくなくても、自分ではなかなか失敗と認めることができない。そこで、「スケジュール」というチェックポイントを使って、失敗しているのかどうかを客観的に判断してみる。

事業の進捗が予定より遅れて、スケジュールを引き直すことがあれば、それはひとつの「失敗」とカウントする。遅れた理由は関係ない。品質の向上であれ、ユーザーの動向を分析した結果であれ、ピボットであれ、スケジュールを引き直せばそれは失敗だ。

スケジュールの引き直しが許されている間は、「失敗は許される」状態ということになる。しかし、度重なる失敗で、関係者(投資家やメンバー)に、これが最後だと通告されたとき、もしくは自分でこれが最後だと思ってしまったときは、「失敗は許されない」状態である。

2. 失敗を清算するための行動

もし「危険ゾーン」にいることに気付いたのなら、いますぐ「清算」の行動に出るべきだ。ここにいる状態で、最後のひと頑張りは絶対してはいけない。あなたは、もう十分やってきた。これ以上頑張ると潰れてしまう。心理的に大きな抵抗があると思うが、最後のひと頑張りをするエネルギーは、ここで使ってほしい。

やることはシンプルだ。それは、関係者(投資家やメンバー)に謝ること。メンタルが「危険ゾーン」に入ってしまったことをていねいに説明すればよい。事業を副業などしながら細く長く続けていく方向に切り替えるとしても、「いつまでにはできそうです」などとコミットしないで、あくまで失敗で終わらせる。いったんすべてきれいに清算する。謝って、許してもらうことで、強制的に「失敗は許されている」状態に移行するのだ。

その後、個人的に野心を持ち続ける分には問題ない。別の本業があるなかで、今度は副業として事業を進めることになるので、なかなか進まないことにストレスはたまるが、他人に迷惑をかけることはないのでメンタル的に潰れるまではいかない。もちろんその間に思考の癖の修正することは忘れずに。


現在の私

私はいま、クオリサイトテクノロジーズ株式会社という地方(沖縄と北海道のみに拠点)にありながら首都圏レベルの仕事ができる会社で、エンジニアとして働かせてもらっている。うつ病から十分に回復していないうちに就職したため、就職してから1年半後に再びうつ病で休職してしまう最悪の状況で迷惑をかけたが、最近やっと復職することができた。

そして、うつ病になる前にやっていた事業からはいったん離れて、趣味の時間で別のサービスもリリースしている。相変わらずなかなか進まないことでストレスは感じてしまうが、日々の認知行動療法でそのような思考の癖を修正しながら、まずは普通の生活ができることを目指している。

2012-08-27

iOS + PHPでPush Notificationを実装する

Morning Relayという目覚ましアプリで、iOS + PHPでPush Notificationを実装してみた。公式ドキュメントを読むと複雑で難しそうだが、じっくりやれば大丈夫。サーバー側の実装は公式ドキュメントには実例が載っていないのだが、「apns-php」というPHPのライブラリを使うことでラクにできた。

環境

  1. XCode 4.3
  2. PHP(フレームワークCakePHPを使っているが、特にCakePHPに依存している個所はない)
  3. サーバー側のライブラリにapns-phpを使用、ローカルでの作業にMac標準の「キーチェーンアクセス」を使用

概要

  1. 準備
    • App IDを作成する
    • プロビジョニングファイルの作成とローカルへのコピー
    • ローカルでCSR(証明書署名要求: Certificate Signing Request)ファイルを作成、それをAppleのサーバーにアップロードして証明書と鍵を受け取る
    • 自分のサーバーに配置するためのSSL証明書と鍵を作成する(2種類のpemファイルを作成)
  2. iOS側での実装
    • RemoteNotificationを登録する
    • デバイストークンを取得する
    • デバイストークンを自分のサーバーに送る
  3. サーバー側での実装
    • apns-phpをダウンロードする
    • apns-phpのファイルを修正する
    • Apple Push Notification サービス(APNs)にプッシュ

準備

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が送られてきた!

f:id:MonteCut:20120827234122p:image

参考URL

Local および Push Notification プログラミングガイド(公式ガイド)

apns-phpの公式サイト

PROGRAMMING NOTE Apple Push Notification サービス(APNs) の実装方法

iPhoneアプリで稼げるのか【iPhone】Push Notificationの実装方法

2012-06-28

Morning+の流入率 − リーンスタートアップを始めてみました

Morning+(モーニングプラス)というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。2週間の検証実験が終わりましたので、公式サイトへの流入率をまとめまておきます。

流入率は、ブログ記事、ソーシャルメディアのタイムラインなど外部サイトの情報を見たユーザーが、どのくらい公式サイトへのリンクをクリックしてくれるかを示すものです。この数字が低ければ、頑張ってメディアへの露出を増やしても、なかなか集客につながりません。

スタートアップの評価指標は以下のようなものがあると思いますが、流入率以外は別のエントリーでまとめます。

  1. 公式サイトへの流入率(大手メディアの記事、FacebookTwitterから)
  2. ダウンロード率(公式サイトのダウンロードバナーのクリック率)
  3. 1度使う率
  4. 定着率
  5. 紹介率(口コミ率)

流入率の計算方法

Morning+では、大手メディアの記事、Twitterのタイムライン、Facebookのタイムラインのそれぞれで流入率を算出しています。

  1. 大手メディアから公式サイトへの流入率
  2. Twitterから公式サイトへの流入率
  3. Facebookから公式サイトへの流入率

1は、大手メディアの記事を見た人における公式サイトへのリンクをクリックする人の割合です。2は、TwitterのタイムラインでキャッチコピーとURLを見た人におけるクリックする人の割合です。3は、Facebookのタイムラインで投稿を見た人におけるクリックする人の割合です。

結果

番号指標結果備考
1大手メディアから公式サイトへの流入率10-11%リリース初日の昼間に記事を書いてくださったのは、TechWaveイケダハヤトさんのブログです。これらの記事を見た人のうち、公式サイトへのリンクをクリックした人の割合は、それぞれ11%と10%です。どちらの記事も、AppStore、Google Playへの直接リンクが貼られていないため、アプリをダウンロードするには公式サイトを訪れる必要があります。
2Twitterから公式サイトへの流入率0.7%リリース初日に、morning-plus.comを含むツイートをした人はリツイートを含めて25人、その25人のフォロワー数の合計はのべ23,774人。Google Analiticsで調べたTwitterから公式サイトへの流入は39人。単純にするためフォロワーの1/4にリーチしたとすると、フォロワー5944人のうち39人がリンクをクリックした計算になります。
3Facebookから公式サイトへの流入率7%公開初日のFacebookページの「リーチ数」は824人、「話題にした人」は38人です。このFBページの「いいね!」数は当時48人でした。僕の個人の友達は約200人ですが、Morning+のFBページを「いいね!」してくれた人よりは「話題にした人」の割合が下がることを考慮して、FBページと同数のリーチ数があるとします。すると、初日のFBでのリーチ数は1648人あったことになります。Google Analiticsの分析では、Facebookから公式サイトに流入してきた人は108人でした。Facebookの投稿を見た人1648人のうち、108人が公式サイトへのリンクをクリックしてくれたということになります。

考察

僕は「流入率が悪い=アプリのコンセプトが悪い」というのが成り立つのではないかと考えています。アプリのコンセプトそのものが悪いと、いくら機能を改善してもユーザー数が大きく伸びることはありません。

この流入率が高いか低いかは、他のアプリがどうなのかわからないので判断できませんが、期待していたよりは低いです。

お礼

記事を書いてくださっただけでもありがたいのに、検証のためにと記事のPV数まで快く教えてくださった、TechWaveの本田様、ブロガーのイケダハヤト様、本当に感謝しています。

2012-06-26

Morning+のダウンロード率 − リーンスタートアップを始めてみました

Morning+(モーニングプラス)というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。2週間の検証実験が終わりそうですので、ダウンロード率を計測してみました。

ダウンロード率は、ブログ記事、ソーシャルメディア、広告などの外部サイトから公式サイトに流入したユーザーが、どれだけ実際にダウンロードしてくれるかです。この数値が悪いと、せっかく集客してもユーザー獲得にはつながりません。

スタートアップの評価指標は以下のようなものがあると思いますが、ダウンロード率以外は別のエントリーでまとめます。

  1. 公式サイトへの流入率(大手メディアの記事、FacebookTwitterから)
  2. ダウンロード率(公式サイトのダウンロードバナーのクリック率)
  3. 1度使う率
  4. 定着率
  5. 紹介率(口コミ率)

ダウンロード率の計算方法

Morning+では、以下の計算方法でダウンロード率を出します。

公式サイトのダウンロードバナーをクリックした人の数 / 公式サイトを訪れた人の数

のはずだったのですが、アクセス解析Google Analitics)の設定がうまくいかず、「App Store, Google Playでのダウンロード数 / 公式サイトを訪れた人の数」で計算しています。

ただ、このアプリに限っては、後者の計算方法でも結果はあまり変わりません。現状のDL件数ではApp Store, Google Playで目立つことはないので、マーケットで直接ダウンロードされることはほぼないと考えられます。また、アプリを紹介してくださったブログのなかにはマーケットへの直接リンクが含まれているのでダウンロード数の方が多くなる可能性はありますが、このアプリでは公式サイトでのブログがコンテンツの一部になっていますので、アプリを1度でも使ったユーザーは、ほぼ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のダウンロード数のグラフをアップしておきます。

f:id:MonteCut:20120626164712p:image

考察

ダウンロード率を上げるには、公式ページのデザインを改善する方法あるかもしれません。

公式ページのデザインが悪くないと仮定した場合、ダウンロード率はコンセプトのよさに左右されるのではないかと思っています。アプリがダウンロードされるのは、公式サイトを見ておもしろいと思ってくれた場合だけからです。

前作の目覚ましアプリMorningBombのときは、3日間でダウンロード数が474、公式サイトのUU数が1085でしたので、割合は43.4%です。ただ、DL数に大きく寄与したGIGAZINEの記事では、記事だけで公式サイト以上のことが伝わるクオリティーがあったこと、マーケットへの直接リンクがが含まれていたことから、単純に今回と比較することはできません。

2012-06-25

Morning+の定着率 − リーンスタートアップを始めてみました

Morning+(モーニングプラス)というiPhone/Androidの目覚ましアプリでリーンスタートアップを始めました。2週間の検証実験が終わりそうですので、定着率を計測してみました。

定着率は、イケダハヤトさんのブログ記事、重視すべきは定着率―バケツに穴は空いていないか?でも書かれているように、スタートアップにおける最も重要な評価指標といえます。評価指標は以下のようなものがあると思いますが、定着率以外は別のエントリーでまとめます。

  1. 公式サイトへの流入率(大手メディアの記事、FacebookTwitterから)
  2. ダウンロード率(公式サイトのダウンロードバナーのクリック率)
  3. 定着率
  4. 紹介率(口コミ率)

定着率の計算方法

Morning+では、以下の計算方法で定着率を出します。

1週間で50%以上(3.5日以上)使ったユーザー数 / これまでに1度でも使ったユーザー数

土日はアラームを使わない人が増えるのを踏まえて、週3.5日以上の利用で定着していると定義しました。1度でも使ったことがあるユーザー数は、第1週で170人、第2週で252人です。

結果

第1週:18%

第2週:17%

f:id:MonteCut:20120625183046p:image

定着率が高いかどうかは、比較するものがないのでわかりません。どなたか、ご存知でしたら教えていただければうれしいです。連絡先は、TwitterFacebook、monte.cut[アット]gmail.comです。

定着率を上げる手段

ユーザーへのアンケートを行っている途中ですが、定着率を上げるために、今後以下の問題を改善するとよさそうです(優先度順)。なお、アンケートはまだまだ絶賛募集中ですので、ご協力よろしくお願いいたします。

  1. 毎日同じ時間に鳴るリピート設定がない
  2. 複数の時間を設定できない
  3. マナーモード中だと音が鳴らない(iPhone版のみ)
  4. アラームの音がイマイチよくない

特に「1」は実装が簡単な割には効果的なんじゃないかと予想しています。