Refactoring English: Month 7

Michael Lynch

Refactoring English:7ヶ月目

原文は Michael Lynch により に公開されました。 このブログを購読する

一言でまとめると

中途半端なタスクを抱えすぎている。

ハイライト

  • 抱えている中途半端なタスクの数を減らす方法を模索した。
  • アーリーリーダーのより多くの人と対話する方法を考えた。
  • Gleam言語のある設計判断にどうしても納得できなかった。

目標の達成度

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

本の予約購入をもっと手軽にできるようにする

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

最初の先行販売はKickstarterで行ったので、そのまま継続して使おうと決めていた。ところが数ヶ月経って、Kickstarterでは本を買うのにアカウント作成が必須で、これが大きな摩擦になって購入をためらわせていることに気づいた。

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

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

この章はLobstersで好評を得て、Hacker Newsでも好調だったが、モデレーションによりフロントページから外された。Hacker Newsのユーザーにはマーケティング色が強い点が不評で、通報されたのだろうと思う。

この章では、これまでのどの章よりも有用なフィードバックをもらえた。否定的なものも多かったが、指摘はいずれももっともで、純粋に役に立った。フィードバックを踏まえて記事を修正し、議論の中から新たに2つのセクション(“Briefly introduce your product”“Turn your numbers into graphs”)のアイデアも得られた。

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

  • 結果:ビデオ通話で会えたのは3人だった。
  • 評価:D

目標には遠く及ばなかった。原因のひとつは、1ヶ月で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対1の編集フィードバックを購入してくれたクライアントだ。有料クライアントは3人だけだが、彼らと一緒に作業することで、ターゲット読者がどんなライティングの悩みについて助けを求めているのかが見えてくる。

これらを踏まえ、読者ともっと対話するためのアイデアを挙げてみた:

  • 購入後に読者一人ひとりに連絡を取り、本から何を学びたいのか、これまでの内容が期待に沿っているかを聞く。
  • ライティング・コンサルティングのページを磨いて、より魅力的にする。
  • 学ぶ意欲はあるが料金を払えない人向けに、割引価格のコンサルティングを提供する。
  • Hacker Newsで何度も記事を投稿しているのに伸び悩んでいるユーザーに声をかけ、フィードバックの依頼に興味がないか聞いてみる。
  • 「チーム向けに呼んでください」的なメニューを用意し、職場のチームに向けてライティングのテーマで話をしたり、質問に答えたりする。

本のマーケティングをどう改善できるか?

書きかけのブログ記事と同様に、本を宣伝するためにやりたい簡単なことがたくさんあるのに、時間を確保できていないため、ずっと頭の中で場所を取り続けている。

やりたい低コストで効果の高いタスクを、思いつくままに書き出してみた:

  • ウェブサイトを改善する。
    • faviconを追加する。
    • CTAがメルマガ登録ではなくアーリーアクセスの購入になるようにUIを調整する。
    • アーリーアクセスページを改善する。
      • すでに「pre-order(予約販売)」から「early access(アーリーアクセス)」へ名称を変更した。
    • ウェブサイトで、利用可能な章の数だけでなく、どの章が利用可能かを表示する。
  • 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での実験は続けるつもりだが、ElixirやOCamlも試してみようと思っている。Gleamで気に入っている多くの機能を持ちつつ、自分の不満点を解消してくれそうだからだ。

まとめ

何を成し遂げたか?

学んだこと

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

来月の目標

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

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。

コメント