【個人開発の設計術】AIと壁打ちしながら「基本設計書」と「詳細設計書」を書き上げた全記録
こんばんは！IT業界で働くアライグマです！
先日、「正規表現ストッカー(仮)」という新しい個人開発プロジェクトの始動を宣言しました。多くのアイデアがそうであるように、このプロジェクトも「こんなツールがあったら便利なのに」という、ごく個人的な課題から生まれています。
さて、アイデアが固まったら、すぐにでもコードを書き始めたい――。エンジニアであれば、誰もがこの初期衝動に駆られるのではないでしょうか。しかし、私はPjMとして、そして過去に幾度となく個人開発を頓挫させてきた一人の開発者として、この衝動をぐっとこらえ、その前にやるべき、最も重要で、そして最も退屈に思える作業に取り掛かりました。
それが、「設計」です。
今日は、私がAIアシスタント（Gemini）との対話を通じて、どのようにしてプロジェクトの「憲法」と「地図」を作り上げていったのか、そのリアルな思考プロセスと、完成した設計書を、余すところなく公開したいと思います。
なぜ、一人でも「設計書」を書くのか？
「一人で開発するのに、仕様書なんて大げさじゃない？」
その気持ちは痛いほど分かります。しかし、断言します。個人開発を「完成」まで導きたいのであれば、設計書は絶対に必要です。なぜなら、それは「未来の自分」との、最も重要な契約書になるからです。
- 未来の自分との契約書: 3週間後のあなたは、今のあなたがなぜこの技術を選んだのか、なぜこの機能を重要だと考えたのか、その熱量を忘れてしまっています。設計書は、その時の情熱と意思決定の理由を、未来の自分に正確に伝えるための、タイムカプセルのようなものです。
- 思考の「外部化」と整理: 頭の中にある曖昧なアイデアを、ドキュメントという形に「外部化」するプロセスは、それ自体が最高の思考整理術です。文章にしようとすると、「あれ、ここの仕様、矛盾してるな」「この機能、どうやって実現するんだ？」といった、考慮漏れや矛盾点が、面白いように見つかります。
- スコープの明確化（フィーチャークリープの防止）: 設計書は、「やること」と「やらないこと」を最初に定義する、プロジェクトの防波堤です。開発途中で「こんな機能も追加したら、もっと良くなるかも…」という悪魔の囁きが聞こえてきても、設計書があれば、「いや、v0.1のスコープはここまでだ」と、冷静に自分を律することができます。これこそが、個人開発における最大の罠「フィーチャークリープ」を防ぐ、唯一の方法なのです。
「基本設計書」でプロジェクトの“憲法”を定める
まず私が着手したのは、プロジェクトの「Why（なぜ）」と「What（何を）」を定義する、基本設計書の作成です。これは、プロジェクトに関わる全ての意思決定の拠り所となる、言わば「憲法」です。
私が定義した項目は以下の通りです。
- プロジェクトの背景と目的 (The Why): なぜこのサービスを作るのか。誰の、どんな課題を解決するのか。ビジネス上のゴールは何か。ここがブレると、プロジェクト全体が迷走します。
- プロダクトの段階的リリース計画（ロードマップ）: いきなり完璧を目指すのではなく、v0.1、v1.0と、段階的にどう成長させていくかの大まかな地図を描きます。
- 機能要求リスト (The What): v0.1で実現すべき機能を、「ユーザーは〇〇できる」というユーザー視点で、具体的にリストアップします。
- UI/UX ワイヤーフレーム: ユーザーが実際に触れる画面の、ごく簡単な設計図です。手書きのスケッチでも構いません。視覚的なイメージを共有することで、認識のズレを防ぎます。
- アーキテクチャ概要: v0.1とv1.0で、どのような技術的な構成を取るかの、大まかな方針を定めます。
この基本設計書があることで、プロジェクトの「北極星」が定まり、開発の途中で道に迷うことがなくなります。
「詳細設計書」で実装の“地図”を描く
基本設計書という「憲法」が定まったら、次はその憲法を基に、具体的な法律、つまり実装のための詳細な「地図」を描く、詳細設計書を作成します。これは、エンジニアである私自身のための、具体的な「実装指示書」となります。
私が定義した項目は以下の通りです。
- 技術仕様: どの言語、どのフレームワーク、どのライブラリを使うのか、具体的な技術スタックを明記します。
- コアロジック詳細: アプリケーションの最も重要な処理（この場合は正規表現のチェックや保存処理）を、どのように実装するかの詳細な計画を立てます。
- データモデル: データベースやLocalStorageで、どのような構造でデータを保存するのかを定義します。
- 異常系の考慮: 「もしエラーが起きたら」「もし無効なデータが入力されたら」といった、正常系以外のシナリオに対する挙動を、可能な限り洗い出しておきます。
- 開発環境と規約: どの環境で開発し、どのようなコーディングルールに従うのかを明文化します。
この詳細設計書があることで、いざコーディングを始める際に、「あれ、ここの実装どうしよう…」と手が止まることがなくなり、スムーズに開発を進めることができます。
【舞台裏】AIとの対話で、設計はこう進化した
さて、ここからが今回の開発ジャーニーの舞台裏です。これらの設計書は、決して私一人の頭の中から、一直線に生まれたわけではありません。そこには、AIアシスタントとの、試行錯誤に満ちた「対話」がありました。
最初の失敗：AIが提案した「壮大な設計」
最初、私はAIにこう依頼しました。「正規表現チェッカーの技術仕様書を作ってほしい。将来的にユーザー登録と課金機能もつけたい」と。
するとAIは、その「将来の拡張計画」を律儀に汲み取り、v0.1の段階から、Laravel + Inertia.js + MySQLという、フルスタックのサーバーサイドアプリケーションを前提とした、非常に壮大で、本格的な設計書を提案してきました。
私の判断：「合理的ではない」
その提案を見た瞬間、私はPjMとして、即座に「No」を突きつけました。
なぜなら、「まだ一人もユーザーがいない、登録すら不要なMVP（最小限の製品）のために、なぜサーバーを立て、データベースを構築する必要があるのか？合理的ではない」と考えたからです。これは、個人開発のスピード感を著しく損なう、典型的な「過剰品質」です。
ピボット（方向転換）：対話による設計の進化
そこで、私はAIに対して、より明確な制約とディレクションを与えました。
「ありがとう。でも、v0.1はもっとシンプルにしよう。ユーザー登録は不要で、サーバーもデータベースも使わない。全ての処理がブラウザだけで完結する、完全なクライアントサイド・アプリケーションとして設計し直してほしい。データ保存にはLocalStorageを使おう」と。
この指示を受けて、AIは設計を全面的に見直しました。そして、私たちが最初に合意した「v0.1は静的サイトとして、v1.0でLaravelを導入する」という、より現実的で、理にかなった段階的アプローチの設計書が完成したのです。
このプロセスから学べるのは、AIは完璧な答えを一度で出す魔法の杖ではない、ということです。AIは、与えられた情報から最も論理的な答えを導き出しますが、その前提となる「ビジネス的な判断」や「プロジェクトのフェーズに合わせた合理性」を判断するのは、人間の役割です。
AIは、あなたの思考を加速させる、最高の「壁打ち相手」であり「アシスタント」です。しかし、プロジェクトの舵取りをする「船長」は、常にあなた自身でなければならないのです。
まとめ
一見、遠回りに見える「設計」というフェーズ。
しかし、この最初に費やした数時間が、未来の開発における数十時間、数百時間もの無駄な時間を節約してくれることを、私は経験から知っています。
個人開発を成功させる秘訣は、自分自身を「一人の優秀な部下」だと考え、PjMであるあなたが、彼（自分）のために、最高の「航海図」を用意してあげることです。
完璧な設計図が、今、私の手元にあります。
次回から、いよいよこの設計図を基にした、実装のフェーズに入ります。この「正規表現ストッカー(仮)」が、少しずつ形になっていく様子を、ぜひ楽しみにしていてください。