AI駆動開発の実運用ノート

本編の目次　›　第2部 要件定義と設計　›　大規模な要件追加・仕様変更の作法

AI駆動開発の実運用ノート No.53コードより先に「設計メモ」を書く

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第2部「要件定義と設計」から、「大規模な要件追加・仕様変更の作法」のお話です。

道具大きな変更はコードより先に「設計メモ」を書く

いきなり作り始めない——何をどう作るかを先に文書で決める

大規模な変更ほど、実装の前に設計メモを1枚書く。実際にマルチテナント化では、このメモ1本で「決めるべきこと20項目」を1日で決め切り、コードは1行も書かずに関係者の承認を得た。

メモに書くこと具体的には
選んだ案と、捨てた案・その理由後から「なぜこの形にしたか」を人間も AI も思い出せる（同じ議論を蒸し返さない）
決まったこと・保留中のこと1つずつ番号を振る。保留は「いつ決めるか」も添える（曖昧なまま実装に進まない）
着手前に調べること「調べた結果によっては設計を直す」前提で書く（思い込みで作り始めない）
事実は具体的に「どのファイルの何行目がこうなっている」まで書く（うろ覚えで書かない）
だから何

この1枚が AI への「発注書」になる——迷わず実装させられ、後戻りも減る

大きな変更は必ず「設計メモ」から始めます。 いきなり作り始めず、何をどう作るかを先に文書で決めます。

実際、複数社対応への拡張では、このメモ1本で「決めるべきこと20項目」を1日で決め切り、コードを1行も書かないまま承認を得ました。

メモに書くのは4つです。 選んだ案と、捨てた案とその理由。決まったことと、保留中のこと。着手前に調べること。そして、事実は「どのファイルの何行目」まで具体的に書くことです。

この1枚がAIへの「発注書」になります。迷わせずに実装させられて、後戻りも減ります。

この回の出典

つづく