AIを使って本物のプロダクトを出荷する、しかし本質を見失わない

約30年にわたるソフトウェア開発経験を持つエンジニアが、自身がコーチを務める子供の野球チームでの経験から、ラインナップ管理の煩わしさを解決するアプリ「CalledUp」を開発した。このアプリは、ロスター、スケジュール、ラインナップ、保護者へのメッセージングを一元化し、コーチが本来の指導に集中できるようにする。

開発にあたって、著者は「AIがコードを生成するからアプリが完成する」という昨今の流れに与せず、自らが長期間メンテナンスできることを絶対条件とした。具体的には、データモデルや状態管理、コードの境界といった重要なアーキテクチャ上の決定はすべて自分で行い、AIはその枠組みの中で具体的なコードを書く役割に徹させた。AIを、まだチームのやり方を覚えていないが有能な新人エンジニアのように扱ったのだ。

著者が特に重視したのは、思考と構築の分離である。多くの機能は、グラウンドで練習を見ながらスマートフォンでAIアプリ（Claude）と対話する形で生まれた。「問題点は何か」「コーチなら実際どう使うか」といった会話をするうちに、頭の中で解決策の輪郭が固まる。帰宅後にコードエディタを開いた時には、すでに設計ができている状態だ。この習慣により、設計とコーディングを同時に行うことで生じる「機能するが問題の本質を外した」アウトプットを避けられた。

開発プロセスでは、一度に一つの小さな機能だけを実装した。まずAIに計画を生成させ、それを注意深く読み、疑問があれば修正する。テストもデモではなく、実際にスマートフォンでアプリを起動し、リアルなシナリオで行う。ラインナップを作成し、突然一人の選手を外したときにどうなるかを確認する。テストの基準は「コンパイルが通るか」ではなく、「試合開始1時間前にジェイコブが欠席してもシステムが破綻しないか」だ。

AIの役割は、アイデアから実装までの時間を大幅に短縮することだった。スイフトのボイラープレート、レイアウトのググり、何度も似たようなリストビューを書く作業──これらがかつては一晩かかっていたが、AIのおかげで約1時間に短縮された。この節約された時間が、サイドプロジェクトを完成に導くか、中途半端なブランチで腐らせるかの分かれ目だと著者は言う。

最後に著者は、自分自身が実際に抱える問題から始めること、キーボードに触れる前に思考を済ませること、先輩エンジニアなら決して委任しない決定は自分で行うこと、小規模で誠実に開発を続けること、そして実際に出荷することを勧めている。ツールは確かに強力になったが、リスクはAIが弱いことではなく、強すぎるがゆえに「製品を長持ちさせるために必要な部分をすっ飛ばしてしまう」ことにある。本質を見失わずに、しっかりと構築すべきだと著者は締めくくっている。