| @雑談

Money

個人開発ではないが、課金については仕事で結構やってきてまぁまぁの知見を得た。かつて自分も情報を得ようとネットで探してみたが、極めて情報が少なかった。ソフトウェア開発についてのノウハウは結構ネットに転がってるが、値付けなどについての情報は少ない。エンジニアとマーケッターでは文化が違うのかもしれないが、そもそも値付けに関しては商材(ソフトウェア)によって様々なので定石がなく、結局のところ自分で試してみないと正解がわからないのではないかと思う。そういう前提はあるものの、自分が得た知見をベースに Cside さんの質問に答えてみたいと思う。

寄付募集型か、有料で一部の機能を解放する型か

寄付型ではかなり少人数しかお金を払ってくれない。どんなにヘビーに使ってもお金を払う必要がなければ1円も払わない人の方が圧倒的だと思う。

機能に課金しないのであれば、共感とか支援という文脈でお金を払ってもらうかたちになる。となるとソフトウェアにどんな機能があるかよりも、どんな人が作っているかや、作り手の思想や哲学の方が大事になる。ソフトウェアのファンではなく作り手個人のファンを作る感じに近い。

とういわけで、自分の人間的魅力に自信がある場合を除いて機能解放型(フリーミアム)をおすすめしたい。

価格設定

めちゃくちゃに難しい。これは実験もしづらい。しかしある程度ユーザーを集められているなら、「ヴァン・ウェステンドルプの価格感度メーター」がおすすめ。ユーザーに以下の四つを問い、グラフ上にプロットして最適価格を探る。

  • この商品がいくらなら高すぎて購入に抵抗を感じますか?
  • この商品がいくらなら安くないと感じますか?
  • この商品がいくらなら高くなくて買得だと感じますか?
  • この商品がいくらなら安すぎて品質に不安を感じますか?

高すぎると高くないの交点が高さの限界点、安くないと安すぎるの交点が安さの限界点、安すぎると高すぎるの交点が最適価格となる。

書籍『Product-Led Growth』より
書籍『Product-Led Growth』より

有料で一部の機能を解放するなら、どこまで有料にするか

これもめちゃくちゃに難しいが、以前書いた以下の記事は正鵠を射ていると思う。

ソフトウェアには売りとなるコア機能があるはずで、この機能を段階性の課金にする。たとえば一定期間内で 5 回までは無料で使えるが、 6 回目からはサブスクリプション登録済みのユーザー限定にする。そしてそのコア機能を使いたくなる魅力的なおまけの機能をたくさん作る。そうするとおまけ機能を使いたいがためにコア機能もじゃんじゃん使って制限に到達し、お金を払うことになる。

おまけ機能自体に課金することはあまり良くなくて、課金の仕組みが複雑になってメンテナンスコストが上がる。課金体系をシンプルにするためにおまけ機能とコア機能をセット販売すると、人によって何に価値を感じるかは様々なので「コア機能だけ使いたいのでコア機能だけの安いプランを作ってほしい」と言われてしまう。なので課金対象はあくまでコア機能の無料枠をはみ出た部分だけにし、おまけ機能は無料化するのが良い。

料金プランはシンプルであればシンプルであるほど良く、開発者自身も楽になるしユーザーの認知的負荷も小さくなる。複雑な料金プランは誰も幸せにならない。

買い切り型か、月額サブスクリプション型か

自分が買い手のときは買い切り型が好みだが、売り手として考えるときは月額サブスクリプションが良い。

ソフトウェアは作っておしまいではなく必ずメンテナンスが発生する。買い切り型では常に新機能を追加した新しいバージョンをリリースしなければ収益を上げられず、メンテナンスに十分な時間を割くことができない。結果としてソフトウェアの品質が低下してしまう。サブスクリプション型であれば毎月定額で収入を得られるので、メンテナンスに時間を割きやすい。

ユーザーとしても海のものとも山のものともつかないソフトにいきなり数千円を払うのには抵抗があるはずなので、試しやすい金額で使い始められるサブスクリプションの方がうれしいはずだ。

サブスクリプションの継続率は作り手にとって示唆に富んだ情報源にもなる。継続率が低下していたらユーザーの満足度が下がってきているというシグナルだし、開発方針の決定に有効活用できる。ソフトウェアはユーザーの満足度が全てだ。満足度を測るために機能開発することさえある。それをせずにサブスクリプションの継続率から満足度を推し量ることができるなら一石二鳥だ。

サブスクリプションのデメリットは開発難易度が上がることだ。 App Store や Google Play の仕組みを使うと Apple や Google にショバ代を取られるし彼らの方針に振り回されて大変な目に遭う。ウェブアプリであれば Stripe を使って自前実装することもできるが、スマートフォンアプリで機能課金をする(有償で機能制限を解除する)場合はアプリ内決済の実装がルール上必須となる(リーダーアプリ除く)。そのほか、ユーザーからの問い合わせも増えるので、サブスクリプションは財務的にはメリットがあるが、肝心の機能開発に割ける時間が減ってしまうというリスクもある。


以上が自分の知見を元にした Cside さんの質問への回答になる。

しかし冒頭にも書いたように価格を含めた課金の設計は売る物によって様々で定石はないと思う。結局のところは実際に自分で試して正解を探り当てていくしかない。

ここに書いてある情報がある日突然マーケティングっぽいことに手を出すことになった門外漢の人の助けとなれば幸いです

| @労働

可也山.jpg

プロダクトマネージャーになって 5 年ちかくが経った。最初の 2 年くらいはエンジニア気分が抜けず、 Vim を開いて何かやったりということがあった。ただ 3 年目くらいからはエンジニアっぽいことは一切やらず、プロダクトマネジメントだけをやるようになってきたと思う。ようやく自己紹介をするときによどみなく「プロダクトマネージャーです」と言えるようになってきた。

現在は登山アプリ・サービスの会社で仕事をしていて、割と頻繁に山に行ってドッグフーディングしている。なのでユーザー(山に登る人)の課題感が大体わかっているつもりだ。

もしいまの環境を変えることになったとして、自分は登山アプリ以外のプロダクトマネジメントができるのだろうかとふと思った。山が好きだから(ドメイン知識があるから)できているのか、それともプロダクトマネジメントのスキルが身についてきているのか。

これまで B2C 、 C2C 、 B2B2C など様々なサービスの開発に関わってきた。正直 ATI (圧倒的な当事者意識)が高い方ではなかった。なのでそんな自分がプロダクトマネジメントできるとは思ってもみなかったが、登山アプリの会社に就職して登山を好きになり、当事者意識が高まってプロダクトマネジメントを生業とするに至った。なのでいまの環境を離れてしまえばプロダクトマネジメントはできない可能性がある。趣味と仕事が重なる領域以外でも自分のプロダクトマネジメントスキルが活かせるのかが気になっていた。

しかしそもそも自分はソフトウェア(デジタルプロダクト)自体が好きなのだということに気がついた。あのプロダクトはこういう戦略で成長したとか、ソフトウェアの背景にある作り手の思想とか、そういうことを考えるのが好きだ。

ベンチャー企業のなかには、そのプロダクトがユーザーのどんな問題を解決しているのか作っている側も分からないまま突っ走っていることがあるのではないかと想像する。いまの職場でも、ユーザーがどの部分に最も価値を感じているのかを理解するまでにはだいぶ時間がかかった。

ある程度のシェアを獲得して、今後さらに規模を拡大したいというフェーズでは、ユーザーがプロダクトのどの部分に最も価値を感じているのか、ユーザーがプロダクトに期待している価値は何かをはっきりと理解する必要がある。ひょっとすると作り手の思い込みでユーザーが必要としていない機能を作っているかもしれない。プロダクトの価値を再定義し、機能を整理する必要性が出てくる。 0 → 1 のプロダクトマネジメントはではなく、 1 → 10 のプロダクトマネジメントだ。自分はこのような役回りが好きだし、こういった仕事もプロダクトマネージャーの気づかれにくい重要な役割の一つだと思う。

| @登山/ランニング

Apple Watch でトレランするならフットパスが便利

Apple Watch でトレラン(ランニング)する人のための記事を以前書いた。アプリを組み合わせれば Apple Watch が Garmin 相当になるという記事だった。

その記事ではトレラン中の地図&アクティビティトラッカーとしては WorkOutdoors が良いと書いていたが、フットパスというアプリを発見してしまってこっちの方が地図が見やすく操作も簡単で高機能だった。 Apple Watch でトレランするならフットパスが激しくおすすめだ。

フットパスは、スマートフォンのアプリを開いて指先で地図上をなぞるといい感じにルート(ウォーキング、ランニング、ハイキング、サイクリング、ドライブなどに対応)を提案してくれるというのがウリだが、正直この機能は日本の道路では使いづらい。きちんと区画整理されている欧米の街だったら使いやすいかもしれないが、ぐねぐね細い道が入り組んだ日本の道路では「そこじゃないんだよな」というルートが提案されることがある。

指なぞりルート作成機能はいまいちなのだが、自分が感心したのは以下だ。

  1. ゴール時刻の予想タイムを出してくれる(フットパス上で計画したルートだけでなく、 GPX を取り込んでも表示してくれる)
  2. 行動中の Turn-by-turn navigation (もうすぐ右ですとか、分岐を直進とか教えてくれる)
  3. Mapbox Outdoor Style の地図のほか、国土地理院地図を選ぶこともできる(国産アプリ以外ではめずらしい)
  4. 行動中に登りが残り何メートルあるか確認できる機能(地形を視覚的に確認できる)
  5. ウェブサイト footpathapp.com の使い勝手

ゴールタイム予測

Footpath App
何時頃ゴール地点に着くかを予測してくれる。

何時頃ゴール地点に着くかを予測してくれる。モーダルウィンドウ内の太字部分(「 15'00"/km 」と書いてあるところ)を左右に短くスワイプするとペースを変更出来て、任意のペースで何時間でゴールできるか確認することができる。

登山用の計画アプリだと「何月何日の何時に登山開始」みたいに日時を入れないと予想時間が表示されないが、これだと日時を指定することなく「いまスタートしたら何時頃下山できるか」がぱっとわかる。

スマートフォンアプリ側で計画を調整して Apple Watch に転送して開始すると、活動中は現在のペースだと何時頃ゴールできるかをリアルタイムで推測してくれる。

ゴールタイム予測

Turn-by-turn navigation

Turn-by-turn navigation

地図を表示しながらの Turn-by-turn navigation

いわゆるカーナビのような機能。 Garmin の Forerunner 9XX シリーズに付いてる機能を Apple Watch で利用できるようになる。 WorkOutdoors ではナビゲーション機能はなく、ルートを外れたときと復帰したときにアラートがなる仕組みだった。正直なところトレイルでカーナビのような機能はいらないのではと思っていたが、実際に使ってみるととても便利だった。ルートを間違ったことを事後的に教えてもらっても便利だが、なるべくならルートを間違うこと自体を予防したい。もうすぐ分岐があることを事前に教えてもらえると、分岐にさしかかったときに注意するのでテキトーに走って間違ったルートに進むということがない。

標高断面図

標高断面図 全体

標高断面図 部分

これからどれくらいの登りが控えているのかを確認できる。これがめっちゃ便利。予定しているコース全体で見ることもできるし、直近のセクションに拡大して確認することも可能。予定している累積獲得標高のうちすでに何メートル登ったか、残りは何メートル登るのかが一目でわかる。これは登山を始めた当初から欲しい情報だったのでスーパー便利だ。

パソコン向けウェブサイト

footpathapp.com

パソコン向けのウェブサイトがまたよくできていて、ルートに任意のポイントを設置することが可能。前回トレランのレースに出たときはエイドステーションにマーキングしておいて関門時刻を書いておいた。こうすることでエイドまであと何キロメートルかがわかり、精神的に楽だった。

もちろんウェブサイトでルートを作成、編集することもできるし、 GPX ファイルを取り込むこともできる。

注意点

自分が知る限り、 Apple Watch でトレランするならフットパスが最高なのだが注意点がいくつかある。

1. 日本語訳が良くない

「他のワークアプリで使用する」というトグルスイッチを有効にしたら、ログが自動的にワークアウトに追加されなかった。この項目の意味はフットパスを地図アプリとしてのみ使い、ワークアウトのログは純正アプリで取るケースを想定していそうだが、この日本語では意味がわからない。

2. GPX インポートしたとき、本来通りたいところではないところにルートが引かれる

地図アプリの定番 SDK に Mapbox というものがある。フットパスも Mapbox をベースにしているが、 Mapbox も独自のルート情報を持っているようで、 GPX ファイルを取り込んだときに勝手にルートが Mapbox 上のルートに置き換えられてしまう。 Mapbox 上のルートは間違っていたり、現在使われていないところが残っていたりするのでちょっとやっかいだ。

3. Apple Watch Ultra でないとナビゲーション通知が事前に届かない

Apple Watch Ultra であればちゃんと分岐の前で通知が来るので便利なのだが、 Series 6 だと通過後に通知が来ることがあった。

4. UI がもっさりしている

デジタルクラウンを回すことで距離モード、ペースモード、標高モードを切り替えられるが、この切り替えがスムーズに行かずストレスを感じる。

5. ランニング向けの情報が不足

純正のワークアウトアプリであれば、ランニング中に心拍数ゾーンを確認できたり、ケイデンスや上下動を確認できたり、任意の地点でセグメンテーションしたりすることもできるが、フットパスにはそれらの機能がない。フットパスは地図アプリとして使い、ログは純正ワークアウトアプリで取れということかもしれないが、それだと GPS を使うアプリを同時起動することになって電池の持ちが悪くなりそうだ。

6. サブスクリプションに登録する必要がある

年額 2600 円のサブスクリプションに入らないと機能が使えない。自分は全然払う価値があると思うが、サブスクリプションに抵抗がある人は買い切り 1200 円の WorkOutdoors をどうぞ。

まとめ

いくつか注意点がありはするものの、フットパスに出会ってから山を走るのが快適になった。トレランのレースに出るとまわりは Garmin や Polar 、 Sunto などを使っている人ばかりで、「やっぱり Apple Watch で山を走るのはダメなのかな?」と不安になっていたが、いまは全く不安を感じなくなった。

電池持ちのよい Apple Watch Ultra とフットパスがあれば、日常生活では Apple Watch の便利な機能(タッチレス決済、 iPhone や Mac のロック解除、音を鳴らして iPhone を探す、 Apple Music で音楽を聞く)を享受しつつ、ルートを確認しながら安全に山を走ることができる。めっちゃおすすめです。

Footpath app

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

OGP 読み込み君が悪用されていて困ったという記事を書いた。

Referer でブロックされるようなサイトからリンクするときに OGP 読み込み君をかませて掲示板やブログのコメント欄に URL を投稿しまくっていたのだと思う。調べたら 73 万件以上のリンクが OGP 読み込み君によって生成され、リンク先の OGP カードがキャッシュされていて、ディスク容量を 2.8GB も消費していた。許せん。

認証なしで使える OGP 生成カードのようなエンドポイントを露出していたのがそもそもの間違いだった。スパマーのはびこる今日のインターネットではこういう無防備なことをはするべきではなかった。

ということで iframe で OGP を展開する方式をやめて、インライン表示するようにした。普通に OGP 表示用の HTML を生成してキャッシュしている。なので初回に OGP を読み込むときにめっちゃサイトのレスポンスが遅くなった( iframe であれば非同期読み込みできてメインの HTML の描画は高速だった)。

良くも悪くも、インターネットは巨大になってきていて、ちょっと穴のあるシステムをインターネットに公開してしまうと悪意をもった人に悪用されて膨大なダメージを負ってしまう可能性がある。難しい世の中になってきている。

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

OGP 読み込み君を作ってよそのサイト(自分のブログの過去記事含む)の OGP をいい感じに iframe で表示していた。

しかし最近この機能がスパマーに悪用されているようだ。自分がこのブログ内で言及した覚えのない URL へのアクセスが一杯あり、そのせいでめちゃくちゃにサイトの負荷が高くなっているようだった。 OGP 読み込み君はキャッシュする機能はあるが、基本的に Ruby でよそのサイトに HTTP リクエストを投げるので悪用されると負荷が高くなってしまう。

Nginx で悪用されたくないパスへのリクエストには Referer 制限をするようにしたのでこれで負荷が下がってほしい。

追記

ロードアベレージが平均 3 、高いときは 20 くらいになってたのが 0.1 くらいに戻った。

海外のスパマー、本当に色々酷いことやる。日本語読めないのに OGP 読み込み君の仕様を突き止めて悪用してる。多分、こんなことしても利益は 1 円もないのに何がしたいんだろう。他人にダメージを与えられればそれでいいんだろうか?

| @ブログ

よく検索されているキーワード

検索フォームの下に「よく検索されているキーワード」を追加した。実はこれ完全に自己満足で Google Analytics のサイト内検索で調べる限りだと検索機能はほとんど使われていない。一方で自分はめちゃくちゃ使っている。なので自分自身の検索も含むすべての検索ログをアクセスログから抽出して集計し、検索回数が多い順に並べて表示した。

検索フォームにはインクリメンタルサーチ機能があって、検索ワード入力途中にも HTTP アクセスがあるので検索ログには不完全なキーワードも残る。それらが表示されないように 1 文字だけのキーワードや、実際に Tantiny に投げて返ってくる結果が少ないキーワードは除外している。

自己満足ではあるのだが、このサイトをもっとも閲覧していてもっとも検索している自分が便利になればそれで良い。

| @ブログ

嘉穂アルプス 屏山

最近結構走ってるから iOS のフィットネスアプリとか HealthFit でめっちゃログや統計を確認してる。

前月との比較 直近 12 ヶ月間の月ごとの走行距離 日毎の積み上げの前年比
前月との比較、直近 12 ヶ月間の月ごとの走行距離、日毎の積み上げの前年比

いま自分は月間 100km 以上走ることを目標にしている。月間 100km はガチラン勢からしたら大した距離ではないのだが、油断して 3, 4 日走るのをサボったり雨が降ったりすると達成が難しくなるので、前月の同日と比べて進捗はどうかを確認してる。

同じような感じで進捗や達成状況を確認できる機能がブログにも必要なのではないかと思って、自分のブログのアーカイブページで年を選ぶとその年の月ごとの投稿数をグラフで表示するようにした(これまでは年で絞っても年ごとのグラフしか表示されてなかった)。

これで去年の同月に比べてどうかとか、その時期にどんな内容(カテゴリー)の記事をよく書いていたのかがわかるようになった。ランニングと同じように自分の頑張り状況が可視化されるようになった。


そもそもブログを書くことの意義とは何だろうか。大まかに二つあって、以下のように整理されるのではないかと思う。

  1. バズる記事を書いてアクセスを集める
    • 集めたアクセスで自分の認知度を高める
    • 集めたアクセスをマネタイズする(広告)
    • 世の中を変える
  2. 自分の内省のために書く
    • 読書や学習で得た知識を貯めておく
    • 考えを整理する

1 の観点でいうとアクセス数が重要なのだが、いまどきブログで小銭を稼ごうとか世界を変えようとかしてる人はいないはずで、ほとんどのブログは著者自身のために書かれてる(↑の 2 の方)と思う。自分のために文章を書きたい人にとって、書いた内容と密度や頻度、また過去に書いた記事を簡単に振り返ることができることの方が重要なはずだ。

なのに、たいていのブログサービスはアクセス解析機能はあるが、過去の自分の執筆状況を統計的に確認できる機能はない(少なくとも ameblo とはてなブログと livedoor Blog にはなかった)。アクセス数は Twitter で影響力のある人にシェアされたとか外部要因で増えることもあるから、それだけで自分のブログアクティビティを正確に測るのは難しい。

同じような話を以前にもブログに書いている。

振り返りの観点でも既存のブログはあまり良くない。たいていのブログはそもそも自分で書いた過去記事を読むのも大変だったりする。時系列に全文表示されてページネーションして辿らないといけない。

検索機能もいまいちだ。自分の考えたことを貯めておく場としてはちょっと貧相すぎる。

世の中に一般的に出回ってるブログは著者自身のためというより、いかにアクセスを集めて広告でマネタイズするかに主眼が置かれているから、内省や情報の取り出しやすさはあまり考慮されていないのだろう。いかに PV を上げるか、いかに滞在時間を長くするか、いかに回遊させるかが大事になってくる。

しかし先ほども書いた通り、芸能人や著名人を除き、ブログは自分のために書いている人が多いはずで、アクセス数を集めることよりも書き手の体験にフォーカスしたブログがあってもよいのではないだろうか。

ランニングはアプリを使ってログを取ることでいろんなデータが可視化されめっちゃモチベーションが上がる。「今月 100km 走っちゃった〜」とか、「 1km のペースが 6 分切れるようになってきた〜」とか。前年同月との進捗比較も面白い。

ブログでも「今月は 10 記事書けた〜」とか「 1000 文字以上の記事を 5 記事書いた〜」みたいな達成感はあるんじゃないかと思う。つまり、 GitHub の Contribution グラフのブログ版みたいなやつが必要だと思うのだ。

GitHub Contributions Graph

ランニングだと時計だったり Strava などのサービスが走るモチベーションを喚起してくる。一方でブログは誰も書くのを促してくれない。

ブログを書く人が少なくなったのは SNS のせいという面は間違いなくあるけど、ブログ自体の進化が足りないのだと思う。もっと書き手の脳みそをハックして、著者に書きたいと思わせるような仕組みがないとブログは衰退していくばかりなんじゃないだろうか。

突き詰めると、ブログの主なマネタイズ手法が広告しかないのが根っこの問題な気がする。読み手に広告を見せることで収益化するのではなく、書き手の使い勝手や満足度を高めることで収益化できる可能性(書き手に対して機能課金する)はないのだろうか。ランニング系のサービスやアプリは実際そうやって収益化してる(うまく行っているかはわからない)。