Arduinoで進めるプロジェクト型学習（PBL）：4週間の単元例

Arduinoで進めるプロジェクト型学習は、講義のあとではなく、実際の問題を解こうとする中で生徒が内容を学ぶ単元設計です。流れは5つの段階からなります。まずドライビング・クエスチョンを投げかけ、チームが問題を調べて何を測るかを決め、Arduinoでプロトタイプを作り、校内でテストして改良し、最後に分かったことを実際の聞き手に発表します。この記事の単元例のドライビング・クエスチョンは「学校のエネルギー、水、騒音、教室の空気の問題をどうやって測り、どう知らせればよいか？」です。4週間で各チームがこのうち1つの問題を選び、センサーで測り、しきい値を超えると警告を出す動く装置を作り、集めたデータをもとに学校へ提案をします。

以下に、明日すぐ授業に持っていけるものをすべてまとめました。週ごとの単元表、まとめの質問つきの授業ごとの流れ、4つの問題シナリオとBlueGraysのスタートプロジェクト、材料リスト、チーム契約と役割、プロトタイプのサイクルとテスト記録のテンプレート、中間チェックと最終発表の評価基準、PBLでよくある落とし穴、チェックリストです。例はすべて同じ前提で作っています。24人のクラス、週2コマ（2 × 40分）、4人ずつの6チームとします。スキルを順番に教える計画を探しているなら「8週間のロボットプログラミング授業計画」、短く集中したプログラムなら「5日間のArduinoワークショップ」のほうが向いています。この単元は、それらのあと、生徒がすでにLEDを点灯させ、センサーを読んだ経験がある段階でいちばん効果を発揮します。

プロジェクト型学習とは？プロジェクト課題との違いは？

従来の順番では、まず内容を教え、学んだことを示すために最後にプロジェクトを出します。プロジェクトはデザートであって、食事ではありません。プロジェクト型学習ではこの順番が逆になり、プロジェクトそのものが授業になります。生徒はanalogRead()やしきい値、平均の取り方を、問題を解くために必要になったその瞬間に学びます。Arduinoはこの方法によく合います。現実の世界を数値に変えてくれるからです。LDRは廊下の明るさを、サウンドセンサーは食堂の騒音を、DHT11は教室の温度を測ります。プロトタイプは安く、数分で変えられます。しきい値が違っていれば、コードの数字を1つ変えて書き込み直すだけです。そのおかげで、PBLの中心にある「試す、測る、直す」のサイクルが1コマに収まります。違いを表にまとめます。

ドライビング・クエスチョン：単元を支える1文

ドライビング・クエスチョンとは、4週間ずっと教室の壁に掲示され、どの授業も「今日はこれにどう近づいた？」と結びつける問いです。この単元では、どのチームも自分の担当部分を選べるように、共通の問いをわざと広くしています。「学校のエネルギー、水、騒音、教室の空気の問題をどうやって測り、どう知らせればよいか？」。1週目の仕事は、この広い問いをチーム自身のサブクエスチョンに絞り込むことです。「学校でのエネルギーの無駄」はサブクエスチョンではありません。「休み時間に空いている7Bの教室で、照明は何分間ついたままになっているか。誰に、どうやって知らせればよいか？」はサブクエスチョンです。よいサブクエスチョンの答えは、数値で始まり、装置で終わります。チームのサブクエスチョンを承認する前に、次の6つの基準で確認してください。

• 現実的：学校で実際にこの問題に困っている人がいて、チームがそれが誰かを言える。当番の先生、学校の職員、食堂のスタッフ、学級委員など。
• 測定できる：手元のセンサーで問題を数値にできる。明るさ、音の大きさ、土壌水分、温度、距離など。
• 身近で範囲が狭い：場所と時間帯が1つに決まっている。「学校」ではなく「2階の廊下、昼休み」。
• 答えが1つでない：答えが「はい」か「いいえ」ではなく、「どのように」「いつ」「どれくらい」を問っている。
• 4週間に収まる：解決に商用電源の配線に触れること、学校のネットワークへの接続、予算の承認待ちが必要ない。
• 警告で終わる：装置は測って黙っているだけではなく、しきい値でLED、ブザー、ディスプレイを使って誰かに知らせる。

4週間のプロジェクト型学習の単元

計画は8コマを基本にしています。週2コマ、1コマ40分です。各週はPBLの5つの段階に沿って進みますが、調査とプロトタイプの間に厚い壁はありません。2週目でもまだ問題を絞り込んでいるチームがあってもよく、3週目に新しい測定から新しい調査の問いが生まれることもあります。大切なのは、各週の終わりに表の成果物がそろっていることです。先生の役割も週ごとに変わります。最初は問いを投げかける人、途中はコーチ、最後は聞き手を教室に招く進行役です。

次の表は、同じ計画を授業ごとに分けたものです。各授業の最後の3分はまとめの質問にあて、チームは1文の答えをテスト記録の下に書きます。この答えは次の授業のウォームアップになり、最終発表では過程の証拠になります。ミニ講義は10分以内にしてください。それより長くなるとチームの作業時間が削られ、単元はいつの間にか従来の授業に戻ってしまいます。

4つの問題シナリオとBlueGraysのスタートプロジェクト

チームにゼロからコードを書くことを期待しないでください。PBLの目的は問題を解くことであって、1行目からプログラムを書くことではありません。BlueGraysには、どのシナリオにも回路図、部品リスト、コードがそろったスタートプロジェクトがあります。チームはそれを組み、理解し、自分たちの問題に合わせて変えます。表の無料プロジェクトは誰でも使え、プレミアムのプロジェクトにはプレミアムが必要です。6チームなので、1つのシナリオを選べるのは2チームまでにしてください。同じシナリオの2チームが別の場所を測れば、発表で比較もできます。

2つの点については、最初から生徒に正直に伝えてください。1つ目は、KY-038はデシベル計ではないことです。マイクが拾った揺れを0〜1023の数値に変えるだけです。チームは「食堂は85 dB」とは言えませんが、「昼休みの食堂は空いている教室よりずっと高い値になる」とは言え、その差を数値で示せます。PBLには比較のデータで十分です。センサーの反応や調整方法は「KY-038サウンドセンサー」の記事にあります。2つ目は、DHT11が測るのは温度と湿度であって、空気のこもり具合ではないことです。閉め切った教室で実際に増えるのは二酸化炭素です。教室の空気チームは、温度と湿度をもとに「窓を開けよう」という提案を組み立て、発表で「次のステップはCO2の測定」と伝えればよいでしょう。エネルギーチームと水チームのセンサーについては、「LDR光センサー」と「土壌水分センサー」の記事でキャリブレーションを詳しく説明しています。

材料リスト：6チーム＋予備1セット

チーム契約と役割

4人のチームで全員に仕事がないと、いちばん手の早い生徒が作業をして、ほかの生徒は見ているだけになります。いちばん簡単な対策は、4つの役割と毎週のローテーションです。4週間、4つの役割で、全員がどの役割も1回ずつ担当します。役割は「これだけをやる」という意味ではなく、「これについて責任を持つ」という意味です。コードを書くのはコード係だけではありませんが、その週にコードが何をしているかをクラスに説明するのはコード係です。契約は1回目の授業でチーム自身が書きます。先生は下の項目を必須にし、4人全員が署名したら承認するだけです。

• 私たちのサブクエスチョン：..................................................（1文、1つの場所、1つの時間）
• 成功の基準：..................が..................を超えたら、私たちの装置は..................で知らせます。
• 役割（1週目）：プロジェクトマネージャー........、回路........、コード........、データ・記録........。役割は毎週1人ずつずらします。
• 決め方のルール：意見が合わないときは、まず測ります。測定がなければプロジェクトマネージャーが決め、その決定をテスト記録に書きます。
• 助けを求めるルール：先生のところに行く前に、回路図、プロジェクトの「コードを理解」の欄、チームメイトを確認します。
• 欠席：授業を休んだメンバーは、次の授業でテスト記録を読み、2分で追いつきます。その週の仕事はほかの人が引き受けます。
• 署名：.............. .............. .............. ..............

プロトタイプのサイクル：最小限の動作版

PBLの単元がいちばんよくつまずくのは、チームが最初の2週間を完璧な装置の設計に使ってしまうときです。ルールは簡単で、4回目の授業の終わりまでに、どのチームも最小限の動作版を持っていなければなりません。この版がすることは3つです。センサーを読み、値をシリアルモニタに表示し、値がしきい値を超えたらLEDを1個点灯させます。箱もディスプレイもWi-Fiもありませんが、実際のデータを出し、テストできます。騒音チームにとっては、LDRで光の強さを測定のコードにif文とLEDを1つ加えることです。エネルギーチームにとっては、LDRで作る常夜灯がほぼこの版そのものです。ただし論理が逆になります。LEDは暗いときではなく照明がついているときに点灯し、「部屋は空いている？」という問いは次の版でPIRとともに加わります。その後の版では、どれも変更を1つだけ加え、テスト記録に書きます。

1. バージョン0、測定：センサーを読み、1秒に1回値をシリアルモニタに表示します。手、光、音、水で値が変わることをチームが確認します。
2. バージョン1、最小限の動作版：推測したしきい値とLED1個。しきい値を超えるとLEDが点灯します。4回目の授業の中間チェックで見せるのはこの版です。
3. バージョン2、キャリブレーション：現場での測定のあと、しきい値を推測ではなくデータから選びます。たとえば、空いている教室の値と休み時間の値の中間です。
4. バージョン3、安定した警告：値がしきい値の近くを行き来すると、LEDがちらつきます。対策は、直近10回の測定の平均を取るか、点灯用と消灯用に2つの別々のしきい値を使うことです。
5. バージョン4、使う人に合わせる：警告を、問題の影響を受ける人に合わせた形にします。食堂なら誰からも見える3色のランプ、教室なら先生の机の上の小さなLCD。箱詰めと設置はこの版で行います。

中間チェックと最終発表の評価基準

回路、コード、理解、デバッグ、記録といった一般的な基準には、「Arduinoプロジェクト評価のルーブリック」の記事の基本ルーブリックをそのまま使えます。PBLの単元では、そこに3つの基準を加えるだけで十分です。これらは、プロジェクト課題では測らないけれど、この単元が本当に教えていることを測ります。中間チェックは4回目の授業で行い、問題の定義と最小限の動作版だけを見ます。目的は成績をつけることではなく、方向を修正することです。最終発表では3つの基準すべてを採点します。単元の最後に際立ったプロトタイプは、科学コンテストに出すこともできます。テーマのアイデアは「Arduinoの科学コンテスト向けプロジェクトアイデア」の記事を参照してください。

• 問題（30秒）：サブクエスチョンと、インタビューした人が問題を説明した1文。
• 測定（45秒）：どこで、いつ、何回測ったか。表かグラフを1つだけ。
• ライブデモ（45秒）：聞き手の前で装置がしきい値を超え、警告を出す。予備として短いデモ動画も用意しておく。
• バージョン（30秒）：テスト記録から決定を1つ：「この測定のためにしきい値を変えました。」
• 提案（30秒）：学校への具体的な提案（どこに、装置を何台、誰が管理するか）と、あと1週間あったら何をするか。
• 質疑（2分）：先生や聞き手が、自分で選んだチームメンバーに質問する。そのため、全員がどの部分も説明できなければならない。

この単元でBlueGraysは何に役立つ？

• プロジェクトさがしでスタートプロジェクトを選ぶ：2回目の授業でチームは3つの質問に答えます。「何を作りたいですか？」には計測と検知、ボードにはArduino Uno / Nano、経験にはたいていのクラスで「いくつか作ったことがあります」を選びます。結果画面には、最もおすすめのプロジェクトと並んで、同じ部品で始められる無料の練習用プロジェクトが表示されることもあります。詳しくは「プロジェクトさがし」の記事にあります。
• 「コードを理解」でコードを理解する：スタートプロジェクトのコードをコピーして先に進むだけでは、PBLではうまくいきません。チームはそのコードを変えることになるからです。コードを理解タブは、まず「このコードの働き」の要約を、次にステップごとの解説を、最後に変更を1つだけ求める自分で試すの課題を示します。無料のプロジェクトでは誰でも使え、プレミアムのプロジェクトではプレミアムでロックが解除されます。使い方は「「コードを理解」のガイド」の記事で紹介しました。
• マイ工房 › 部品で部品を計画する（プレミアム）：教室の棚にある部品を数量とともにマイ工房 › 部品に登録すると、作れるプロジェクトと部品が不足しているプロジェクトのリストで、どのシナリオが今日から始められ、どれに注文が必要かが分かります。詳しくは「手持ちの部品で作れるArduinoプロジェクト」の記事にあります。
• 先生自身の見本プロジェクト：単元の前に、シナリオを1つ自分で組み、学ぶ > フォーラム > 新しい投稿からチュートリアルカテゴリーでシェアできます。回路の写真（最大5枚）を追加し、「コードを追加」でコードを入れ、関連する既成のプロジェクトをリンクします。投稿は書いた言語で公開されます。シェアでリンクをクラスのグループに送りましょう。既成のプロジェクトも、プロジェクトページの「シェア」で同じように渡せます。手順は「自分のプロジェクトで授業をする」の記事にあります。
• クラスのプレミアムアクセス：スマート水やりステーションのようなプレミアムのスタートプロジェクトやマイ工房 › 部品のために、生徒一人ひとりに別々のサブスクリプションは必要ありません。生徒がカードを登録せずに利用できる、1回限りで自動更新されない教育者向けパッケージについては、「クラス全員分のプレミアムコード」の記事で説明しました。

アプリにできないことも知っておいてください。BlueGraysには、クラスの作成、チームの進み具合を先生に見せる管理画面、課題の配布機能はありません。問題カード、チーム契約、テスト記録は、紙か学校で使っている共有ドキュメントで管理します。アプリが担うのは単元の「どう組む？コードは何をしている？どの部品が足りない？」の部分で、「なぜこのしきい値？誰の役に立つ？」の部分はチームと先生の仕事です。この分担はPBLにも合っています。考える作業は画面ではなく、チームの中に残るからです。

PBLでよくある落とし穴と対策

単元前のチェックリスト

• ドライビング・クエスチョンをポスターに書き、教室に掲示している。
• 4つのシナリオカード（問題、使えそうなセンサー、スタートプロジェクト）を全チーム分コピーしている。
• 7セットを数え、どのセンサーも一度試してシリアルモニタに値が出ることを確認している。
• パソコンにArduino IDEとボードのドライバをインストールし、USBケーブルを試している。
• スタートプロジェクトが生徒のスマホやタブレットで開ける。プレミアムのプロジェクトを使う場合は、コードを配っている。
• 問題カード、チーム契約、テスト記録の用紙を全チーム分印刷している。
• 校内めぐりと現場での測定について学校の管理職の許可を得ていて、食堂、廊下、校庭の測定時間が決まっている。
• 最終発表の聞き手（学校の管理職、学校の職員、ほかのクラス）を招待し、日程を伝えている。
• 中間チェック（4回目の授業）と最終発表（8回目の授業）用に、PBLの評価基準表を印刷している。

この単元の本当の成果物は装置ではなく、「まず測って、それから決める」という生徒の習慣です。装置はその証拠として机の上に置かれています。初めて実施するときは、4つのシナリオをすべて使う必要はありません。2つのシナリオと6チームで始めても、同じサイクルを教えられます。授業に持っていく前にスタートプロジェクトを自分で一度組んでみたい場合は、BlueGraysアプリをダウンロードして、LDRで作る常夜灯を回路図、コード、コードを理解のステップと一緒に試してみてください。