PBLグループのただ乗り、役割と記録で防ぐ設計

プロジェクト型学習をやったことのある先生なら、だれもが目にする場面があります。発表は立派なのに、実はグループの一人か二人が全部やっていて、残りは名前を連ねただけ、という場合です。4人のグループなのに実質的な貢献者は1.5人ほど、というのも珍しくありません。ただ乗りは生徒の人柄の問題ではなく、たいていは設計の問題です。だれが何を担当したのかが不明確で、貢献が見えず、評価が成果物一つだけにかかっているとき、ただ乗りは合理的な選択になります。何もしなくても同じ点数がもらえるのなら、やらないほうが得だという計算が成り立つからです。構造を変えれば行動が変わります。

ただ乗りを減らす構造的な仕掛け

次の仕掛けは、「がんばりなさい」という小言よりはるかに効果的です。

• 相互依存する役割: 資料調査・設計・検証・発表のように、一人が抜けると進行が止まる役割に分けます。役割が独立していると、分業ではなく分離になってしまいます。
• 個人の成果物を必須にする: グループの成果物とは別に、各自が自分の役割の中間成果物を提出するようにします。貢献が目に見えるようにします。
• 貢献ログの記録: 毎コマ「今日自分がやったこと」を一行ずつ残します。この記録が評価の証拠であり、振り返りの材料になります。
• 役割の交代: 長いプロジェクトであれば途中で役割を一度入れ替え、特定の役割に紛れて過ごすことを防ぎます。

ただ乗りを防ぐ最も確実な方法は監視ではなく、やらなければそれが見えてしまう構造をつくることです。

AIを貢献の可視化に活用する

貢献ログを人が一つひとつ追いかけるのは負担です。AIを補助として使えば、その負担は軽くなります。

1. ログの要約: 生徒が残した一行の貢献をAIが集め、グループ別・個人別の活動の流れとして要約します。
2. 偏りの検知: 特定の生徒のログが何日も空いていれば、先生に信号を送ります。点数を減らすためではなく、面談すべきタイミングを知るためです。
3. 振り返りの問いの生成: プロジェクトの終わりに、各自のログをもとに「最もつまずいた瞬間と、その解決方法」を尋ねる個人の振り返りの問いをつくります。
4. 自己評価・相互評価の補助: 相互評価の点数と実際のログが大きく食い違っているとき、先生が確認すべき点を指し示します。

ここでAIは、判断ではなく観察を助ける役割にとどまるべきです。「この生徒はただ乗りをした」という結論は、ログと面談を総合して先生が下します。ログが空いているからといってすぐに減点してしまえば、たくさん働いたのに記録を残さなかった生徒が割を食うことになります。AIが示した信号はあくまで面談を始める地点にすぎず、点数を減らす根拠ではないという線を、はっきり引いておく必要があります。

まとめ

PBLのただ乗りは、意志ではなく構造で解く問題です。一人が抜けると止まる相互依存の役割、個人ごとの成果物、貢献ログという三つの仕掛けをそろえるだけでも、紛れて過ごすことは難しくなります。AIはログを要約し、偏りを検知して先生の観察を助けますが、評価の判断は人が下します。次のプロジェクトでは、成果物の評価の比重を少し下げ、毎コマ一行の貢献ログを取り入れてみることをお勧めします。貢献が見え始めると、まずグループの空気が変わります。