■ 1. 背景と結論
- 前回記事の振り返り:
- 半年前、人間のコードレビューをやめて実装前に「コンセプト」をチームで確認するワークフローへの移行を提案した
- 当時は未実践だったため、半年ちょっと実際にコードレビューをなくした結果を振り返る
- 結論の概要:
- 人間のコードレビューをやめてもリリース数は落ちず、リリースまでの時間が減った
- 代わりに置いた「人間による意図の確認」はほとんど機能しなかった
- 原因はフローの構造にあるため、次は「人間が行った判断だけを確認する」方針に変更する
- 同じ考え方で、AIが自律的にループして改善するフローもサポートする
- 前回の役割分担:
- AIが担保するのは要件充足、設計の正しさ、セキュリティ
- 人間が担保するのはチーム内の知識共有と、AIへの指示が正しいかどうか
- 人間はAIに渡すプロンプトのレビューに集中するという主張
■ 2. 実施したワークフロー「Ito」
- ツール化:
- ワークフローを「Ito」という社内ツールにした
- 最初はCLIで各自のターミナルから実行し、その後Claude Codeのスキルにした
- 仕組み:
- Ito専用のGitHubリポジトリにissueとしてコンセプトを作成し、ラベルで状態管理する
- コンセプトの記載項目:
- Why: 解決したい課題
- Outcome: 何ができたら完了か
- Boundaries: 絶対に触らない範囲、今回やらないこと
- AI Findings: AIによる事前調査の結果
- 変更規模による3レベル:
- minor: 事前確認・事後共有ともになし、Typoや文言の修正を想定
- quick: 事前確認なし、事後共有あり、バグ修正や小さな改善を想定
- full: 事前確認・事後共有ともにあり、新機能や大きな変更を想定
- Gap Report:
- 実装後、コンセプトと実装コードの差分をAIに突き合わせさせて作成し、issueにコメントする
- quickとfullは開発定例などでGap Reportを共有する
■ 3. うまくいったこと
- ワークフローの定着:
- 半年ちょっとで277件のコンセプトが作られた
- 内訳はquick205件、full40件、minor32件
- Gap Reportは277件中254件（92%）で作成された
- 人間のコードレビューの消滅:
- 人間のapproveがついたPRの割合は導入前の97%から、4月以降は1割未満になった
- 移行期の3月はまだ70%程度だった
- 0%にならないのは、hotfixなどの緊急対応や意図的に人に見てもらいたい場合の例外があるため
- レビュー待ちの減少:
- 週あたりのマージ数は5.1から5.5に増加
- マージまでの時間の中央値は19.2時間から16.1時間に短縮
- 遅いほうの4本に1本がかかった時間は2.8日以上から23.0時間以上に短縮
- 遅いほうの10本に1本は5.8日以上から4.7日以上に短縮
- 24時間以内のマージ割合は65%から77%に、3日超の割合は22%から14%に改善
- 300行以上のPRの中央値は2.8日から21.3時間に短縮
- 300行未満のPRの中央値は6.1時間から5.9時間でほぼ変化なし
- 数日間レビュー待ちで寝かされていたPRが、ほとんど1日以内にマージされるようになった
- 中央値が16時間前後で止まる理由:
- PR作成は日本の夕方17〜18時台が最多で、翌朝マージになる構造のため
- マージ=リリースの仕組みのためであり、リリースが別サイクルなら中央値は下がると想定
- メンバー減少下でのPR数維持:
- 集計期間中にチームは5人から4人に減った
- 1人あたりの週のマージ数は1.03から1.38へ34%向上
- 4人体制での導入前約3ヶ月と比べ、週4.2から週5.5へ31%向上
- 4人になった直後、最初の人間レビュー完了までの中央値は3.3時間から17.4時間に悪化していた
- その時期にコードレビューをやめたことで数字上は改善した
- 事故の非増加:
- hotfixやrevertの件数は増えておらず、目に見える事故は増えていない
■ 4. うまくいかなかったこと
- コンセプトの書き手はAI:
- 当初はエンジニア本人がタスクを整理してコンセプトを立案する想定だったが崩壊した
- 素直にやれば、AIにコードを調べさせた延長でそのままAIにコンセプトを書かせる流れになる
- コンセプト本文のうちAIの事前調査部分が64%を占める
- コンセプト作成から実装開始までの中央値は2分
- Gap Reportの37%はコンセプト作成から30分以内に作成された
- コンセプト作成から実装、Gap Reportまでが、AIとの一連の流れで一気に終わっている
- コンセプトは「実装前に立ち止まる場所」ではなく「AIが出力する書類」になっていた
- エンジニア個人の意図を出さなくても、AIの作業だけでフローが最後まで通る構造だった
- 事前確認のLGTM化:
- fullのコンセプト40件で差し戻しは0件
- 立案者以外のコメント68件のうち84%（57件）はほぼ「LGTM!」のみ
- 前回記事でコードレビューについて懸念した「他の人が指摘するからLGTMだけ押す」現象が、コンセプトのレビューでも起きた
- AIが調べて書いたコンセプトを渡されても、人間はLGTM以外返しようがない
- 確認が機能した例外:
- 数件は機能し、どれも「コード上からはわからない外部の事情」の指摘だった
- 例はユーザーの実際の機能利用経路や、リリース前の社内確認方法といった外部依存
- 事後共有の不機能:
- 事後共有必須のquickとfull245件のうち、開発定例で確認済みになったのは73件
- 59%（145件）は確認待ちのまま残っている
- 開発定例などワークフロー外のルール徹底が不十分で、事後共有が定着しなかったことも原因
■ 5. 問題の本質
- 元の方針の妥当性:
- 「AIへの指示が正しいか」を人間が見る方針自体は今も正しい
- AIが自律的に動く現在、起点となった人間の意思や意図こそが最重要の情報
- 構造上の問題:
- ワークフロー内のどこにも、本人しか持っていない情報を要求する箇所がなかった
- コンセプトの4項目はコードを読めばAIが全て埋められる
- 立案者の考えが入っていないものをレビューしても、指摘することはほとんどない
- 改善の方向性:
- 「必ず立案者の考えを入れる」ワークフローにすれば、コンセプトのレビューは機能する
■ 6. 次のワークフロー（人間起点）
- AIが下書きし人に判断を聞く:
- 人はこれまで通りやりたいタスクをAIに伝える
- AIが調査してコンセプトを下書きする
- AIは下書きから「決まらなかった点」を0〜4個取り出して人間に聞く
- 人間の答えを言い換えずにそのまま「本人の判断」として記録する
- 「本人の判断」欄はAIが勝手に埋めてはいけないという絶対のルールを設ける
- 人間に聞く内容の例:
- ユーザーから見える挙動が変わるがよいか
- 今回やらないと決めた範囲はなぜやらないのか
- 後戻りしにくい変更をいま入れてよいか
- レベルは判断の有無で決定:
- 従来のfull基準は新機能や複数ファイルといった規模だったが、規模のリスクはAIレビューで見られる
- 人間の確認が必要なのは人間にしか決められない判断がある時だけ
- 「本人の判断」が0個ならquick
- 外部に影響する判断や後戻りしにくい判断が1つでもあればfull
- 事前確認は「本人の判断」のみ:
- レビュー観点は「この判断でよいか」に絞る
- もう1つの観点は「コードから見えない外部事情が抜けていないか」
- フォーカスが定まるため、脳死のLGTMはしづらくなる
- Gap Reportの絞り込み:
- 現状は実装要約から推奨事項まで4セクションあり、長すぎて共有が難しい
- 今後はBoundariesを破っていないかを確認する
- 「本人の判断」になかった判断をAIが実装中にしていないかも確認する
- 開発定例では必ずGap Reportを共有し、quickとfullの2段階とも徹底する
- これまでとこれからの比較:
- 人が出すもの: コンセプトの文章（実際はAIが書く）から本人の判断（Decisions）へ
- レベルの基準: 変更の規模から、人にしか決められない判断があるかへ
- 事前確認の対象: コンセプト全文からDecisionsだけへ
- Gap Report: 4セクションをIssueに書く形から、新しく出た判断だけをコメントで追記する形へ
- 完了: 人間が手動で行う形から、開発定例で共有後に完了する形へ
■ 7. AI起点の自律ループフロー
- 背景:
- 今後は人間起点ではなくAI起点の変更が増えると予想し、実際に増えている
- チームでは、エラーをトリガーに自動で修正PRを作り、AIレビュー後にマージし、定時に自動リリースする仕組みがすでに動いている
- この流れは不可避に近く、AI起点の改善フローを本ワークフローでもサポートする
- 考え方:
- 人間起点と同じ考え方で、違うのは粒度のみ
- 人間起点では判断を1件ごとに、AI起点ではループごとに記録する
- ループのコンセプト:
- ループ開始前に1回だけ立案し、必ずfullとしてチームで「本人の判断」を確認する
- 目的の指標: 何をどう測るか、例としてLPからの登録率
- 悪化させてはいけない指標: 表示速度、登録後の継続など
- 任せる範囲: 触ってよいページやファイル、1回の変更量の上限
- 触らせないもの: 価格や機能の表現、法務に関わる文言、計測コードそのもの
- 判定のルール: 何日測り、何をもって採用・取り消しとするか
- 人に上げる条件: どうなったら人を呼ぶか
- 期限: いつ見直すか
- 期限の重要性:
- 最も重要な項目は期限
- 無期限だと誰も見ていないゴーストループが動き続け、チームでハンドリングできなくなる
- 1回ごとのPRの自動マージ:
- 1回ごとのコンセプトはAIがループ内で自動作成する
- 中身は仮説、根拠にした計測値、期待する効果、変更内容など
- 本体コンセプトの範囲内かを自動判定し、実装から自動マージ、自動リリースまで繋げる
- 範囲外に溢れる場合は人間の判断が必要としてfullにする
- Gap Reportは仮説と結果の差:
- 期待した効果と実際に測った結果の差を記録する
- 開発定例での共有材料になり、次のループの仮説材料にもなる
- 人間の確認範囲:
- PR単位のマイクロマネジメントではなく、その週のAI起点コンセプトのまとめのみを開発定例で確認する
- 3パターンの比較:
- 人が起点（判断なし）: 判断・確認なし、AIレビュー後マージ、Gap Reportは新しく出た判断だけ
- 人が起点（判断あり）: コンセプトごとに判断を出しDecisionsを確認、AIレビュー後マージ
- AI起点のループ: ループごとに判断、ループのコンセプトと定期まとめを確認、範囲内なら自動マージ
- AI起点のGap Reportは仮説と結果の差
- どれも原則は同じルールで運用できる
- 全体の原則:
- どの場合も人間がやることは「判断を出すこと」と「判断を確認すること」の2つだけ
■ 8. 総括
- 人間がレビューすべきもの:
- コードでもAIが書いた文章でもなく、人間が下した判断が妥当かどうか
- 最も難しかった点:
- 小規模チームとプロダクト特性により、コードレビューの停止自体は思ったよりすんなりできた
- 難しかったのは、レビューをやめた後に人間がどこに関与し責任を置くかの設計
- 何もしないと人間による関与はゼロに収束していく
- 今後:
- 新しいワークフローでも別の困難に当たる可能性があり、その時はまた振り返る