当日のシート

自動化の層を下から積み上げた8段です。Day1 の冒頭に現在地を1回塗り、Day2 の最後にもう一度塗ります。2回の差が2日間の成果です。

塗り方は3段階だけにしてください。細かく刻むと2回目の比較ができなくなります。

8層の現在地

塗り終えた後の記入欄

Day1 の記入が終わったら、次の2行だけ書いてください。Day2 の最後に同じ欄をもう一度書き、行が動いたかを見ます。

AI が出した指摘を、4分類のどれに入れるかを決めるシートです。ハンズオン1（Issue #1）とハンズオン2（Issue #2・#3）で使います。

指摘を全部直すと、5行の修正に半日かかります。全部見送ると、レビューを回す意味がなくなります。この2つの間に線を引くために、指摘ごとに3軸を先に決めてから分類します。分類から入ると、その日の気分で線が動きます。

指摘10件の記入欄

出どころは「同一セッション」「履歴を切った別セッション」「観点別のレビュアー」「CI」のどれかを書きます。同じ指摘が2か所から出たときは、両方に行を立てずに1行にまとめ、出どころを2つ並べてください。重なった数がそのまま、レビューを何本回すかの判断材料になります。

集計欄

下の数は、上の記入欄から自動で数えています。

一番下の行が大きいほど、人が読む量を減らせます。人が読む量を減らす手は「基準表を厳しくする」ではなく「CI に落とせるものを CI へ移す」です。

演習中に自分で数える欄です。あとから思い出して埋めることはできないので、その場で書いてください。

数字を並べる目的は、レビューの置き方を自分の数字で選べるようにすることです。論文の数字ではなく、自分の MR で何が起きたかを見ます。

Day1 3通りのレビュー

ハンズオン1で、同じ差分に3通りのレビューを当てます。順番は固定です。実装したセッションを最初に、履歴を切った側を後にします。

書き終えてから答える欄

履歴を捨てた別セッションのほうが自己レビューより当たる、という測定結果があります（Cross-Context Review で F1 28.6 対 24.6、自己レビューの2回目は 21.7）。自分の数字がこれと違う向きに出たら、そのまま書いてください。1件の MR で逆転することは普通に起きます。数字が一致しなかったことより、「履歴を切るだけで指摘が変わる」ほうが持ち帰る事実です。

Day1 委譲判定の集計

委譲判定シートの集計欄から転記します。

Day2 検出率

ハンズオン2で、仕込み欠陥がいくつあるかは Issue に書いてあります。レビューがそのうち何件を当てたかを数えます。

下の2行が、この日で一番使う数字です。REVIEW.md を書いて指摘が減り、検出率が落ちていなければ、基準が効いています。両方とも減っていたら、Do not report に入れすぎです。

テスト有無の比較

同じリファクタを、機能テストが無い状態と有る状態の2回頼みます。

Day2 夜間ループ

ハンズオン3で、1回目がどこで止まったかを記録します。止まらずに完走したら、その旨を書いてください。

止まった箇所の候補

当てはまるものに印を付けてから、上の欄を埋めてください。

最後に1枚書く欄

自分のハーネスが、5層のどこまで届いているかを1枚で見るための表です。点数を付ける表ではありません。空いている層を見つけて、次に何を足すかを決めるために使います。

対象は1人1式に絞ってください。複数のリポジトリを持っている方は、これから育てるほうを先に決めてから埋めます。

埋め方

判定は3つだけです。細かく刻むと、後で見返したときに比べられなくなります。

先に書く予想

点検表に進む前に、予想を書いてください。埋め終わったら、予想と結果の差を見ます。差が出た場所が、いちばん危ない場所です。

第1層 文脈

AI に読ませている決まりの層です。効き目は一番弱く、置き換えの対象を見つけるために点検します。

第2層 権限

ツールの呼び出しを、通す・確認する・止めるの3つに仕分ける層です。

第3層 フック

実行の直前に割り込み、コマンドの中身まで見る層です。ここが一番厚くできます。

第4層 CI

手元の設定と無関係に、提出のときに動く層です。手元を外した人にも効きます。

第5層 リポジトリ保護

手元の設定を全部外した人にも効く層です。

持ち帰る3行

埋め終わったら、3行だけ書いてください。ここが持ち帰るものです。

なお、第1層に「無い」が並んでいても、第3層と第4層が埋まっているなら危険な状態ではありません。逆に、第1層だけが埋まっていて他が空いている状態は、守っているつもりで何も止まっていない状態です。層の順番に埋める必要はありません。

2日間で作ったファイルを、自社ハーネスのどこに置くかを決めるための台帳です。Day1 の最後に7行、Day2 の最後に10行を埋めます。

演習で作ったものは演習リポジトリ（dl-training-app）の中にあります。そのままでは自社では動きません。この台帳の役目は、置き場所と担当と期日を1行ずつ決めて、研修が終わった翌週に手が止まらないようにすることです。

Day1

D1-2 の maxEffortLevel は v2.1.267 で追加されたキーです。持ち帰り先の Claude Code が古いと無視されます。反映日を決める前に claude --version を確認してください。

Day2

D2-4 の known_issues と patterns は、リリースレビュー側で既に動いているものをコードレビュー側へ写す作業です。新しく作る話ではありません。D2-8 から D2-10 は、理想的なハーネスの雛形の回（プチ演習7・8）で手元に残るものです。D2-10 は1層だけ書き換えたファイルなので、残りの層は反映日の欄に「次に直す層」として日付を入れてください。Day1 7点と合わせて17点になります。

研修後の宿題

自社ハーネスの側に残っていて、2日間では触らなかった箇所です。担当と期日だけ決めてから解散してください。

Day2 の終わりに、この雛形の上で A4 1枚を書きます。読む相手は、2日間の研修に出ていない運用メンバーです。

書けたかどうかの判定は1つです。作成者以外の1名が、このガイドだけを見て設定を1つ入れ直せること。入れ直せなければ、粒度が足りていません。

1. 何を

追加したものを、ファイル名で書きます。機能名では探せません。

2. どこに

置き場所と、効かせるための登録先です。ファイルを置くだけでは動かないものが混ざっています。

3. なぜ

1行ずつ、入れなかったときに何が起きるかを書きます。「品質向上のため」は理由になりません。半年後に外す判断ができません。

4. 壊れた時の戻し方

止まったときの見分け方と、戻す手順です。ここが書けていないと、最初のトラブルで全部が外されます。

止め方を「ファイルを消す」にしないでください。消すと、次に入れ直す人が最初から作ります。

5. 担当と連絡先

6. まだ入れていないもの

入れなかったものを書いておくと、次に足す人が同じ検討を繰り返しません。

書き終えた後の確認

レビュー工数を1つの数字で追うと、うまくいきません。工数は測る人の記憶に依存し、改修の大きさでばらつき、比較にならない数字が残ります。

代わりに、GitLab の MR データから機械的に取れる4つに限定します。人が入力する欄を1つだけ残し、残り3つはデータから取ります。入力欄が増えるほど、3か月後には誰も書かなくなります。

4指標

指摘2が、回答書に書かれた課題に一番近い数字です。「品質は上がったが工数削減は限定的」は、指標2が減らないまま指標1が増えている状態です。指標2を減らす手は、基準表を厳しくすることではなく、機械で判定できる指摘を CI 側へ移すことです。指標3が上がって指標2が下がれば、狙いどおりに動いています。

ビフォー値との突き合わせ

ビフォーは研修前の8週分です。突き合わせの前に、次の3つを揃えてください。揃っていない数字を並べると、施策の効果ではなく期間の性質を見ることになります。決めたものに印を付けます。

ビフォーとアフターの比較

ビフォー側にゲートジョブは存在しないので、4行目のビフォーは 0% です。0% から上がることが悪い変化ではありません。止まった分だけ、人の目を通らずに済んだということです。

アフターの初回値

ハンズオン2で数える「仕込み欠陥の検出数 ÷ 指摘の総数」を、アフター側の初回値として置きます。既知の欠陥が入ったコードに対して、レビューが当たるかを測る形です。過去の改修10本を使ったバックテストの代わりになります。patterns.md のタグ集計は補助です。タグを付けるのは人なので、主指標には置きません。

ビフォー値を正確に取るのは難しいという話が先方から出ています。8週分が揃わないときは、4指標の表だけを渡して、ハンズオン2の検出率を唯一の実測値として扱ってください。揃わない数字を埋めた表を作るより、実測が1つある表のほうが後で使えます。