| @ブログ

これから毎月写真でふりかえってみることにする。

SNS に写真を上げるだけではなく、自分で見え方まで考えて写真を整理してみたくなった。 Flickr に写真を上げてアルバムを作っていたようなことを自分のブログでやる感じ。

ギャラリーのライブラリは Medium Zoom だと足りなかったので PhotoSwipe に移行してみた。

| @技術/プログラミング

このブログは Ruby 2.7 でずっと動かしていた。コミットログをたどると 2020 年の 1 月から Ruby 2.7 のようだ。 Ruby 2.7 は 2023 に EOL を迎えている。

さすがにまずいと思ったので Ruby 3 にしようと一日頑張ってみたが、なかなかうまくいかない。Ruby 3 の キーワード引数の仕様変更はかなり対応がきつい。どこで ArgumentError が起こっているのかが極めて追いかけづらい。他のメソッドに委譲している場合などは特に。

ガチャガチャやってトップページと個別記事ページまでは Ruby 3 化できたので Ruby 3 でデプロイしてみたが、動かない画面があることに気がついたので Ruby 2.7 に戻した。 Kaminari がちゃんと動かない(具体的には kaminari-sinatra と actionview v6 系の互換性がない)のが原因でページネーションするページがちゃんと動かなそうだったので Ruby 3 化は諦めた。 kaminari-sinatra の ActionViewTemplateProxy#initialize を actionview v6 対応させないと無理っぽい。

kaminari のような有名な gem の派生 gem ならきちんとメンテされてるかなーと思っていたが、 kaminari-sinatra の最終コミットは 4 年前だった。

Ruby で View まで作る人たちはほとんどいなくなってるのだろう。

なお動かないところのデバッグは ChatGPT と対話しながらやった。めっちゃ便利。一人だと気がつかないような部分のコードを見てみろと ChatGPT が言ってくれて、そこにデバッグコードを入れてみるとビンゴだったりする。便利な世の中になった。

忘れないようにやったこと・気づいたことをメモっておく。

  • sinatra は v4 にあげないといけないのでパスの正規表現から ^$ は消さないといけない
  • better_errors の REPL がちゃんと動かないので Backtrace を見たいときはログを開くか better_errors を使うのをやめる
  • fork していた sinatra-cache は sinatra 4 では動かないので外した(キャッシュできない部分をどうするかは要検討)
  • capistrano-puma も Ruby 3 対応させないといけない(期待される systemd のフォーマットが変わっているので単にデプロイするだけではだめで一部手作業が必要)
  • tilt は v2.1.0 に固定( Tilt::ErubisTemplate クラスが消えるため、 padrino-helper がエラーを出す)
  • concurrent-ruby は 1.3.5 未満に固定
  • compass は 1.0.3 に固定
  • SESSION_SECRET は 64 文字以上にする
  • haml の過剰な escape を抑制
  • kaminari-sinatra の ActionViewTemplateProxy#initialize を actionview v6.1.7.8ActionView::Base#initialize に対応させる

| @ブログ

人気記事を確認できるようにしたという記事を以前書いている。もう 7 年も前のことのようだ。

調べればこういうログ集約・集計系のサービスはあるようだったが、個人ブログなのでなるべくお金はかけたくない。

しばらくの間は集計後のログを捨てていたが、 2 年半前からログローテートするタイミングで日付ごとのファイルを書き出し保存するようにしていた。日付ごとのログファイルは Amazon の S3 にアップロードしてさくらの VPS サーバーからは待避させている。現状、 2022 年の 6 月 13 日のログから S3 上にデータが残っているので、その日以後の日ごとの人気記事を確認できるようにした。こんな感じ。

日付の選択は最初 React のライブラリを使って作ろうかと思ったが、そういや最近のブラウザーは <input type="date" /> とすると結構ちゃんとしたカレンダー UI と日付選択の機能を提供してくれるので楽をすることにした。

max と min を指定すると選べない日付は非活性にされるし、無理に選択すると form を submit したときにバリデーションしてくれる。

選べない日付は非活性に
max と min を指定すると選べない日付は非活性にされる
バリデーション
選べない日付で無理に submit されたときにはバリデーションもしてくれる

ブログの閲覧者からしたらいつどの記事が読まれていたかなんて興味ないだろうけど、著者である自分には興味深い情報になる。セルフホストのブログだからできる機能だ。

| @雑談

1 月

根子岳と祖母山

正月早々、山に登った。二年連続阿蘇山。砂千里側から登って仙酔峡に下山した。北面は日が当たらず凍っており、傾斜の急なバカ尾根を下るのは怖かった。

ブログには書いていないが確か正月の初売りで Mac mini の M2 Pro モデルを買った。 Apple Silicon の速い Mac を手に入れたので Whisper CPP を使って Castro を作っていた Supertop の Podcast の文字起こしをしてブログに書こうとしていたが、未完のまままだ公開できてない。年末年始で書き上げたい。

仕事はアプリのダウンロード数をどうやったら増やせるかを延々考えていた。開発をしてダウンロードを増やすなんて無理ゲーだろうと思ってたが、頭を使って何個か施策を考えた。あとは企業向けの機能をテコ入れしていた。

2 月

多良岳から見る雲仙方面の山

熊本城マラソンに出てる。サブフォーを狙っていたが練習不足で果たせなかった。一人で出て誰も知り合いのいない熊本城マラソンは孤独だった。来年雪辱を果たしたい。

中旬のやたら寒い時期に佐賀と長崎県境の多良岳・経ヶ岳に登山に行った。パラパラと落ちてくる樹氷の下を歩くのは楽しかった。花粉がやたらきつくて寒かったけど楽しい登山だった。

仕事はやたらネットワーク効果について考えてたが、まだ思考が甘かった。その後ハイパー起業ラジオを聞いたり本を読んだりしてネットワーク効果についての知見を深めていく。

3 月

今津湾

3 月から 6 月にかけてはブログ記事がない( 3 月に熊本城マラソンの記事を書いているが、それ以外は何もない)。

3 月の頭に糸島であったトレランのレースに出た。ショートレースであまりパッとしない成績だった。まだ 300km も走ってないアルトラのトレランシューズ Outroad が破れて悲しかった。

仕事は新規ユーザーの継続率を伸ばすための A/B テストをやってた。

4 月

長垂海岸

平尾台のトレランレースロングに出た。雨降りでコンディションが悪く、関門タイムギリギリのゴールだった。このときからギリギリグセが付いている。

家の近くの山で有名なトレランチームの人たちを招いて緩い練習会をやった。グループ位置共有を宣伝できてよかった。

仕事はどうやって EC を伸ばすかを考えていた。やはり基本はネットワーク効果だと思って、ユーザーがレビューを書ける機能の土台を作っていた。日の目を見るのはだいぶ先のことになる。

あと、ユーザー登録数を劇的に増やす施策をリリースして、毎月の新規ユーザー数をかなり上積みできた。

5 月

退勤からの都市高速

南畑里山トレイルというトレランのレースに出た。楽しかったがショートレースは出し惜しみをしてしまう。レース後、体力が有り余っていた。

仕事ではこの頃から組織変更が計画されていて、自分の役割がちょっと変わりつつあった。

顧客起点を本格的に取り入れることになり、 N1 インタビューをやったりもしてた。

6 月

久住三俣山

仕事で久住に登山に行った。ミヤマキリシマ終わったあとの平日の久住は静かでよかった。

組織変更の荒波に揉まれたり、 EC のシステムをどうするかを考えたりしてた。もはや単なるプロダクトマネージャーではなくなりつつあった。

7 月

通勤風景

キリエビのロングに出た。こちらも関門 10 分前のギリギリゴール。最後の 15km くらいを近くにいた人たちと励まし合いながら一緒に走った。とても良い思い出。

仕事はなんと平社員からいきなり部長になってしまった。やることが大きく変わり、隣の部長から厳しいご指摘を賜りながら歯を食いしばって働いた。

この頃からハイパー起業ラジオを聴いて積読していたネットワーク効果の本をちゃんと読むようになった。

8 月

阿蘇山

脊梁ピストントレイルというトレランのレースに出たが、初めてリタイヤした。登りが急で、また水場がなく、とても消耗するレースだった。折り返し地点の関門時刻に間に合わず、失格となってしまった。めっちゃ悔しい。まだまだ自分は雑魚だと思い知らされたレースだった。来年は完走したい。

仕事では相変わらず EC のシステムをどうするかとネットワーク効果について考えていた。ユーザーインタビューではなく、山を歩いている人に話しかけて話を聞かせてもらうというのもやった。山を歩いてる人たちはほとんど自社アプリを使ってくれているのではないかと思っていたがそうでもなくてショックを受けた。

9 月

長垂海岸の夕焼け

PayPay ドームリレーマラソンに出た。リレーマラソン前の二週くらいは休みの日の朝に大濠公園に集まってみんなで練習したりしてた。大濠公園から西公園や南公園に走りに行った。

仕事は相変わらずゴタゴタの整理をしていた。この頃はあまり戦略的な動きができず、目の前の仕事に右往左往していた。

10 月

七ツ釜

翌月の福岡マラソンに向けて 30km 走を 2 回やりたかったが 1 回しかできなかった。しかし、初めて一人で大濠公園で 30km 走をやったのは自信になった。一人だと諦めないか心配だったけどちゃんと最後まで走れた。

仕事は相変わらずゴタゴタ処理。この頃から MAU を自分たちの力でどれくらい伸ばせるかにチャレンジすることになって、年末に怒涛の機能リリースをすることに。仕込みを始めた。

11 月

南阿蘇外輪山

オアシス再結成の報を受けてオアシスをよく聞くようになってた。その流れでアンディー・ベルがオアシス加入前にやってたバンド RIDE の曲を聞くようになった。 Vapour Trail めっちゃよい。

ランニングは福岡マラソンに出てきた、ネットタイムではあるかサブフォーをギリギリ達成した。 8 秒差。

また 11 月から会社の人たちと週に 1 回大濠公園を走るようになった。部活みたいで楽しい。

仕事ではリリースする機能の狙いや目的を社内で共有するのが難しくて難儀した。プロダクトマネージャー間で認識をそろえるのも難しいし、他部署の人と認識をそろえるのも難しかった。

12 月

会社からの景色

11 月に引き続き宮崎であった青島太平洋マラソンに出たが、記録更新はならなかった。初めてレース中にうんこしてしまった。最悪。そもそも想定外に福岡マラソンでサブフォーできてしまったせいでその後のランニングのモチベーションが落ちてしまって全然走れてなかった。

仕事は仕込んでいた機能が次々リリースされた。炎上した割に期待した効果が得られない機能や、そもそも使ってもらえない機能もあったが、一つは結構当たって成果を出せた。加えて失敗のリカバリーで出した機能も大きな成果につながった。例年、 12 月になると利用が落ち込むが、 MAU を自分たちでコントロールすることは出来なくはないということがわかったのは収穫だった。いままで大雑把に捉えていた MAU を細かく分解して、それぞれの要素ごとの継続率なんかを分析してる。まだこれといった施策はないが、来年はこの知見を活かしてさらにサービスを成長させていきたい。

2025 年の抱負

仕事

去年のふりかえりでは「何者にもなれない人生だった」と書いていた(2023 年のふりかえり)が、いきなり部長になってしまった。

プロダクトマネジメントとピープルマネジメントは別物と本には書いてあるけど、人に頼んで何かやってもらうという点ではあまり変わらないとも思う。人から信頼してもらい、自分の言葉や考えを信じてもらって行動してもらうという点は変わらない。

それを言い始めたらエンジニアだろうが営業職だろうが同じかもしれない。仕事をしていく上で人から信頼してもらうことは重要だ。そんなの誰でも知ってそうだけど、意外とそれができない。

たまたま年末に買った『プロダクトマネジメントの教科書』という本が良くて、この辺のスキル(人から信頼される、リーダーシップやオーナーシップを発揮する)ことについて実践的な内容が書かれていた。

役割に応じた働きができるよう、もうちょい戦略的に動きたい。

ランニング

ランニング実は去年に比べて距離が伸びていない。これまで毎年距離を伸ばせていたが、今年は夏くらいから走る距離が短くなっている。毎月 200km は走りたいのに、部長になってからみるみる前年同月比の走行距離が落ちている。

年間走行距離

ただ、ランニングのペース(スピード)は上がっている。去年だったらできなかったような、キロ 5 分を切るペースで 20 分間走をやれたりはしてる。なので練習の質は上げられていると思う。

来年こそは距離を伸ばして、月間 200km をコンスタントに超えていきたい。できればマラソンで 3 時間 45 分くらいでゴールできるようになりたい。少なくとも 2 月の熊本城マラソンではサブフォーを再現したい。

ブログ

2024年のブログ執筆状況

実はこの記事を含めても 11 記事しか書けていない。もう少し気負わずに日記感覚で気楽に書きたい。クソみたいな記事でも書かないよりは書いた方がマシ。書かなければ何も残らないしふりかえることすらできない。

Twitter が X になったり、 Threads や mixi2 が登場したりしたけど、セルフホストのブログが一番表現力が高く自由度も高い。死ぬ間際に Twitter や Instagram を見返すより自分のブログを見返した方が良いと思える状況にしておきたい。

| @雑談

天山食堂

しばらくブログを書いてなくてなんか執筆のエンジンがかからないのでただの日記でも。

運転免許の更新だった。今回、 10 年ぶりにゴールド免許に復帰できたので南区の試験場まで行かずに済んだ。最近、渡辺通のサンセルコから千代に移動してきた県の合同庁舎内にある千代ゴールド免許センターに行った。

千代県庁口駅は地下鉄空港線沿線ではなく、中洲川端で貝塚線に乗り換えないといけない。なので遠くはないがちょっと行くのが面倒だ。

駅に着いて合同庁舎まで 3, 4 分歩く。千代の街にはほとんど来ない。福岡市民は天神のアクロスでパスポートが取れるので、県庁に来ることも基本的にないんじゃないだろうか。

合同庁舎前に着くと懐かしい感じの名称が。以前博多駅の筑紫口にあって、勉強会でよく通っていた福岡県Ruby・コンテンツ産業振興センターがここに移動してきていた。免許の更新が目的ではあったがRubyコンテンツセンターの看板をパシャリと撮った。

福岡県Ruby・コンテンツ産業振興センター

ゴールド免許センターは二階だった。優良講習は事前予約制で、予約したときに表示される QR コードを保存して持ってきて端末にかざさないといけない。 QR コードをキャプチャして Fantastical に保存していたのに表示されなくて焦る。 Fantastical の iPhone アプリは添付ファイルを開けない仕様だったのを思い出した。 iOS 標準カレンダーは添付ファイルを開けたが、今度は電波のつながりが悪くてなかなか画像が表示されない。自分が端末を操作する直前になって画像が読み込まれ、 QR コードを無事機械に読み取らせることができた。高齢の人にはこれは難しいだろう。事実、年寄りの人には係員の人がずっと付き添っていて渋滞していた。

優良講習の内容はいつもの内容に加えて、最近は電動キックボードが制度として組み込まれたことと、自転車のヘルメット着用が努力義務化されたことを伝えられた。前の人の頭が邪魔であまり映像がよく見えず集中できなかった。

講習が終わって新しい免許証を受け取ってもまだ 10:20 くらいだった。仕事は午後からやろうと決めていた。渡辺通のゴールド免許センターだったら講習後に寄れる店がいくらでもあるけど、千代はなかなか店がない。朝は急いでいて朝食を抜いていたのでお腹がすいている。どこか入ろうと思ったが時間が中途半端すぎる。合同庁舎の横にスターバックスがあったので、そこに入ってとりあえず時間を潰せばよかったのに、火と人という西部ガスがやってそうなレストランが気になり駅に戻ったら、ランチは 11 時からでまだ食事はできなかった。いよいよ店に入るには中途半端な時間になった。せっかく来たのだからと店名が気になった天山食堂という食堂に行くことにした。 Google マップで写真を見ると実に店構えがいい。 15 分前に店に着いたのでコンビニ行ってコーヒーを買って時間を潰す。千代のローソンはすさんでいて、ゴミ箱は持ち込みゴミ禁止の警告がペタペタと貼られ、ゴミ箱の投入口は木の板を貼られて加工され、小さなゴミしか捨てられなくなっていた。監視カメラ撮影中と至る所に掲示があったが、どこにも監視カメラは設置されてなさそうだった。カフェラテを買って車止め柵にもたれかかって飲む。朝は紅茶しか飲んでなかったので初めてカロリーを摂取する。寒かったのでほっとする。

コーヒーを飲み終わると 11:00 になっていたので天山食堂へ移動する。自分の前に一人先客がいて二番目だった。場所柄、韓国風の店なのかと思っていたが、店内は普通の和食の店という感じ。メニューに韓国風のものは豚キムチくらい。天山はきっと韓国の山の名前なのではないかと思っていたが、そうではないようだった。佐賀にゆかりがある人がやってる店なのかもしれない。

天山食堂のメニュー

Google マップや Instagram の投稿を見ると、焼肉定食を頼んでご飯をチャーハンに変更するのが通の頼み方のようだが、裏メニューでメニューに書いていないものを一見の客が頼むのは気恥ずかしく、普通に焼肉定食を頼んだ。比較的すぐ出てきた。付け合わせの野菜炒めがとてもうまかった。厨房でガコンガコンと中華鍋を振る音が聞こえたので本格的に炒めてあるのだと思う。ラードで強火を使い短時間で炒めてあり、野菜はシャキシャキしていた。肉は甘辛い味付けで、昔ながらの家で食べる焼肉という感じだった。小鉢の冷や奴が印象に残っている。豆腐の上にネギと鰹節がかかっていた。味噌汁もちゃんとだしをとったやつでうまかった。これで 800 円。最近は福岡も外食の値段が上がっているので、ほとんど手作りでこの値段は安い。 Google マップを見ると以前はもっと安かったみたいだ。

天山食堂の焼肉定食

分量もちょうど良く、食べ終えてあたたかいお茶を飲み、店を出た。ここから歩いて呉服町までも行ける。呉服町は以前のオフィスがあったところなので行ってみるのも一興だったが、午後の仕事が気になったのでおとなしく千代県庁口駅まで戻って地下鉄を乗り継いで会社へ向かった。孤独のグルメのような一日だった。

| @Mac/iPhone

iA Writer

iPad Air を買ったことで iPad で文章を書くときに何を使うか考え始めた。 iOS と iPad で iA Writer は同一アプリとなっているようで、 iPhone 用に買った iA Writer をそのまま iPad Air でも使うことができた。

iPad Air で iA Writer を使ってみて、ファイル管理っぽい機能があることに初めて気が付いた。 iOS では小さく表示されるのでそんな機能があることに気がつかなかった。それで Mac 版を試してみたところ結構良かったので、ブログなどの文章書きを Vim から iA Writer に乗り換えることにした。

iA Writer は iPhone では 6 年くらい前から使ってる。その頃は 1200 円くらいで買えたがいまはめっちゃ値上がりしてて 8000 円もする1( iPhone 用アプリで 8000 円ですよ!)。ドルベースの価格も上がっているが円安が効いていて高くなっている(ドルでの価格は 49.99 ドル)。

iA Writer for iOS は電車の中で文章を編集するのに使ってた。通勤してた頃、混んだ電車の中でパソコンを取り出せず、 iPhone の iA Writer で Vim で書き起こしたポエムの続きを書いたりしてた。

まぁまぁ便利だったのだが、やっぱりスマートフォンのキーボードでは書きづらいしまぁこんなもんかなぁと思いながら、どうしても iPhone で文章を編集したいときだけ起動するような使い方をしていた。

iPad Air で iA Writer を使ってみて、ファイル管理っぽい機能があることに初めて気が付いた。

iA Writer のファイル管理機能

スマートフォルダという機能もあって、バラバラに散らばったファイルをいい感じに整理できることにも気が付いた。 Apple Music のスマートプレイリストみたいな機能だ。 macOS の Finder の機能を転用してるのだと思う。

iA Writer のスマートフォルダ

"メモを取り、書き、編集するための集中できる環境。それ以外には何もありません。"

iA Writer のウェブサイトではフルスクリーン表示できて文章を書くことに集中できることをウリにしているが、自分にとってはファイルを一覧表示・管理できる機能(ファイラー)がめっちゃ便利だと思った。これまで Vim + memolist で書いた文章は一定期間経過したら Day One に取り込みつつ、年ごとアーカイブ用フォルダーを作って Ruby スクリプトでそこに待避していたが、そんなことをする必要なく iA Writer だけでファイルの管理ができてしまう(サブディレクトリに移動させたいファイルをドラッグ&ドロップで移動させればよい)。

Day One のカレンダーで過去の記事を見られる機能は便利だが、Day One はプレーンテキストを捨てて Markdown ベースの独自仕様リッチテキストに移行してしまったし、起動に時間がかかるのも微妙だと思っていて、シンプルにプレーンテキストのファイルとして管理できる iA Writer の方がよい気がしてきた。

Day One のカレンダー UI

iA Writer の良いところを列挙するとこんな感じ。

  1. 起動が速い
    起動してすぐ書き始められる
  2. ファイル管理機能
    Finder とテキストエディターが統合されたような使い勝手
  3. クイック検索
    Vim の Unite 検索のような機能があり、めっちゃ素早く対象のディレクトリ以下のファイルを検索できる

これまで Vim を使い続けてきたのは Unite での検索が便利すぎたからだった。メモ書きディレクトリに移動してテキトーに Vim を起動して UniteGrep すれば書きかけのファイルをぱっと探せる。

iA Writer には UniteGrep と似たクイック検索という機能があって、しかもショートカットで検索 UI を呼び出せるところが良い( + + o)。

iA Writer のクイック検索

Day One にも似たような検索機能はあるものの、検索窓を呼び出すショートカットがない。いちいちマウスカーソルを動かして🔍マークをタップしないと検索できない。検索窓はマウスやトラックパッドに手を持ち替えることなく表示されないとダメだと思う(一つ前の記事参照

デバイス間のファイル同期は iCloud を使っている。複数の端末で同時に開いてもコンフリクトが起こることはほぼなくファイルが同期される。敬虔な Apple 信者でいる限りファイルの同期のために Evernote や Notion を使う必要はない。

いまは Obsidian や Roam Research のような新手のソフトもあるようだが、自分の場合は iA Writer で満足している。使っていないが Wiki Link 記法も使えるのでファイル同士の繋がりを作ることもできるようだ。

職業プログラマーになって以来、テキストエディターは Vim 一択だろうという気持ちでいたが、 GUI でファイル検索・管理できるという一点で iA Writer を気に入ってしまった。コードを書くならいまでも Vim が良いが、ブログの文章や個人用メモは完全に iA Writer に乗り換えてしまった。世間的に大人気な Notion を使っていたらこのようにエディターを他のものに乗り換えることはできなかったのでプレーンテキスト万歳だ。


ピアソン版の『達人プログラマー』に GUI のファイル検索だと目的のファイルが見つかるのに時間がかかるので grepfind でファイルを探す方が高速だ、という記事がある(第3章)。 Unix 哲学的な話で、小さな機能を持つソフトを組み合わせて使う方が効率的だという話だった。 grepfind で検索して xargs -o vim するより、テキストエディターの中で一覧表示出来る方が便利だ。少なくとも普通の人にとっては。何でもシェルでやるのが良いという時代は終わったのかもしれない。

とはいえ iA Writer は macOS の仕組みの上で達人プログラマー的なやり方を継承しているようにも感じる。例えば先ほどのスマートフォルダは macOS の Finder にある機能だ。ひょっとしたら UI が同じだけでまるっきり別の実装がしてあるかもしれないが、 OS や SDK が提供しているシンプルな GUI を組み合わせて便利なものを作るのが今風の達人プログラマーなのかもしれない。


  1. Mac 版は同一ライセンスになっておらず Mac App Store から別途購入する必要がある。 8000 円は高いので一か月くらい悩んで買った。 

| @労働

アプリの使い方がわからないというユーザーがいっぱいいると、「 UI がクソだからに違いない」というご指摘をされることがある。

しかし、アプリの特性上、どうしても使い始めるまでのステップ数が多くなることはあるし、たまにしか使わなくてなかなか使い方を覚えられないアプリもある(自分はいまだに世界で 15 億人以上が使っている Instagram の使い方が覚えられない)。利用頻度が低いせいでなかなか使い方を覚えられないだけなのに、 UI のせいにされてしまって延々 UI を改善すべしとなってしまうとつらい。

継続率を限りなく上げるべしというのも危険。『ネットワーク・エフェクト』という本で「ユーザーの 8 割は離脱する」と書いてあった。

テクノロジーブログ「テッククランチ」に「ユーザーの約4人にひとりは、アプリを1回利用しただけで離脱している」という記事が掲載された。3万7000人分のデータを調べたところ、多くのユーザーは1回試しただけで使うのをやめていたという。残念ながら、私が実施した調査でも同様の結果だった。私はグーグルプレイの元プロダクトマネジャーであるアンキット・ジェインとともに「モバイルユーザーの80%を失うのは普通」という記事を書いている。 — アンドリュー・チェン『ネットワーク・エフェクト』

でも継続率が 2 割しかないと聞いて「けしからーん」と怒る人たちがいて、継続率を限りなく 100% に近づけろという話になったりする。「けしからーん」と言ってる当人だってインストールしたアプリ全部を毎日は使ってないはず。毎日使うアプリは LINE とか Instagram とかマンガアプリとか PayPay くらいじゃないだろうか。

分析調査会社混むスコアのデータによると、人々はたった3つのアプリに80%の時間を費やしている。 — アンドリュー・チェン『ネットワーク・エフェクト』

現実的な観点で継続率とか利用率の目標を置けたらいいけど、割と勘とか理想論で数値目標が決まったりする。絶対達成できない目標掲げて仕事するのめっちゃつらいので、まずは現状の利用状況調べて妥当な目標を設定するべきだと思ってる。むしろアプリを使う全ユーザーにこちらがやってほしい行動をやらせようとするのは虫がよすぎるというか、傲慢なのではないか。

ユーザーすべてが作り手と同じような頻度、気持ちでアプリを使ってくれる訳じゃないことを前提とした上で UI とか継続率は考えていけたらいいと思う。絶対に一人も脱落させない UI やオンボーディング体験を作ることは難しい。