クイズで理解不足を見つけ、速度を調整する

読んだことと、理解したことは同じではありません

この章で話者が問題にするのは、コードを読むこと自体ではありません。読むと、その場では内容が分かったように感じます。しかし、あとで自分の言葉で説明したり、別の状況に使ったりできないことがあります。この状態を、ここでは「分かったつもり」と呼びます。

話者は、自分のコードレビューについて個人的な例を出します。エージェントが大きな変更を書いたとき、彼はまず説明文を読みます。それだけで理解した気になり、そのままチームメートにコードを送ってしまいそうになります。ところが、変更について質問されると、答えられない部分が見つかることがありました。読むという行為だけでは、自分の理解の穴が見えなかったのです。

ここで大切なのは、記憶と理解を分けることです。読んだ直後に用語や文章を思い出せても、コードの仕組みを理解したとは限りません。理解しているなら、少なくとも変更の目的や、主要な部分がどのようにつながっているかを説明できます。すべての行を暗記する必要はありませんが、仕組みについて質問されたときに考えられる状態が必要です。

説明文の最後に、五問のクイズを置く

この問題への話者の対策は、コード説明文（code explainer）の最後に、五問のクイズを埋め込むことです。質問の難しさは「中くらい」です。細かい知識を意地悪に試すテストではありません。説明を読んだ人が、変更の重要な考え方を本当に追えているかを確かめるための質問です。

話者の手順は次のようになります。

1. エージェントにコード変更を作らせます。
2. 変更の背景や仕組みを説明する文書を読みます。
3. 文書の最後にある五問に答えます。
4. 答えられない部分があれば、説明文やコードに戻って確認します。
5. 五問を通過してから、エージェントが書いたコードをチームメートにレビューしてもらいます。

つまり、クイズはレビュー依頼の前にあるゲートです。話者は、クイズに合格できるまではコードを送らない、と説明しています。これは、すべてのチームに必ず同じ手順を導入しなければならない、という発表ではありません。講演で紹介された、話者自身の実践です。

この手順の目的は、点数をつけることではありません。答えられない質問が、説明文をもう一度読むべき場所を教えてくれます。話者は、このクイズを使うと自分の理解不足が何度も明らかになった、と述べています。したがって、クイズは他人を評価する道具である前に、自分の「分かったつもり」を発見する道具です。

図2　コード説明文の下に置かれた五問クイズ。最初の答えと、正解についての説明が表示されています。

この画面は、コード説明文の内容を五つの質問で確かめる例です。最初の答えを選んだあとに正解と説明が表示されるため、単に正誤を記録するだけでなく、理解を確認する流れになっています。講演では 11:07 に、このクイズの画面が示されます。

思い出す練習を、あとからもう一度行う

講演では、読んだあとに答えるインタラクティブなエッセイの例も紹介されます。その例は、文章を読んだかどうかだけでなく、読んだ内容を思い出せるかを確認します。さらに、あとで同じ内容を思い出すための、間隔を空けた復習（spaced repetition）も話に出てきます。

間隔を空けた復習とは、読んだ直後に一度だけ確認するのではなく、時間を置いて思い出す方法です。たとえば、変更の説明を今日読んだら、後日その変更の目的や仕組みについて質問に答えます。すぐに答えられなければ、説明に戻ります。この流れによって、知識を一時的に見た状態から、あとで取り出せる状態へ近づけます。

ただし、講演で紹介された外部の文章、クイズの実装、復習の通知がどのくらい続くかについては、この講演の情報だけでは確認できません。ここで確実に言えるのは、話者が説明とクイズを一回限りの読書で終わらせず、あとから思い出す仕組みと結びつけて考えていることです。

図1　講演で示された、量子ビットの状態空間について質問と答えを表示する復習カード。

この画面は、質問の答えを表示したあと、どの程度思い出せたかを選ぶ形式のインタラクティブな復習を示しています。したがって、読むだけでなく、いったん自分で答えを出し、その結果を確認する流れが見えます。これは、説明文を読んだという事実と、内容を取り出せるという能力を分けて確認する例です。動画では 10:48 にこの画面が示されます。

クイズは「速度調整器」になる

AIエージェントを使うと、コードを書く速度を大きく上げられます。しかし、作成が速くなっても、人間の理解が同じ速度で進むとは限りません。理解を確認しなければ、変更を作る工程だけが速くなり、人間が内容を追う工程は置き去りになります。

話者は、クイズをこの流れの速度調整器（speed regulator）として説明します。自動車の速度調整器が、車をただ速くするのではなく、設定した速度に保つように、クイズはAIによる加速に理解の確認を組み込みます。コードが正しく動くかを調べるだけではなく、人間が変更を理解しているかも確かめます。

ここでいう「正しさ」と「理解」は別のものです。テストが通り、仕様に合っていても、コードをレビューする人が変更の考え方を説明できるとは限りません。反対に、クイズで理解の穴が見つかったとしても、それだけでコードが間違っているとは限りません。クイズは、正しさの検査を置き換えるものではなく、正しさの検査に理解の確認を加えるものです。

例：レビューを急ぐ前に止まる

**例（説明のために作ったもの）**として、エージェントがログイン画面を変更したとします。説明文を読んだあと、次のような五問に答えます。

• この変更は、利用者のどんな問題を解決しますか。
• 画面の状態は、どの部分で管理されていますか。
• エラーが起きたとき、どの処理へ進みますか。
• 変更しなかった部分は、なぜそのままでよいのですか。
• この変更を別の画面に広げるとき、何に注意しますか。

これらは、この講演で実際に出された質問ではありません。クイズがどのように理解を確認するかを示す、教師が作った例です。答えが曖昧なら、レビュー依頼を急がず、説明文や変更内容に戻ります。答えられるようになって初めて、チームメートとより具体的な議論を始められます。

なぜ「クイズはばかばかしい」と考えないのか

大人の開発者にクイズを出すと、学校のテストのようで幼く感じるかもしれません。しかし、話者の経験では、クイズは自分の理解不足を繰り返し見つけました。重要なのは、クイズに合格することそのものではありません。自分がどこまで分かっていて、どこから分かっていないかを、コードレビューの前に知ることです。

AIを使う仕事では、「動いた」「テストに通った」「説明を読んだ」という結果だけで、理解したと判断しやすくなります。五問の確認は、その判断を少し遅らせます。この小さな停止によって、人間は変更の内容に戻り、質問を作り、必要ならエージェントに説明を求められます。そうすれば、AIの速度を捨てずに、人間が仕事のループから外れることも防げます。

この章の要点は、クイズを評価のためだけに使うことではありません。クイズは、読書が生む「分かったつもり」を表面に出します。そして、理解をコード作成やレビューの速度に合わせるための、実際の制御点になります。AIがコードをさらに速く作れるようになるほど、こうした制御点を意識的に置く意味は大きくなります。