Refactoring English: Month 7

Michael Lynch

『Refactoring English』第7月

一行要約

中途半端なタスクを同時に抱え込みすぎている。

ハイライト

  • 同時に抱えている未完了タスクの数を減らす方法を考える。
  • アーリーリーダーのより多くの人と話す方法を考える。
  • Gleam言語のある設計判断を受け入れられずにいる。

目標の評価

毎月の始めに、達成したいことを宣言しています。目標に対してどれだけできたかは、次のとおりです。

ユーザーがより手間なく私の本を予約購入できるようにする

  • 結果:Kickstarterの予約購入からStripeの決済リンクに切り替えた。
  • 評価:A

最初の先行販売はKickstarterで実施したため、その後の予約購入もそのままKickstarterを使うことにしました。しかし数か月後、Kickstarterでは本を買うために顧客がアカウントを作成しなければならず、それが大きな障壁となって購入をためらわせていることに気づきました。

Stripeへの切り替えは売上に影響したようです。Stripeでは30日間で22件の予約購入があったのに対し、Kickstarterのみだったときはわずか7件でした。ただし、Stripeに切り替えた後に新しいサンプル章も公開したので、完全に同条件の比較ではありません。

本のウェブサイトで新しいサンプル章を公開する

これはLobstersで好意的に受け止められ、Hacker Newsでも好調でしたが、モデレーションによってフロントページから外されました。Hacker Newsのユーザーはマーケティングを強調している点を好まず、フラグを立てたのではないかと思います。

この章では、これまでのどの章よりも有益なフィードバックを得られました。否定的なフィードバックも多くありましたが、批判はもっともだと感じたので、正当に役立ちました。フィードバックをもとに記事を改訂し、議論から新たに2つの節、「製品を簡潔に紹介する」「数値をグラフにする」のアイデアも得ました。

少なくとも10人の読者とビデオ通話で会う

  • 結果:3人の読者とビデオ通話で会った。
  • 評価:D

これは目標を大きく下回りました。問題の一部は、ひと月全体で2回しか通話を予定していなかったことです。しかしもう一つの問題は、実施した通話にアーリーリーダーを十分集められていないことです。

Refactoring Englishの指標

指標が戻ってきました!

以前は毎月、財務情報を公開していましたが、報告する面白い数字がなくなったので、TinyPilotを売却した後はやめていました。先行販売が始まった今、再び共有すべき数字ができました。

指標2025年5月2025年6月変化
ユニークビジター2,9866,574+3,588(+120%)
予約購入による収益$193.20$597.24+$404.04(+209%)
コンサルティングによる収益$0.00$242.45+$242.45(+inf%)
スポンサーによる収益$48.25$48.25$0.00(0%)
総収益$241.45$887.94+$646.49(+268%)

訪問者数の増加が売上の増加につながったのはうれしいですし、特に、訪問数以上の割合で売上が伸びたのは喜ばしいことです。これを維持できるかはわかりませんが、読者が人に薦めたいと思うほど本を楽しんでいることの、よい指標になるでしょう。

同時に抱える下書きを減らすには?

この本でうまくいっている戦略の一つは、毎日少なくとも1時間、「難しい」執筆に取り組むと決めることです。つまり、その1時間をフォーマット調整、文法チェック、校正には使えません。

この戦略はうまく機能しています。6月は、おそらくキャリアのどの月よりも多くのものを公開しました。Refactoring Englishの電子書籍に新しい章を3つ追加し、新しいサンプル章を1つ公開しました。そしてこのブログにも、3本の新しい記事を書きました。

この戦略の問題は、より簡単な執筆タスクを控えることで、文法チェックと校正をすればほぼ完成する記事がたまっていくことです。特に先月は書きかけの文章が多く、何を公開済みで、何に最終編集が必要なのかを把握し続けることに、精神的なリソースを無駄に使っているように感じました。

根本的な問題は、新しいブログ記事を書き始め続けていたことだと思います。単純な答えは、未完成の保留記事がある間は新しい記事を書き始めないことなのかもしれません。

アーリーアクセス読者ともっと話すには?

執筆しながらRefactoring Englishを販売する利点の一つは、未完成の本を予約購入する人は、おそらく平均的な読者よりも特に熱心だということです。読者の疑問に本が答えられていて、読みやすいと感じてもらえるよう、アーリーリーダーと頻繁に話すつもりでした。

実際には、読者とつながるのに苦労しています。サンプル章について短いアンケートを送ったり、フィードバックへの返信を呼びかけたりしましたが、メーリングリスト登録者約1,400人と予約購入者約250人のうち、返答は数件しかありませんでした。

ライブのビデオセッションも始め、講義、ライティングワークショップ、オフィスアワー、人気のソフトウェアブログ記事を題材にした読書会形式の議論など、さまざまなことを試してきました。ライブセッションは楽しく、参加者から優れたフィードバックをもらえています。しかし各回の参加者は読者のうち数人だけで、結局は読者のごく一部にしか届いていないように感じます。

もう一つ、うまくいっているフィードバック源は、1対1の編集フィードバックを購入してくれる顧客です。有料クライアントは3人しかいませんが、彼らと仕事をすると、ターゲット読者がどのような文章上の問題について助けを求めているのかが見えてきます。

これを踏まえ、読者ともっと話すためのアイデアは次のとおりです。

  • 購入後に読者一人ひとりへ連絡し、本から何を学びたいのか、現時点で期待に応えられているかを尋ねる。
  • ライティングコンサルティングのページを少し磨き、より魅力的にする。
  • 学ぶ意欲はあるものの料金を払えない人向けに、割引価格のコンサルティングを提供する。
  • 記事を投稿し続けているものの注目を集められないHacker Newsのユーザーに連絡し、フィードバックのために私を雇うことに興味があるか尋ねる。
  • 「チーム向けに私を予約する」選択肢を用意し、誰かの職場のチームにライティングのトピックを紹介して質問に答えられるようにする。

本のマーケティングを改善するには?

書きかけのブログ記事と同様に、本をマーケティングするためにやりたい簡単なことがたくさんあります。しかし、それらに時間を割り当てていないため、ただ頭の中で場所を取り続けています。

ここに、やり遂げたい手近なタスクを思いつくまま書き出します。

  • ウェブサイトを改善する。
    • faviconを追加する。
    • メーリングリストへの登録ではなく、アーリーアクセスの購入を行動喚起にするようUIを調整する。
    • アーリーアクセスページを改善する。
      • すでに「予約購入」から「アーリーアクセス」へリブランドした。
    • 章数だけではなく、利用可能な章をウェブサイトに表示する。
  • 1年前に収録したブロガーへのインタビューを公開する。
    • これはHit the Front Page of Hacker Newsを再始動する計画のために収録したものです。しかしその製品は結局棚上げにしました。誰かにインタビューを頼んだのに、ずっと公開せず寝かせたままなのが気になっています。
  • 抜粋のウェブ版を電子書籍に移植し、その章をウェブサイト上で完了済みとして印を付ける。
    • 大半は済ませましたが、とても退屈なので先延ばしにしています。ウェブ上の抜粋にはあるものの、まだ電子書籍に組み込んでいない章が3つ残っています。

Gleamでプログラミングしていて、控えめなforループが恋しい

今年は新しいプログラミング言語を学ぼうと思い、Gleamを試しています。昔のAOL Instant Messengerのチャットログをパースするために使っています。ログは次のような形式です。

Session Start (DumbAIMScreenName:Jane): Mon Sep 12 18:44:17 2005
[18:44] Jane: hi
[18:55] Me: hey whats up
Session Close (Jane): Mon Sep 12 18:56:02 2005

Gleamの第一印象については、より長い記事を書きました。それ以降も、さらに何時間かGleamでプログラミングしています。

Gleamで最も調整が難しいことの一つは、ループなしで作業することです。Gleamには意図的にループがありません。代わりに再帰関数を使うか、リストの各要素に対してマッピング関数を呼び出すことになっています。

ループがないことで最も困るのは、チャットログをパース用のトークンに分割しようとするときです。気にしている区切り文字は[' ', '\n', '[', ']']です。コロンも気にしていますが、その直後に単一のスペースが続く場合だけです。つまり、': 'のような場合です。

Goのような言語なら、forループで文字列を反復処理します。スペース文字を見つけたら、直前の文字が:かどうかを確認して、: のケースを処理します。

Gleamではループがないため、多くの葉で同じ複雑な関数コードが重複する、この妙な決定木を作ることになります。

Gleamの設計上の選択には、私が「Gleam流」のことをするとエレガントに感じられるという意味で、興味深いものが多くあります。しかしループについては、単に適切な道具なしで作業しているように感じます。

Gleamの実験は続けますが、Gleamで気に入っている機能を多く備えつつ、私が感じているいくつかの問題点にも対処しているElixirやOCamlも試してみるつもりです。

まとめ

何ができたか?

学んだこと

  • すでに書きかけの記事があるときは、新しいブログ記事を書き始めたい誘惑に抵抗する。
  • うまくいっていることに注力して、読者との会話をもっと増やすべきだ。

来月の目標

  • これまで話したことのない読者と少なくとも10人話す。
  • マーケティングのアイデアのバックログを片付ける。
  • Refactoring Englishの新しい章を公開する。

原文は Michael Lynch により に公開されました。

この記事は「gpt-5.6-terra」を使用して翻訳されました。