つまずく原因はだいたい決まっています。決めるべきことを決めないまま先に進むか、決めたことを書き残さないまま進むか、このどちらかです。以下はそれを防ぐための順番です。
工程
- 00
スコープを決める
誰の何を解決するかを決める。同時に「今回は作らないもの」も書き出す。 ここが無いと、仕様がどこまでも膨らむ。
- 01
壁打ちする
どんな機能が要るかをAIと会話しながら洗い出す。判断に迷うところは「詰めて」と言って、質問攻めにしてもらう。
- 02
仕様書を作る
機能一覧・画面一覧・業務フローまで。実装方法は書かせない。 仕様と設計が混ざると、後から見直せなくなる。
- 03
モックアップを見る
主要画面をHTMLで出してもらう。必ず気づくことがあるので、仕様書に反映してから次へ進む。
- 04
DB設計を確定する
テーブル定義だけを先に固める。詳細設計より前に。 ここが後から変わると、全部やり直しになる。
- 05
詳細設計書を作る
仕様書とDB設計をもとに、技術的な設計書を作る。ファイル構成と開発フェーズの分割まで含める。
- 06
設計書をレビューさせる
別チャットで設計書だけ読ませ、セキュリティ・金額・難易度・将来の変更しやすさを見てもらう。 同じチャットだと、自分が書いたものを甘く見る。
- 07
本番サーバーに疎通確認する
コードを書く前に、空のページを本番に上げておく。PHPバージョン、DB接続、パーミッションをここで潰す。 環境の問題は、コードが増えるほど切り分けが難しくなる。
- 08
フェーズを実装する
機能単位で依頼する。設計書から外れる必要が出たら、実装前に確認を取らせる。
- 09
動作確認して直す
エラーは原因を特定してから直す。いきなり修正コードを書かせない。 当てずっぽうの修正は、別の場所を壊す。
- 10
設計書を更新する
実装中に変えた点を設計書に戻す。 実物と食い違った設計書は、次のチャットで害になる。
08〜10を、フェーズの数だけ繰り返す
- 11
本番公開する
デバッグ表示オフ、ファイルのパーミッション、バックアップを確認してから公開。
全体を通して効くこと、ひとつだけ挙げるなら
ステップが変わったら、チャットも変える
ひとつのチャットで仕様検討から実装まで走らせると、後半でAIが前提を見失います。話が長くなるほど、最初に決めたことの輪郭がぼやけていくためです。人間側も、どこで何を決めたのか追えなくなります。
工程ごとにチャットを分け、決まったことは会話ではなくファイルに残す。次のチャットは、そのファイルを読ませるところから始める。仕様書や設計書を作るのは、AIのためでもあり、未来の自分のためでもあります。
- 壁打ち・仕様持ち出すもの：仕様書
- DB設計・詳細設計持ち出すもの：テーブル定義、詳細設計書
- レビュー持ち出すもの：指摘と修正した設計書
- 実装（フェーズごと）持ち出すもの：更新済みの設計書
- デプロイ持ち出すもの：公開手順とチェックリスト
ほかに外せないこと
- 「何を作るか」と「どう作るか」を、同じ書類に書かない。
- 一括で作らせない。必ずフェーズに割って、動く単位で確認する。
- 設計書と実物がずれたら、その場で設計書を直す。あとでまとめて直そうとすると、まず直らない。
