要件定義よりまず試作で作る、動かす作り方

息子に触らせてから作る、に変えたら開発が変わった

息子向けのアプリをいくつか作っています。知育系のAndroidアプリで、今のところ一般公開はしていません。完全に家庭内向けの、息子専用のアプリたちです。

—

最初は普通に「仕様を考えてから作る」をやっていた

最初のうちは、ちゃんと考えてから作っていました。「こういう操作にしよう」「このボタンはここに置こう」「クリアしたらこういう演出にしよう」——頭の中で組み立てて、それをコードに落としていく、いわゆる普通の順番です。

でも完成したものを息子（小1）に触らせると、だいたい想定外の使い方をされます。

ボタンを連打する。関係ないところを押しまくる。クリア演出を何度も見たくて、わざと間違え続ける。

こっちが「こう使うだろう」と思っていた動線を、まったく無視してくれます。

—

「とりあえず触らせる」に変えた

あるときから、順番を逆にしました。

最初に完成度の高いものを作るのをやめて、まず動くだけのものを作ります。見た目は雑でいい。細かい演出もなくていい。「一応動く」状態になったら、すぐ息子に渡します。

そこで何が起きるかを見てから、本格的に作り直す。

これに変えてから、明らかに作るものの精度が上がりました。「使われない機能」を最初から作り込まなくて済むようになりました。

—

Claude CodeとCodexが、この進め方を現実的にしてくれた

このやり方が自分にとって機能するようになったのは、AIコーディングツールを使い始めてからだと思います。

自分はいわゆるバイブコーディングで開発していて、コードはほぼ自分で書きません。Claude CodeやCodexに仕様を伝えて、出てきたものを確認・調整するスタイルです。

このスタイルだと、試作のスピードが速い。「とりあえず動くもの」を作るコストが低いから、「まず触らせてみる」が気軽にできます。

以前なら「ちゃんと作ってから渡そう」と思っていたのが、今は「雑でいいからとりあえず渡す」に変わりました。

—

要件定義より先に、本人の反応を見る

エンジニアリングの文脈では「要件定義が大事」という話をよく聞きます。何を作るかを明確にしてから作り始める、という考え方です。

でも息子相手だと、そもそも本人が「何が楽しいか」を事前に言語化できません。触ってみて初めて「これ楽しい」「これつまらない」が出てきます。

だから要件定義より先に、本人の反応を見るしかない。

これはたぶん、プロの開発でも本質は同じで、あすけんのような企業でも「動く試作を先に作ってユーザーに触らせる」という方向に動いているらしいです。AIによって試作コストが下がったことで、こういう開発の進め方が現実的になってきているんだと思います。

—

個人開発だからこそできること

ユーザーが息子一人、というのは制約のように見えて、実はすごく贅沢な環境です。

フィードバックが即座にもらえます。「つまらない」という反応もすぐわかります。修正してまた渡す、というサイクルが同じ日のうちに回せます。

AIで試作を爆速で作れるようになって、個人開発のこういう小回りの良さが、以前より活きるようになってきた気がしています。

「完成してから渡す」より「渡してから完成させる」——この順番の変化が、今の自分の開発スタイルの中心になっています。