変更を納得させる技術

https://fresh-engineers.connpass.com/event/409436/

1. 変更を 納得させる技術 asa1984 (アサヒ) 新卒N年目の勉強会&交流会！ 〜若手エンジニアのAIの使い方・向き合い方〜
2. 変更を納得させる技術 asa1984 (アサヒ) 25新卒 株式会社HERP
3. 変更を納得させる技術 変更量は増えたが デリバリーが追いつかない！
4. 変更を納得させる技術 レビュアーを納得させる 既に AI の方がコーディングが上手いし、バグ探しも上手い めっちゃ自信あるから！マージして！頼む！ では、なぜマージできない？ どうやったらレビュアーを「納得」させられるか？
5. 変更を納得させる技術 「レビュー」を分解する コード品質は十分か 期待通りに動作するか デプロイしても安全な変更か 仕様・設計の合意 上から解決していく
6. 変更を納得させる技術 静的検査 方針：Skill, Rules, AGENTS.md を極力削り、静的検査に落とし込む After Before 規約や過去の指摘事項を Skill や 可能な限り厳格な linter 設定 AGENTS.md に追記する 型システムの活用 遅い、漏れる、高い プロジェクト固有のカスタムルール
7. 変更を納得させる技術 健全性（soundness） 雑定義 コーディングスタイルのズレ ある検査を通過したコードでは、特 定の誤った振る舞いが起き得ない こと 型の不一致 起き得ない誤りはレビュー対象から外れ る（人間も AI も） 期待通りに動作するか モジュールの依存方向の違反 権限チェック漏れ 仕様・設計との整合
8. 変更を納得させる技術 正当性（correctness） 基本 雑定義 プログラムが仕様どおりに振る舞う こと 事例ベースのテスト・スナップショットテスト 発展：より強い保証 Property Based Testing より強い手法も、プロジェクト固有の検 証ツールも、AI によって導入コストが下 がった モデル検査 半自動化：完全には自動化できない部分 検証ツールを作り、AI や人間の動作確認を省 力化する
9. 変更を納得させる技術 「レビュー」を分解する コード品質は十分か 期待通りに動作するか 決定論的なハーネスが 担保 デプロイしても安全な変更か 人間がレビューする 仕様・設計の合意
10. 変更を納得させる技術 正当性（correctness） 雑定義 プログラムが仕様どおりに振る舞うこと ところで、何を保証したいのか？
11. 変更を納得させる技術 仕様・設計の合意 PRD DesignDoc PO や CS と合意する 開発者間で合意する（運用面は CS とも） 何を作るか 満たすべき仕様 仕様を保証するテスト事項 アーキテクチャ上のトレードオフ どちらもテンプレート化し、ドキュメントとして運用し、合意の記録を残す
12. 変更を納得させる技術 現状 確認事項 主体 コード品質は十分か 静的検査 + AI レビュー 期待通りに動作するか 自動テスト + AI レビュー デプロイしても安全な変更か 人間（PR レビュー） 仕様・設計の合意 人間（PRD, DesignDoc） 一方、1. 合意の記録の正当性 2.影響範囲と復旧方法と動作確認手順 3. インシデント 多発箇所の確認 は残している
13. 変更を納得させる技術 人間が判断するレイヤーを上げる 何を作りたいか 人間 仕様・設計の合意 人間 → 将来的に仕組み化 デプロイの安全性 人間 → 将来的に仕組み化 期待通りの動作 コード品質 自動テスト + AI 静的検査 + AI
14. 変更を納得させる技術 しかし、簡単ではない！
15. 変更を納得させる技術 どうやったらレビュアーを「納得」させら れるか？ 我々は何をレビューしたいのか を問い直す 一つ一つを、より省力で、より 強く保証できる手段へ移す