一行まとめ

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

ハイライト

• 本の全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件報告しました。動画での概念実証を求められたので、5月29日に作成して送ったところ、連絡を待つように言われました。

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

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

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

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

当初は、読者からのフィードバックをもとに継続的に本を編集していく計画でした。そうすれば、最終章に到達したときには、他の章が読者のコメントによって何度も改稿されているため、本はほぼ完成しているはずでした。

しかし実際には、想定していたよりずっとフィードバックを反映できませんでした。

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

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

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

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

読者フィードバック用ツール

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

Help this Bookという、読者が電子書籍上で直接フィードバックを送れるウェブアプリの発想は気に入っています。ただ、すべてのフィードバックをサードパーティに預けて毎月利用料を払い続けることはしたくありませんでした。

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

AIプロジェクトと大きな壁

全体として、プログラミングではAIによって生産性が上がっていると感じています。gitのマージコンフリクトの解消、馴染みのないコードのデバッグ、シンプルなツール作成など、AIが明らかに役立つ作業もあります。

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

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

半年前は、作りたいものの概要をざっくりAIエージェントに渡して、基本的なv1を実装させるようにしていました。出力が雑になることは分かっていましたが、所詮プロトタイプなので、自分のプログラミング感覚に合うまでフィードバックを重ねればよいと考えていました。

しかし、出来の悪いプロトタイプを綺麗にするのは想像以上に難しいことが分かりました。プロトタイプが一定以上ひどくなると、そもそもコードが何をしようとしているのかを解きほぐすこと自体が困難になります。

AIには、既にあるコードを正当化しようとする奇妙なバイアスがあるように感じます。あるコンポーネントが同じデータを3回もループしていて分かりにくいと指摘しても、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ができてしまうので、作ること自体に痛みがありません。そして、その巨大なPRに対して改善の指示を出して前進している気分にもなれますが、変更が大きすぎるせいで、どの部分を切り出して小さな変更にできるのかを見極めるのが難しくなります。

複雑な変更で巨大で手に負えないPRがいかに簡単に生成されてしまうかが分かった今、AIの使い方を変えて、機能をより小さな変更へ分割することに前もって力を注ぐようにできます。

まとめ

今月できたこと

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

学んだこと

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

来月の目標

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