一言でまとめると

本が完成しました！ まあ、一応は。

ハイライト

• 本の全22章を書き上げました。
• AIのおかげでプロトタイピングが速くなると思っていましたが、今はそうとも限らないと感じています。

目標の自己評価

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

Refactoring Englishを「内容完成」まで持っていく

• 結果: 全章を完成させました。
• 評価: A

6週間にわたって「あと1週間で終わる」という感覚が続いていたので、ようやく全章を書き終えてほっとしています。

Refactoring Englishの読者が読みながらフィードバックできるツールを作る

• 結果: ツールは40%ほどしか完成していません。
• 評価: C

本来2〜3日で終わるはずのプロジェクトに思えましたが、思ったよりずっと難航しました。特に巨大な壁が原因です。

Refactoring Englishの指標

うわっ、相変わらずマーケティングをサボっているので、数字にもろに表れています。

最後の数章をとにかく書き上げたくて、マーケティングに投資するよりも執筆だけに集中しました。

バグバウンティの指標

セキュリティのバグバウンティは続けていますが、かける時間は減らしました。計画していた70/30の配分にはなっていませんが、だいたい60/40くらいでしょうか。

メインで取り組んでいるベンダーからは、今回さらに7,000ドルが支払われ、これで合計17,000ドルになりました。ただ、レポートの処理が遅くなってきたので、新たにバグを探すのはほとんどやめています。

他にバグレポートの対応が早いプログラムがないか、いくつか別のプログラムにも報告してみましたが、どこも早くはありませんでした。

• KeePassXC — 5月18日にZero Day Initiative経由でRCEを報告しましたが、まだ返答がありません。
  • KeePassXCのユーザーの皆さん、これはゼロクリック攻撃や、悪意のあるサイトを訪れただけでデータベースが侵害されるようなものではないので、あまり心配しないでください。
• Cloudflare — 5月22日にHackerOne経由でDoS／ロジックバイパスを報告しました。返答なしです。
• Proton — 軽微な問題を1件報告しました。動画での概念実証（PoC）を求められたので、5月29日に作成して送りましたが、「連絡を待ってほしい」とのことでした。

本はいつ「完成」するのか

本の全章を書き終えてほっとしていますが、まだ正式に「完成」とは考えていません。

この1年半、基本的に1章ずつに集中して書いてきたので、自分の本を通しで読んで全体の一貫性を確認したことが一度もありません。「完成」と呼ぶ前に、少なくとも数回は通読したいと思っています。

なぜ継続的に改稿しなかったのか

当初は、読者からのフィードバックをもとに本を継続的に編集していく予定でした。そうすれば最終章にたどり着いたときには、すでに読者のコメントを反映して何度も改稿を重ねているので、ほぼ完成状態になっているはずでした。

しかし実際には、読者のフィードバックを想定よりずっと取り入れられませんでした。

過去の章の改稿と新しい章の執筆で意識を切り替えるのが難しかったのです。1週間かけて過去の章を直しても、前進している感覚が得られませんでした。一方で新しい章を追加すれば、公開している進捗メーターが少し進むので、モチベーションになりました。

継続的に改稿しなかったもう一つの理由は、計画していたほど読者に働きかけなかったことです。常に本の進捗に遅れを感じていたので、「この章を出してからそのあとで読者への働きかけにもっと力を入れよう」という気持ちがずっとありました。

ただ、読者に働きかけても、本の内容に反映されることはめったにありませんでした。読者から最も多かった反応は「本が気に入ったよ」か「まだ読み始めていない」でした。

詳細なフィードバックをもらえたときも、それをどう活かせばいいか迷うことがありました。内容に納得できれば判断は簡単でしたが、多くの場合は、自分では不要だと思う内容の追加を提案されることが多かったのです。読者が間違っているというわけではありませんが、自分の直感に反してまで取り入れるなら、複数の読者に共通する傾向を見たいところです。しかし、傾向が見えるほど十分なフィードバックは得られていませんでした。

自作の読者フィードバックツール

全章を書き終えた今は、読者にもっと働きかける余裕が出てきたと感じています。

Help this Bookという、読者が電子書籍の中で直接フィードバックできるウェブアプリの発想は気に入っています。ただ、すべてのフィードバックをサードパーティに預けて毎月利用料を払うのは避けたかったのです。

Julia Evansさんが自分のプロダクト用にカスタマイズした読者フィードバックツールを自作していたのを見て、いいなと思い、自分でも取り組んでいるところです。

AIプロジェクトと「巨大な壁」

全体として、プログラミングにおいてAIは自分の生産性を上げてくれると感じています。gitのマージコンフリクトの解消や、見慣れないコードのデバッグ、シンプルなツールの作成など、明らかにAIが有利なタスクもあります。

以前は、AIはプロジェクトの立ち上げにすごく役立つと思っていました。でも今はそうとも言い切れません。私は「巨大な壁」と呼んでいるものに何度もぶつかっているのです。

とりあえずAIにプロトタイプを作らせる

半年前は、AIエージェントにやりたいことの概要を高いレベルで伝えて、基本的なv1の実装を作らせるようにしていました。出力が雑になるのはわかっていましたが、所詮プロトタイプなので、自分のプログラミング感覚に合うまでフィードバックを繰り返せばいいと考えていました。

ところが、できの悪いプロトタイプをきれいにするのは想像以上に難しいことがわかりました。ある程度ひどくなると、そのコードがそもそも何をしようとしているのかを解きほぐすことすら困難になります。

AIには、すでにあるコードを正当化しようとする奇妙なバイアスがあるようです。あるコンポーネントが同じデータを3回もループしているから分かりにくいと指摘しても、AIはXやY、Zのせいで3回ループする必要があると主張し続けます。そもそもX、Y、Zが人為的な制約なのではないか、とは決して問いません。

これが「壁」です。AIが作った分かりにくいコードの巨大な壁を乗り越えようとして、立ち往生してしまうのです。

核となるロジックを直さなければ、問題はどんどん悪化します。コードの悪臭はカビのように増殖してコードベース全体に広がります。脆弱な基盤の上に構築を続け、AIはすでに存在する悪いパターンをただ複製し続けるのです。

プロトタイプを小さく分割する

なら簡単な解決策があります。AIエージェントにプロトタイプをより小さな単位で作らせるのです。AIを短く繋いで、あまり脇道にそれられないようにします。AIにプロトタイプ全体を作らせるのではなく、まずはウェルカムページから始める。それをレビューしてマージできたら、次はシンプルな機能を一つ追加する、といった具合です。

これは認証のような複雑な塊に行き当たるまではうまくいきます。AIが2,000〜5,000行にも及ぶ分かりにくいコードのプルリクエストを作り、それが巨大な壁になるのです。これ以上機能を分割する方法が思いつかず、巨大なPRを抱えてまたしても「巨大な壁」に阻まれます。

4,000行の変更は、400行の変更に比べてレビューに20倍も時間がかかるだけでなく、より長いまとまったレビュー時間も必要になります。20分の空き時間があれば400行の変更には取り組めますが、4,000行の変更ではコンテキストを把握するだけで20分かかります。コンテキスト切り替えのロスで大半を無駄にせず、4,000行の変更で意味のある進捗を出すには90分のまとまった時間が必要ですが、特に週末プロジェクトではそんな時間を確保するのは困難です。

例：Little Momentsの認証実装

例を挙げましょう。Little Momentsでは、認証をマジックログインのメールで行っています。何週間も、この機能をデッドコードや壊れた機能を持ち込まずに分割する方法が思いつきませんでした。ログインの流れを半分だけ実装するなんてできないと思っていたのです。

巨大なPRを何週間も少しずつ削っていくうちに、実はログインの半分なら実装できることに気づきました。私が別にメンテナンスしているPicoShareにはシンプルな認証フローがあります。このアプリは単一の許可されたユーザーを想定しているため、認証はユーザー名／パスワードの組み合わせですらなく、単なるパスフレーズです。認証なしの状態からいきなりメールベースの認証に大きく切り替えるのではなく、認証なしからパスフレーズ認証へと段階を踏めるのです。

そこで、まずパスフレーズ認証を動くようにしました。しかし、パスフレーズからマジックメールログインへの移行は依然としてかなり大規模なPRで、レビューに何週間もかかりそうでした。数日間いじっているうちに、さらに分割できることに気づきました。

実際にログインリンクをメールで送る代わりに、本来送るはずだったリンクへユーザーを即座にリダイレクトするようにしたのです。これでも1,700行のPRになりましたが、実際にメールを送るよりは管理しやすくなりました。そして、実際にメールを送信する部分は、わずか1,000行にまで抑えられました。

AIがこれをより難しくする理由

こうした作業でAIが本当にプラスになっているのか疑問に思う理由は、AIを使っていなければ問題を分割するこうした機会に気づけていたはずだとわかっているからです。自分で4,000行のPRを作ってから「うーん、これはかなり大きいな」と言うことは絶対にありません。PRが大きくなるにつれて扱いがどんどん面倒になるので、自然と変更をより小さく分割する機会が見えてくるのです。

AIはその自然なフィードバックループを断ち切ってしまいます。AIなら、メールをチェックしている2分の間に4,000行のPRができあがるので、作ること自体に苦痛がありません。そして4,000行のPRに簡単に修正指示を出して、進捗している気にもなれます。でも変更が大きすぎると、どの部分を切り出して独立した小さな変更にできるのかを見極めるのが難しくなります。

複雑な変更で巨大で管理不能なPRがいかに簡単に生成されてしまうかがわかった今、AIの使い方を変えて、機能をより細かく分割することにもっと初期段階から投資できるようになりました。

まとめ

何ができたか

• 本の残りの章を公開した。
• 本のフィードバックアプリの部分的なプロトタイプを作った。
• Little Momentsの認証を部分的に実装した。
• PicoShareの新リリースを2回出した。

学んだこと

• AIを使うと、ソフトウェアをより小さな単位で作ろうとする自然なフィードバックサイクルが失われる。
  • 解決策は、複雑な機能のライフサイクルのより早い段階で分割に一層力を入れ、AIの出力をより厳しくチェックすることだと思う。

来月の目標

• Refactoring Englishのウェブサイト改善に少なくとも5時間投資する。
• Refactoring Englishのウェブサイトに3万人のユニーク訪問者を集める。
• 読者フィードバックツールを完成させる。