一言でまとめると

ホームランを狙ってフルスイングする代わりに、バントしてみたらどうだろう？

ハイライト

• 投資が少なくリターンも小さめのブログ投稿を試しています。
• フリーランスの編集サービスについて、本を読んでくれた方を対象にする形へ戦略を切り替えています。
• Hacker Newsのフロントページに載る確率について、私の直感は大きく外れていました。

目標の自己採点

毎月のはじめに、その月に達成したいことを宣言しています。結果は次のとおりでした。

Refactoring Englishのサイトに新しい読者を呼び込む記事を公開する

• 結果：「The Software Essays that Shaped Me」を公開し、最初の3日間で16,000人の読者を集めました
• 評価：B+

目標自体は達成できましたが、記事に時間をかけすぎ、出来栄えにもやや物足りなさを感じています。

Refactoring Englishの新しい章を公開する

• 結果：新しい章は公開できませんでした
• 評価：F

新しい章の初稿は書いたものの、公開には至りませんでした。「The Software Essays that Shaped Me」とフリーランスの編集案件に予定より多くの時間を使ってしまったためです。

まだ話したことのない読者20名にパーソナライズしたメールを送る

• 結果：2名の新しい読者にメールを送りました
• 評価：D

もう読者に連絡しても新しい学びはないと片付けてしまおうかと思っていました。ところが数日前、以前連絡した読者から返信があり、本で学んだことを活かして初めてHacker Newsのフロントページに記事が載ったと教えてくれました。これは明らかに価値のあることでしたし、もっと積極的にやるべきだと気づかされました。

この件については後述でさらに考えを整理しています。

Refactoring Englishの指標

9月はサイト訪問者数も予約販売も良い伸びがありました。読者が別の読者を呼んでくれるような好循環を作りたいところですが、まだそこまでは至っていません。それでも、今月は1,000ドル近く売り上げられたのは嬉しいことです。

バントを試す

野球でバントとは、バットを振るのではなく、ボールの軌道にバットを置いて当てる打ち方です。メリットは空振りしにくいことですが、デメリットは遠くまで飛ばせないことです。バントで望める最高の結果は一塁に到達することくらいで、ホームランになることはまずありません。

私のブログ記事のほとんどは「ホームラン狙い」の記事です。Hacker NewsやReddit、検索結果で1位を取りたいので、多くの労力を注ぎ込んでいます。

問題は、この「ホームラン狙い」の記事を書くのに約1か月かかってしまうことです。本を書きながらブログも出すとなると、記事を1本書くたびに本の執筆を1か月止めなければなりません。

そこで、代わりに「バント」的な記事を書けないかと考え始めました。そうすれば、本の執筆を止める期間を1か月ではなく1週間程度に抑えられます。

本来じっくり取り組むべきテーマを手抜きで仕上げるつもりはありません。むしろ、気軽に書けるテーマを選んで、どうなるか試してみたいのです。

最初のバントは、「I Once Appeared in The Old New Thing」でした。22歳のとき、初めての本格的な仕事で経験した出来事について書いたものです。特に深い洞察があったわけではありませんが、面白いエピソードだと思いました。執筆は4時間ほどで終わり、その内容としては十分完結していると感じました。

次のバントは、「The Software Essays that Shaped Me」でした。他の人が好きなソフトウェア関連のブログ記事をリスト化しているのを見かけて、気軽に楽しくできるだろうと思ったのです。何より、良いソフトウェア文章を好む人なら、私の本にも興味を持ってくれるかもしれません。

ところが書き始めると、「The Software Essays that Shaped Me」は単なるバントでは収まらなくなり、結局9月のほぼすべてをこの記事に費やしてしまいました。

当初は好きなブログ記事を並べるだけで終わらせるつもりでしたが、それでは退屈すぎると感じました。そこで各記事に短いコメントを添えてみることにしました。すると熱が入ってしまい、最終的には元の記事よりも長いコメントを書いていました。どんなコメントなら面白く読めるか、何度も書き直して探りましたが、今でもうまくいったとは言い切れません。

結局「The Software Essays that Shaped Me」には17時間を費やしましたが、これだけの労力をかけてまで書く価値があるのか、途中で立ち止まって考えることもありませんでした。

この記事は、私のブログを読んでくれている人には面白いものだと思います。知り合いが自分に影響を与えた記事のリストを公開したら、私も興味を持って読みます。しかし、この記事のコメント欄で他の人が自分のリストを共有しているのを見ても、正直まったく興味を惹かれませんでした。コメントに力を入れたことで多少はカバーできたかもしれませんが、所詮「良いブログ記事のリスト」だけでそこまで面白くするのは難しいのだろうと思います。

どちらの記事も良い結果を残しました。どちらもHacker Newsのフロントページに載りましたが、セカンドチャンスプール経由だったので、きれいなノックアウト勝ちというよりTKO勝ちのような感覚です。

投資した労力にほぼ比例して結果が出たのは興味深いことです。普段はそうならないことが多いのですが。

せっかくのチャンスを逃した話

以前はRefactoring English関連の記事がHacker Newsで伸びると、読者が本を購入してくれるのが目に見えて増えていました。今回は「The Software Essays that Shaped Me」が2位まで上昇し、11時間フロントページに留まったにもかかわらず、購入は1件だけでした。

Hacker Newsで私の投稿を見た人は、すでに私が本を書いていることを知っていて、興味のある人はもう買ってしまったのかもしれないと思いました。

Hacker Newsのフロントページから記事が落ちた翌朝、目が覚めてふと気づきました。本の宣伝を入れ忘れていたのです！

本のサイトに載せているサンプル章には、すべて「このテーマで本を執筆中です。アーリーアクセスを購入できます」という小さなセルフ広告を入れています。

ブログ記事にそのセルフ広告を入れ忘れたため、最初の14,000人の読者は私が本を書いていることを知らないまま記事を読んだことになります。しまった！

今後は入れ忘れがないよう、ブログのテンプレートを修正しました。

フリーランス編集の進め方を変える

数か月前、他の開発者のブログ文章を改善する手伝いをするフリーランスの編集サービスを始めました。本の中で概念を説明する方法が、実際の読者にもちゃんと伝わるか確かめる良い機会になると考えたからです。

難点は、編集にかなりのコストがかかることです。1件あたり4〜7時間かかり、その日の「頭を使う作業」の枠を使い切ってしまうので、同じ日に自分の執筆を進めるのが難しくなります。また、誰からも急かされているわけではないのに、早く返さなければというプレッシャーも感じています。自分自身の執筆経験から、フィードバックを何日も待たされるのがどれだけ辛いか分かっているからです。

初めのうちは、フリーランスの編集は狙いどおりに機能し、本のための良いアイデアが得られました。しかし件数を重ねるにつれ、本に活かせる新しい気づきは減ってきました。今では、書いているフィードバックのほとんどが、本ですでに書いた内容を相手に合わせて書き直したものになっています。

編集自体は続けたいのですが、今後は本を読んでくれた著者だけを対象にしたいと思っています。料金も2倍にし、ブログ記事1本の編集を400ドルに設定しました。ただし、本を読んでくれた方には90%割引を提供するつもりです。

90%割引では、ほとんどお金をいただかないのと変わりませんが、依頼する側にも多少なりとも当事者意識を持ってもらうために、いくらかは負担してもらいたいと考えています。

本を読んでいない方の依頼も引き続き受けますが、本の執筆時間を削ってでもやる価値があると思える金額は設定したいと思っています。400ドルでもまだ安いかもしれませんが、様子を見てみます。

なぜ読者への働きかけをサボってしまうのか

なぜ読者への働きかけという目標を達成できないのか、考えています。一見すると難しそうには見えないのですが、いつも最優先にはならず、つい後回しにしてしまいます。

他にも先延ばしにしてしまうタスクはありますが、それらは単純にやりたくないからです。一方で、読者に連絡を取るのは実際には楽しいのです。さまざまな読者が何をしていて、私のテクニックをどう活かしているのか知るのは面白いです。

問題の一端は、読者にメールを送るまでに「よし、やるぞ」というエネルギーが必要なことです。というのも、次のような手順を踏まなければならないからです。

1. 予約購入してくれた読者のリストを開く
2. ウェブサイトを持っている人を探す（パーソナライズした内容を書くため）
3. その人のサイトを読んで相手のことを知る
4. AIが書いたように見えないよう、言葉を選びながらメールを書く

まずはメールを送る顧客とそのウェブサイトのリストをまとめておくと良いかもしれません。そうすれば、連絡したい気分になったときに毎回ゼロから始めずに済みます。

Stripeで購入後メールを送る面倒さ

何人かのRefactoring Englishの購入者から、「支払ったのに本へのリンクが記載されたメールが届かない」と戸惑いの連絡をもらいました。支払いはStripeで受け付けており、支払い完了後にStripeが本のURLへリダイレクトする仕組みです。リダイレクトに気づかなかったり、ページをブックマークし忘れたりすると、購入者は本にアクセスできなくなってしまいます。

購入者からリンクが見つからないと連絡があるたびに、Stripeの設定画面で購入後メールのカスタマイズ方法を探し、数分で諦めて、結局自分で正しいリンクをメールで送っていました。

先月、ようやく腰を据えてStripeのドキュメントやフォーラム投稿を調べましたが、一回限りの支払い完了後にStripeが送るメールをカスタマイズする方法は見つかりませんでした。分かる限りでは、唯一の方法は自分でウェブサーバーを立ててStripeのWebhookを受け取り、自分のメールプロバイダーから独自にメールを送ることです。Stripeが加盟店に支払い完了メールの文面を少しもカスタマイズさせてくれないばかりに……。

Webhookに応答するウェブサーバーを立てること自体は、私にとってそこまで難しいことではないはずです。ただ、Stripe、Buttondown、Netlify Functionsを連携させるコードを書く必要があり、それぞれに細かな落とし穴やバグがあります。特にStripeはひどいものです。これまでに購入後にメールが送られるようにするだけで約10時間を費やしましたが、今でも正しく動いているか自信がありません。

これまでにハマった落とし穴は次のとおりです。

• StripeのGoクライアントライブラリは、StripeのWebhook APIのたった一つのバージョンにしか対応していません。
  • いえ、ドキュメントにはどのバージョンか書いていません。実行してWebhookの失敗で気づくしかないのです！
• Stripeアカウントを最新のWebhook APIバージョンに更新してから、過去のイベントのWebhookを再送しても、新しいバージョンを使うと表示されながら実際には古いAPIバージョンが使われます。
• Stripeのcheckout.session.completedのWebhookリクエストには、ドキュメントには載っているのに実際にはline_itemsが含まれていません。
  • 別途APIを呼び出さないと顧客が何を購入したか分からないので厄介です。
• NetlifyはHTTPヘッダー名を黙って小文字に変換するので、Stripe-Signature:ヘッダーを探すときはstripe-signatureで探す必要があります。
• StripeのWebhook署名シークレットは、Stripe APIキーとは別物です。

サイドプロジェクト

Hacker Newsでの成功を時間帯別に分析する

まだリリースもしておらず、今後どうするかも決めていないプロダクト「Hacker News Observer」をいじり続けています。今のところはデータを集めて、Hacker Newsでの成功に関するちょっとした疑問を解消するのに使っています。

ずっと気になっていたことの一つが、Hacker Newsのフロントページに載りやすい時間帯があるのかどうかです。そこで、1日の中で投稿がフロントページに到達する割合を集計してみました。

最初は成功率を多く数えすぎるバグがあるのかと思いました。私の体感では、Hacker Newsの投稿がフロントページに載る割合は12%よりずっと低いと感じていたからです。しかし、ここ数日のランダムな区間を見てみると、数字は合っていそうです。/newestを見ると、通常2〜5件のストーリーがフロントページに入っています。数日前の30分間の区間では、投稿の27%がフロントページに到達していて驚きました。

投稿数が少ない週末は、成功率がかなり高くなるだろうと思っていました。実際、週末の投稿のほうがフロントページに載りやすいのは事実ですが、思っていたより効果は小さかったです。

• 平日：投稿の12.1%がフロントページに到達します。
• 週末：投稿の13.2%がフロントページに到達します。

平日5%に対して週末20%くらいを想像していました。週末に投稿してもフロントページに載る確率はわずかに上がるだけなのに、成功したとしても読者数はかなり少ないので、週末投稿の魅力はあまりないことになります。

HN Popularity Contestでやっているように、データを個人ブログに絞って分析してみたいとも思っています。個人ブログが載りやすい時間帯があるのか気になるからです。

まとめ

今月やったこと

• 「The Software Essays that Shaped Me」を公開しました
• 「I Once Appeared in The Old New Thing」を公開しました
• 「Get xkcd Cartoons at 2x Resolution」を公開しました
• Refactoring English関連で2件のフリーランス編集案件に対応しました
• Refactoring Englishの購入者へ購入後メールを送るWebhookハンドラーを構築しました
• Hacker News Observerに「時間帯別成功率」機能を追加しました
• Jellyfin Rokuクライアントのコードへのコントリビュートを開始しました
• 企業とコミュニティメンバーの関係改善について話し合うため、AirGradientとミーティングを行いました

学んだこと

• 低投資のつもりの記事が高投資になりそうなら、撤退も検討しましょう。
• Stripeでは購入後メールをカスタマイズできません。
  • 顧客にメールを送るには、他のさまざまな作業が必要になります。

来月の目標

• 本を読んでくれた読者向けの編集割引を整備します。
• 連絡を取るアーリーアクセス購入者のリストを作成します。
• 本の新しい章を公開します。