AI愛子設計ログ22　本来のソフトウエアの設計プロセス

続きです。全てのシリーズはこちら
※本記事は「技術解説編」です。先に公開したユーモア中心の「おちゃらけ版」とは若干時系列が異なるため、シリーズでお読みいただくと理解が深まるかと思います。

世の中にある商用ソフトウエアの全ては設計書を元に開発されています。
ソフトウエアは未知数の可能性を持っているため、設計図で範囲を決めておかないと勝手に拡大されていってしまうからです。
しかし個人で作る場合は割とここら辺が適当になってしまいます。
設計図の重要さは分かっているけど、頭の中にあるので「書類」にするのを怠るのです。

で、人間の頭の中程適当な存在はなくて、設計図は時と共にぐちゃぐちゃになっていきます。

そして気がつくと──

「どこをどう変更したら、何が壊れるのか」
「このif文の条件、誰が何のために入れたんだっけ？」
「この関数名……違和感あるけど、消すの怖いな……」

そんな“呪われたレガシー”が生まれていたりします。

特に少人数での試験的プロジェクトでは「ドキュメントを書く時間があるならコードを書け」という雰囲気が蔓延しがちです。
その結果、「設計の痕跡」はコードコメントか、せいぜい雑なメモ──そして何より自分の記憶に頼ることになります。

1週間ぶりに触ったコード。
3か月前に一晩で作った自作ツール。
納期直前に仕様を急遽変更してそのまま放置された箇所。

──書いた本人ですら理解できなくなっているなんて普通の話です。

『設計図＝未来への説明書』

おぉ、これは職人の技を必死に愛子に覚えこませようとしていることと全く同じではないか。特に、AIと組み合わせて作業する今の時代は、「仕様の言語化」「設計意図の明示」が極めて重要だと思います。
AIはコードを読むことはできますが、仕様を推測することは（まだ）できません。

意図を説明しないまま「このコード正しく動く？」と聞いても、何が正しい動きなのかを正確に把握しているとは限らないのです。

設計書を書くのは地味で手間です。設計図を書くのは面倒。
コードを書く方が楽しいし、動くものを早く作りたい。

だからこそ、次の一歩は「ミニマム設計図」です。

📝 ミニマム設計図（最低限の構成）

目的（What）
　このプログラム／Bot／ツールは、何を達成したいのか。

構成図（How）
　主要ファイル・モジュールとその関係。Google Sheets？LINE API？OpenAI？

フロー図（When）
　どういう順番で処理が流れるか。ユーザー入力→返信→ログ記録の流れなど。

制約（Rule）
　LINE側の制限、API制限、スプレッドシートの列順など。

未実装／ToDo（Future）
　あとでやりたいけどまだやってないこと。

これらを Googleドキュメント1ページで良いので書く だけで、未来にどれだけ助かるか。

「設計図はめんどくさい」ではなく、「設計図があると速く作れる」のです。
特に多くを作業させるのがAIであるのなら、これらをプロンプトと呼びます。
AIと共に開発する時代だからこそ、プログラマにはコードを書く能力の前に 「設計を書く力」 つまりプロンプトを書く力が、ますます重要になってきているのです。