ゲーム制作を授業で扱う：先生向けの進め方

ゲーム制作を授業に組み込む前に決めること

授業でゲーム制作を扱うとき、最初に問うべきことは「何を学ばせたいか」です。ゲームを完成させること自体が目的になると、技術の差が評価の差に直結してしまいます。目的を「設計書を書く力」「ユーザーテストとフィードバックの経験」「プロジェクトを期限内にまとめる判断」のいずれに置くかで、単元の構成がまったく変わります。

目的が定まったら、次の三点を確認してください。

• 使用環境：学校の端末（Chromebook・Windows・iPad など）でブラウザが動くか、インストールが必要なツールは許可されているか。
• 時間数：1単位時間45〜50分として、何コマ確保できるか。後述するように、最小構成でも6〜8コマは必要です。
• 完成物の形式：発表会・展示・オンライン公開など、「誰かに見せる」出口を決めておくと生徒のモチベーションが上がります。

時間数別の現実的な単元設計

6〜8コマで収める「最小構成」

6〜8コマは「ゲームを体験する→設計書を書く→素材をそろえる→組み立てる→テストして直す→発表する」の流れをぎりぎり回せる最低ラインです。この規模では完成度よりプロセスの体験を優先し、「一つのルールだけ持つシンプルなゲーム」を目標にします。クリック一回で動く当たり判定ゲームや、選択肢が二択だけのテキストアドベンチャーがこの規模に合います。

ツールは生徒が初日から操作を始められるものを選んでください。Scratch のようにブロックを並べるビジュアルプログラミングは、コマ数が少ない場合の現実的な選択肢の一つです。HTML と JavaScript を使う場合は、テンプレートを教師側で用意して「埋める箇所だけ変える」形にすると時間を節約できます。

12〜16コマで組む「標準構成」

時間に余裕があるときは、設計フェーズを厚くできます。「どんな人に遊ばせるか（プレイヤー像）」「どう操作するか（インタフェース設計）」「難易度をどう調整するか」を設計書に落とし、クラスメイトにレビューしてもらう時間を挟みます。

このフェーズが充実すると、技術力が高くない生徒でも「設計の丁寧さ」で貢献できます。グループ制作にする場合は役割分担（企画・制作・テスト担当）を明示し、誰が何をしたかを記録させると評価にも使えます。

授業外の時間をどう扱うか

家庭での作業を前提にすると、端末や通信環境の差が成果物の差になります。授業内で完結できる量に設計し、「続きは任意でやっていい」とするほうが公平です。どうしても家庭作業が必要な場合は、学校の端末を貸し出すか、放課後に制作スペースを確保する手段を並行して考えてください。

進行中のつまずきとその対処

「何を作ればいいかわからない」が止まる

企画フェーズで手が止まる生徒は、ゲームを「複雑なもの」と思い込んでいることが多いです。「ルールが一文で言えるゲーム」という制約を最初に与えると動き出しやすくなります。例として「ボタンを3回押したら勝ち」「タイマーが切れる前に答えたら正解」など、本当に単純なものを黒板に書いておくと参考になります。

技術でつまずいて制作が止まる

特定の生徒が「バグが直せなくて1コマ消えた」という状況は頻繁に起こります。対処の基本は「詰まったら作業を次に進める」ルールを先に共有しておくことです。バグを後回しにして別の部分を作り、最後に戻るか、その機能を削るか選ばせます。完成を妨げる一点にこだわるより、「動く範囲で仕上げる」判断を教えることも、この授業の学習内容の一つです。

サポート体制としては、困っている生徒のところに教師が個別に回るより、「詰まっていること」を付箋や共有ドキュメントに書いて貼っておき、同じ問題を抱えた生徒どうしで解決する流れをつくると、教師の負荷が下がり生徒間の対話も増えます。

グループ制作で特定の生徒だけが作業する

役割を「誰が何をいつまでにやるか」のタスクリストに落とし、毎回の冒頭5分でチェックインする習慣をつけると偏りに早めに気づけます。また、「企画書・設計書を書く人」「テストプレイして改善点を言葉で出す人」「素材（画像・テキスト・音）を準備する人」といった技術以外の役割を最初から明示しておくと、コードを書けない生徒の居場所ができます。

評価のしかた

完成したゲームの「面白さ」で評価することは避けたほうが無難です。面白さの判断は主観的で、技術力や時間投資量と混在するため、評価基準として機能しにくい側面があります。

評価しやすい観点の例を挙げます。

• 設計書の記述：ルール・操作方法・想定するプレイヤーが具体的に書かれているか。
• テストと改善の記録：「こう直した・なぜ直したか」が振り返りシートに残っているか。
• 発表での説明：制作の判断理由を自分の言葉で話せるか。
• 制作過程への貢献（グループの場合）：タスクログや役割分担表から確認できるか。

ゲーム自体の出来栄えを見る場合も、「操作説明がゲーム内にあるか」「意図したルールどおりに動くか」のように客観的に確認できる項目に絞ると評価のぶれが小さくなります。

完成物を外に出す選択肢

授業の出口として「誰かに遊んでもらう」経験は学習効果を高めます。校内発表会・他クラスへの体験会に加え、ブラウザで動くゲームであればオンラインで公開する方法もあります。アソバースはHTMLファイルやZIPファイルをそのままアップロードして公開できるプラットフォームで、URLを発行するだけで校外の人にも遊んでもらえます。公開前に保護者の同意や学校の情報公開ルールを確認する手順を、授業設計に組み込んでおいてください。

次の行動

まず「何コマ確保できるか」と「何を評価するか」の二点だけ決め、それに合う単元の骨格を書いてみてください。ツールの選定はその後で、端末環境を実際に確認しながら絞り込むと現実に即した判断になります。生徒の完成物をブラウザで動かせる状態にしておくと、発表や共有の幅が広がります。

参考資料

• 文部科学省「小学校プログラミング教育の手引」
• IPA「情報処理推進機構：教育機関向け情報セキュリティポリシーに関するガイドライン」
• Scratch 公式ドキュメント（MIT Media Lab）