一行要約

完成した本の方がより高く売れるのでしょうか？

ハイライト

• Refactoring Englishは過去2番目に売上が高い月となりました。
• ほぼ完成したドラフトと完成した本では、どちらが購入されやすいのかを売上データから検証しました。
• 本のフィードバックツールを完成させました。
• 時間管理のための新しいツールを試しています。

目標の達成度

毎月初めに、その月に達成したい目標を掲げています。以下が今月の結果です。

Refactoring Englishのウェブサイト改善に5時間以上投資する

• 結果：ウェブサイトの改善に約3時間を費やしました
• 評価：B-

少しは改善できましたが、まだ磨き込む余地があります。

Refactoring Englishのウェブサイトに3万人のユニーク読者を集める

• 結果：1万7,523人のユニーク読者を獲得しました。
• 評価：B-

設計ドキュメントに関する章を無料の抜粋記事として公開しました。LobstersとRedditでは好評でしたが、Hacker Newsでは反応がありませんでした。

設計ドキュメントの章への反応がこれほどポジティブだったことには驚きました。普段、開発者に設計ドキュメントの話をすると、返ってくる反応はたいてい「設計ドキュメントもそれにまつわる一切が嫌いだ」というものです。今回の投稿へのコメントは、設計ドキュメント全般に対しても、私の提案に対しても、清々しいほど好意的でした。

読者フィードバックツールを完成させる

• 結果：ツールは稼働を開始しました。
• 評価：A

しばらく大規模なAIによる停滞に行き詰まっていましたが、大きな機能を細かく分割することをより真剣に考え、コードの品質にこだわりすぎないようにすることで乗り越えました。今回は、完璧を目指すよりもまず完成させることが大切でした。

Refactoring Englishの指標

6月は、初期のクラウドファンディング開始以来、書籍の収益が最も高かった月となりました。訪問者数の増加は、設計ドキュメントに関する抜粋記事のおかげです。

残りの8%でどれだけ変わるのか？

ここ数か月、Refactoring Englishのウェブサイトでは、本書をアーリーアクセスで「ほぼ完成」と表示していました。ほぼ完成の状態から完全に完成した状態にすることで、売上にどのような影響があるのか気になったので、週ごとの売上を確認してみました。

本を「完成」と表示しても、週ごとの売上に明確な影響は見られませんでした。では、日ごとの平均で見るとどうなるでしょうか。

なるほど、本を完成としてからわずかに増加していました。

また、特にアメリカの読者が、本の完成後により高い割合で購入しているのかどうかも気になりました。本が購入されるたびにメール通知が届くのですが、米国の価格で支払う顧客からの売上が増えているように感じていました。ただ、きちんと計測したわけではなかったので、データを確認してみました。

興味深い結果でした。本を完成させても、地域別価格で購入した顧客の売上には影響がありませんでしたが、米ドルで購入した顧客は、本の完成後3週間で購入率が20%高くなっていました。

最新の抜粋記事を公開した後の売上は、明らかに数字が大きく変わるため含めていません。そこは別のカテゴリーとして扱うことにします。

ただ、アメリカ人が読者の大半を占めているため、この数字は常に少し偏りがあります。訪問者あたりの収益で正規化するとどうなるでしょうか。

おや、話がひっくり返りました。訪問者あたりで正規化すると、結果が逆転します。完成版と未完成版で購入率が変わらなかったのはアメリカの読者でした。完成版に対して訪問者あたり約20%多く支払っていたのは、米国以外の読者だったのです。

この情報をどう活かせばよいのかはわかりませんが、好奇心は満たされました。

読者が本のアプリで有益なフィードバックを残してくれています

これまでにも読者に本のフィードバックをお願いしてきましたし、熱心にフィードバックをくれる読者もいましたが、それはごく少数でした。本を読みながらメモを残せるウェブベースのフィードバックアプリを作れば、楽しくて役に立つのではないかと考えました。1、2週間でさっと作れるだろうと思っていました。そして、短い…2か月後、ついに稼働させることができました！

フィードバックツールは公開してまだ数日ですが、読者がより多くのフィードバックをくれるようになっているようです。ある読者は読了したばかりで、フィードバックアプリが体験の中で特にお気に入りの部分だったと教えてくれました。嬉しいことでした。

15年ぶりに時間計測ツールを使ってみる

年に一度くらいのペースで、「自分の時間は一体どこに消えているのだろう？」と自問します。この問いは、何かに集中して取り組んでいるのに、思ったほど進捗が出ないときによく浮かびます。過去にこの問いを自問した記録をいくつか紹介します。

• 2022年
• 2023年
• 2025年

今回は、「時間計測ツールを使ってみようか」と思いました。

約15年前に、RescueTimeという時間計測ツールを試したことがあります。あまり役に立ったとは感じませんでしたが、数週間続けて様子を見ようかと思いました。ただ、画面に表示されるすべてのウィンドウのデータを見知らぬ企業に収集させていることに気づき、すぐにRescueTimeをアンインストールしました。

RescueTimeのオープンソース版があればいいのにと思ったとき、「待てよ、きっとあるはずだ」と気づきました。実際にありました。ActivityWatchというツールです。オープンソースで、プライバシーを最優先にしています。ウィンドウやブラウジングのアクティビティをすべて記録しますが、データはすべて自分のマシン内に留まります。

問題は、ActivityWatchがRescueTimeに比べてずっと洗練されていないことです。タイムラインが何を示そうとしているのか、まったく理解できませんでした。

アクティビティをどう分類するかをルールで指定することになっていますが、そのUIも使いにくいと感じました。

ActivityWatchを諦めかけたとき、「まあ、データ収集の部分はちゃんと動いているはずだ。自分でフロントエンドをバイブコーディングしてみたらどうだろう？」と思いました。

そこで実際に作ってみたところ、意外と簡単でした。まずはコマンドラインツールから始めていますが、今後はウェブアプリに拡張する予定です。

自作のActivityWatchフロントエンドを使うには、アプリ名、ウィンドウタイトル、URLに基づいてアクティビティを分類する設定ファイルを作成します。

- name: Book/Feedback Site
  rules:
    - url: "*refactoring-english-feedback*"
    - window_title: "*refactoring-english-feedback*"

- name: Book/Website
  rules:
    - url: "*refactoring-english-landing*"
    - window_title: "*refactoring-english-landing*"

- name: Book/Writing
  rules:
    - app: Zathura
    - app: Code
      window_title: "*refactoring-english*"
    - app: firefox
      window_title: "mtlynch/refactoring-english *"

出力は次のようになります。

$ go run ./cmd/app --config data/config.yaml
...
Book               1h34m   19.7%
  Feedback Site      48m   10.0%
  Writing            46m    9.7%

今のところデータは興味深いものですが、最大の課題は、すべてのアクティビティを自動で分類するのが難しいことです。例えば、Wikipediaの閲覧というカテゴリーを追加できますが、それが本の執筆という正当な作業の一環なのか、それともただ沼にはまって、気がつけば自身の発明によって命を落とした発明家の一覧を読んでいるだけなのか、区別がつきません。

まとめ

できたこと

• Refactoring Englishのフィードバックツールを完成させました。
• 一貫性とEPUB互換性のためにRefactoring Englishの電子書籍を修正しました。
• Little Momentsのデモ動画を作成しました。
  • この中のおふざけ写真は、なかなかの出来だと自負しています。

学んだこと

• 読者は、100%完成した本とほぼ完成した本の違いを、私が思っていたほど気にしていないようです。
  • 完成した本の方が購入率は確かに高くなりますが、ウェブサイトの訪問者数で補正すると、その効果はかなり小さいものです。

来月の目標

• Refactoring Englishについて話すため、5つのポッドキャストに売り込みます。
• Refactoring Englishのウェブサイトに3万人のユニーク読者を集めます。
• アーリーアクセスを終了し、本のバージョン1.0リリースを宣言します。