【完全理解を手放す開発術】非エンジニアがマルチAIを指揮して破綻なくシステムを構築する設計・制限ルール

先日、避難所システムのV1として開発を終えましたが、そこから「もう少しやってみよう」と思い、さらなる改良に着手しました。

今までの構成から、サーバを介したデータ送受信を核とし、将来的にはクラウドでの運用も見据えた設計へとステップアップさせています。

とはいえ、そこまでの構成になると、これまでの自分の知識ではまったく歯が立ちません。そこで今回、思い切って「自分が技術をすべて理解すること」を手放す決断をしました。

「何もわからない人間が開発を主導して本当に大丈夫なのか？」という不安や葛藤は当然ありました。ですが、視点を変えて会社組織で考えてみると、ソフトウェア開発企業の社長が必ずしも現場の細かな技術を完璧に理解しているわけではありません。

もちろん、わかるに越したことはありません。しかし、勉強を始めればさらに勉強が必要になり、結局何も形にできないまま言い訳を重ねて還暦を迎えてしまうのではないか……そんな危機感を覚えました。ただでさえエンジンがかかるのが遅い自覚がありますので、これは十分に起こりうるリアルな未来だと感じたのです。

そこで、開発の進め方を根本から変えることにしました。

これまでは思いついた都度AIとチャットし、「ここを実現するにはどうすればいい？」と聞いていました。
　今回はまずAIと課題について議論を重ね、システムとしての全体像を固めます。その上で概略仕様書を作成させ、疑問や矛盾を徹底的にぶつけてブラッシュアップし、最終的な詳細仕様書へと落とし込んでいきます。

ここからが運用のポイントです。仕様書を作ったAIとは別のAIにレビュー・評価を依頼します。

懸念点や矛盾が指摘されれば、最初のチャットAIに戻して仕様書を修正させます。修正版を再度別のAIに評価してもらい、問題がなくなった段階で初めてコーディング用AI（Claude CodeやCodexなど）に読み込ませて実装に入ります。

なお、今回開発している避難所システム自体は、将来的にオープンソースとして無償公開する予定です。非常時に金銭を求めるような仕組みにはしたくないという思いと、オープンソースとして多くの人の目に触れることで、より堅牢で良いシステムに育つと考えているためです。

自分自身の学習としては、今後もUnity C#などを着実に積み上げていく予定です。

ここから先は有料エリアとなります。