Refactoring English: Month 11

Michael Lynch

Refactoring English:11ヶ月目

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

一言サマリー

公式に遅れています。

初めての方へ

こんにちは、マイケルです。ソフトウェア開発者で、小さなインディー系テック企業をいくつか経営しています。現在はRefactoring English: Effective Writing for Software Developersという本を執筆中です。

毎月、このような振り返り記事を公開して、本の進捗や仕事全体の状況を共有しています。

ハイライト

  • 本の執筆が遅れています。
  • 素晴らしいブログ記事に触発されて、便利なシェルスクリプトについてより深く考えるようになりました。
  • ゲームのOxygen Not Includedが面白いです。

目標の成績表

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

本を読んでくれた人向けの編集割引を用意する

  • 結果: 割引について説明するページを作成した
  • 評価: A

ページ自体は作成しましたが、あえて早期アクセスの特典としては宣伝していません。新規顧客を釣るためではなく、すでに本に熱意を持ってくれている人と仕事がしたいからです。この割引についてここで触れているのは、この毎月の振り返りをわざわざ読んでくれるような方こそ、フリーランスの編集クライアントとしてぜひ迎えたい相手だからです。

標準料金を2倍にし、早期アクセス購入者向けの割引を追加してから、フリーランスの編集依頼は一件も来ていませんが、それはそれで問題ありません。その分、執筆の成果が増えましたし、編集の仕事で執筆が中断されるとしても、金銭的に見合うと感じられるように収支のバランスを取りたいと思っています。

連絡を取る早期アクセス購入者のリストを作る

  • 結果: 連絡できる顧客63名のリストを作成した
  • 評価: A

もっと読者に一対一で連絡を取ろうという目標を何度も立ててきました。連絡先を探すまでの摩擦が大きいことに気づいたので、目標をシンプルにして、連絡するのに適した顧客のリストを作ることだけにしました。基準は次のとおりです。

  1. メールアドレスがGmail/Yahoo/Hotmailなどのフリーメール系ドメインではないこと。
  2. メールアドレスのドメインが、実際に存在するウェブサイトを持っていること。

要するに、相手のウェブサイトを見て、一人ひとりに合わせた独自のメッセージを送れるような読者を探しているのです。このリストをもとに3名に連絡し、うち2名から返信がありました。そのうち1名は先月のライブセッションにも参加してくれました。パーソナライズしたメールが参加のきっかけになったのだと思います。つまり、この1対1のアプローチは引き続き良い結果を生んでいます。あとは、もっと数をこなすだけです。

本の新しい章を公開する

  • 結果: 新しい章を2.5章分公開した
  • 評価: A

“How to Get Meaningful Feedback on Your Design Document”、「Verbs Drive the Sentence」、「Stay Positive」を公開しました。設計ドキュメントの章は厳密には0.5章分で、書籍版では設計ドキュメントに何を盛り込むべきかといった詳細を加えて拡充する予定です。

“How to Get Meaningful Feedback on Your Design Document”は、しばらくぶりの大きな空振りでした。投稿した先のどこでもほとんど反応がありませんでした。刺さるかどうか100%の自信はありませんでしたが、9割方いけるだろうと思っていました。設計ドキュメントの書き方は読者が最も関心のあるトピックの一つだったので、もっと需要があると予想していたのです。

Refactoring Englishの指標

指標2025年9月2025年10月変化
ユニーク訪問者数7,28322,398+15,115 (+208%)
予約販売による収益$484.71$570.75+$86.04 (+18%)
コンサルティングによる収益$429.60$0.00-$429.60 (-100%)
スポンサー収益$48.25$48.25$0.00 (0%)
合計収益$962.56$619.00-$343.56 (-36%)

10月のサイト訪問者数は、3月に大々的に行ったKickstarterキャンペーン以来、最も多い22,398人のユニーク訪問者でした。そのうち93%は、先月公開した“The Software Essays that Shaped Me”経由でした。この記事は思ったような出来にならなかったと感じていたものです。

訪問者数と予約販売数がもっと素直に比例してくれればとは思いますが、それでもブログ記事が本に新しい読者を連れてきてくれているのは嬉しいことです。

遅れています

本を書き始めたときは、2025年10月までには終わると確信していました。余裕を持たせて12月完成と公言しましたが、その余裕すら必要になるとは思っていませんでした。

ところが、実際にはその余裕があってもまだ足りないことがわかりました。

5月には、各章の執筆にかかる時間を見積もって書き出していました。半年経った今、その見積もりはどれくらい正確だったでしょうか。約40%も過小評価していました。

当初は全114時間で完成すると考えていましたが、99時間執筆した現時点での新たな見積もりは157時間です。つまり、完成まであと58時間必要だと見込んでいます。

また、週5時間は執筆できると見積もっていましたが、これも誤りでした。6ヶ月で99時間ということは、週あたり約3.8時間のペースだったことになります。

基本的に、1日に集中して書けるのは最大で1時間です。それ以上書こうとしても生産性はがくんと落ち、2時間目の生産性は1時間目の2割程度に感じます。午後に2時間目をねじ込むこともたまにはありますが、稀なことです。

さらに、しっかりとした執筆時間を確保できない日常的な要因を考慮に入れていませんでした。

  • 本以外の執筆
    • 例:ブログ記事、振り返り、メモなど
  • 育児の急な変更
    • 普段は家族が育児を手伝ってくれていますが、誰かが体調を崩したり予定が合わなくなったりして、代わりが見つからないときは、妻か私が仕事を休んで対応します。
  • フリーランスの編集業務
  • 体調不良
  • 休暇
  • どうしても執筆のやる気が出ない日

今後も週3.8時間ペースで進むと仮定すると、残り58時間を消化するには15.3週間かかります。つまり2026年2月中旬の完成です。余裕を見て、2026年3月末までの完成を目指すことにします。

残りの章については、スケジュールにもっと自信があります。本の前半にある「Get to the Point」(魅力的な導入の書き方について)のような章は、頭の中で曖昧なままになっている思考プロセスを形式化し、洗練させなければならないため難しいのです。一方で、私自身の執筆プロセスや編集者の雇い方といったテーマは、どう考えているかではなく、実際に行っている具体的な行動について説明すればよいので、書きやすいのです。

おすすめ

Evan Hahnの便利スクリプト

先月読んだ中で一番良かった記事は、Evan Hahnの“Scripts I wrote that I use all the time”でした。Evanは開発者としての生活を楽にするために書いたいくつかのスクリプトを紹介しています。特にお気に入りは次のものです。

  • copy: 標準入力から読み取ってシステムのクリップボードに保存する。
    • こんな発想がなかった自分が恥ずかしいです。これまでずっと、マウスでターミナルからコピーするような野蛮なことをしていました。
  • pasta: システムのクリップボードから標準出力に貼り付ける。
  • pastas: システムのクリップボードを監視し、内容が変わるたびに標準出力に出力する。
    • 最初に記事を読んだときは、このスクリプトがどれだけ巧妙かを見落としていました。
    • 片方のターミナルでpastas | wget --input-file=/dev/stdinを実行しておき、ブラウザ側ではクリップボードにURLをコピーし続けると、わざわざ画面を切り替えなくてもpastasコマンドがコピーしたすべてのURLをダウンロードしてくれます。
  • emoji: テキストで絵文字を検索する。emoji coolのように実行すると、「cool」という概念に関連する絵文字をすべて出力してくれます。

Evanのスクリプトの多くは素晴らしいアイデアで、すぐに取り入れました。

さらに重要なのは、この記事のメタな発想です。開発者は、日々のワークフローから摩擦を取り除くスクリプトについて考えるべきだということです。また、そもそも何がスクリプトになりうるのかという認識も広がりました。emojiのようなものは、すべての絵文字とその説明のリストを持っていなかったので、自分ではスクリプトにしようと思わなかったでしょう。でもEvanの記事を読んで、Evanと同じようにリストを生成すれば作れるのだと気づきました。

それに触発されて、私もローカルで動かしているLLMに質問するためのchatスクリプトをPATHに追加しました。コマンドラインツールの使い方を調べるためにわざわざウェブブラウザを開くことがよくあるので、代わりにコマンドラインに留まったままchatに打ち込めるようにしたのです。

#!/usr/bin/env bash

# Read prompt from command-line arg.
PROMPT="$1"

# Add implicit context for the prompt.
PROMPT+=' Assume a Linux OS.'
PROMPT+=' Prefer command-line tools.'
PROMPT+=' Optimize for the simplest possible response.'
PROMPT+=' If there are multiple methods, show me the simplest one.'
PROMPT+=' If possible, show me just a code snippet with no additional explanation.'

# Use a default LLM model but allow the user to override it.
MODEL="${MODEL:-llama3.2:1b}"

ollama run $MODEL "$PROMPT"

例えば昨日は、画像のリサイズ方法を思い出すのに使いました。

とにかく速いです。このプロンプトは私の環境で265ミリ秒で完了したので、ブラウザに切り替えて検索し、答えを探してクリックしてから作業に戻るよりずっと速いのです。

Evanのもう一つの記事である“Why ‘alias’ is my last resort for aliases”は、このスクリプトの話とうまく補完し合っています。シェルのエイリアスを使うよりも、PATH上のフォルダ(例えば~/.local/bin配下)に便利スクリプトを置く方が、より柔軟性が高いと論じています。

Oxygen Not Included

私は普段あまりゲームをしませんが、年に1本だけPCゲームを買います。たいていは10〜20時間で飽きてしまいますが、15〜50ドルで10〜20時間楽しめれば十分元は取れていると思っています。中には25〜100時間も熱中するゲームもあります(Stardew ValleyXCOM2Cyberpunk 2077)。

Oxygen Not Includedは、Andrew KellyとMitchell Hashimotoがどれだけ好きかを語っているのを見て以来、1年近く気になっていました。Andrew Kellyは、システム思考を教えるのにあまりに優れているので、小学校の必修科目にすべきだとまで言っていました。

Oxygen Not Includedでの私の宇宙コロニー

10月にOxygen Not Includedをプレイし始めましたが、本当に面白いです。FactorioやRimworldと比較されるのをよく見ますが、私はその2つはプレイしたことがありません。最も近いと感じるのはStardew Valleyで、特に農業の部分です。どちらのゲームも、何かを生産するシステムを作ろうとします。序盤は原始的な道具しかなく多くの作業を手作業でこなさなければなりませんが、進むにつれてより強力な道具が手に入り、作業を自動化して生産性を高められるようになります。

Oxygen Not Includedの最大の難関は、覚えるのが難しいことです。ゲーム内でいくつかの概念は説明されていますが、多くは試行錯誤で学ばなければなりません。YouTubeのチュートリアルもありますが、奇妙なほど長いです。例えば、やがて配管を作れるようになるのですが、仕組みがわからずYouTubeでチュートリアルを探すと、どれも60分以上あるのです。しかも、百万人規模にスケールするような超複雑な配管を解説しているからで、私がやりたいのはトイレを1つ作るだけなのに、という感じです。

これまで見つけた中で最高のチュートリアルは、Jahwsというプレイヤーが書いたこのガイドです。

Oxygen Not Includedが得意な方、私のコロニーのダメなところを教えてください。

まとめ

何ができたか

学んだこと

  • 本を週5時間も書くことはできない。
    • 本だけを書いている週なら5時間は簡単に確保できるが、割り込みや競合する優先事項が数多くある。

来月の目標

  • 本の新しい章を2つ公開する。
  • 10名の読者に連絡を取る。
  • Refactoring Englishのウェブサイトに人を呼び込むためのツールやブログ記事を作る。

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

コメント