Arduinoプロジェクトのルーブリック：評価表、提出シート、ポートフォリオ

Arduinoのプロジェクトを「動くかどうか」だけで評価すると、友だちのコードを写した生徒と、回路を3回組み直して自分でバグを見つけた生徒に同じ点をつけることになりかねません。より公平なArduinoプロジェクトのルーブリックは、5つの視点で見ます。回路（正しく、きれいに組めているか）、コード（生徒が意図して何かを変更できるか）、理解（先生が選んだ行を説明できるか）、デバッグの過程（動かなかったときに何をしたか）、そして記録と発表（自分のしたことを示せるか）です。回路、コード、記録は成果物を測り、理解とデバッグは過程を測ります。成績の半分以上が過程から決まるようになると、生徒は間違いを隠すのをやめ、説明するようになります。

この記事は、明日の授業にそのまま持っていけるテンプレート集です。6観点・4段階のメインのルーブリック、配点、1枚のプロジェクト提出シート、40分の提出授業、5分間の机上チェックリスト、自己評価と相互評価のシート、学期のポートフォリオ、そして1人の生徒の成績をステップごとに計算した例を収めています。例では、24人のクラスが3人ずつのグループで取り組む架空の場面を想定しています。毎週の授業で手早く観察するための3段階の短い表が欲しい場合は、8週間のロボットプログラミング授業計画のルーブリックを使ってください。以下のセットは、プロジェクトの最後につける成績のためのものです。

なぜ「動くかどうか」だけでは足りないのか：5つの視点

Arduinoのプロジェクトでは、成果物と学びがいつも同じところにあるとは限りません。LEDが順番に点灯する信号機は、生徒がコードを一度も読まずに書き込んだだけかもしれません。一度も点灯しない常夜灯は、生徒がシリアルモニタでセンサーの値を測り、しきい値の選び方がまずかったことを突き止めた試みかもしれません。それこそが、その授業で学ぶべきことです。だからこそ、ルーブリックを2つのグループに分けると役立ちます。成果物の側では、回路、コード、提出された書類を見ます。その証拠は机の上、紙の上、写真の中にあります。過程の側では、生徒の説明の仕方と、バグを探すときにたどる道筋を見ます。これは質問し、観察して初めてわかります。下の表は、各視点で何を見るか、そして証拠がどこから得られるかをまとめたものです。

メインのルーブリック：6つの観点、4段階のレベル、配点

5つの視点に、6つ目の観点として作業態度・安全・チームワークを加えました。グループで進めるArduinoの授業では、USBケーブルを挿したままワイヤーを差し替えたり、自分の役割を放り出して離れてしまったりすることも学びの一部です。どのレベルも観察できる行動として書かれています。「よく理解している」のようなあいまいな表現ではなく、「選んだ行を正しく説明し、それを変えると何が起きるかを言える」のように、机のそばで見て取れる内容です。あるセルの行動を一度確認できれば、その生徒をそのレベルに位置づけるのに十分です。2つのレベルで迷ったら、低いほうを短いメモとともに記録してください。次のプロジェクトで最初に確認するポイントになります。

配点には意図があります。成績の45%は成果物（回路、コード、記録）から、55%は過程（理解、デバッグ、作業態度）から決まります。理解の配点が最も大きいのは、コードを簡単に写せる授業では、生徒自身の説明こそが本当に学んだことを示す最も確かなしるしだからです。最初のころのプロジェクトでは、回路の組み立てを25%に上げ、コードを10%に下げてもかまいません。初めの数週間は、生徒はたいてい既成のコードを書き込むだけだからです。学期の後半になり、2つのプロジェクトを組み合わせたり自分で動作を加えたりし始めたら、コードを20%に上げ、回路を15%に下げるほうが理にかなっています。合計は100のままにして、プロジェクトを始める前に配点を生徒に伝えてください。何で点が取れるかを知っている生徒は、提出シートもより丁寧に書きます。

プロジェクト提出シートのテンプレート

提出シートは1枚で、グループがプロジェクトを見せる前に記入します。立派なレポートを作るためのものではなく、ルーブリックの証拠を1か所に集めるためのものです。部品リストと接続表は回路の観点を、変更した行はコードを、バグとその修正はデバッグを、写真と動画は記録を裏づけます。最後の行の「この行は何をする？」は、先生が自分で記入します。下の例は、BlueGraysの無料プロジェクトLDRで作る常夜灯を作った架空のグループのシートです。部品リストはプロジェクトの必要な部品セクションから、接続は回路図から取っています。テンプレートとしてコピーするときは、3列目を消してください。

「この行は何をする？」という質問の強みは、写したコードであっても、生徒が本当に理解していることが見える点です。グループのメンバーごとに別の行を選び、答えをシートの最後の行に書き込みます。よい行とは、プログラムの動きを変える行です。たとえばpinMode()、analogRead()やdigitalRead()、ifの条件、delay()です。波かっこや空行は選ばないでください。質問は2段階で行います。まず「この行は何をする？」、次に「この行の13を12に変えたらどうなる？」と聞きます。2つ目の質問に正しく答えられた生徒は理解が3、プログラム全体を順に説明できる生徒は4になります。既成のプロジェクトで行を選ぶときは、プロジェクトのコードを理解タブにあるステップごとの解説が、プログラムの中心となる行へすぐに案内してくれます。生徒の目線でこのタブを読む方法は、「コードを理解」と「自分で試す」で解説しています。

提出授業：40分で8グループを評価する

5分間の机上チェックリスト

このリストをA4に印刷し、1グループに1部使います。順番には意図があります。まず電源と回路、次にコード、口頭の質問は最後です。プロジェクトが動かなくても途中でやめないでください。残りの項目が、デバッグの観点の証拠を集めてくれます。1グループにかける時間は最大5分です。何回か提出を経験すると、ほとんどのチェックは4分で終わります。

• 電源：ボードがUSBで給電され、電源LEDが点灯している。
• 共通GND：ブレッドボードのマイナスのラインがArduinoのGNDピンにつながっていて、センサーとLEDが同じラインにある。
• 部品：LEDの向きが正しく（長い足がプラス側）、すべてのLEDの手前に抵抗があり、抵抗値がシートと一致している。
• 回路図との照合：使っているピンが、提出シートの接続表と完全に一致している。
• コード：ボードのコードに、シートに書かれた変更が含まれている。確信が持てない場合は、グループにもう一度書き込んでもらう。
• 動作：プロジェクトが想定どおりに動く。動かない場合は、グループがその理由か、今どのステップを試しているかを説明できる。
• 変更をその場で見せる：グループが変更した値を元に戻し、違いを見せる。
• この行は何をする？メンバーそれぞれが別の行について質問され、答えがシートに書かれている。
• バグ記録：このプロジェクトについて少なくとも1件の記録がある（症状、試したこと、修正）。
• 証拠：真上から撮った鮮明な回路の写真と、動いている様子の10〜20秒の動画がある。

自己評価シート

自己評価シートは、生徒が自分の学びを言葉にする助けになり、先生にとってはルーブリックと比べられるもう1つの視点になります。グループのシートではなく、生徒が1人ずつ記入します。最も大事なのは最後の列です。「はい」にチェックを入れた生徒には、証拠を1つ書いてもらってください。自己評価は成績には入りませんが、先生がつけたレベルと生徒のチェックが2段階離れていたら、その生徒と1分間話すよいきっかけになります。生徒が自分を過小評価していることもあれば、先生が見逃した場面を覚えていることもあります。

相互評価シート

相互評価シートは、グループ同士がお互いのプロジェクトを試しているあいだに記入します。最初にルールを決めておきましょう。点数はつけず、観察と提案だけを書きます。生徒がクラスメートを採点するのは公平でもなく、教室の雰囲気にもよくありませんが、「よかった点2つ、提案1つ」という形式なら、役に立つフィードバックの伝え方を学べます。必要なら、生徒が書いた提案の質をチームワークの観点の証拠として使うこともできます。記入済みのシートは、プロジェクトの持ち主のグループに返してください。それがポートフォリオに入る1部になります。

ポートフォリオ：学期を通して集めるもの

ポートフォリオが語るのは、1つのプロジェクトではなく学期全体の物語です。ある生徒の最初のLEDプロジェクトの提出シートと、最後のプロジェクトのシートを並べると、どんな数字よりもはっきりと成長が見えます。紙でもデジタルでもかまいません。大切なのは、どのプロジェクトでも同じ項目を同じ名前のつけ方で追加することです。デジタルのポートフォリオなら、学校ですでに使っているクラウドフォルダや学習プラットフォームで十分です。生徒ごとに1つのフォルダ、プロジェクトごとに1つのサブフォルダを作り、ファイル名はプロジェクト番号、プロジェクト名、バージョンの順で始めます。紙のポートフォリオなら、プロジェクトごとに仕切りを入れたリングファイルで十分です。

ポートフォリオで最も価値があるのはバグ記録です。デバッグの観点の証拠がそこにあるからです。各行は6つの問いに答えます。日付とプロジェクト、症状（何が起きたか）、最初の推測、試したこと（順番に）、本当の原因、次回どうするか、です。記入例：「11月12日、LDRで作る常夜灯。LEDがまったく点灯しない。推測：LEDが逆向き。LEDの向きを逆にしたが変化なし、値をシリアルモニタに表示した。本当の原因：教室の明るさに対してしきい値50は低すぎた。次回は最初にセンサーの値を測る。」学期を通して10〜15行たまった記録を見ると、その生徒がもうしなくなった間違いがわかります。コンパイルエラーも記録させましょう。よくあるエラーはArduinoのコンパイルエラーで調べられ、センサーの値の読み方はシリアルモニタの使い方で学べます。

アプリのデータ：BlueGraysでわかること、わからないこと

生徒が自分のスマホでBlueGraysを使っている場合、アプリのいくつかの機能は、評価に役立つ小さな証拠になります。どれにも共通するのは、生徒が自分の画面で先生に見せる情報だという点です。アプリが先生に別途送ることはありません。ですから、それだけで成績をつけるのではなく、会話のきっかけになり、ポートフォリオを補う証拠として使ってください。

• 作りました：生徒はプロジェクトを終えるとプロジェクトページのこのタイルをタップし、プロジェクトはマイ工房 > 完了したプロジェクトに入ります。ポートフォリオを確認するときにこのリストを開いてもらえば、学期中に作ったプロジェクトのすばやい索引になります。印をつけるのはワンタップなので、これは証明ではなく自己申告です。リストにある各プロジェクトについて、ポートフォリオに提出シートか写真があるかを確認してください。
• 「自分で試す」を使った口頭チェック：プロジェクトのコードを理解タブの最後にある自分で試すの課題は、「この行は何をする？」の一歩先にあります。課題を読み上げ、スマホを見ずに、どの行をどう変えるかを生徒に言ってもらいます。そのあとで実際に変更して書き込ませます。ヒントや解答を表示を使ったかどうかは正直に言うと、最初に約束しておきましょう。ヒントを使って解けたら理解は3、ヒントなしで解いて理由を説明できたら4とすることができます。
• 「困ったときは」と「トラブルシューティング」：「コードを理解」の困ったときはセクションや、プロジェクトにある場合はトラブルシューティングのリストを使って問題を解決していくグループは、デバッグの方法を身につけていることを示しています。どの項目がバグを見つけるのに役立ったかを聞き、バグ記録に書かせてください。
• 今日のクイズとマイレベル：毎日変わる問題セット、XP、そしてA1のはじめの光からC2の工房の達人までのレベルは、授業と授業のあいだも生徒が電子工作に触れ続けるよい方法ですが、成績にはしないでください。問題は家で1人で解くもので、レベルが下がることはなく、結果は生徒がどれだけ時間を割けるかで決まります。やる気を高めるために使いましょう。希望する生徒は週の終わりに新しいレベルをクラスでシェアできますが、誰にも強制はしません。

成績計算の例：1人の生徒の得点

LDRで作る常夜灯のプロジェクトに取り組んだグループで、Samさんが読み上げ係だったとします。提出授業での観察は次のとおりです。回路図を見てミスなく回路を組んだ（回路3）。しきい値は変更したが、新しい動作は加えなかった（コード2）。ifの行を説明し、しきい値を300ではなく600にすると、それほど暗くなくてもLEDが点灯すると言い、プログラム全体を順に説明した（理解4）。LEDが点灯しなかったとき、値をシリアルモニタに表示することを提案し、記録に書いた（デバッグ3）。提出シートに写真はあったが、接続表が抜けていた（記録2）。役割を果たし、隣のグループを手伝った（作業態度4）。得点の計算方法は2つあります。線形方式では、各観点の得点はレベルを4で割り、配点を掛けたものです。ゆるやかな換算では、レベルを1 = 50%、2 = 70%、3 = 85%、4 = 100%として数えるので、取り組み始めたものの苦戦した生徒が、ある観点でゼロに近い点になることはありません。

Samさんの成績は、線形方式では100点中77.5点で、四捨五入すると78点です。ゆるやかな換算では86.5点、つまり87点になります。どちらの方式を選んでも、学期を通して同じ方式を使い、最初のプロジェクトの前に生徒に説明してください。そのうえで、パーセンテージを学校の評定の尺度に当てはめられます。表は数字以上のこと、つまり次に何をすべきかを教えてくれます。Samさんの最も低い2つの観点はコードと記録です。次のプロジェクトでは、新しい動作を加えること（たとえば暗くなったらLEDに加えてブザーを短く鳴らす）と、接続表を助けなしで作ることを目標にできます。配点と換算をスプレッドシートに入れておけば、レベルを入力するだけで24人全員の成績がすぐに出ます。

公平な評価：グループ活動、動かない回路、写したコード

• グループ内の個人の貢献：成果物の観点（回路、コード、記録）はグループ全体に与えてかまいませんが、過程の観点（理解、デバッグ、作業態度）は常に個人ごとです。「この行は何をする？」でメンバーそれぞれに別の行を尋ねれば、この区別が自然に組み込まれます。役割（組み立て係、確認係、読み上げ係）はプロジェクトごとに交代させ、学期の終わりまでに全員がどの役割も少なくとも1回は担当するようにします。
• 動かない回路：提出時にプロジェクトが動かなければ、回路は最大2にしますが、過程の観点は下げないでください。体系的にバグを探し、記録し、どこで行き詰まったかを説明できる生徒は、デバッグで3や4を取れます。必要なら、次の授業までに1回だけ修正を認め、回路の得点を評価し直してもかまいません。
• 写したコード、既成のコード：既成のプロジェクトから始めるのは写すことではありません。授業ではもともと既成のコードを使います。本当の問題は、生徒がそのコードで何をしたかです。コードの観点は変更を、理解の観点は説明を見るので、ほかのグループから持ってきて理解していないコードは、その2行で自然に低い評価になります。シートの「どのプロジェクトから始めたか？」の行があることで、出どころを隠すのではなく明記する習慣が身につきます。
• チャットボットで書いたコード：家で取り組むプロジェクトでは、コードがAIツールで書かれていることもあります。禁止するのではなく、提出時の口頭チェックを増やしてください。点が入るのは、コードを書いた人ではなく、コードを説明して変更できる生徒です。
• 壊れた部品と欠席：グループのセンサーが壊れていたり、生徒が提出日に欠席したりした場合は、その日はルーブリックを記入せず、次の授業で机での短いチェックをして完成させます。教材が原因の問題が、生徒の成績に表れてはいけません。
• 全員が同じ表を知っている：最初のプロジェクトの前に生徒と一緒にルーブリックを読み、各レベルの例を1つずつ見せてください。レベルの説明を知っている生徒は、成績に異議を唱える代わりに、次のレベルに進むには何をすればいいかを尋ねるようになります。

初めてルーブリックを試すのに、大きなプロジェクトを待つ必要はありません。LDRで作る常夜灯や信号機のような1回の授業で終わるプロジェクトから始めて、提出シートとチェックリストを一度使い、そのあとで配点をクラスに合わせて調整してください。もっと長いプログラムの最後に評価を置く場合は、5日間のArduinoワークショップの記事にある3分間の発表テンプレートが、これらのシートとよく合います。生徒がBlueGraysでプロジェクトを開くなら、部品リスト、回路図、そして「この行は何をする？」の質問のもとになるコードを理解のステップがすでにそろっています。各プラットフォーム20件、合計60件の無料プロジェクトから始められ、プレミアムプロジェクトに進むときは、生徒一人ひとりがサブスクリプションを契約する代わりに、プロフィール > 教育者向けパッケージから、自動更新のない1回きりの5個または10個のコードパックを購入して配れます。