【個人開発の羅針盤】AI(Gemini)×Vibe Codingで失敗を測定するための計画書Ver.1

こんにちは！Tomoyaです。

最近は、雪が降ったり気温が低いと体感でもわかるくらい冷え込んでいますね。こうゆう時は、「早く冬が終われ！」と思ってしまいますがそんな冬も１年で見れば一時でしかなく気が付けば夏になって「暑すぎる！」と感じているのが日本の四季の良い所に感じます。そこに気づくと今も楽しんで生活できるようになってきます。

さて今回は、私が個人開発を行っていく上で指標とする事と流れをここに表明して、取り組む為の軸となる記事を作成しました。これからこの記事を基に進めていきたいと考えているので、ここを軸にする事で羅針盤の役割として機能する予定です。

ここで決めたことも失敗や問題点や気づきがあれば修正していくつもりです。

ではご覧ください。

---

はじめに：なぜ「計画」が必要なのか？

闇雲にスタートするのは良いですが、始めに目的や手順を計画しておくことで問題が起こっても何が原因かを明確にできるので私は重要だと感じています。

そして「あれも欲しい」「これも欲しい」と機能追加の沼にハマって永遠に公開(完成)しない（個人開発あるある）を防ぐ狙いもあります。

このVibe Codingの本質は、爆速でアイデアを形にできる事です。

理想ではありますが、始めから完璧を目指さないで市場に出す事で反応を見て修正をする。そしてユーザーと作り上げていくのが長く愛用してもらう事になると思うからです。なので

100%の１よりも60%の10を作る事を意識して行っていきたいと思います。

---

目的とゴール設定（ここがブレると失敗する）

完了の定義：ここは段階的にゴールを設けて進めていく。

---

【How】技術スタック：どこで行うのか？

前回の記事でも示した通りGoogleエコシステムを主戦場に戦っていきます。理由はシンプルに以下の３つです。

• シンプルで一貫性がある
• 長期的成長見込み
• 使いやすい

SNSやニュースを見るとあれが良い、これが良いと細かく言えば評判が立っていますが実際はどれも十分レベルが高いと思っています。後は、自分たちがどう使うのか？が問題だと感じています。

ここで迷いすぎる事で見失わないようにGoogleの幅広いサービスとレベルの可能性を見て私はGoogleエコシステムを主戦場とすることで個人開発を行って発信していきたいと思いました。

理由を知りたい方は以下のリンクからどうぞ

---

【Rule】「Vibe Coding」のルール

目的に対してルール・条件はとても重要なポイントだと感じています。ここが定まっていないと軸がグラグラになって闇雲に行う事と変わらなくなってしまうからと考えます。原因もわからなければ推測もイメージもできず修正もできないので、どこで変化をつけていいのかわからなくなる問題を避けたいと感じています。

AIとの付き合い方（重要）：

• 「基本はGeminiAIを使っていく」
• 「自分でもわからない事を書かない。期待しない」
• 「うやむやな指示をしない/明確な指示をする」

全体的なルール・条件：

• 「機能の追加・修正指示は２つ/１回までにする」
• 「動くものを作る事・動かないものは削除する」
• 「２回以上修正依頼して改善しない場合は、コードを調査して他のAIに解決策を貰う」
• 「AIが作成した機能は、コメントに機能の説明を簡潔に追記させる（学習のため）」

---

【完了１を目指す】MVP（Minimum Viable Product）の範囲

何を記入するか: 動くプロトタイプを作成するためにする事(MVP)

• 目的を明確にする：公開を前提とした動くwebアプリのプロトタイプの作成。（完了１を目指す）
• ユーザー体験：誰が使うのか？まず動くものを作る事、複雑なものではなくシンプルな欲しい機能を最大３つまで提示する。（自分の作りたいアイデアを記入）
• ルールと条件：詳細な流れ：リストにはCRUDを付ける。など
• 色の指定（カラースキーム）
• 出力形式：日本語。命名規則
• 技術スタック（あれば）

始めの段階で「やらないこと」リスト（最重要）: 捨てる勇気を持つ・順次追加していく。

• ログイン機能などのバックエンド機能
• デザイン性(UI/UX)「デザインはテンプレートそのままで、こだわらない」
• セキュリティ・クォータ設定
• 複数ページの作成。(/about, /privacyなど）
• PWA化
• 有料課金機能
• プッシュ通知（ブラウザ/モバイル）
• 多言語対応（日本語のみ）
• SNSシェア機能は不要

---

【When】スケジュールと期限

仕事の量は、完成のために与えられた時間を満たすまで膨張する

英国の歴史学者・政治学者シリル・ノースコート・パーキンソン

「締め切りが先であればあるほど、本来は短時間で終わるはずの仕事であっても、余計な手間をかけたり先延ばしにしたりして、結局その時間一杯まで使い切ってしまう」という現象の事です。

スケジュールと時間はとても重要です。やり始めると止まらなくなってしまい、いつの間にか100%を目指しているなんてことになりかねないからです。

ここで予め時間制限を設定する事で終わるように行動しようと思えます。

パーキンソンの法則に則って

始めはタイムボクシング式で30分×2/1日行い。
期間は１週間の締め切りを設けてVibe Codingを行っていきます。

---

【Money/Risk】予算と撤退ライン

基本的に無料範囲で行えるように構築していきますが、もしものために最低限のセキュリティ設定（APIキー制限など）とクォータ設定を設けて任意の最大金額までは利用できるようにします。

ここで最大金額まで行くアプリケーションは需要があるか又はキャパオーバーかがわかるので良いデータになります。

何もせず下手するとコストが積みあがっていくので必ずここは設定します。

撤退ライン：

最初の1作目の撤退ライン（というか成功定義）は、「市場の反応」ではなく「自分自身」に向けて行います。

新規ドメインのブログやアプリがGoogleにインデックスされ、検索流入が始まるまでには通常3ヶ月〜半年かかるようなので致命的なランニングコストやサーバー代などの利用料がかからなければ「放置」で様子見していきます。

1. 公開したアプリで発見した「致命的なバグ」が1週間かけても直せなかったら、その機能は一旦捨てる。
2. 評価軸：「自分が設定した期間内（1週間）に公開まで漕ぎ着けられたか？」を指標にする。

まとめ

今回は、私が個人開発を行う上での前準備としての暫定記事を執筆しました。

なぜ計画が必要から目的・技術スタック・ルール・MVP・期限・コストの順で設定していきました。

この記事を基に進めていき、問題があれば都度修正していこうと思います。

何か気になったポイントやアドバイスがあればぜひコメントをお願いします。

ここまで読んでいただきありがとうございました。次回もぜひご覧ください。

最新の記事も気になったらご覧になっていってください。