学生中心の政策 – RECF ライブラリ

関連情報については、以下の追加ポリシーを参照してください。

REC 財団は、コーチ、イベントパートナー、コミュニティのその他の人々がチームやイベントに関係する大人と共有できる、印刷「チーム大人向け行動ガイドライン」セットも作成しました。

導入

REC 財団の学生中心の学習モデルは、財団の使命とビジョンと一致しており、学生に効果的な教育上のメリットを提供します。この生徒中心のポリシーは、シーズンを通してメンターによって確認され、生徒とその家族と共有される必要があります。

このポリシーは、REC 財団の学生中心主義の目標に対する認識を高め、競争プログラムが提供する学習機会を最大限に活用できるように、学生、メンター、その他のプログラム参加者に期待を透明に伝えることを目的としています。全体的な義務は、学生が自分の能力と知識に合ったデザイン、コード、ゲーム戦略を使用し、メンターの作品を使用することで不当な優位性を持たないようにすることです。メンターのあらゆる活動において、学生の学習は常に最優先事項であるべきです。

REC Foundation プログラムの学生は、構築とプログラミングの作業すべてを行うだけでなく、構築、設計、ゲームプレイに関するすべての決定を行う必要があります。メンターがチームのためにこのような決定を下したり、学生の単独の能力を超える設計、構築、プログラミングにつながる形で設計、構築、プログラミングに参加したりする場合、このポリシーに違反することになります。もっと簡単に言えば、メンターはロボットやコードに触れてはいけません。疑問がある場合は、「生徒主導、生徒の成功」を思い出してください。追加のガイドラインはこのドキュメントに記載されています。

共通用語

提供された例の言語を簡素化するために、一般的な用語を以下に定義します。

学生: REC 財団のイベントや活動に参加する小学生、中学生、高校生、大学生のチームメンバー。プログラム固有の年齢と学年については、該当するプログラムゲームマニュアルを参照してください。
メンター: 競技の 1 つ以上の側面について生徒に指導やサポートを提供する教師、保護者、コーチ、またはその他の生徒以外のチームメンバー。この場合、他のチームやプログラムの学生で、年下の学生や他の学生を支援する学生は「メンター」とみなされます (たとえば、高校生が中学生のチームを指導するなど)。
イベント: 予選イベント、イベント地域選手権、全国選手権、シグネチャーイベントなど、REC 財団の管轄下で運営される競技会。

注：REC Foundationのプログラムには、ロボットをベースにした競技会、ドローンをベースにした競技会、およびどちらにも属さない競技会が含まれるため、「ロボット」、「ドローン」などの用語の代わりに、「機械」または「メカニズム」という用語が一般的な用語として使用されます。

REC財団の使命とビジョン

Robotics Education & Competition (REC) Foundation の世界的な使命は、すべての教育者に競争、教育、労働力準備プログラムを提供し、科学、テクノロジー、エンジニアリング、数学、コンピューターサイエンスへの学生の関与を高めることです。

私たちは、すべての学生がチームの一員として設計と革新を行い、失敗を克服し、忍耐し、世界的な課題に立ち向かう能力に自信を持つ未来を思い描いています。

学生中心主義とは何ですか?

教育界では「生徒中心」という言葉にはさまざまな定義があります。 REC 財団は、学生中心主義を、学生のリーダーシップと学習を優先する枠組みであると考えています。私たちは、困難を乗り越えて失敗から学ぶことが生涯にわたるスキルを身につけるための重要なステップであると信じています。

学生中心主義は、REC Foundation のイベントや活動の学習と応用の両方の環境で表現されます。

学生中心の学習: 学生はメンターの指導の下、エンジニアリング設計プロセス、機械設計、プログラミング、チームワークに関する知識とスキルを高めるための学習機会に積極的に参加します。学生中心のチームは学生が主導します。つまり、構築、プログラミング、戦略、コミュニケーションを含むすべての決定と活動に対して学生が責任を負います。
生徒中心のアプリケーション: 生徒は、自分のマシンがどのように設計、構築、プログラミングされ、他のチームとのゲームプレイやスキルマッチで利用されるかについて、主体性/所有権を持ち、制御することができます。生徒は学んだことを活用して、構築、プログラミング、ゲームプレイ戦略、コミュニケーションスキルを進歩、革新、向上させます。

生徒中心主義がなぜ重要なのか?

結局のところ、生徒たちは、自分のアイデアを試し、成功と挫折から学び、困難な問題や状況に耐え抜く機会を与えられたときに、最も多くを学びます。ストレスの多い状況や競争の激しい状況では、メンターが生徒の問題を解決したり、機械を修理したりする方が簡単または早い場合があります。その結果、生徒は学習の機会を逃してしまいました。

代わりに、メンターには、問題を解決するのではなく、問題解決の背後にある考え方について学生を教育するために必要なときに指導を提供することを奨励しています。メンターは、学生がチームで作業し、機械を設計するために必要なスキルを習得するのに役立つ貴重なリソースになります。以下に示す例では、メンターの役割は主に、学生が自分のマシン、ドキュメント、ゲーム戦略、および他のチームとのコミュニケーションに知識を適用できるように学習を促進することです。

必要に応じて、メンターは生徒に代わって問題を直接解決するのではなく、問題解決の背後にある思考プロセスを生徒が理解できるように指導することが推奨されます。メンターの役割は主に、学生が自分の知識をマシンの設計、構築、エンジニアリングノートブック、ゲーム戦略、および他のチームとのコミュニケーションに適用できるように、学習を促進することです。

学生中心の競争環境では、各チームは学生チームメンバーのスキル、能力、知識を使用して競争します。デザイン、コード、戦略は学生によって開発されるため、どのチームも他のチームに対して不当な競争上の優位性を持つことはありません。学生たちはリーダー、戦略家、デザイナー、プログラマー、ビルダーとなり、競技会では他のチームに対する大使となります。メンターは、学生の学習を促進するツールやリソースを提供することで学生をサポートします。

このガイドの解釈

以下の例は、メンターがチーム内の学生と関わる方法を説明し、ガイドすることを目的としています。これらは主題のカテゴリにグループ化されていますが、トピックや例の完全なリストではありません。以下の例では、アクションを生徒中心または非生徒中心のいずれかに分類しています。

生徒中心 の例は、生徒中心の学習と応用の目標を表しています。学生とメンターはこれらの行動に努めるべきですが、スキルを発達させている学生がこれらの行動を達成するにはメンターからの指導が必要になることが予想されます。
学生中心ではない の例は、REC 財団の学生中心のポリシーに沿わないガイダンスを表しており、行動規範違反とみなされる可能性があります。

これらのリストは、イベントや外部の学習環境で発生する可能性のあるすべてのシナリオを網羅しているわけではないため、参加者は、明示的にカバーされていない状況を解釈するために、これらの例の精神を考慮する必要があります。さらに、生徒中心として記載されている行動も生徒に対して禁止される場合があります。このポリシーは、ゲームマニュアルを考慮して常識的に読んでください。

機械設計、物理的構築、検査

REC Foundation のコンペティションと同じプラットフォームを利用するさまざまなメカニズムの設計が多数存在します。これらの設計は、メカニズムの仕組みや一般的な機械設計に関する幅広い点を説明するのに役立ちますが、常に学生が独自の設計を構築するための出発点として機能するものであり、競技でそのまま使用されるものではありません。

空中ドローン競技チームへの注意: このプログラムでは、変更されていない標準のドローン設計が使用され、ドローン設計が学生によって開発されることは求められません。ドローンのトラブルシューティングや修理などのその他の機械的な側面も、学生中心のポリシーに該当します。以下の例には複数の RECF プログラムが含まれます。ADC チームは、プログラムのルールに関連する例を適用する必要があります。

生徒中心の例

生徒は機械設計のアイデアをブレインストーミングして研究し、プロトタイプを構築してテストし、メカニズムを組み立てます。
学生はメンターから基本的な建築技術や機械設計の概念を学びます。
他のチーム、ビデオ、またはその他のソースから見つかったデザインのアイデアは、エンジニアリングノートブックと審査員とのチームインタビューでクレジットされます。
生徒は積極的に機械設計に取り組み、計画どおりに動作しない場合は調査します。
メンターは、学生から質問があった場合にトラブルシューティング戦略を共有します。
チームは、VEX Robotics またはその他の承認されたソースから提供された指示に従って構築された完全なロボットを出発点としてのみ使用します。生徒たちは、シーズンが進むにつれて学んだことを取り入れて、デザインを改良したり、まったくオリジナルのデザインを構築したりします。
あるチームのコントローラーは、バッテリーが満充電されていても電源が入らないようで、生徒たちは何をしたらよいかわかりません。メンターは、学生が問題を解決するためのオンラインリソースを見つけるのを手伝い、コントローラーを再起動して再び動作するまでの手順を説明します。生徒は、問題が再び発生した場合にその解決方法を学びます。
チームメンバーが違法な物質または違法な部品をマシンに追加しようとしています。メンターは、ゲームマニュアルと検査チェックリストをチェックして、自分の行動が許可されているかどうかを確認するように学生に促します。
若い学生は金属の車軸を切断する必要がありますが、切断装置を安全に使用できません。生徒が希望の長さに印を付けた後、大人が車軸を切り、その機会を利用して生徒に道具の安全な使い方を教えます。

生徒中心ではない例

メンターは、VEX Robotics やその他の承認されたソースから提供されていない、競争力のある機械設計用に事前に作成された手順書やコピーできるモデルを、出発点としてのみ学生に提供します。
メンターは学生の最小限の支援でメカニズムを構築します。
メンターは、メカニズムまたは機械システムの全体または一部を構築または設計します。
メンターは、学生の支援をほとんど受けずに、または全く受けずにメカニズムを構築または修正します。
メンターは、生徒がミスをするかもしれないという理由で、生徒が見ている前で壊れた機械を修理します。
学生たちは自分のマシンを分解して、別の設計戦略を試したいと考えています。新しい戦略は古い戦略よりも効果が低い可能性があるため、メンターはこれを許可しません。
学生はツールを使用してコンポーネントを合法的に変更できますが、メンターが介入して自分で変更します。
メンターは、学生に自分のマシンに違法な部品や材料を使用するように勧めたり、指示したりします。
メンターは、学生の構築を指導するために詳細な CAD 図面を作成します。

プログラミング/コーディング

チームは、チームメンバーの能力を反映したコードを作成する必要があります。

新しいスキルや概念を学ぶときは、学生がその知識を理解して応用できるように、しっかりとした基盤を築く基礎から始める必要があります。プログラミング初心者の学生は、基礎知識の開発と応用を重視した学習リソースを使用し、現在の能力レベルを超えたプログラミング概念を取り入れるべきではありません。この一般的なガイドラインは、適切な学習の進行と競技会での公正なプレーをサポートします。

外部ソースからのサンプルコードやカスタムライブラリを利用するチームは注意が必要です。使用されるプログラムは、生徒の努力と能力を反映したものである必要があります。コードの機能を理解せずに盲目的にコードを使用することは、このプログラムの教育目標と一致しません。学生はコードを理解し、説明でき、また、メカニズムで使用されるコードと同等のレベルでプログラミングできることを実証できる必要があります。

生徒中心の例

生徒は独自のマシンをプログラムし、自律的な戦略を開発します。
学生はメンターや他の情報源からプログラミングの基礎を学び、それを応用して自分のマシン用のカスタムプログラムを作成します。
生徒は、コード内、エンジニアリングノートブック (VEX チーム)、または競技ログブック (ADC チーム) 内にコメントを使用して、プログラミングの概念がどのように導き出されたかを説明します。
メンターは、疑似コード、フローチャート、またはその他の視覚的表現を使用して、学生のプログラムフローの開発を支援します。
学生は、プリインストールされたプログラムを出発点として使用し、より高度なプログラムを構築します。
生徒はシーズンを通して独自のプログラムを作成および修正し、コードの機能と開発について説明します。
学生は、コード内に含まれるプログラミング概念の応用を実演します。
メンターは、学生が複雑なプログラミングタスクに遭遇したときにトラブルシューティングのヒントを共有します。
メンターは、チームが遭遇した問題を解決するのに役立つ可能性のあるプログラミングの概念とデバッグ手法について説明します。
学生は解決策を考案し、必要なコード変更を行います。
カスタムライブラリまたは関数を使用する学生は、独自のカスタムライブラリおよび関数を作成することもできます。

生徒中心ではない例

メンターは、学生が使用できる自律的なプログラムまたは戦略を開発します。
メンターがマシンをプログラムします。
学生は、メンターや他のソースによって開発されたカスタムコードの全部または一部をコピー/貼り付けます。
生徒は自分で作成していないカスタムコードを利用しますが、説明できません。
メンターは学生のコードを「クリーンアップ」または修正します。
学生はメンターの支援なしではコードの機能や開発を説明することができません。
学生はコード内に含まれるプログラミング概念の応用を実証できません。
学生は別のチームによって開発されたカスタムライブラリを使用しますが、独自のカスタムライブラリを作成することはできません。

ゲーム戦略とマッチプレイ

チームは、マシンとチームメンバーの能力を反映した戦略を作成する必要があります。どのチームもメンターから提供される戦略を持つべきではありません。

生徒中心の例

生徒はゲームのビデオを視聴し、ゲームのマニュアルを読んで、採点基準を理解し、採点戦略を立てます。
メンターは、以前のシーズンのゲームを使用して、ゲームとその制約を分析し、設計上の決定についてブレインストーミングを行う方法をモデル化します。
学生は、デザインと試合のプレイに影響を与えるゲーム戦略について合意します。
イベントでは、学生たちは練習場、チームピット、待ち行列エリアで学生同盟パートナーと協力してゲーム戦略について話し合います。
メンターは試合中は観客として明るく前向きな励ましを与え、試合終了後は生徒が振り返るのを助けます。
メンターがイベントの運営方法を説明します。彼らは、自分のチームが試合に時間通りに到着できるようにシステムを構築し、ピットで同盟パートナーを見つけて今後の試合の戦略を話し合うのを手伝います。
生徒は試合の結果や主審の判定に納得できない場合、自ら主張します。
メンターは、チームに、練習場を離れる前に、練習場をリセットするのを手伝うように注意します。

生徒中心ではない例

メンターは、デザインを決定する際に使用するスコアリング戦略を学生に伝えます。
メンターは、試合前または試合中に（ドライバーまたは自律）学生チームのメンバーまたはアライアンスパートナーに試合のプレイ指示を与えます。
メンターは、同盟選択のためにどのチームを選択するかを指定したり、同盟選択に関する学生の決定に過度の影響を与えたりします。
メンターは、特定の同盟パートナーとベストを尽くさずにプレイするよう生徒に勧めます。
試合後、メンターは審判長と試合の判定について議論します。
練習場では、メンターが自分のチームや他のチームに、段階的な指示を含めて練習内容を指導します。
メンターは、他のチームに関する詳細なスカウト情報を収集し、生徒のゲームプレイの決定を指導します。

ピットインタビュー、エンジニアリングノート、審査

チームがルーブリックを使用して面接の練習をすることは問題ありません。これにより、自信とコミュニケーションスキルを養うことができます。生徒がメンターから提供されたスクリプトの文を使用することは許可されません。

空中ドローン競技チームへの注意: このプログラムでは、エンジニアリングノートブックの代わりに競技ログブックを使用します。以下の例には複数の RECF プログラムが含まれており、ADC チームは各自のプログラムのルールに関連する例を適用する必要があります。

生徒中心の例

学生とメンターは、チームインタビューとエンジニアリングノートブックの評価基準とサンプルの審査員の質問を確認します。
メンターは面接プロセスを尊重し、学生が独立して自分自身を表現できるようにします。
学生たちは互いに協力し合い、インタビューのテーマや回答について話し合います。
学生は、シーズンを通してのデザインの発展、作成されたメカニズムの機能性、イベントで使用されたプログラムの機能性を詳細に説明できます。
学生チームのメンバーは交代でエンジニアリングノートブックに貢献します。彼らのノートの内容は、彼ら自身の声を使ったチームとしての取り組みを反映しています。
学生は自信とコミュニケーションスキルを養うために、ルーブリックを使用して面接の練習をします。

生徒中心ではない例

メンターは、ピット面接で何を言うべきかのスクリプトや指示を学生に渡します。
メンターは、ピット面接中に学生に積極的に指示を出したり、面接プロセス中に邪魔をしたりします。
メンターは面接の質問に答えたり、面接後に審査員に近づいて情報を追加しようとしたりします。
メンターは、後で分析するためにチームインタビューを録音しようとします。
メンターは、チームがエンジニアリングノートブックを提出したり、審査員とのチームインタビューに参加したりすることを許可しません。
メンターは、チームのエンジニアリングノートブックのコンテンツを提供したり、学生が記入するだけでよい設計プロセスを文書化する方法の詳細な概要を提供したりします。

オンラインチャレンジ

生徒中心の行動

学生は課題を選択し、提出物を作成します
学生とメンターはプロジェクト/チャレンジの要件を確認します。
提出された作品は学生のアイデアと努力の成果を表しています。
メンターは生徒が作成したエントリーをアップロードします。
メンターは学生と一緒にプロジェクト/課題の要件を確認します。

生徒中心ではない行動

メンターは学生からの意見を聞かずにトピックや課題を選択する
メンターはプロジェクト/チャレンジ製品の全部または一部を作成します。
メンターのフィードバックはプロジェクトの方向性を積極的に導きます。

引用

アイデアやテクノロジーの進歩は、多くの場合、他者の知識に基づいているため、それらの貢献を認めることが重要です。チームの学生以外の誰かが開発した機械設計のアイデアやコードを使用または適応させるチームは、プログラム固有のノートブックとコードでこれらのソースを引用する必要があります。チームインタビューでは、学生はこれらの貢献がマシンの開発にどのように活用されたかを説明する必要があります。チームは好みの引用形式を選択できますが、これには通常、次の情報が含まれます。

リソースまたはソースコードのタイトル
著者
発行日またはリリース日
バージョン（該当する場合）
場所（ソースが見つかる場所）

引用の重要性、引用する内容、引用方法について詳しく学ぶためのオンラインリソースが多数あります。外部ソースを使用または適応するチームは、引用についてさらに調査することが推奨されます。

コミュニケーションと強制

組織内

REC 財団は、組織が学生中心のポリシーを慎重に検討し、各シーズンの初めにチームに関係するすべての学生、教師、その他の大人とこのポリシーを共有することを強く推奨します。登録された各チームには、18 歳以上で高校に在籍していない主任コーチを 1 名配置する必要があります。主任コーチは通常、チームをイベントに同行させ、チームに関係する保護者を含むすべてのチームメンバーが生徒中心のポリシーに準拠していることを確認する責任を負います。主コーチがイベントに参加できない場合は、チームに同行する別の成人がイベント前にこの役割を果たすためのトレーニングを受ける必要があります。以下は、組織内で学生中心のポリシーを伝え、実施するためのいくつかの推奨方法です。

シーズンの初めにチームミーティングを開催し、チームに所属する学生や大人と一緒に学生中心のガイドを確認します。チームを指導したりイベントに参加したりする大人に対して明確な期待を設定します。
教育上のメリットを示すために、大人向けの生徒中心の学習活動をモデル化します。
保護者にイベントでのボランティアを奨励します。これはイベントパートナーにとって貴重なリソースとなります。
イベント以外でのチーム活動は、生徒中心の方針を熟知した大人によって監督される必要があります。
生徒に自分自身を主張する方法を教え、生徒中心の学習を積極的に強化します。
シーズンを通して個々のチーム目標と成長を重視するチーム構造内での成功の定義を作成します。

REC財団の執行

このガイドの目的は、組織に期待を伝え、コミュニティ内でベストプラクティスの整合を促進することです。 REC 財団は、行動規範に従って、このポリシーに反する行為に関する懸念を評価します。学生を大人の行為で罰したいという意図は決してありませんが、公平性を確保し、学生の学習機会を増やすために、組織が責任を負うことが不可欠です。

チャンピオンシップイベント

チームは、チャンピオンシップイベントでの生徒中心の行動に対する監視が強化されることを覚悟しておく必要があります。 REC 財団は、学生中心のポリシーに準拠しているかどうかを判断するために、チームを個別に面接する権利を留保します。一般的に、チャンピオンシップイベントでのチームの行動は、この学生中心のガイドの「学生中心」の例の行動に近づくはずです。

学生チームのメンバーは、チャンピオンシップイベント中に承認された REC 財団委員会から面接に呼ばれた場合、次のことに備える必要があります。

イベントで使用されるマシンの設計とプログラムの開発と機能について詳しく説明します。
要求に応じて、試合やゲームプレイで使用されるすべてのプログラムの電子コピーを提供します。
大人の支援なしに、コードに含まれる概念と同等のレベルでプログラミングの概念を実証します。

機械設計やプログラミングの特定の部分に関する専門知識を持つ学生チームのメンバーがチャンピオンシップイベントに参加できない場合は、参加する他のチームメンバーが知識を共有し、機能をデモンストレーションする準備をする必要があります。