AIだけに会議させて“売れるアプリの仕様書”作らせてみた【仕様書編】

アプリって、思いつきで作り始めるとだいたい途中で詰まります。

大事なのは仕様書

つまりアプリの設計図です。

これが細部までしっかり作りこまれていると実装までの時間も短縮されるし

デバッグも楽になります。

⌛この記事の読了時間：約3分

AIに仕様書作らせたら“完成してた”

前回、AIに会議させて

「意識高い系ごっこタイマー」

というアプリ案が決まりました。（笑）

👇前回記事はこちら

僕が決めた条件は、ざっくりこれだけです。

くだらない。
ちょっと笑える。
でも少し便利。
しかも1日で作れること。

次にやったのが、仕様書をAIに作らせることでした。

出てきたのは、予想以上にきれいな仕様書でした。
集中タイマー、名言テロップ、環境音。
最小構成に絞られていて、
「1日で作る」という条件にも素直に従っている。

この時点で正直こう思ったんです。

「めっちゃしっかりした仕様書、書いてくるやん！」

実際の仕様書👇

人間が仕様を考えると、
どうしても足し算になります。

これも入れたい、あれもあれば便利、ついでにこれも。

人間って欲張りな生き物・・・

でもAIは逆でした。

成立するものだけ残す。

あっさり削ってくる。（笑）

触ってみたら、正直「うーん・・・」

ただ、ここで「AIすごい」で終わらなかったのが今回のポイントです。

最初の仕様書をもとに、
実際にMVPを作ってみました。👇

触ってみた感想を正直に言うと。

・・・全く面白くなかった。（笑）
正直、この時点では“ちゃんとしてるだけ”

使えなくはない。
タイマーとしては成立している。
うん。でも、それだけ。

無難。普通。。。
ちゃんとしてるけど・・・
いやコレ、誰かに見せたいとはならんやろ！🫲

今回の企画って
「くだらないけど笑えるちょっと便利なアプリ」
を作る実験でした。

なのに、できたものはちゃんとしすぎてた。

原因はわりと明確でした。

最初に渡した条件です。

「1日で実装できること」
「機能は最小構成であること」
「シンプルに成立すること」

この縛りが強すぎたせいで、
AIは無難に成立するラインに寄せていました。

AIは間違っていなかった。
条件には忠実だった。

でも、できたものは「成立しているけど刺さらないもの」でした。😅

たった一言で、別物になった

そこでもう一回、AIに改善会議させてみた。

「SNSで人に見せたくなるものにする」

この一言を強く入れて、
もう一度、アップデート版を考えさせてみた。

出てきた仕様書は、
最初とかなり違ってちょいビックリ。🤩

実際の仕様書👇

単なるタイマーではなくなった。

集中するたびに「思考の結晶」が成長する設計になってた💎

中断すると結晶が崩れ、
完了すると保存できて、
コレクションして共有できる。

ここで初めて、ただのツールから「体験」になった感じがしました。

最初がタイマーだとしたら、
アップデート後はゲームに近い。

もっと正確に言うと、
「また触りたくなる理由がある設計」に変わった。

アプリ開発ではこのまた触りたくなる要素は重要。

「成立する」と「刺さる」は違った

今回一番感じたのはここです。

AIは「面白いものを作る」より、
「成立する形に落とす」のが強い。

テーマがくだらなくても、最後は現実に戻してくる。
無茶な条件でも、最低限動くラインまで引き上げてくる。

これはかなり頼りになる。

でも逆に、
「また使いたいと思う体験」までは、
最初の条件だけでは届かなかった。

条件の置き方で、出てくるものがここまで変わる。
これはちょっとズレてるなと感じた最初のMVPがなければ、たぶん気づけなかったことです。

結局、最後は人間だった

ここも正直に書きます。

今回の最終形は、AIだけでは作れていません。

最初の仕様書はAI。
改善案もAI。
でも最後に細かい修正を入れて、今の形まで持っていったのは人間です。

どこを削るか。
どこを残すか。
どこをもう少し強くするか。

この最終調整は、やっぱり人間がやっています。

AIが成立させて、人間が意味を強くする。

今回の仕様書編は、その境目がいちばんよく見えた回でした。

仕様書編のまとめ

今回の気づきをまとめると。

アプリは思いつきで作り始めると途中で詰まる。
AIは仕様を成立させる力がある。
でも、成立するだけでは人に刺さらない。

条件の置き方で、出てくるものはここまで変わる。
最後の調整は、やはり人間がやる必要がありました。

最初の仕様書は正しかった。
でも無難すぎた。😅

「SNSで見せたくなるものに」という条件を足したことで、
ただのタイマーがようやく体験として残るものに変わった。
この違いは大きいですね！

次回予告

次回は、アップデート仕様書をもとにアプリを完成させた話です。

設計があれば実装は楽になる。
最初はそう思ってました。

でも実際は、そこからが本番でした。🤣

最初のMVPは正直ショボかった。
実際、仕様書がここまで固まっていれば最初のMVP完成まで10分もかかっていません。
しかし、出来上がったものを確認してからアップデート仕様を固めて・・・
結晶コレクション型まで進化させて・・・
ここまでいくのも長かった。

正直、修正が一番大変でした。😅

AIは設計まではできる。
でも「どこをズラすか」「どこを強くするか」「どこを修正するか」
こういう判断は
やはりまだまだ人間の仕事です。

この“ズラし方”と“設計の作り方”は、別でまとめる予定です。

次回はいよいよ、このアプリの実装編

アプリが最終的にどうなったのか！？完成品を公開します。

今回も最後まで読んで頂きありがとうございます。

他にもこんなことを自動化したい！
こんなアプリ作ってほしい！

などありましたら

是非、コメントで教えてください🙌

この記事がよかったらスキ、シェア、フォローしてもらえるとうれしいです。🤗

あわせて読みたい👇

AIの実用的な使い方や、自動化をどう進めているかは開発ログマガジンでも連載中です。
▼興味があればこちらもどうぞ。👇

▼AI初心者の教科書シリーズをもう一度見直したい方はこちら👇
※役立つ記事は保存をおすすめします。

▼他にも仮想嫁AIエルの処刑シリーズ連載マガジンを執筆しています👇