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

本編の目次 › 第4部 規律の仕組み化 › ルールは事故とともに育つ

AI駆動開発の実運用ノート No.93最初のフックは事故を直すPRの中で生まれた

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第4部「規律の仕組み化」から、「ルールは事故とともに育つ」のお話です。

起源最初のフックは事故の復元 PR の中で生まれた

「フック整備プロジェクト」は一度も存在しなかった

最初のフックは、マージ事故で消えたコード468行を復元する——まさにその PR に再発防止として同梱された。翌日にはスカッシュマージ禁止が明文化された。

  • 事故 → 復元 → 同じ PR で再発防止を機械化——以後3.5ヶ月続くパターンの初回
  • 規律の実装はすべて課題番号付き・PR 経由——機能と同格の成果物として扱われる
  • 事故→機械化のリードタイムは同日〜翌日が標準(書式ミス事故は当日中に2段階対応)
実例 — 当時のコミットログ原文(連続する2日)
4/06  fix: 前PRで消失したページ実装468行を復元(再発防止フック2本を同梱)
4/07  docs: スカッシュマージ禁止を明文化——「ソースコードの欠損事故を引き起こす」

その最初の1本の生まれ方が、このプロジェクトの全体を象徴しています。

「フック整備プロジェクト」は一度も存在しませんでした。

最初のフックは、マージ事故で消えたコード468行を復元する——まさにその同じPRの中で、再発防止として一緒にコミットされました。そして翌日、スカッシュマージ禁止が明文化されます。

事故が起きます。復元します。そして同じPRの中で再発防止を機械化します。

この「事故→復元→機械化」が、以降3.5ヶ月ずっと続くパターンの初回になりました。

規律づくりは独立したプロジェクトではなく、事故対応の一部として行われています。 記憶が新しいうちにその場で機械に落とす。だから間に合います。

この回の出典

つづく