Refactoring English:第11か月
一言でまとめると
公式に、遅れが出ています。
初めての方へ
こんにちは、Michaelです。ソフトウェア開発者で、小さなインディーテック企業を経営しています。現在、Refactoring English: Effective Writing for Software Developersという本を執筆中です。
毎月、こうした振り返り記事を公開して、本の進捗や仕事全般の状況を共有しています。
ハイライト
- 本の執筆が遅れています。
- 素晴らしいブログ記事に触発され、便利なシェルスクリプトについて考えるようになりました。
- ゲームのOxygen Not Includedが楽しいです。
目標の自己採点
毎月のはじめに達成したい目標を掲げています。結果は次のとおりでした。
本を読んだ読者向けの編集割引を用意する
- 結果:割引について説明するページを作成しました
- 評価:A
ページ自体は作成しましたが、アーリーアクセスの特典としてはあえて宣伝していません。新しいお客さんを呼び込むよりも、すでに本に熱意を持ってくれている人と仕事がしたいからです。この振り返りで割引について触れているのは、毎月の更新を読んでくれるほど私の活動に関心を持ってくれている方こそ、ぜひ編集のクライアントとしてお迎えしたいと考えているからです。
標準料金を2倍にし、アーリーアクセス購入者向けの割引を設けてから、フリーランスの編集依頼はまだありません。ただ、それで問題ないと思っています。その分、執筆に充てる時間が増えました。編集の仕事で執筆の時間が削られるとしても、金銭的に十分見合うと感じられるバランスにしたいと考えています。
連絡を取るアーリーアクセス購入者のリストを作る
- 結果:連絡可能な63名のリストを作成しました
- 評価:A
読者に個別で連絡を取ることを何度も目標にしてきました。連絡先を探す手間が大きな障壁になっていると気づいたので、今回は目標をシンプルにして、連絡するのに適した購入者のリストを作ることにしました。基準は次のとおりです。
- メールアドレスがGmailやYahoo、Hotmailなど、メール専用ドメインではないこと。
- メールアドレスのドメインで実際のウェブサイトが運営されていること。
要するに、ウェブサイトを見て、その人に合わせた個人的なメッセージを送れる読者を探しているのです。このリストをもとに3名に連絡したところ、2名から返信があり、そのうち1名は先月のライブセッションにも参加してくれました。パーソナライズしたメールが参加につながったのではないかと思っています。1対1の働きかけは引き続き良い結果が出ているので、あとは回数を増やすだけです。
本の新しい章を公開する
- 結果:2.5章分を公開しました
- 評価:A
「設計ドキュメントで有意義なフィードバックを得る方法」、「動詞が文を牽引する」「ポジティブに書く」の3本を公開しました。設計ドキュメントの章は、書籍版では内容を拡充して詳しくする予定なので、現時点では0.5章分として数えています。
「設計ドキュメントで有意義なフィードバックを得る方法」は、久しぶりの空振りでした。どこに投稿してもほとんど反応がありませんでした。100%当たるとは思っていませんでしたが、90%くらいの手応えはあったのです。設計ドキュメントの書き方は読者の関心が高い上位トピックだったので、もっと読まれるだろうと期待していました。
Refactoring Englishの指標
| 指標 | 2025年9月 | 2025年10月 | 変化 |
|---|---|---|---|
| ユニーク訪問者数 | 7,283 | 22,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%が先月公開した「私に影響を与えたソフトウェア・エッセイ」経由でした。この記事は思ったような出来にならなかったと感じていたものです。
訪問者数がそのまま予約数に直結すればいいのですが、そううまくはいきません。それでも、ブログ記事が本に新しい読者を連れてきてくれているのは嬉しいことです。
遅れています
執筆を始めたときは、2025年10月には完成すると自信を持っていました。余裕を見て12月完成と公表しましたが、その余裕は使わずに済むだろうと思っていました。
ところが、余裕が必要だったばかりか、さらに遅れが出ています。
5月に各章の執筆にかかる時間を見積もって書き出したのですが、6か月経った今、その見積もりはどれくらい正確だったでしょうか。答えは、約40%も過小評価していました。
当初は114時間で完成すると考えていましたが、99時間書き進めた現時点での見積もりは157時間です。つまり、完成まであと58時間必要ということになります。
週5時間は書けるだろうとも見積もっていましたが、これも外れでした。6か月で99時間ということは、週あたり約3.8時間のペースです。
基本的に、集中して書けるのは1日1時間が上限です。それ以上書こうとしても生産性ががくっと落ち、2時間目の効率は1時間目の20%程度に感じます。午後に追加で1時間を確保できることもありますが、稀です。
また、執筆の時間を確保できない日常的な要因も考慮していませんでした。
- 本以外の執筆
- 例:ブログ記事、振り返り、メモなど
- 育児の予定変更
- 普段は家族が育児を手伝ってくれますが、誰かが体調を崩したり都合がつかなかったりして代わりが見つからないときは、妻か私が休みを取って対応します。
- フリーランスの編集作業
- 同じ日に両方をこなすのは難しいと感じています。
- 体調不良
- 休暇
- どうしても書く気になれない日
今と同じ週3.8時間のペースが続くと仮定すると、残り58時間を終えるのに15.3週間かかります。つまり2026年2月中旬の完成です。余裕を見て、2026年3月末の完成を目標にします。
残りの章については、スケジュールの見通しに以前より自信を持っています。冒頭の「要点を突く」(魅力的な導入の書き方について)のような章は、頭の中で曖昧な思考プロセスを言語化し、磨き上げなければならないため難易度が高いのです。一方で、私自身の執筆プロセスや編集者の雇い方といったテーマは、考え方ではなく具体的な行動を説明すればよいので、ずっと書きやすくなります。
おすすめ
Evan Hahnの便利スクリプト
先月読んだ中で一番良かった記事は、Evan Hahnの「いつも使っている自作スクリプト」でした。開発者としての生活を楽にするために作ったスクリプトをいくつか紹介しています。特にお気に入りは次のものです。
copy:標準入力から読み取り、システムのクリップボードに保存します。- 恥ずかしながら、この発想はまったくありませんでした。今までずっとターミナルではマウスでコピーするという野蛮な方法をとっていました。
pasta:システムのクリップボードから標準出力へ出力します。pastas:システムのクリップボードを監視し、変更があるたびに標準出力へ出力します。- 最初に記事を読んだときは、このスクリプトがどれほど賢いかを見逃していました。
- 1つのターミナルで
pastas | wget --input-file=/dev/stdinを実行しておき、ブラウザ側ではURLをクリップボードにコピーし続けるだけで、ターミナルを行き来することなく、コピーしたすべてのURLをpastasがダウンロードしてくれます。
emoji:テキストで絵文字を検索します。たとえばemoji coolと打つと、「cool」に関連する絵文字がすべて表示されます。
Evanのスクリプトには素晴らしいアイデアが多く、すぐにいくつか取り入れました。
さらに重要だったのは、記事の根底にある考え方です。開発者は日々のワークフローから摩擦を取り除くスクリプトを考えるべきだという発想です。何がスクリプトになり得るかという視野も広がりました。たとえばemojiのようなものは、すべての絵文字とその説明のリストを持っていないので自分では作ろうと思わなかったでしょう。しかし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のもう一つの記事「なぜエイリアスに alias を最後の手段としてしか使わないのか」も、便利スクリプトの話とよく響き合います。便利スクリプトをPATH上のフォルダ(例:~/.local/bin)に置く方が、シェルのエイリアスを使うより柔軟性が高いと論じています。
Oxygen Not Included
私は熱心なゲーマーではありませんが、年に1本はPCゲームを買います。1本あたり大体10〜20時間で飽きてしまうのですが、15〜50ドルでそれだけ楽しめれば十分元は取れていると思っています。中には25〜100時間も熱中するゲームもあります(Stardew Valley、XCOM2、Cyberpunk 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が得意な方がいれば、私のコロニーでやらかしているおかしな点をぜひ教えてください。
まとめ
できたこと
- 「設計ドキュメントで有意義なフィードバックを得る方法」を公開しました
- 設計ドキュメントについて、アーリーアクセス読者向けのライブ配信を行いました。
- 「動詞が文を牽引する」「ポジティブに書く」の2つの新しい章を公開しました。
- 「Litestream 0.5.0は見送りを」を公開しました
- 「JavaScriptで私のブログを読む」を公開しました
学んだこと
- 本の執筆に週5時間は確保できません。
- 本だけを書く週なら5時間は難なく確保できますが、割り込みや競合する優先事項が数多くあります。
来月の目標
- 本の新しい章を2つ公開する。
- 10名の読者に連絡を取る。
- Refactoring Englishのサイトへ人を集めるツールまたはブログ記事を作る。
記事をランダムに読む