【個人開発の記録】作る前に、いちばん疑わしい前提から確かめることにした

個人開発で新しいアイデアを思いついたとき、すぐに手を動かしたくなりませんか。私もそうでした。今回は、作りたい気持ちを一度抑えて、先に検証することにした話を紹介します。検証にも優先順位があると、身をもって知りました。

【体験】作りたい気持ちを抑えて、先に検証することにしました

ヒアリングを支援するアプリを、個人で作ろうとしていました。言葉にするのが苦手な人からでも、AIとの対話で要件を引き出せるようにする。そんなアイデアです。

アイデアが固まると、すぐにでも作り始めたくなります。画面のイメージも浮かんでいました。

ただ、今回はいきなり作り始めませんでした。先に、検証を挟むことにしたのです。

理由は単純です。作り込んでから「そもそも意味がなかった」と気づくのが、いちばん怖かったからです。時間をかけて実装したあとに前提が崩れると、やり直しがききません。

これまでの個人開発では、作りながら考えることが多かったように思います。それ自体は悪くないのですが、今回は前提そのものが疑わしいアイデアでした。作りながらでは、取り返しがつかなくなると感じたのです。

そこで、実装なしで答えを確かめる「スパイク」という進め方を使うことにしました。言葉だけは聞いたことがありましたが、自分で使うのは今回が初めてでした。

調べてみると、スパイクはチーム開発の文脈で語られることが多い言葉でした。個人開発でそのまま使っている例は、あまり見かけませんでした。それでも、考え方自体は個人開発にも十分使えると感じ、試してみることにしました。

確かめたいことは2つに分けました。1つは「技術的にできるか」。もう1つは「そもそも意味があるか」です。順番をどちらにするかで、かなり違う話になると気づきました。

【検証1】モック(見た目だけの画面)を、AIにどこまで任せられるか

最初に確かめたのは、操作できる画面(モック)を、AIにどこまで任せられるかでした。

「やりたいこと」をまとめた文章から、見せられる品質のモックを作れるか。そして、修正の指示を3回重ねても、意図どおり反映され、レイアウトが崩れないか。この2点を確認しました。

結果は、3回の修正指示すべてで意図どおり反映され、崩れはありませんでした。色味の変更、文字サイズの調整、新しい項目の追加。どれも、前の版の良いところを保ったまま反映されました。

業種を変えても確認しました。製造業・飲食店・税理士事務所の3つです。業種によってデバイスの前提が違います。スマホ中心か、PC中心かです。気をつけるべき点も違います。機密情報の扱いなどです。

それでも、どの業種でも初回から見せられる品質のモックが生成されました。ここは「go(合格)」と判定しました。

正直、この結果には少し驚きました。業種ごとに細かく調整しなくても、ここまで対応できるとは思っていなかったからです。

かかった手間も、思っていたより軽いものでした。1つの版を作るのに、十数秒ほどでした。何度もやり直しても、負担に感じるほどではありませんでした。

この検証だけを見れば、「作れそうだ」という手応えは十分にありました。ここで作り始めたくなる気持ちも、正直ありました。

【独自検証】いちばん大事な検証は、まだ終わっていません

ここまでは、順調に見えるかもしれません。ですが、正直に書きます。いちばん大事な検証は、まだ終わっていないのです。

本当に確かめたかったのは、こうです。言葉にするのが苦手な人が、AIとの対話を通したとき。従来の聞き方より、より多く・正確に・具体的に要件を言葉にできるのか、です。

これが本当なら、作る価値があります。もし差がないなら、コンセプトそのものが成立しません。モックがどれだけきれいにできても、この前提が崩れていては意味がないのです。

ここだけは、AIでは確かめられませんでした。検証の条件がありました。本当に言葉にするのが苦手な人に、協力してもらう必要があったのです。

自分や、知り合いのエンジニアで代用してはいけない。あらかじめ、そう決めていました。

代用してしまうと、肝心な部分をすり抜けてしまいます。「検証済み」のつもりになるだけです。それでは、検証をした意味がありません。

そのため、この核心の検証だけは、まだ手つかずのまま残っています。モック生成の検証は進んだのに、いちばん大事な検証だけ止まっている。少し歯がゆい状態です。

【気づき】検証にも優先順位があると知りました

今回、検証にも優先順位があると気づきました。「できるか」を先に確かめるより、「意味があるか」を先に確かめるべきだったのです。

モックがきれいに作れるかどうかは、実は二の次でした。その前に、コンセプトの土台そのものが崩れていないかを確かめる必要があったのです。

もう一つ、気づいたことがあります。終わっていない検証を、隠さずに書くことの大事さです。

ブログで紹介する以上、きれいにまとまった話のほうが書きやすいのは確かです。ですが、途中で止まっている部分を隠してしまうと、自分自身が見失ってしまいます。

次に何をすべきかは、はっきりしています。実在する、言葉にするのが苦手な人に協力してもらい、核心の検証を済ませることです。それまでは、本実装には進みません。

正直、誘惑はあります。モックの検証がうまくいった分だけ、気持ちが強くなるのです。「このまま作ってしまいたい」という気持ちです。ただ、そこで作り始めてしまうと、今回決めたルールの意味がなくなります。

【今の運用】新しいアイデアほど、先に疑ってかかる

この経験から、個人開発の進め方を1つ変えました。アイデアが固まったら、すぐ作り始めるのをやめたのです。

代わりに、作り始める前に、自分に3つ問いかけるようにしています。

• このアイデアが成立しないとしたら、何が崩れたときか
• その崩れそうな部分を確かめるのに、実在の第三者(自分や知人以外の人)が必要か
• 技術的な検証と、価値そのものの検証。どちらが崩れたときの損失が大きいか

技術的にできるかどうかは、後回しにしています。先に、そもそも意味があるかどうかを確かめます。意味がなければ、技術的にどれだけうまく作れても仕方がないからです。

検証が途中で止まっていても、それをそのまま認めるようにもしています。無理に完了したことにせず、次にやることとして残しておきます。

記録の残し方も少し変えました。「検証済み」とだけ書くのはやめました。何が済んでいて、何が済んでいないか。そこを分けて書くようにしています。あとで自分が読み返したときに、迷わないようにするためです。

まとめ:作る前に、いちばん疑わしい前提から確かめる

今回の経験から、1つの基準ができました。作る前に、いちばん疑わしい前提から確かめる、という基準です。

技術的にできるかどうかより先に、そもそも意味があるかどうかを確かめる。この順番を間違えると、時間をかけた後で気づくことになりかねません。

今回、技術的な検証のほうが先に終わりました。たまたまそうなっただけです。どちらを先に検証するかは、アイデアによって変わると思います。

大事なのは、どちらが先に終わったかではありません。両方とも確かめると、あらかじめ決めておくことだと感じています。

もし今、「作りたい」気持ちが先行している方がいれば、一度立ち止まってみてください。いちばん疑わしい前提は何か、考えてみる価値があると思います。

検証が途中で終わっていても、それは失敗ではないと思います。次にやることが、はっきりしているだけです。私も、残りの検証を済ませてから、次に進むつもりです。

X(@kandt0517)でも、AI活用やアプリ開発の気づきを発信しています。よければ、フォローして一緒に学んでいきましょう。

参考・引用元ソース

本記事は、個人開発の記録(自分用の検証メモ)にもとづいています。外部の情報源からの引用はありません。