iOSアプリをローカルサーバーと通信させて実機デバッグする方法

お久しぶりです、社内で「ラブライブ、紅白出場おめでとうございます」と声をかけられる田村(@Utmrer)です。

私はiOS/Androidのクライアントサイドとサーバーサイドの実装をどちらも担当しているのですが、「ローカルサーバーで開発してるAPIを使いながら、アプリも開発する」ということをよくします。

その時に、アプリ側で通信するhostを本番環境のhostから自分のPCのローカルIP(192.168.1.XX, 10.0.1.YYなど)に変更してローカルサーバーとアプリを通信させていたのですが、IPv6サポートの流れからか、iOS9では出来なくなりました。*1

ローカルサーバーと通信出来ないとぶっつけ本番でデプロイする恐怖や、変更する度に開発環境にデプロイする煩わしさと戦わなければいけません。
それらを避けるためにiOS9でもローカルサーバーと通信する方法をご紹介します。

TL;DR

• IPアドレス指定での通信が出来なくなったのでローカルホスト名を使う
• hostnameを使ってhostの設定を自動化すると楽ちん
• ATSの設定もScriptで自動化出来る

Macのローカルホスト名を確認しよう

Macのローカルホスト名はシステム環境設定アプリから共有を選択すると表示されます。
このnozomi.localの部分があなたのローカルホスト名で、アプリが通信するhostです。

VagrantやMAMPで起動してるローカルサーバーのlocalhost:port(ex. localhost:8888)へ、Macと同じローカルネットワーク上のiPhoneのSafariからnozomi.local:8888という感じでアクセス出来るかと思います。

iPhoneからローカルサーバーと通信する

前項で確認した*.localのhostを本番環境のhostと置き換えればアプリとローカルサーバーが通信する準備が整ったのですが、App Transport Securityの影響でAllow Arbitrary Loads=YESにしてない場合は*.localのローカルサーバーとは通信は出来ない状態でしょう。
この設定も自動化して行きたいので環境別のhost設定からATSの設定まで自動化して行きましょう。

Info.plistにhostを持たせる

まずはこのようにInfo.plistに本番環境のhostを設定しておきましょう。 ServiceHostというKeyにexample.comという本番環境のhostが定義されています。

このServiceHostの値をビルド時に自動で設定します。サンプルコードではdiffを出したくないのでPreprocess Info.plist Fileを有効化しました。 Preprocess Info.plist Fileについて詳しくはこちら

ローカルホスト名はhostnameコマンドで取得できるのでBuild PhasesでScript追加してDebug Configurationの時だけInfo.plistを上書きするようにします。

Preprocessed-Info.plistを編集しているのでビルドの度にdiffが出てイライラすることもありません😊

そしてこのようにInfo.plistからhostを呼び出せばConfiguration毎に異なるhostへアクセス出来ます。

ATSの設定に*.localを含める

上記のようなATSの設定をしている場合、*.localはATS例外に含まれていないので通信できません。
*.localのhostもScriptでATS例外に追加しましょう！

上記のScriptをBuild Phasesに追加すると*.localもATS例外に追加出来ます。 Delete処理が入っているのはDerivedDataにPreprocessed-Info.plistのキャッシュが残っている場合があるからです。

ATSの環境別設定とPlistBuddyについてはこちらもご覧ください。 tech.connehito.com

今回ご紹介した内容を設定してあるサンプルプロジェクトも作ってみたのでもし良ければご覧ください。 特にBuild Phases辺りが肝です。 github.com

終わりに

以上で「iOS9でもローカルサーバーと通信する方法」&&「環境別の設定の切り替えを自動化」は終わりです。
「ﾅﾆｿﾚｲﾐﾜｶﾝﾅｲ」なところや、もっと簡単な方法があるよ〜って方は是非教えて下さい！ランチしながらPlistBuddyについて熱く語りましょう。

*1:App Transport Security and IP addresses in iOS9 - Stack Overflow

【1コマンドでOK】MySQLユーザーに贈る、スロークエリ解析の始め方

こんにちは！

CTOの島田(@tatsushim)です。前回の私の記事ではインフラ構成について触れました。
インフラを構築したらその運用が必要になりますね。今回は社内で行っているDBのスロークエリ解析について紹介したいと思います。

時間がない人向けに要点を3つにまとめると

• ママリでは定期的にクエリの見直し時間をとっている
• その理由は、レスポンスタイムがユーザーの滞在時間に大きく影響するため
• pt-query-digestを使うとカジュアルにクエリログを解析できるから初心者にもオススメ

という感じです。それぞれについて解説していきます。

定期的にクエリの見直しをする

現在ママリでは、定期的にクエリの見直しをする時間を開発スケジュールに入れています。
それは、レスポンスタイムがユーザーの滞在時間に大きく影響するためです。
ORマッパーでコードを書いていると気づかないうちにスロークエリを発行してしまいがちなので、 定期的に対策を行うことで問題を未然に防いだり、コードを書く際にも発行クエリへの意識が向くようになりました。

スロークエリを解析してみる

元々MySQLにはスロークエリの閾値を決めて吐き出す機能がありますが、
どのクエリから対策をすれば良いかの取捨選択を行う際に、そのログを目grepするのは辛いので社内ではpt-query-digestを利用しています。

pt-query-digestとは

mysqlのslow queryのログ等を集計し、改善が必要なクエリを上位に並べてくれるツールです。

pt-query-digestで解析する

インストール

• pt-query-digestコマンドを使うために、percona-toolkitをインストールする
• mac環境でbrewが入ってれば、コマンドは以下のみ

brew install percona-toolkit

実行する

• 以下コマンドで集計結果が出ます*1
• pt-query-digestコマンドの引数にはスロークエリのログ(ここではmysql-slowquery.log)を渡します。

pt-query-digest mysql-slowquery.log

結果を見てみる

• 結果には改善が必要なクエリが上位に出力されます。なので基本は上から潰していきます。
• 頻度や実行時間を確認することができます。以下が1つの具体的な例です。*2

Attribute    pct   total     min     max     avg     95%  stddev  median
============ === ======= ======= ======= ======= ======= ======= =======
Count         19      44
Exec time     25     75s   514ms      3s      2s      3s   956ms      2s
Lock time      1     7ms   128us   263us   155us   214us    37us   131us
Rows sent     85   2.77M  20.33k 105.50k  64.42k 101.89k  38.80k  92.42k
Rows examine  26  36.57M 243.30k   1.40M 851.03k   1.39M 543.75k   1.03M
Query size     1  72.24k   1.64k   1.64k   1.64k   1.61k       0   1.61k
String:
Databases    foo
Hosts        10.1.0.193 (8/18%), 10.1.3.127 (6/13%)... 
Users        bar
Query_time distribution ← クエリの実行時間の分布
  1us
 10us
100us
  1ms
 10ms
100ms  ############################################
   1s  ################################################################
 10s+

• このサンプルの場合、1sを超えることが多いクエリになっていますね。ここを改善すれば大きな改善になると思われます。

おわりに

いかがでしたでしょうか？ インストールから実行まで2コマンドでできるので、カジュアルにトライしてみると今まで見落としていたスロークエリが見えるかもしれません。
弊社ではスロークエリを減らし、レスポンスタイムが改善されたグラフを見て一緒に(･∀･)ﾆﾔﾆﾔしたい方を募集中です。

参考サイト

pt-query-digest

*1:--typeを指定することで、PostgreSQLのログ等にも対応が可能です。詳しくは参考サイトをご覧ください。

*2:中身はサンプルです。実際の解析結果ではありません

本当に使える！PHPerなら知っておきたい便利な配列関数79選！！ ver.2015

こんにちは、出前館愛用者の金城です。怠惰に過ごしたい休日といえば、deliveryですよね！！

さて、秋も深まりつつある今日この頃ですが、この場を借りてPHPにおける連想配列について書いてみたいと思います。
私達コネヒト開発陣一同は、親しみと敬意を以って連想配列に日々接しております。
このブログをご覧にいらっしゃるみなさまも、きっと日々の生活の中で・・・職場で、家庭で、あるいは気の置けない旧友との心温まる交流の場面でも、連想配列に夢中で居る事と思います。

そんな彼らについて、php.netを覗いてみると、このような記述があります。

配列で使用する便利な関数がたくさんあります

あの「一体、何に使うんです・・？」といった関数も標準で多く用意されていることで名高いPHP語をして曰くところの、「たくさん」です。
どんなものかとワクワクしますよね。

そこで、今回は「どんな関数があるのだろう」を見ていきたいと思います！
単に50音順に並べても分かりにくいので、公式リファレンスをベースにして、(主観で)7つのグループに分けながら「たくさんの」関数を紹介してみたいと思います！
見たこともない、まして使ったことのない(あるいはこの先も使うことのない!)関数が、きっと1つはあるはず・・？

ほとんどJSが書けなかった新米デザイナーが、ベンチャー入社半年で学んだチーム開発で大切な「7つのおもてなし」

こんにちは！デザイナーのきよえし(@kiyoe_furuichi)です。
この度10月でConnehito.incに入社して半年が経ちました！めでたい！
ほとんどJSが書けなかった私も今ではフロントもごにょごにょするデザイナーになりました。

良いタイミングなので今回のエントリーは、半年の間に学んだことの共有として、 デザイナーもできる、チーム開発で大切な「おもてなし」についてご紹介したいと思います。

チーム開発における「７つのおもてなし」

0. どうして「おもてなし？」

入社した当時を振り返った時、自分の開発過程やメンバーとのやりとりを見ていかに早く自分のタスクをこなせるかを優先した"オレオレ"デザイナー だったことに気づかされました。その衝撃をきっかけに、"チームとしてサービスを作り上げる"にはどうすれば良いのかを意識して考えるようになったんです。
それから、チーム開発で大切なことはメンバー全員が他のメンバーのことを考え、気持ちよい実装を行えるように気遣う「おもてなし」の心を持って開発を行うことが大切だなあと感じるようになりました。
現在もまだまだ模索中ですが、今回は、今の私が考える「おもてなし」について以下にまとめてみます。

「7つのおもてなし」

1. こまめな共有・把握
2. 思考の過程を残す
3. 互いをねぎらう
4. ”伝える”コメントに
5. 楽しむ工夫をする
6. 会話からインプットする
7. できることを増やす

これから具体例をいくつかご紹介しますが、実際に過去に行った会話を抜粋しています。

1. こまめな共有・把握

おもてなしのポイント

メンバーがそれぞれ今何に着手しているか、次に何をするのかを共有・把握をする。開発が滞ることがないよう、メンバーそれぞれの状況を気遣うことが大切！

具体例

私：次タスクAに着手する予定ですが、もしかしてエンジニアさん的にタスクB先にやっておいたほうがコンフリクトせずスムーズにすすめられそうですか？？

エンジニア ： あ、そうだねー！タスクBを先にデプロイしたいかも！先行して実装しておいてもらえると助かります！ありがとう🙏

私：かしこまりました！実装しておきますー！

声かけを行ったり、メッセージで前もって確認しておくなど、同じタスクを受け持つ実装者が次に着手するものを把握しておきましょう。(いつどのタイミングで上がってくるのかまで分かっておくと◎) 把握しておくことによって、"もしかするとこっちを先に着手したほうがいいかも"、といったような気づきが生まれたり、逆も然りで、共有しておくことによって、メンバーも気づきを得て、お互いのことを気遣ったタスクの順序づけをすることができます。それによって、滞ることなく、気持ち良い開発が行えるようになります！

2. 思考の過程を残す

おもてなしのポイント

仕様や実装に必要な情報だけでなく、その時何を考えてこうなったのか、思考の課程をメモとして残しておくようにする。未来の自分、チームが当時を振り返る際に大切な手がかりになる！

具体例

ディレクター：この機能なんだけど、なんでこの色になったんだっけ？

私：えっと、、記憶ちょっと曖昧なのでメモの確認させてください！

私：(確認してみよ〜)

[メモ]：要素Aのカラーリング、イメージ的には淡いピンクが適しているんだけど、要素Bとかぶるからナシ。色々試した結果、淡い紫にすることに。ちょっとネガティブな印象を与えるかも、数値とFBで振り返ってみて要検討

私： ディレクターさん、イメージ的には〜なんですが、一方で〜・・・

ディレクター：なるほど、だよね。ここやっぱピンクにした方がいいかも。例えばさ〜・・・

毎日いろんな新しい機能を実装していると、どうしても記憶が曖昧になったり抜け落ちることがあります。 リリース後の機能を振り返るためには、何を考えてこの機能になったのか、文脈を理解した上でレビューをしなければなりません。でもそれって結構難しいんですよね…。 なので少しでも思考を思い出しやすくするために、未来の自分、メンバーのおもてなしとしてメモとして残しておきましょう。

3. 互いをねぎらう

おもてなしのポイント

メンバーの頑張りをねぎらう声かけ・感謝の気持ちを伝えることを大切に。チームの結束はここから生まれる！

具体例

「LGTM！」

LGTMとは、Looks good to meの略語で、いいね！の意味合いでつかう言葉です。よくエンジニア界隈でPull Requestのレビュー完了時に使われていますね！ 私たちもレビューの完了時に、レビュワーが実装者に対して労いの言葉として「LGTM!」を送っています。

主にこのサイトを利用しています : LGTM.in/g

「おつです！」

機能をリリースしてSlackで全体に通知する際、メンバー全員が実装者に対して「おつです！」「おつ！」「おつかれさまですー！」など労いの言葉をかけるよう心がけています。

このように、お互いを労うことはチーム間の信頼関係を築くうえでとても大切です。 実装していただいたことへの感謝の気持ちを持って開発を行ないましょう。

4. "伝える"コメントに

おもてなしポイント

ミスコミュニケーションを起こさないよう、相手に言葉の内容が”まっすぐ伝わる”文章でメッセージを送る！

大きな開発の終盤になったりすると、それぞれ自分のタスクの実装で余裕がなくなりがちです。そんな時はどうしてもレビューやメッセージのコメントが荒くなり、ミスコミュニケーションが起こりやすかったりします…！

そんな課題を簡単に解決するのが、emoji・顔文字です！ 使うと文字が与える単調さがちょっとだけ緩和されて、どんなときも安定感のある”伝わる”コメントをすることができます。

具体例

before

ここ実装抜けもれあります、よろしくお願いします。

after (emoji)

ここ実装抜けもれあります、よろしくお願いします 🙏✨

after (顔文字)

ここ実装抜けもれあります、よろしくお願いしますヽ(=´▽`=)ﾉ

ちょっとやわらかい印象になりますよね！

5. 楽しむ工夫

おもてなしのポイント

チーム全体がポジティブに開発できるよう、ちょっと楽しくなる工夫を取り入れてみる。 単調な作業の中に、クスッとさせるおもしろさを取り入れるのも、相手の気分を明るくするおもてなしの一つ！

開発を行っていると、バグが出たり、謎のレイアウト崩れなど、ちょっとした闇が稀に襲ってくることがあります。 そんなとき、気分がちょっと上がるものがあると嬉しいですよね！

具体例

ドラゴン

チーム全体ではバグのことをドラゴンと呼んで楽しんでますw ちょっとバグfixドラゴン退治が楽しくなりました。

元ネタ : バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP

Reactionの投げ合い

最近、SlackのReactionが頻繁に飛びかってます！ よくわからないemoji(笑)だったり、ランチや夕飯の時間帯になると食べ物のemojiがつくことが多いです。

ラーメンション

@ramention kiyoeshi

ラーメン + メンション。大体週末にramentionしてチームでラーメン食べにいきます。

寿司🍣

最近、寿司(🍣)のemojiでReactionするとなんかくる？！？！？？？？！(謎)

このような、ちょっとしたことだけど、見てるだけでちょっとクスッとなるような工夫があると、チームがより明るくポジティブな雰囲気となって良いアウトプットを生み出すことにつながっていくと考えています◎

6. 会話からインプットする

おもてなしのポイント

それぞれのメンバーの視点から見るチームの課題をインプットし、もっとチーム開発をより良くするための鍵を積極的にさがしてみる！

開発を行っていると、目の前にあるそれぞれの課題をこなすことに精一杯で、視野が一方向になりがちです。なので月一程度に、ラフに1to1ランチをするのがおすすめです！

具体例

もっと仕様詰める段階でサーバサイドも見たいです！その方がロジックの工数の見積りだったり、ここはこうじゃない？みたいなところが言えるので後々の出戻りがすくなくなるかと！

7. できることを増やす

おもてなしのポイント

ちがう役割の領域にトライする。一歩踏み入れてできる範囲を増やすことによって、単純なコードなどでの手戻りなどが短縮されるため、お互いに工数を減らせることにつながる。

具体例

サーバーサイドエンジニア：フロントが簡単なViewを表示するロジックが書けると結構助かるかも！

サーバーサイドエンジニア：新しいページをつくる際のRoutingをぱぱっとできるようになってくれると助かります🙏

iOSエンジニア：ストーリーボードでViewを少し作れるようになってくれるとネイティブのUI部分任せられるから助かるかも。

こういったように、役割のちがうエンジニアさんから、"できるとうれしい"部分を日頃から聞いてストックしています。 休日などにコードを読んでみたり、書いてみたりして覚えることで、お互いの手間が省くことができるようになります。 できないところは教えてもらいつつ、自分のできる領域を広げることにトライしてみましょう。

まとめ

以上、「7つのおもてなし」いかがでしたでしょうか。

人の温かみのある、なくてはならないサービスであり続けるために、チーム開発をする上で「おもてなし」の心はとても大切だと考えています。 この半年、開発をしていて思うのは作り手のテンションがユーザーさんにも伝わるということです。 ポジティブな感情はよいサービスを生み出す原動力。少しの心遣いで、チームの雰囲気が良くなり以前よりもっと楽しく開発を行えるようになりました！

チーム開発で大切なことは、 メンバー全員が他のメンバーのことを考え、気持ちよい実装を行えるよう「おもてなし」の心をもった開発を行うこと です。 みなさんも、「おもてなし」について今一度考えてみませんか？
最後まで読んでいただきありがとうございました！

---

コネヒトではエンジニアさん、デザイナーさん、デザイナーさん、デザイナーさんをWANTEDしています！ 全チームメンバーが手厚くおもてなしします♡ お待ちしておりますー！
www.wantedly.com

Plistを操作するPlistBuddyでiOS9のApp Transport Securityの煩わしさから開放される

こんには！コネヒト所属のラブライバー兼エンジニアの田村(@Utmrer)(26歳)です。 先日母にラブライブレードが見つかりこの世の地獄を味わいました。

さて、iOS Developerの皆さん、PlistBuddy使ってますか？ PlistBuddyはMacに最初から入っているPlistを操作するコマンドで、弊社のiOS開発で活躍しまくりのコマンドです。
今回はPlistBuddyでiOS9から対応が必要になったApp Trasport Security(以下ATS)の煩わしさから開放される方法をご紹介します。

開発環境のドメインとATSの設定にかかる問題

先日iOS9がリリースされ、ATSの設定をしていたDeveloperの方も多いと思います。 サービスで使用しているドメインがすべてSSLに対応している場合は必要ありませんが、対応していない場合はNSExceptionDomainsにホワイトリストで指定しなければいけません。
しかし、問題になるのが開発環境のドメインをInfo.plistに追加するかどうかです。

開発環境のドメインを本番環境のサブドメインにしている場合はNSIncludesSubdomainsで大丈夫ですが、まったく違うドメインの場合はNSExceptionDomainsに追加する必要があります。
しかし、開発環境のドメインをNSExceptionDomainsに追加するのには抵抗があります。 なぜならInfo.plistはunzipすればすべての人が見ることが出来るので、開発環境のドメインを公開することは望ましくありません。

そこで活躍するのが複数のPlistをMergeして1つのPlistにするPlistBuddy Mergeコマンドです。

PlistBuddy Mergeで環境別にATS例外を設定する

開発環境のドメインを以下のようなPlistにしてInfo.plistとは別に用意しておきます。

そしてBuild Phasesに以下のようなScriptを追加することによってDebugのConfigurationでビルドした時のみ、開発環境のドメインをInfo.plistに追加する事ができます。(Preprocess Info.plist FileをYesにする必要があります)

これでDebugビルドの時だけNSIncludesSubdomainsに追加するとか、間違えてReleaseビルドに開発環境のドメインを含めてしまうなどのミスや煩わしさから開放されます。 atsPlist="${SRCROOT}/YourApp/development-ats.plist"の所をatsPlist="${SRCROOT}/YourApp/${CONFIGURATION}.plist"とすれば複数のConfigurationで別々のドメインを設定することだって出来ます。やったね！

おわりに

弊社のiOS開発では他にもPlistBuddy SetでBundleVersionにcommit hashを含めたり、外部ライブラリのDebug Modeを切り替えたりしています。
「PlistBuddyでこんなScript書いてるけどすげー便利だぜ」というのがある人は是非教えてください。

参考文献

PlistBuddy(8) Mac OS X Manual Page

インフラエンジニアがサービスの0→1を創る際に意識した、たった1つのこと

こんにちは！

CTOの島田(@tatsushim)です。 先日mamari tech nightというエンジニア向けのLTイベントを社内で開催しました。 その際にママリのインフラ構成について発表したのですが、当時を振り返り大事だなと思うことがあったので、今回はその学びを共有したいと思います。

完璧なインフラ構成は必要ない

結論からお伝えするとサービスの立ち上げ時に「完璧なインフラ構成は必要ない」というお話です。

ママリの最初のインフラ構成

実はママリの最初のインフラ構成は以下のような構成になっていました。*1

構成は1台のEC2インスタンスのみで、もちろん、DB(MySQL), Apacheなどは全部入りです。 しかしインフラ構成はしばらく変えず、アプリケーションの機能開発にリソースを割きました。

そのインフラ、本当に今必要？

サービスを創る際、1エンジニアとしてはそのサービスを滞りなく運営するために必要なインフラを整えます。 その際、例えば以下のようなケースを考えます。

• サービスがもしヒットしたら膨大なトラフィックが来るはず
• ユーザーランキングの集計ロジックは重いから、キャッシュサーバーたててキャッシュしておかないと
• ユーザー数が100万になったときにも耐えられるようなインフラ設計にしておかなければ

しかし上記はほとんどのケースでサービスのリリースからある程度経ったあとに必要とされる機能です。 実際は多くの場合以下のようになると思われます。

• サービスがもしヒットしたら膨大なトラフィックが来るはず
  → 多くのケースで、期待した程膨大なトラフィックがそもそも来ない
• ユーザーランキングの集計ロジックは重いから、キャッシュサーバーたててキャッシュしておかないと
  → ユーザー数が数千人程度の集計ならMySQLで十分なレスポンス速度が出る
• ユーザー数が100万になったときにも耐えられるようなインフラ設計にしておかなければ
  → サービスによるが、100万人まで数ヶ月〜数年かかる。

最後のケースはまず1万人いってから考えても遅くないかもしれません。

リリースから1年後のママリのインフラ構成

リリースから1年後はサービスの成長に伴い、大規模なトラフィックをきちんと捌ける構成になっています。

しかし最初からこのような構成にするのは金銭的にも人的にもコストが高いです。 よってサービスの芽が出てから必要に応じて構築すればよく、
リソースの少ないスタートアップにおいてはサービスの本質的な機能の開発にリソースを割くべきです。

「やらないこと」を決めるということ

開発に限ったことではないですが、「やらないこと」を決めることが大事だと日々痛感しています。
1日が本当にあっという間に過ぎていく中で、如何に本質的なことにエンジニアのリソースを投下できるかが勝負の分かれ目だと感じています。

最後に

最後まで読んでいただき、有難うございます。 このブログのフィードバックや、ウチはこうやってるよ！という話を一緒にさせてもらえると嬉しいです。
この記事を読んでくださったあなたが「やらないこと」をどう決めてるか是非教えてください。

*1:この構成からスタートした理由はインフラ代の節約が主な理由です。

継続率を落とさずに160%成長させたプッシュ通知での最強グロースハックのコツ ママリQ

こんにちは。コネヒトでディレクターをやっています松井と申します。

今日は、ママリQにてプッシュ通知を使って継続率を落とさずに160%成長させたグロースハックについて紹介したいと思います。

ママリQのダウンロードはこちらから。

iTunes の App Store で配信中の iPhone、iPod touch、iPad 用 ママリQ-妊娠,出産,子育てや妊活の疑問を話せるママ友が欲しいママのアプリ

ママリQ 妊娠,出産,子育て,妊活、ママの疑問をママ友が解決 - Google Play の Android アプリ

継続率を上げるにはユーザーのマインドシェアを勝ち取ること

どのようなアプリでも毎日起動され続けることがアプリのゴールとなっていると思います。 ただユーザーが自発的にそのアプリを起動しよう！と思い立って起動されるアプリはとても数が限られていますよね？

Facebook、Twitter、Instagram、ニュースアプリあたりはとても利用頻度が高いとは思いますが、 それ以外の中で毎日起動するものはその人の一日の中で「大切なもの」という認識をされているからだと思います。

そこで私は

毎日起動され続ける = ユーザーの頭のなかを占めている割合が大きい

つまり

マインドシェアを勝ち取ることが重要

という仮説を立てました。

ユーザーのマインドシェアを勝ち取るのにプッシュ通知は効果的

さて、ユーザーのマインドシェアを勝ち取るにはどのようにしたらよいのでしょうか？ いくつか解決アプローチはあると思いますが、1つの施策として効果的なのはプッシュ通知だと思います。

ただ、一筋にプッシュ通知をやればいいんだ！とは行きません。 みなさんもユーザーとしてアプリを利用していて、「この通知ほんとうざいな〜」と感じたことがあるのではないでしょうか？

プッシュ通知は一歩施策の方向を間違えると継続率や最悪のケースは退会、アプリ削除まで起きてしまう諸刃の剣になってしまう可能性があります。

しかし、これから説明する事例のようにユーザーにとって価値のある情報を提供できればこそ、継続率を落とすことなくユーザー数を大幅に成長させることが出来ます。

そのためにはユーザーにとってママリはこういう時に立ち上げると便利なんだ！と体験してもらうことで、 ユーザーの生活の中で深く記憶に刻まれる必要があります。 その結果としてマインドシェアを勝ち取ることができるのです。

では、いつ、どんな時にプッシュ通知をすればよいのでしょうか？Connehitoでのプッシュ通知の施策の設計についてお話したいと思います。