コードが書けないQAが、AIと一緒に読書管理アプリを作った話

「この本、読み終わったっけ?」

本棚の前で同じ本を手に取り、首をかしげる。

読書が好きな方なら、一度は覚えがあるのではないでしょうか。

私はこの小さなモヤモヤを解消したくて、読書管理アプリを自分で作りました。

と言っても、私はプログラミングができません。コードは一行も自分で書いていません。コードを書くのはAI。私が担ったのは、「何が欲しいか」を言葉にすること、できたものを実機で検証すること、そして直すべき箇所を判断することでした。

欲しかったのは「読書の現在地」だけ

世の中の読書管理アプリはどれも高機能です。ただ、私が欲しかったのは「自分の読書の"現在地"がひと目でわかること」、それだけでした。読み終わった本はこっち。読んでいる本はこれ。次はこの本から。——「読書予定」「読書中」「読了」の3つのステータスで本を並べる、それだけのシンプルなアプリです。

機能は意図的に最小限に絞りました。記録が目的になったら、読書はいつのまにか義務になってしまいますから。

開発は、AIとの対話の繰り返し

開発のメインパートナーはCodexでした。ところどころでClaudeにも手伝ってもらいました。「こういう画面が欲しい」「この動きは違う」と言葉で伝えると、AIがそれをコードにしてくれる。その繰り返しの中で、頭の中にあった「欲しかったアプリ」が、少しずつ目の前に現れていきました。

初めて画面が思った通りに動いたときの感動はいまでも忘れられません。

いちばん役に立ったのは、QAとしての経験

私はフリーランスでQA(品質保証)の仕事をしています。特に大事にしているのは「失敗は資産。検証が未来を変える。」という考え方。コードは書けなくても、「動かして、壊して、確かめる」ことなら毎日やってきました。

AIは驚くほど優秀ですが、出力を鵜呑みにはできません。生成された画面を実機で触り、バグを見つけては言葉で伝えて直してもらう。アプリ開発とはいえ、やっていたことの半分はQAでした。

この経験を通じて実感したのは、AI時代のものづくりで価値を持つのは「コードを書く力」だけではない、ということです。「欲しいものを言語化する力」と「できたものを検証する力」——この2つがあれば、ものづくりの入口に立てる時代になっていました。

作ったものは、公開してこそ

リリース後も大概バグは見つかる——これも私の信条のひとつです。だからこれで完成とは思っていません。自分で使い、直し、育てていくつもりです。

「プログラミングができないから」とアイデアを寝かせている方がいたら、お伝えしたい。いまは、作れます。欲しいものを言葉にする力と、できたものを疑って確かめる力があれば。

そして後者は、QAという仕事が私に授けてくれたものでした。