方向転換

赤ちゃんひとり、iPhone一台、一週間

一週間ほど前、カロリーや減量、トレーニングの目標を記録するシンプルなiOSアプリ Ultimate Kami を作り始めました。生後4週間の息子の世話を しながら、住宅ローンの契約手続きを しながら、料理や掃除を しながら、1週間でApple App Storeでのリリースまでこぎつけました。開発の95%はiPhone上で Claude Remote Control と Wispr Flow を使って進めました。その多くは、小さな息子を腕に抱いて寝かしつけながらです。

namagen を開発したときのやり方とはあまりにも対照的で、「僕たちはもう未来に生きているんだ」と感じる瞬間がありました。自然な話し言葉で開発するというのは、完全なパラダイムシフトです。

指示はすべて普通の英語で話すだけ。タイピングもせず、コードを一行も見ることもありません。Ultimate Kami をリリースできる状態まで持っていけたその驚くほどのスピードに、ソフトウェアづくりへの自分の向き合い方を根本から問い直すことになりました。

情熱は報われない

namagen とは違って、Ultimate Kami は最初から情熱プロジェクトになるようなものではありませんでした。存在理由は、シンプルだけれど具体的な問題をいくつか解決すること。ところが、まったく馴染みのない開発方法で、それをあまりにも速く、完璧に解決できてしまったので、心の底から揺さぶられました。これを AI精神病 と呼ぶ人もいるかもしれません。でも、それはどうでもいいことです。大事なのは、プロセスから十分に距離を置けたことで、本当の問題に集中できたということです。

開発と改善のサイクルがとても短かったので、プロジェクトを始めてわずか1日か2日で実際の生活の中で試し、そこで得た自分自身のフィードバックをすぐに反映できました。それに比べて、情熱プロジェクト である namagen は、テストができて 実際に使える 状態にするまで、文字通り何年もかかっています。

問題に恋をする

namagen は最初から Handmade の哲学 に沿って作ってきました。ライブラリは最小限にとどめ、すべてをゼロから書いています。サンプル単位のDSPから全体のアーキテクチャ、データ構造、メモリ割り当て、シリアライズまで、コードのあらゆる部分を本当に隅々まで理解していました。独自のプログラミング言語とVM、マルチスレッドの同期とシリアライズ、オーディオ処理、2Dレンダラーと無限キャンバス、そしてイミディエイトモードUI ライブラリも自分で実装しました。それもすべて、エージェント型のコーディングツールを使わずにです。この開発はとてつもなく学びの多い経験で、心から誇りに思えるものができました。ほんの少し前までは、技術的に自分にできるとすら思っていなかったものです。

でも、そこにこそ問題がありました。僕は、実際のユーザーが抱える実際の問題を解決することよりも、作業そのものに、そして技術に恋をしていたのです。今は、何かを作るために全力を注ぎ、とんでもない時間を捧げる前に、まずアイデアを検証し、ユーザーのためにどんな問題を解決しようとしているのかを見極め、必要なら早めに失敗するべきだと確信しています。

これはエージェントを使うこととはあまり関係のない話かもしれません。それでも、問題に恋をすることと、物事を片付けることに恋をすることの違いは、エージェントによってさらに際立つようになったと思います。同じように、改善サイクルが数日で回る世界と比べると、何か月、あるいは何週間もかかるやり方では、Handmade の哲学 を正当化するのは難しくなります。

人が欲しがるソフトウェアを作って売ることで成功したいなら、やり方を大きく変える必要がある。そう決めました。作業に恋をしたり、一つの問題に時間をかけすぎたり、技術的には満足のいく結果が得られてもユーザーにとっての効果がどんどん薄れていくような深みにはまったりすることは、できるだけ避けるつもりです。

顧客とプロダクトを中心に考えるよう、自分に課しています。人がお金を払ってでも解決したいと思う問題を見つけます。大人になってからのほとんどを筋金入りのエンジニアとして過ごしてきた人間にとって、これはまったく違うアプローチです。

エンジニアからマネージャーへ

コーディングエージェントを使うということは、エンジニアの帽子を脱ぎ、マネージャーになることを受け入れるということです。エージェントは、頼んだ仕事を何でも疲れ知らずにこなしてくれる、24時間いつでも動けるプログラマーのチームのようなものです。マネージャーとしては、自分でコードを書いた場合と同じレベルのコントロールはまず得られないという事実を受け入れなければなりません。それでも、チームのプログラマーたちに並行してタスクを割り振り、それによる効率の向上を得られるなら、そのトレードオフには十分価値があります。エージェントが本領を発揮するのは、まさにここです。

チームと普通の英語でやり取りできるのも、ものすごく大きな利点です。英語は情報が抜け落ちやすく曖昧さだらけなので、それに伴う不正確さは受け入れるしかありません。でも、簡潔で容赦がなく、間違いやすいプログラミング言語で作業する必要はもうないのです。

多くのエンジニアにとって、これがなかなか受け入れがたいのもよくわかります。仕事の中身そのものがまるごと変わってしまうのですから。

筋金入りのエンジニアの中には、切り替えがほぼ不可能な人もいるでしょう。何でも自分でやりたい、第三者(他人、外部ライブラリ、エージェント)を信頼できない、というエンジニアの考え方を覆すのは簡単ではありません。ものづくりの技そのものを愛している人たちには、気の毒に思います。この革命が本格的に加速していく中で、結局損をするのは彼らだからです。僕たちはまだ何も見ていない。そう確信しています。

とはいえ、特定の分野に関する深いエンジニアリングの知識は、エージェントと仕事をするうえで大きな強みになります。エンジニアリングとプロセスを深く理解しているマネージャーは話がずっと通じやすく、たいていプログラマーのチームからはるかに良い結果を引き出せます。エージェントについても同じことが言えると思っています。

ミニマム・バイアブルな事業

数多くのミニマム・バイアブルな事業を次々と試していくことを、自分への挑戦にしています。エージェントがあれば、はるかに野心的な事業をずっと短い時間で作れるようになったと思っています。数日でアイデアを形にして、試してみて、追い風があるかを見極め、あればそこに力を入れる。Ultimate Kami はその最初の一歩です。

ここから先は、アウトプットを続け、アイデアをユーザーや商業的に成り立つプロダクトへと送り込み続けられれば、うまくいく何かにきっと出会えるはずです。失敗を目指せ という昔からの格言はまさにぴったりで、そのほうがずっと良いやり方だと思います。改善サイクルを短くし、ユーザーの需要を確かめ、需要がなければ学びとして受け止めて次のアイデアに進む。

それに比べて namagen は、6年かけて作ってきたもので、サンクコストがあまりにも大きすぎて、諦めることを考えるだけでほとんど耐えられません。その差は歴然としていて、エージェントの時代 においてはなおさら、千倍もの違いがあります。

このページは英語の原文を AI で翻訳したものです。原文（English）