既存サービスでグロースハック的なことをやっていくとき、アプリケーションエンジニアとしてのとっかかり

最近は、はてなブログでグロースハック的なことをやっている id:polamjag です。このエントリははてなエンジニア Advent Calendar 2018 の 20 日目のために書かれました。

昨日のエントリは SRE の id:hokkai7go さんによる re:Invent2018に行ってきました - Hatena Developer Blog でした。re:Invent アツいですね。Amazon.com の CTO のキーノート、Skrillex のロゴ T シャツを着ていて、一体どういう文脈なのかと思ったら Skrillex が re:Play というアフターパーティーに出演していたらしいということを知り、そこからもスケールの違いを感じました。



今の数字がどうなっているのか、どう取っているのかを調べられるのはエンジニアだけかも

サービスを伸ばすためにどういう施策をやったらいいのか考えたり、考えた施策の優先順位を決めたり、といったときには、普通はなんらかの数字が重要な判断基準になると思います。数字といっても、今月の売上はいくらでした、といった粒度の数字だけではそういった判断はできないはずで、なぜ売上がそうなっているのか説明できないと本質に近づくことはできないと思います。

いわゆるコンシューマ向けのサービスであれば、ユーザーのみなさまの行動が重要な説明材料になるはずです。既に多くのユーザーさんに使っていただいているサービスであれば、今月はこのサービスでどういう行動をしましたか、なぜそうしようと思いましたか、といったことを全員に直接質問して回るのはたいてい不可能でしょう。というわけで、ユーザーのみなさまの行動のログをとっていい感じに分析できる必要がある、というふうに言えるでしょう。

Web アプリケーションやスマホアプリにおける行動ログを集計する仕組みには、概ね以下のような段階やジャンルが存在すると思います:

  • 行動ログを集めてるデータ基盤的な存在があるならそれで
  • Google Analytics などのサービスを入れていて、それで見れるメトリクスならそれで
  • サービスのデータベースに入っているアプリケーションのデータを集計することもあると思います
  • 基盤めいたものに入っていない状態なリバースプロキシなどのアクセスログを直接集計するのは最終手段に近い
    • どのようなセグメントのユーザーによる操作なのか、といった情報は普通のアクセスログには現れない

こういった仕組みの面倒を見るのは、基本的にはアプリケーションエンジニア (あるいは SRE などインフラサイド) の担当であることが多いと思います。また、実際にどういうフックポイントでどういう情報を送っているのか、データベースはどういうスキーマで何が保存されているのか、ということを知っているのも当然ながらアプリケーションエンジニアであるはずです。

ログについては、社内にそういうチームや横断組織があるならうまく連携してやっていくという感じかもしれないですし、なければとりあえずチーム内でまわしていくということになろうかと思います。手元にそういう仕組みがない状態でも、昔のログがとりあえず S3 に置かれてあれば、そこそこ大規模であってもほぼ前準備なしで Amazon Athena でいい感じに集計できたりと、まず素朴な数字を見てみてスタート地点に立つということをやりやすくなっているのではないかと思います。

ということで、実際に施策の実装をやっていく前のフェーズでも、アプリケーションエンジニアがグロースハックめいたことをやっていくためのスタート地点以前に立つためにできることはいろいろありそう、そのあたりから回していけるとチームの初速を出せるかもしれませんという話でした。


明日は id:takuji31 さんが Kotlin についてなにか書く回です。引き続きはてなエンジニア Advent Calendar 2018をよろしくおねがいします!

2018年、実売18000円のスマホで生活する (moto e5)

数ヶ月前に、それまで使っていた iPhone 6s の画面を完全に割ってしまい、これはまずいということで間に合わせの予備用として買ったのが moto e5 だった。

Amazon の紹介リンクを貼り付けているけど、画面を割ったのはプライムデー真っ最中のタイミングで、東京23区内でもお急ぎ便が数日かかりそうな感じだったのでヨドバシ.comで買った。ポイント還元率を考慮すると値段はだいたい一緒。日曜の夜10時くらいに注文して、翌日月曜日の朝10時前に出社したときには都内のオフィスに届いていたのはさすがに笑ってしまった。

moto e5 は Android 8.0、RAM は 2GB、本体ストレージは 16GB、CPU (Snapdragon 435) は完全にローエンドという感じで、ディスコンになってない機種のなかでは最弱クラスだとおもう。安かろう悪かろうではなく安いのだ、というやつ。適当なベンチマークを走らせてみても、下手すると完走することすらできずにクラッシュしてしまうという感じで、スコアが出ても iPhone 6s の数割程度出ればいい方だ。

実際に使っていると、画面のスクロールがなめらかにできる瞬間というのが基本的に存在しない。Android の開発者メニューから GPU の利用状況を表示するアレを有効にしてみると、プリインストールのホームランチャーを含むほとんどすべての画面で 20 〜 40fps くらいしか出ていないことがわかる。スクロールだけでなく、あらゆる読み込みがのろくて、Windows XP とかのころを思い出す感じ。

一方で、のろいのはのろいけど動くことには動くのが面白い。ぶっ壊れてて何も動かないということはなくて、単に超遅いだけで動いてはいる、という感じ。TwitterInstagramYouTubeNetflixSpotify も使える。Slack とかも遅いし操作感はガビガビだけど普通に使っている。Google カレンダーは最近のアップデートで一気にスクロールが重くなってちょっと困っている。あと、普通に写真だって撮れる。

f:id:polamjag:20181006164435j:plain
夕方の渋谷。もちろん色とかの補正はしているけど、撮る気が失せるほど画質が悪いというわけでもない

当然 Chrome も動くし、当たり前だけど ServiceWorker のオフラインキャッシュみたいな最新のウェブ技術もふつうに動いていた。PWA もインストールできる。

という感じで、一応 Android のバージョンは新しいので、遅いこと以外は意外と困らないのが面白い (遅いのは困るけど……)。2ヶ月くらい使っていて、新品で 18000 円の物体でここまでインターネットを我が物にできるのはかなり尊いことだな、と思うようになった。あと、CPU がしょぼいのにバッテリーの容量は妙にでかい (4000mAh) ので、3〜5 日くらいは充電する必要がなくて面白い。ガラケーだってもっと頻繁に充電してたと思う。

個人的には音楽ライブラリは常に iTunes と同期したいので iPhone 6s の画面は修理したけど、面白くてしばらく moto e5 を使い続けていた*1。いまは iPhone XR の発売を待ち続けている。

*1:なんか iPhone の調子がおかしくてバッテリーがすぐ減るというのもあったけど

オープンソースソフトウェアなら、ドキュメントが散逸してもそれらはたいてい Web 上でパブリックに公開されているはずなので Google で検索すればなんとか辿り着くことができるかもしれない、一方クローズドソースの場合は、グループウェアとか GitHub のどこかとかレポジトリ内に Markdown も含めるとか Google ドキュメントとかでなんかいろいろ書くことになるだろうけど、それらの検索エンジンは Google の Web のそれほど賢くないので埋もれてしまうかもしれない、ということをふと思いついた。

macOS + Visual Studio Code で拡張を使わずに C-a で物理行頭と論理行頭をいったりきたりする

物理行頭・論理行頭っていうのはこういう意味[要出典]で、

function hoge () {
// ↙物理行頭
        alert(1);
//      ↑論理行頭
}

Emacs を使ってたころから、 C-a を一回押すと論理行頭に、もう一回押すと物理行頭に、更に押し続けると論理行頭と物理行頭を行き来する、という設定にしていたので、これを VS Code でも真似したい。

で、拡張作ったりしないとダメかな〜と思っていたものの、普通に Home を打鍵したときの挙動は既にこれと全く同じ感じだったことに気がついたので、C-a でも同じ command を実行するように設定すればよさそう、と思ってやってみたら正解だった。

Preferences > Keyboard Shortcuts > "For advanced customizations open and edit keybindings.json" をクリックすると開ける keybindings.json に、以下のようなエントリを追加すればよい。

[
    {
        "key": "ctrl+a",
        "command": "cursorHome",
        "when": "editorTextFocus"
    }
]

よくみると、デフォルトでは cursorLineStart コマンドになっている。

HTML 中のルビ文字列を乱暴に全部消したい

テストデータとかに使うための長い適当な文字列がほしいという時は、Lolem ipsum とかでググるか、Wikipedia や青空文庫から拝借するのだけど、青空文庫でルビ付きの作品はそのままコピペするとルビがくっついた文字列になるので変で困っていた。具体的には、

親譲おやゆずりの無鉄砲むてっぽうで小供の時から損ばかりしている。

夏目漱石 坊っちゃん

を (プレーンテキストに) コピペすると、たいていこうなるはず。

親譲おやゆずりの無鉄砲むてっぽうで小供の時から損ばかりしている。

いったん ruby 要素のことは考えずに、ルビの文字列だけ消滅させてしまえばコピペしたときにはわからなくなるので、そういうことをする最短の JavaScript スニペットを作った。それがこちら。

Array.from(document.querySelectorAll('rt'), el => el.parentNode.removeChild(el))

参考

blog.sushi.money

iPhone で Dropbox とかから音楽ファイルをダウンロードしてリピート再生できるアプリ

Documents というアプリが便利です.

Documents by Readdle

Documents by Readdle

  • Readdle Inc.
  • 仕事効率化
  • 無料