Refactoring English:4ヶ月目
ひとことで言うと
ついに、本を書くことになりました!
今月のハイライト
- 本の予約販売が成功しました(ぎりぎりでした)。
- ブログ記事をいくつか書き、アクセス数の予測は見事に外しました。
- 本を執筆するためのマークアップ言語を選ばなければなりません。
目標の成績表
毎月初めに、その月に達成したい目標を宣言しています。結果はこうなりました。
Refactoring EnglishのKickstarterで5,000ドルを集める
- 結果:196人のバッカーから6,701ドルを集めました。
- 評価:A+
Kickstarterは予想以上に好調で、終了間際に大きく盛り返しました。
Refactoring Englishのブログ運営の章を公開する
- 結果:開発者に読まれるブログ記事の書き方を公開しました。
- 評価:A
この記事はHacker NewsとLobstersでは好評でしたが、redditでは伸びませんでした。
3月末までにHacker Newsのフロントページに2回載る
- 結果:開発者に読まれるブログ記事の書き方とHN Popularity Contestの両方がフロントページに掲載されました。
- 評価:A
なんとか達成できたので今はほっとしていますが、今月はずっと「5本のアイデアが全部外れたら格好悪いな」と不安でした。幸い、5本中2本がヒットしてくれました。
本の予約販売は成功した
今月の大半、本の先行販売は失敗に終わると思っていました。5,000ドルの目標に対して1,500ドルも足りないペースだったのです。
終了4日前、あるブログ記事がHacker Newsで注目され、状況は一変しました。
最終的にKickstarterでは6,551ドルが集まり、5,000ドルの目標を上回りました。事後注文を含めると、現在は6,701ドルになっています。

先行販売の詳細については、先週記事にまとめました。
Kickstarterについては改めて記事を書く予定ですが、とても良い経験になりました。本への関心を測るのにうってつけの手段でしたし、6,500ドルの事前注文額は、伝統的な出版社からもらえる前払い金よりも多い金額です。
Julia Evansさんのビジネスモデルは自分にも通用するだろうか
Refactoring Englishの先行販売でワクワクしたのは、ブログで生計を立てられるかもしれないという希望が見えたことです。
TinyPilotを運営していた頃、ブログは最初の数十人の顧客を見つけるのに確かに役立ちました。しかし次第に、個人ブログが売上につながらなくなったと感じるようになりました。当然といえば当然で、インディー開発者の日記に興味がある人が、400ドルのKVM over IPデバイスを買いたいとは限りません。
ハードウェア事業は複雑で、時間に追われることがほとんどでした。そのため、1日の中で最も頭が冴えている時間を個人ブログに充てるのは難しかったのです。それ以来、ブログを書くことと収益化がうまく両立する事業形態を模索してきました。
私の仮説は、教育コンテンツを作ればブログを続けていけるというものです。自分が実践していることについて書き、より深く学びたい読者に向けて本やコースを用意すれば、読者は理解を深められ、私の活動も支えてもらえます。
ブログと関連コンテンツで収益を得ている代表例が、Julia Evansさんです。ソフトウェアに関するブログを運営し、イラスト入りのzineを販売して収益化しています。
Juliaさんは現在収益を公開していませんが、2019年時点でzineから年間約10万ドルの売上がありました。当時はブログを本業にする前の副業としての数字です。もちろんこれは売上であり利益ではありませんが、デジタル商品なのでGumroadなどの決済手数料などを除けば利益率は90〜95%程度だったはずです。
副業の段階で年間10万ドルの売上というのは、かなりすごいことです。仮に本業に専念して売上が3倍になったとしましょう。私がその半分でも達成できれば、ブログと関連商品で年間15万ドルになります。簡単ではありませんが、実現不可能ではないと思っています。
生活がかかったつもりでブログを書く
今月は、本の顧客を見つけるためにヒットするブログ記事を書こうとした、少し特殊な挑戦でした。普段は締切に追われたり、読者数を最大化するためにテーマを選んだりすることはありません。
ネタのストックや書きかけの記事はたくさんあるので、次の観点で評価してみました。
- 書きやすさ:完成度の高い記事をどれだけ楽に書けるか
- 想定読者数:ヒットした場合、どれくらいの読者に届きうるか
- ヒットする確率:想定する読者に届く可能性はどれくらいか
- 本との関連度:この記事を見つけた読者が、本にも興味を持つ可能性はどれくらいか
きちんと点数化したわけではありませんが、頭の中でのざっくりとした評価はこんな感じでした。
| タイトル | 書きやすさ | 想定読者数 | ヒットする確率 | 本との関連度 |
|---|---|---|---|---|
| もう私のお気に入りのGitコミットではない | 4 | 5 | 4 | 4 |
| 役に立つコミットメッセージの書き方 | 2 | 5 | 3 | 4 |
| 開発者に読まれるブログ記事の書き方 | 2 | 4 | 2 | 5 |
| 幸せにオープンソースプロジェクトを維持する方法 | 3 | 3 | 4 | 2 |
| 文章を磨く:力強い動詞を使う | 5 | 1 | 1 | 5 |
| Windowsを35年使った後にNixOSを3ヶ月使ってみた | 3 | 2 | 5 | 1 |
| ZigでCアプリケーションをビルドする | 3 | 3 | 4 | 1 |
結局、上位3つを選びましたが、結果は予想とは違いました。実際の数字は次のとおりです。
| タイトル | 売上への貢献 | 総読者数 | Hacker News | |
|---|---|---|---|---|
| 開発者に読まれるブログ記事の書き方 | 高 | 22.3k | 9.7k | 325 |
| 役に立つコミットメッセージの書き方 | 中 | 2.6k | 126 | 1.2k |
| もう私のお気に入りのGitコミットではない | 低 | 31.6k | 87 | 6.4k |
「もう私のお気に入りのGitコミットではない」は、最も手応えを感じていたアイデアでした。すぐ書けそうでしたし、元の記事が人気だったので潜在的な読者も多いと思ったからです。実際、Lobstersでは好評で、redditではまずまずでしたが、Hacker Newsでは振るいませんでした。この記事を書いていて初めて気づいたのですが、存在すら知らなかったGoogle Discoverに取り上げられ、そこから1万5,000人が訪れていました。
この記事は私にとって少し異色でした。というのも、他のブログ記事への反論を書いたのは初めてだったからです。書き始めたときは、元の記事に対して言いたいことがはっきりあり、意気込んでいました。しかし初稿を書き終えると、迷いが生じました。6年も前に書かれた記事をわざわざ攻撃しているように感じられたのです。攻撃的な響きを和らげるよう表現を調整しましたが、それでもやや挑戦的な印象は残りました。
「役に立つコミットメッセージの書き方」は、先行販売の呼び水になるはずだった記事です。Lobstersでは好評で、redditではまずまずでしたが、Hacker Newsでは振るいませんでした。売上にどれだけ貢献したかは判断が難しいところです。記事経由で予約した読者と、同じ日に送ったメーリングリストの告知を見て予約した読者を区別できないからです。
「開発者に読まれるブログ記事の書き方」は、本を救った意外なヒット作でした。Lobstersではまずまずで、redditでは惨敗でした。Hacker Newsへの最初の投稿は失敗に終わりましたが、翌朝、別の人が再投稿してくれたところ大変な反響があり、その日の4位まで上がりました。何より、Hacker News経由で記事を見つけた多くの人が、そのまま先行販売で購入してくれました。
Hacker News人気コンテスト
「エンジニアリングをマーケティングにする」は、マーケティングが苦手なエンジニア(つまり私のような人)に人気の手法です。
考え方はシンプルで、有料プロダクトに関連する無料ツールを作り、その出来の良さに感心した人が有料プロダクトにも興味を持ってくれることを期待します。
Hacker Newsのブログ人気ランキングを作りたいと、ずっと考えていました。他の人気Hacker News執筆者と自分を比べてみたかったからです。昨年夏に簡単なプロトタイプを作ったのは、Hit the Front Page of Hacker Newsコースを再開するために使う予定だったからです。
コースを棚上げにしてRefactoring Englishに集中してからは、このランキングツールをどうするか決めかねていました。3月になり、先行販売を何としても成功させたいと思ったとき、プロトタイプに1〜2日手を入れて公開すればいいと気づいたのです。

Popularity ContestはRefactoring Englishを宣伝するために作ったツールです
このツールは見事Hacker Newsのフロントページに掲載されましたが、本の売上にはつながりませんでした。
意外だったのは、トップ100に入った人たちの多くが自分の順位を気にしていたことです。Hacker Newsで最も人気のある個人ブロガーの一人なら、もう十分有名でHacker Newsなど気にしないだろうと思っていましたが、たくさんの方が公開コメントやDM、メールで反応をくれました。
特に多くのトップブロガーが、順位の推移に関心を示しました。中でもJohn Gruberさんは、私のツールが、Hacker Newsが近年自分のサイトに手動でペナルティを課してきたという自身の仮説を裏付けていると感じたようです。
その反応を受けて、個別ブログのより詳しい統計を見られる機能を追加しましたが、まだ大きな反響はありません。

トップブロガーが自身のドメインの統計を共有したがっているようだったので、ブログごとの詳細ビューを作りました。
本に使うマークアップ言語を選ぶ
これまで本はHugoとMarkdownで書いてきました。正式なPDF版にはまだ着手していないので、出版用の技術選びは先延ばしにしていました。
本の制作が正式に決まった今、執筆方法を決める必要があります。重視しているのは次の点です。
- そのツールでネイティブにPDFを出力できるか
- そのツールでネイティブにepubを出力できるか
- そのツールでネイティブにHTMLを出力できるか
- ツールの成熟度はどうか。単純なことをやろうとしてバグや行き止まりにぶつかる可能性は低いか
- DRMフリーの技術書の伝統的な出版社で、この形式に対応しているところはあるか
- 初版はセルフパブリッシュする予定ですが、再版で紙の書籍を伝統的な出版社と出せると理想的です。
候補は次のとおりです。
| ツール | epub | HTML | 成熟度 | 出版社対応 | |
|---|---|---|---|---|---|
| Asciidoctor | ✅ | ✅ | ✅ | 高 | なし |
| LaTeX | ✅ | ❌ | ❌ | 非常に高 | No Starch Press |
| Pollen | ❌ | ❌ | ✅ | 低 | なし |
| Typst | ✅ | ❌ | ❌ | 低 | なし |
| mdBook | ❌ | ❌ | ✅ | 低 | なし |
勝者はAsciidoctorかLaTeXになりそうです。
AsciiDocからLaTeXへの変換ツールはサードパーティ製のものがあります。No Starchから「ぜひ再版を出したい」と言われたら、一度きりの変換作業くらいは我慢できるでしょう。
Typstも数時間試してみました。オープンソースでLaTeXよりシンプルなのは気に入りましたが、新しく成熟度も低いツールをあえて使うほどの利点は感じませんでした。また、書籍というより研究論文向けに最適化されている印象でした。
サイドプロジェクト
fusion RSSリーダーのテストカバレッジを上げる
数ヶ月前にNixOSに乗り換えてから、自分のマシンでより多くのサービスをホストするのを楽しんでいます。特にお気に入りなのがfusionで、GoとSvelte、SQLiteで作られたミニマルなRSSリーダーです。

fusionはGo、Svelte、SQLiteで作られたミニマルなRSSリーダーです。
fusionで一番気に入っているのは、メンテナの方が親切で、私のちょっとした改善も受け入れてくれることです。空き時間に少しずつ貢献しています。
特に力を入れたのが、pullパッケージのリファクタリングとテストの拡充です。
pullパッケージの変更前(v0.8.9)と変更後(v0.9.3)
きっかけは、If-Modified-Since HTTPヘッダーに対応したかったことでした。しかしHTTPリクエストを担うコードを見ると、修正が困難でした。主な問題は次のとおりです。
- データベースの読み取り、フィードを取得すべきかどうかの判断、外部データのパース、結果の書き戻しなど、さまざまな責務が混在していた。
- そのコードを検証する自動テストがなかった。
- テストを書こうにも、このコードを実行する公開関数は
Puller.PullAllしかなく、しかもその関数はワーカープールまで管理しているため、さらに複雑だった。
主な改善点は次のとおりです。
- HTTP関連のロジックを独自のファイルに分離した。
- RSSのパースを独自のファイルに分離した。
- 複数ワーカーを管理する部分から単一フィードを取得するロジックを切り離し、単一フィードのテストを容易にした。
- データベースとのやり取りのインターフェースをよりシンプルで明確にし、テストでデータベースをモックしやすくした。
- フィードを更新すべきかを判断する専用関数を作り、更新ワークフローの他の部分と混ざっていた判定処理を分離した。
もう少し整理したい部分は残っていますが、今の進捗には満足しています。おかげでいくつかのバグを修正し、fusionの機能も改善できました。
What Got Doneは正式に終了すべきだ
2019年に、What Got Doneというウェブアプリを作りました。初めての本格的なSaaS事業への挑戦でしたが、顧客は見つかりませんでした。
今でも毎週使っています。週次アップデートの連続投稿は5年続いていますが、継続的に使っているのは私だけです。たまに他の人が使い始めても、数週間で飽きて投稿しなくなります。
作った当時はウェブ開発の知識が今よりずっと浅く、当初はGoとVue 2、AppEngine、Google Cloud Firestoreで構築しました。その後AppEngineをfly.ioに、FirestoreをSQLiteに置き換えたことで開発は少し楽になりましたが、Vueでの開発は今でも苦痛です。Vueから素のJavaScriptへ段階的に移行する良い方法も見つからず、30時間以上かけて大規模に書き直す気にもなれません。
最近、このサイトはHugoで生成する静的サイトにしたほうが理にかなっていると気づきました。好きなエディタで週次アップデートを書き、mainブランチにプッシュすればCIがサイトをビルドして公開してくれる。今のこのブログと同じ仕組みです。そうすればユーザーアカウントや認証、データベース管理といった複雑さがごっそりなくなります。しかも、アップデートはSQLデータベースに閉じ込められたレコードではなく、検索可能なプレーンテキストファイルとして残ります。
サイトの運用コストはゼロで、保守も年5時間ほどしかかかっていません。だから終了を急ぐ必要はありませんが、まずは新規登録の受付を停止しました。
いずれ、最近使ってくれていたユーザーに終了を告知し、データをエクスポートできるようにするメールを送る予定です。
面白かったリンク
- 競争の激しい市場でSaaSを4年間運営して - ブートストラップで会社を立ち上げた経験について読んだ中で、最も優れたブログ記事の一つです。Maxさんの教訓のほとんどに同意します。ブートストラップの創業者としての私の経験からも、すべてが腑に落ちる内容でした。
まとめ
今月やったこと
- もう私のお気に入りのGitコミットではないを公開した
- 開発者に読まれるブログ記事の書き方を公開した
- 本の予約販売はぎりぎりで成功したを公開した
- 本の販促ツールとしてHacker News Popularity Contestをリリースした
来月の目標
- Kickstarterから得た教訓についてブログ記事を書く。
- 本の新しい章を書き上げるか、本のトピックについてライブセッションを行う。
- 公開謝辞やブログ記事の編集協力を選んだKickstarterバッカー全員と特典の調整をする。
お願い
マークアップ言語(WordやGoogle Docsではない)で本を出版した経験がある方は、ぜひその体験を教えてください。
記事をランダムに読む