一度に一つだけ変える(小さく試す反復)

この章でわかること: エンジニアが当たり前にやっている「小さく変えて、確かめて、記録して、次へ」という進め方。これはコードが読めない人ほど効く、最強の型です。

一度に一つだけ変える

AIに「あれもこれも」とまとめて頼むと、たくさんの変更が一気に返ってきます。うまく動けば気持ちいいのですが、どこかが壊れたときに手も足も出なくなります。 10箇所同時に変えて動かなくなったら、原因はその10箇所のどれか、あるいは組み合わせ。コードが読めないと、切り分けは事実上不可能です。

一度に一つだけ変えていれば、話は単純です。

料理で新しいレシピを試すとき、調味料を一度に5種類変えたら、次に何を直せばいいか分かりません。一つずつ変えるから「これが効いた/外した」が分かる——それと同じです。

大事なのは、各ステップのあとで必ず自分で触って確認することです。「動いているはず」で先に進むと、どこで壊れたか分からなくなります。

型はいつも同じです。

確認の観点は生成物の良し悪しの見分け方で扱った「利用者になって触る」がそのまま使えます。

「予約サイトを作って」のような大きな要望は、そのままAIに投げず、手順に分けてから一つずつ頼みます。分解自体をAIに手伝ってもらってもかまいません。

段階的に頼むコツは良い指示の出し方でも触れています。「一つずつ」と「伝え方」はセットで効いてきます。

小さく進む型を支えるのが、Git とバージョン管理のコミットです。コミットは「ここまでの状態」のセーブポイント。うまくいった一つを確認できたら、すぐコミットして記録します。次の変更で失敗しても、この地点に安全に戻れます。

一つの変更で直らない・悪化したときに、同じ場所をAIに何度も上書きさせるのは危険です。壊れた上にさらに変更が積み重なり、収拾がつかなくなります。

こうしましょう。

「積み上げて直す」のではなく「戻ってやり直す」。これが、傷を広げないコツです。

商談や提案でプロトタイプを見せるなら、その場で動くことがすべてです。小さく作って各段階で確認しコミットしてある物は、壊れても直前に戻せるので、デモが安定します。逆に一括で作った物は、当日ちょっと直そうとして壊すと、戻せずに詰みます。

「一度に一つだけ変える」は、単なる作法ではなくリスクを最小化する進め方です。コードが書けなくても、この型を守るだけで、あなたは自分の成果物をコントロールできます。