一言でまとめると

完成した本の方が、人はお金を払ってくれるのだろうか？

ハイライト

• Refactoring Englishは売上が 역대2位の月となった。
• ほぼ完成したドラフトと完全版ではどちらが買われやすいのか、売上データを分析した。
• 本のフィードバックツールを完成させた。
• 時間管理のための新しいツールを試している。

目標の達成度

毎月のはじめに、その月に達成したいことを宣言している。目標に対する結果は次のとおりだ。

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

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

多少は改善できたが、まだ磨きをかける余地がある。

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

• 結果：ユニーク読者は1万7,500人だった
• 評価：B-

設計ドキュメントに関する章を無料の抜粋記事として公開した。LobstersとRedditでは好評だったが、Hacker Newsでは振るわなかった。

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

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

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

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

Refactoring Englishの指標

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

最後の8%でどれだけ変わるのか？

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

本を完成と表示しても、週ごとの売上に目立った変化はなかった。では、1日あたりの平均で見るとどうだろうか。

なるほど、本を完成とマークした後にわずかな増加があった。

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

面白いことに、本を完成させても地域別価格で購入する顧客の売上には影響がなかったが、米ドルで購入する顧客は、本の完成後3週間で購入率が20%上昇していた。

最新の抜粋記事を公開した後の売上は、明らかに数字を大きく左右するので含めていない。その期間は別のカテゴリーとして扱うことにした。

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

おや、話がひっくり返った。訪問者あたりで正規化すると、ストーリーが逆転する。完成版でも未完成版でも同じ割合で購入しているのはアメリカ人で、完成した本に対して訪問者あたり約20%多く支払っているのはアメリカ以外の読者だったのだ。

この情報をどう活かせばいいのかはわからないが、好奇心は満たされた。

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

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

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

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

年に一度くらい、「自分の時間は一体どこに消えているのだろう？」と自問する。何かのプロジェクトに集中しているのに、思ったほど進捗しないときはいつも、この疑問が浮かんでくる。過去に何度かこの問いを自分に投げかけた記録がこちらだ。

• 2022
• 2023
• 2025

今回は「時間管理ツールを使ってみようかな」と思った。

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

RescueTimeのオープンソース版があればいいのにと思ったとき、「待てよ、たぶんあるはずだ」と思い至った。実際、存在した。ActivityWatchというツールだ。オープンソースでプライバシー重視の設計になっており、ウィンドウやブラウジングのアクティビティをすべて記録するが、データはすべてローカルマシンに留まる。

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

アクティビティをどう分類するかをルールでActivityWatchに教えることになっているのだが、その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リリースを宣言する。