ドッグフーディングの再発見

#AI

自作エディタを作り始めた

ここ2ヶ月くらい、自分用のターミナルで動くエディタを自作していた。私は普段Neovimを使用しているが、コーディングをAIを経由して行うようになってから、エディタの使い方が根本的に変わった。コードを直接編集することがかなり減った一方で、コーディングエージェントの台頭以前には頻度が少なかった、同プロジェクト内での並行開発などの操作をするようになった。この編集作業の変化において、Neovimに大きな不満を感じたことはないが、一方でNeovimである必要もないな、と思うことが多くなった。このような理由から脱Neovimを考え始めたが、これだけソフトウェアの生産が楽になっている時代に他人が作った既存のエディタを使い始めても、学びがないしおもしろくない。どうせなら自分用のエディタをイチから作り、作る過程でテキストエディタと周辺のエコシステムの設計に詳しくなってしまおうと思った。

重厚な初期設計に夢を見た

Opus4.5以降くらいから、だいぶコーディングエージェントに丸投げできる領域が増えた。逐一面倒を見なくとも、事前に設計が固まっていれば、ある程度のクオリティのものを作ってくれる。また、開発中にFableも使えるようになり、より一層自動化された開発を夢見ることができてしまうようになった。今回のエディタ開発では、AI時代であれば、重厚な設計を元にAIという下請けにコーディングを任せて放置しておけばある程度のクオリティの成果物が達成できるのではないかという、AI時代以前によく幻想として批判されがちだったものの実現性を検証も行う目的も今回の開発に含めていた。

結果から言うと、その開発手法はうまくいかなかった。

理由は明白で、「小さく始める」、「ドッグフーディング」のどちらも行わなかったからだ。元から私はこの2つとも重要視するタイプではあったが、AIの潮流に惑わされて、ソフトウェアの歴史に学ばない愚かな開発をしてしまっていた。

成果物の使用者が人間である以上、人間によるドッグフーディングが必要であり、 それは開発のなるべく初期からできる必要がある

今回の開発では重厚な設計と要件を完全に実装することが前提のロードマップになっていたため、設計どおりの実装になるまでかなり時間がかかり、実装が達成されるまでの間、ろくにドッグフーディングができなかった。また、多少は実際に動かせるようになったあとでも、設計に含まれるミス、設計内の曖昧性による解釈違いなどによって手直しが必要になり、その手直しをする部分が根幹に関わるような部分だと再び再設計から実装まで行う必要がでてきた。
このような問題はドッグフーディングの有無が原因ではなく、設計がそもそも悪いと言われるかもしれないが、机上だけで設計と実装のコンフリクトに気づいて設計を修正できるのは超人だけである。今回はその超人にAIがなれるかと夢を見たものであるが、夢のままで終わってしまった。
E2Eテストがあればよかったというのも違う。実際、E2Eのテストは開発の初期からできるようにはしていて、そこそこワークしているように見えた。しかし、E2Eテストはあとから見ると筋が悪く、実際のユースケースに即していなかったり、ただpassするためだけのアドホックなテストが多かった。すでに自分が直接E2Eでドッグフーディングできる状況の場合、想定すべきユースケース、テストケースには一定の勘が働くものであるが、何度も書いているようにドッグフーディングができる状況ではなく、かつ事前設計に対する楽観視をしていたため、なかなか不備に気づかないまま進んでしまっていた。
また、ドッグフーディングができていないので、段々と開発のモチベーションが落ちていった。これは個人開発では致命的である。仕事で開発をするのであれば責任が発生するのでモチベーションに関係なく開発をすることになるが、個人開発はモチベーションがなくなってしまったら全くやる意味がない。もし開発しているソフトウェアを自分自身で使っていないのであれば、そのソフトウェアに対する不満や怒りのような、モチベーションのもととなる要素が全く発生することがなくなる。このエディタも結局、モチベーションが復活することなく開発が途絶えることとなった。

もしドッグフーディングが開発初期からできるようなロードマップを組んでいたらこのような問題は起きていなかっただろう。少なくとも私個人にとっては、AI時代にも「ドッグフーディング」や「小さく始める」のようなプラクティスは引き続き有効であることがわかった。とはいえこの感覚すら、モデルの進化でさらに一新される可能性があるので、定期的に同じような検証はしていきたい。