一言まとめ

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

ハイライト

• 投資もリターンも小さめのブログ投稿を試しています。
• 本を読んでくれた人に絞ってフリーランス編集の戦略を調整しています。
• Hacker Newsのトップページに載る確率についての直感が大きく外れていました。

目標の成績

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

Refactoring Englishのウェブサイトに新しい読者を呼び込む何かを公開する

• 結果: 「The Software Essays that Shaped Me」を公開し、最初の3日間で1万6千人の読者を集めました
• 評価: 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週間程度に抑えられます。

丁寧に扱うべきテーマを手抜きで済ませたいわけではありません。むしろ、簡単にカバーできるテーマを取り上げて、どうなるか試してみたいのです。

最初のバントは、「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のトップページから落ちた翌朝に目が覚めて、ふと気づきました。本の宣伝を入れていなかったのです！

本のウェブサイトにあるサンプル章には、すべてこのテーマで本を書いていて早期アクセスを購入できることを知らせる小さな自己宣伝が入っています。

ブログ投稿にその自己宣伝を入れ忘れたため、最初の1万4千人の読者は私が本を書いていることを知らないまま記事を読んだことになります。しまった！

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

フリーランス編集へのアプローチを調整する

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

難点は、編集にコストがかかることです。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を再送すると、Stripeは新しいバージョンを使うと主張しながら、実際には古いAPIバージョンを使い続けます。
• checkout.session.completedに対するStripeの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では購入後のメールをカスタマイズできない。
  • 顧客にメールを送るには、他にもいろいろやる必要がある。

来月の目標

• 本を読んだ読者向けの編集割引を設定する。
• 連絡を取る早期アクセス顧客のリストを作成する。
• 本の新しい章を公開する。