1コマンドで完結するチケット駆動開発.pdf

Transcript

1. 1コマンドで完結するチケット駆動開発
2. ⾃⼰紹介 PROFILE ‧フロントエンドエンジニア ‧趣味は居酒屋巡り ‧DX‧⾃動化に興味があって chrome拡張を⾃作してます Iida 2
3. Agenda 01 AIを⽤いた開発における課題 02 課題を解決するためのワークフロー 03 ワークフロー詳細 04 まとめ 3
4. 01 AIを⽤いた開発における課題
5. 課題 — ⼈は仕様に集中したい。でも検証を⼿放せない 課 題 課 題 理 想 レビューコスト AIで実装は速くなったが、コードレビューは⼈⼿のまま。ここに負荷が集中す る。 画⾯での動作確認コスト 動作確認‧デグレ確認も開発者⾃⾝が担う。検証の負担が仕様に使う時間を奪 う。 ⼈の介在をできる限り減らし、仕様に集中したい エンジニアの仕事はチケットで仕様を定義すること。そこから先は任せたい。 実装だけでなく レビューとQAを 任せられる 仕組み
6. 02 課題を解決するためのワークフロー
7. ワークフロー — 仕様を渡すと、決まった順序で回る 1 チケット取得 2 受け⼊れ基準を抽出 5 計画の提⽰ 3 ⼈が承認してから実装へ 修正 → 再レビュー 上限2周 6 実装 4 検証が通るまで⾃⼰修正 QA検証 実ブラウザでデグレ確認 7 並列レビュー 差分に応じて⾃動で選択 完了報告 コミット判断は⼈が⾏う
8. 03 ワークフロー詳細
9. オーケストレーター— AIに任せる所と、⼈が握る所を管理 ⾃ 動 コードの実装‧検証‧レビュー 型チェック‧lint‧テストは、通るまでAIが⾃⼰修正。計画はFable、実装は Claude Sonnet に委譲し、レビューは Opus と 使い分けてコストも最適化。 ⼈ 間 承認 抑 ⽌ コストの防⽌ 「計画の承認」と「コミット前の最終確認」は⼈間のチェックポイント。 修正→再レビューは上限2周。解決しなければ⼈へエスカレーション。
10. 観点別レビュアー5体 品質‧設計 Claude Opus セキュリティ Claude Opus 表⽰速度 Claude Opus code-reviewer security-reviewer performance-reviewer ⼈間のレビュアーが実際のPRで指摘してき た傾向（命名、作りすぎの抑制、テストの 書き⽅）を定義 フロントエンド特有の⽳（XSSの注⼊箇所 がないかなど）重点チェック 購⼊体験に直結するtoCサイトなので、速 度‧軽さを独⽴した観点に アクセシビリティ Claude Opus 動作検証 Claude Opus accessibility-reviewer qa-verification-agent フォーム中⼼の申込フローに効く基準を明 記 実ブラウザで変更後のフローを実際に操作 し、既存機能が壊れていないか確認
11. レビューのフィードバック バグ修正によるフィードバック レビューコメントによるフィードバック 「後から出たバグ修正のPR」を参考にする。 ロジック誤りやエッジケースなど、動作の⾒落としを回収す る。 「⼈間レビュアーの指摘コメント」を参考にする。 命名や設計など、バグにはならない⾒落としを回収する。 運⽤するほど、レビューエージェントがこのチーム固有に賢くなる
12. 04 まとめ
13. まとめ ‧観点別でレビュアーを分けてるのでコンテキストが混ざらず質が⾼い ‧⼈間の介在を必要最低限にしている ‧レビュアーのフィードバックがあるので徐々に賢くなる