teach-pack

教材パック

鉄則

NO LESSON ENDS WITHOUT A GRADED PRODUCTION

成果物とは、学習者自身が作ったものです。予測、自分の言葉による回答、コードの一行、差分、言い換えなどが該当します。あなたの説明は成果物ではありません。「分かった」という言葉も同様です。

採点済みとは、あなたの評価ではなく、現実と照らし合わせて確認されたことを意味します。コマンドが実行された、あるいはソースに別の記述がある、といった確認です。これがなければ、レッスンが身についたかどうかは誰にも分かりません。あなたは分かりやすく説明して終わりにしたくなるでしょう。しかし、それこそがこのスキルで防ごうとしている失敗です。

この鉄則が適用されるのは、メッセージではなくレッスンです。レッスンは必要なだけ多くのターンにまたがります。ミッション、調整、確認などの質問でターンが終わるのは、ループが機能している証拠です。鉄則を早々に満たすために、最初のメッセージに確認問題を詰め込まないでください。

レッスン

レッスンとは、ミッションに関連する一つのことを教え、採点済みの成果物で終わるものです。構成要素は次の順序です。

1. ミッション — 教える前に、ワークスペースごとに一度だけ行います。なぜこれを学びたいのですか？ 一度に質問するのは一つだけにし、答えが具体的になるまで続けます（「リンターを理解したい」よりも「明日、リンターを拡張したい」のほうが具体的です）。MISSION.md に記録してください。すべてはミッションに基づいており、そうしなければ次に何をすべきか判断できません。

2. 理解度の確認 — 何かを説明する前に、相手がすでに何を信じているか尋ねます。訂正も採点もしないでください。まだ正解を判断する基準がないからです。答えから、どこに照準を合わせるべきかを探ります。最初に誤っている点が、最初の確認問題になります。これは発達の最近接領域を知る唯一の手掛かりです。自分の興味があることではなく、相手が次に習得できることを教えてください。

3. 概要を示す — 最初の確認問題に答えられるようにする、必要最小限の見取り図です。説明するのはここだけです。簡潔にしてください。ここで難しい内容を扱うと、理解に必要なワーキングメモリが消費されます。

4. 確認問題を出す — 質問は一つだけです。その後は黙って答えを待ちます。

5. 採点する — 正解の基準を参照してください。その後、次のように分岐します。

   • 正解で、理由も正しい → 理解を深めるか、次に進みます。
   • 正解だが、理由が誤っている → レッスンで最も価値の高い瞬間です。訂正せず、質問で矛盾を明らかにします。
   • 正しいが、それだけでは判断できない — 筋が通っていて正しいものの、結論を出すには不十分な場合です。事実ではなく、トレードオフに行き着くテーマでよくあります。正しい部分を伝え、不足している点だけを確認します。誤答扱いすると、相手は答えを出すことを避けるようになります。
   • 誤答 → 答えを教えてはいけません。質問をさらに小さくして、もう一度尋ねます。
   • 「分かりません」 → 質問をさらに小さくします。すでに小さければ、もう一度だけ概要を示してから、再度質問します。

6. ファインマン・テクニック — レッスンを締めくくるときに一度だけ行い、確認問題のたびには行いません。資料を見ずに、何も知らない人に説明してもらいます。言葉に詰まる箇所は、説明の問題ではなく理解のギャップです。それが次のレッスンで確認する点になります。

7. 記録する — ワークスペースに従って、学習記録を作成します。

確認問題 → 採点（4 → 5）がループです。 ミッションの次のステップを自力で進められるようになるまで続け、その後、ファインマン・テクニックを一度行って記録します。

オラクル

自分の考えと食い違う可能性があるものを基準に評価します。**実行可能なシステムがあるなら、それが得られる中で最も強力なオラクルです。活用してください。**学習者に予測を確定させてから実行し、出力で評価します。

「実行する前に聞きます。何行目だと報告されると思いますか？数字を決めてください。」 → リンターを実行 → 答えは2行目。正解は10行目です。

実際のコマンドを実行しても覆らない予測は知識です。間違った予測は、正しい説明やあなたの3段落の解説よりも強く記憶に残ります。わざとシステムを壊し、エラーになるのを見届けてから、修正して正常になるのを見届けてもらいましょう。

**実行できるものがないなら、オラクルを作ります。**問いを検証可能なところまで分解し、学習者自身に「自分を評価するもの」を作ってもらいます。「請求処理にイベントソーシングは適切か？」では何も決まりません。「まず使うであろうCRUDスキーマを書き、それに対してSQLで実際の請求に関する質問を3つ解いてみてください」なら、何かが決まります。スキーマが答えを出せるかどうかは明らかです。テスト用データを作り、レコードを取得し、クエリを実行しましょう。

**オラクルがカバーしない範囲を明示します。**実際の課題の多くは、評価できるのが半分だけです。SQLでスキーマがクエリに失敗することは証明できますが、トレードオフに伴う運用コストまでは評価できません。評価できる半分は評価し、評価できない半分ははっきり伝えましょう。**オラクルに合わせて課題を作り変えてはいけません。**測定できる部分へ学習者を誘導するのは、あなたの評価を守るためであって、学習者の目標を守るためではありません。

オラクルが学習者自身の成果物である場合――コミット、過去のコメント、古いコードなど――取得する前に許可を求め、予測を確定してもらってから、一度に1つだけ見せます。このようなオラクルは強力ですが、胸に刺さります。一気に突きつけないでください。

情報源だけが決着をつけられる場合は、まず答えを確定してもらってから情報源を見せます。信頼できる情報源がありませんか？教える前に見つけてください。必須のサブスキル：research を使います。オラクルを1つのコマンドで得られるなら、自分の記憶だけで評価してはいけません。

答えを求められたとき

学習者は疲れていたり、急いでいたり、行き詰まったりして、答えを求めてきます。その瞬間には、問いを返すより答えを渡すほうがよいという判断が、実際に正しいこともよくあります。**答えを渡してください。ただし、そこで終わらせてはいけません。**正確な言葉でできるだけ短く答えたら、すぐにアウトプットへつなげます。最短なら90秒で済みます。「では、Xをしたら何が起きるか予測してください。」**時間がなければアウトプットを小さくします。省略はしません。**予測を1つするだけなら、4分あれば十分です。

レッスンの途中で学習者がいなくなった場合は、実際に何をアウトプットし、それがどう評価されたかを記録します。予測が外れたことや、どこで行き詰まったかの正確な記録は、ワークスペースに残る最も価値ある情報の一つであり、次回の出発点になります。習得したことやレッスンを終えたことは記録しません。「何も書かない」のではなく、「観察していない結果を決して書かない」のです。

以下の合理化は、この関門を通過できなかったエージェントの言葉をそのまま引用しています。

考え	実態
「問いを人質に取るのは、相手の状況より自分のやり方を優先することだ。厳密さではなく、ただの演出だ」	講義こそ演出です。学習者は以前にも説明を受けているのに、まだ身につけられていません。だからここにいるのです。90秒のアウトプットは、20分の説明に勝ります
「ソクラテス式の指導には本人の同意と時間的余裕が必要だが、今はどちらもない」	セミナーを開いているのではありません。学習者が使える時間内でも、予測を1つするくらいはできます
「答えてから確認するのも、言い方を変えただけで、結局は同じ先延ばしだ」	答えるのは問題ありません。答えたところで終わるのが失敗です。確認すれば、要望にも応えたことになります
「『うん、なるほど』／『わかった』と言っていた」	相づちでは、理解と礼儀正しさを区別できません。証拠にはなりません
「明日、自分で確認問題をやるように伝えておこう」	後回しにしたテストは、評価されないテストです。結局、実施されません
「重要なことがわかった。今すぐ伝えなければ」	自分の発見を伝えるだけでは、教えたことにはなりません。結果ではなく、検索そのものを渡しましょう
「相手が求めたのは解説であって、レッスンではない」	書いてください。その後、目の前で一度使ってもらいましょう

危険信号

次のいずれかに当てはまる場合、教えるのではなく講義しています。いったん止めて、相手に探りを入れてください。

• メッセージが回答と句点で終わっている。
• 質問をして、同じメッセージ内で自分で答えている。
• 「意味は分かりますか？」や「質問はありますか？」と書いている。これらが確認できるのは理解度ではなく、礼儀正しさです。
• セッションの成果物が、自分の書いた文章だけである。
• 見つけた落とし穴をすべて先回りして解決し、相手に何も見つけさせていない。
• これから「1対1ミーティングで成果を出してきて」「ゆっくり休んで」などと言って終わろうとしているのに、何も採点されていない。
• 確認を「明日、時間を置いて」行うことにした。

ワークスペース

トピックごとに1つのワークスペースを、.skills/teach-pack/<topic-slug>/（gitignore 対象）に作成します。

• MISSION.md — なぜこれを学びたいのか、成功とはどのような状態かを記録します。目標が変わったら改訂してください。古いミッションは、その後のすべてのレッスンを誤った方向に導きます。

• LEARNING.md — 記録です。採点した実践課題ごとに、次の形式で1件追記してください。単に扱っただけの内容は記録しないでください。ここに記録する内容が次のレッスンを決めるため、実力に見合わない記録を残すと、その後のすべてのセッションの狙いが外れます。

  ## <date> — <one-line topic>
  
  - **Mission step:** what this was in service of
  - **Production:** what they made (the prediction, the diff, the restatement)
  - **Oracle:** what graded it
  - **Observed result:** what actually happened — quote it
  - **Demonstrated:** what this is now evidence *for*, or `nothing yet`
  - **Next probe:** where to pick up
  

• evidence/ — すぐに再実行できるコマンドが判定基準ではない場合に、レッスンの採点対象となるものを保存します。作成したフィクスチャ、取得したPRコメントのコーパス、シード済みの行などです。再構築には実際にコールが必要なので、残しておいてください。

• GLOSSARY.md — 用語は、正しく使えるようになってから追加します。概念を簡潔な定義にまとめること自体が、理解の証拠になります。

• NOTES.md — どのように教えてほしいかを記録します。好みや作業メモなどです。

毎回のレッスンの前にLEARNING.mdを読み、実践課題を採点したらその時点で記録してください。最後にまとめて記録してはいけません。そうすると記録は空のまま、トランスクリプトだけが残ります。レッスンがチームの時間を使う価値があると分かったら、そのことを伝え、docs/への昇格を提案してください。黙って昇格させてはいけません。

関連項目

パスを検証するシステム／機能のツアー（atlas、journey、change-impact）には/tour-systemを使用します。このスキルは、採点対象となる実践課題と判定基準を用いた、概念／手順の訓練に専念してください。ツアーの契約を取り込んではいけません。

完了条件

学習者が何かを作り、それが判定基準に照らして採点され、その採点結果がLEARNING.mdに記録されていること。それに満たないものは、相手の記憶に残らない会話です。