プログラミングの大学初年次教育をどのように遠隔で成り立たせるか？の記録
新型コロナウィルスの影響で，大学での対面講義ができなくなる可能性が出てきた3月ごろから，私が主として担当している約120人の受講生を抱える大学1年生必修科目であるプログラミング演習1をどのようにして成り立たせるのかを色々と考え，実行に移してきました．この記事では，その試行錯誤と準備と，失敗と，改善について，記憶がまだ鮮明なうちに自分の記録がてら（また，これから遠隔の演習講義を担当される方への参考情報として）残しておこうと思います．
前提
明治大学 総合数理学部 先端メディアサイエンス学科（FMS学科）では，1年次の4～5月（第1クォーター）にエンタテイメントプログラミング演習があり，ここではHSPという言語を使ってプログラムを書くことで様々なことができることを知り，発表会にてHSPを利用した表現に挑戦します．その後を受けて6～7月（第2クォーター）にこのプログラミング演習1という講義があります．FMS学科では，このプログラミング演習1で体系だててプログラミングの基礎知識を学ぶことになっています．受講生は再履修も含めて120人程度．通常であればメディア教室（コンピュータルーム）を利用して取り組むものとなっています．
このプログラミング演習1で教える言語はProcessingです．プログラミング初学者のための言語としては様々なものが考えられると思いますが，私が関わってきた大学でCやC++，JavaやLispなどで楽しさを見出せずにドロップアウトしていく学生さんを多く見てきて，またプログラミング嫌いを量産していたのを観測していたので，それはすまいとProcessingを選定しました．Processingは，初学者にとってよくわからない呪文が少なく，ちょっとした短いプログラムで見た目に楽しいものを作ることができて，かつ他の言語へも展開しやすいものなのでとても良いです．また，研究にも十分使えるもので，私の研究室ではProcessingやProcessing.jsを利用して成果を出しているものも珍しくありません．
このProcessingを用いた演習講義では，他の言語と同じように，計算や変数，条件分岐や繰り返し，配列や関数などを教えています．プログラミングに関する初年次教育は，基本的に前のことがわかっていなければ先に進むことができません．変数や計算がわかっていなければ条件分岐は理解できませんし，条件分岐や繰り返し，配列など，講義が進むにつれて組み合わせたものが登場するため，どこかで理解をおろそかにすると，ドロップアウトにつながりかねません．もちろん，やる気がない学生さんは仕方がないとは思うのですが，やる気はあるのにドロップアウトしてしまうというのは避けたいので，そこに工夫が必要となります．
また，この講義の続きであるプログラミング演習2（こちらも主担当教員なのですが）では，クラスなどの基礎的なものを教えたうえで，マルチメディア処理，ファイル入出力，ネットワーク通信，WebAPI，フィジカルコンピューティングなどにチャレンジしてもらっています．さらに2年生では，こうした知識をもとに他の演習講義が続いていくことになります．そのため，この演習講義は超重要で責任重大なものであり，ここでこけるとその後もこけ続けることになってしまいます．つまり，プログラミング演習1をクリアできている学生数が少なくなってしまうと，こうした講義にも影響が出てしまうので責任重大という感じです．
さてこの手の講義，難しいのは5～10%程度のすでにプログラミングがバリバリできる学生さんがいるということと，5～10%程度のどうやってもやる気を出さない（出せない）学生さんがいるということです（下図は，FMSで8年，他大学で5年ほど教えてきた肌感覚なので実測値じゃありません）．
この後にプログラミング系の科目が続かず，また進路も様々に分かれていくのであれば，「大学なんだから自ら学ぶべきだ！」と，どれだけドロップしても気にせずレベルの高い演習講義を実施してもよいと思います．ただ，この学科でその後に多くの講義がこれに連なっていますので，ここで脱落すると，他の講義もすべて繋がっているので脱落がほぼ確定となってしまい，大変なことになってしまいます．また，そもそもコンピュータが大好きな学生ばかりが集まっている学科であれば，最低限のレベルと興味はそこにあるでしょうけど，FMS学科は必ずしもコンピュータが大好きな学生ばかりではありませんので，それなりに配慮が必要となります．
そのため，上位5～10%を飽きさせないようにしつつさらに伸びてもらい，80～90%の普通の学生さんの成長を促すというのがこの講義のミッションになります．んでもって，その後のプログラミング系講義につなげていくということになります．まぁ，なんというか難儀な科目だと言えます．
新型コロナウィルス以前はどうやってたか
こうしたことを達成するために，「予習を促すための小テストと予習資料」「基礎の習得を促す基本課題の提示」「チャレンジを促す発展課題の提示」「講義時間内の課題チェックと差し戻し」「質問は隣でまず解決し，その後TAさんへ」「最終成果発表会に向けた自主制作による成長」がこの講義の主設計になります．
まず，大学ではプログラミングにだけ時間を割くわけにはいかず，プログラミングを習得するための講義も十分に時間をとることができないため，予習または復習のどちらかに学生に取り組んでもらう必要があります．そのため，このプログラミング演習では，予習資料を事前にすべて用意し，小テスト課題を設定することで，予習を促しています．
この，予習を促すための小テストと予習資料ですが，例年は講義資料配布サイトに予習資料を事前に用意してアップロードするとともに，講義資料に小テスト対象課題を提示しておき，講義の冒頭に小テスト（パソコンでなにも見ずに取り組んでもらうもの）を実施していました．小テストで点を取るためには，対象課題のプログラムを組むことができるようになっておく必要があるので，これでまず予習をある程度促すことに成功していました．
また，小テストの後に簡単な解説を行った後，基本課題（誰もが最低限出来てほしい課題），発展課題（プログラミングできる学生と，プログラミングできるようになりつつある学生にチャレンジしてほしい課題で，加点対象）を提示していました．この課題に取り組んでもらうことで，プログラミングに関する習得を促しています．予習をしっかりできていれば，課題に十分取り組めるという難易度調整をしていますが，とはいえそう簡単ではなく，また初学者はできたつもりになっていることも多いものです．そのため，課題は講義中に提出してもらい，リアルタイムにチェックをしてフィードバックを返し，課題にOKをもらうまで取り組んでもらうというスタイルをとっています．できるまでチャレンジしてもらい，そうして力を伸ばしていってもらうというスタイルです．発展課題は，できる学生さんたちを飽きさせないためにも設定しています．
また，解決できない場合などにTAさんに頼ってもらうようにしていますが，TAさんをふんだんに動員できるわけではありませんので，TAさん1人につき，学生さんが10～20人という人数構成比になっています．そのため，まずは隣同士助け合ってもらい，どうしても解決できない場合にTAさんに頼るといった方法をとっていました．
ちなみに，課題は過去のものをすべて掲載しており，その中から1問程度は被るような形で提示するため，過去のものに取り組んでいれば楽できるよ！という感じで学生さんには案内しています．まじめな学生さん（伸びがいい学生さん）は，過去のものに取り組んでいるため，早めに課題を終わらせてチェックをもらい，好きにしているといった感じでした．
また，例年であれば，学生さん達はメディア教室で同じ環境を利用し，指定の共有フォルダにできた課題を提出してもらい，その提出課題が教員とリアルタイムで共有されるので，課題をチェックしていき，チェック結果をシステムを用いて提示するという方法をとっていました．
そして講義の最終回に，400人収容可能なホールにて1人90秒で全員が制作したものを発表する，発表会を実施しています．この発表会とても盛り上がりますし，すごいものを見せてくれるのでいつも感激しています．
FMS学科では，1年次だけでエンタテイメントプログラミング演習発表会，プログラミング演習1発表会，プログラミング演習2発表会と，3回もホールにて発表する機会があるため（しかも，先輩たちも聞きに来るため），学会発表などでも思ったより緊張しない学生さんが多くなっている気がします．
さて，導入だけで長くなってしまいましたが，このような演習講義を遠隔で実施しなければなりません．さて，どうするかです．
遠隔ではどういった問題が考えうるか
遠隔講義は，対面の講義と同一ではありませんので，色々なことを配慮する必要があります．
もともとの講義は，「予習を促すための小テストと予習資料」「基礎の習得を促す基本課題の提示」「講義時間内の課題チェックと差し戻し」「質問は隣でまず解決し，その後TAさんへ」「チャレンジを促す発展課題の提示」「最終成果発表会に向けた自主制作による成長」を柱として設計していました．ただ，これがそのまま適用できるかどうかが怪しくなります．
まず，「基礎の習得を促す基本課題の提示」「チャレンジを促す発展課題の提示」についてはまぁ問題はないでしょう．お互いプログラムを融通しあわないか（チートしないか）についての心配はありますが，プログラムのコピーやちょっと改変しただけのものはすぐにばれるよ！ということを周知徹底し，またコピーさせた側も同罪ですと強調することで回避できると思っています．
一方で，「予習を促すための小テストと予習資料」ですが，小テストはその監視もできませんので，これまで通り実施できなくなります．つまり，予習を促すことも難しくなってきます．これは厳しいです．
また，「講義時間内の課題チェックと差し戻し」は共有フォルダが使えないので同じくできません．課題チェックと差し戻しができなければ，ただ課題を提出するだけになってしまい，何ができていないのかもわからず成長にはつながりません．
さらに，「質問は隣でまず解決し，その後TAさんへ」についても，Zoomでは隣と話す手立てもありませんし，TAさんに自主的に質問しに行くこともできません．
最後に，「最終成果発表会に向けた自主制作による成長」についても，日程が十分確保できないため，実施できません．となると，自主的にプログラムを組むことによる成長は見込めないことになります．
一方，学生さんの受講環境の問題もあります．パソコンとネットワークがなければ参加できません．また，パソコンの環境によっても挙動が全然違ってきます．さてどうするかとなります．
もう絶望です．もう無理なことばかりですので．以下は，その問題に対する対応の記録です．
遠隔において受講環境をどうするか？
まず，パソコンが自宅にないと困りますし，ネットワーク環境もないと困ります．全学生が自身のパソコンを持ち，帯域十分なネットワークを利用できれば問題ないですが，パソコンを持っていないことや，スマホによるテザリングしか手がないことも考えられます．
この点については，4月の早い段階で1年生に対してメールにて連絡をし，メールで連絡がつかない場合は，教員が学生さんの自宅や携帯電話に電話をし，個人占有できるパソコンがあるか，ネットワークはどうなっているかなどを収集していきました．また，パソコンを所有していない場合（パソコン購入中でも，新型コロナウィルスの影響でいつ納品されるかわからないというケースも）は学科でノートパソコンを提供するため郵送するなどしました．また，大学からモバイルWIFIのレンタルなども行われていきました．
また，遠隔講義で問題となるのがネットワーク帯域の問題で，貧弱な環境であってもサポートしつつ，また予備的な連絡手段が必要となります．そこで，4月の段階でプログラミング学習用のSlackをたて，そちらに全学生をなんとか参加してもらいました．
こうしたことは，FMS学科では1年生から研究室に配属されるということもあって，各研究室の教員の力により（もちろん事務の皆様の協力もあり）何とか実現できました．すばらしい！
これで，明治大学の講義支援システムであるOh-o! Meijiと，Slackを使いつつ，講義資料を配布したり，課題資料を配布するということがリアルタイムで行えるようになりました．
予習をどう促すか？
遠隔講義（オンライン化）により小テストを実施しようにも，100人を超える学生さんの画面を監視する事なんかできやしませんのでカンニングを防ぐ手立てはありません．また，ネットワークトラブルがある可能性もあるため，限られた短い時間での小テストは実施できませんので，小テストが実施できないことは確定しました．小テストの代替となる予習をどう促すのかが重要な課題となりました．
この予習をなんとかするために，中村研究室の又吉康綱君の協力で，typing.runというプログラムタイピングサービスを実現しました．プログラミングにおいてしばしば学生さんたちを辛い気持ちにさせるのは，まず英語であること，そして{}(),;などの記号などで，講義中にタイプミスで混乱する学生さんも多くいました．そこで，タイピングにより英語やプログラムならではの記法に慣れ親しんでもらい，また，ステップアップしていくトピックについてチャレンジしていってもらうことにしました．
ここでは，各回のトピック（変数や条件分岐，繰り返しや配列，関数など）に合うようにし，タイピング課題をなるべく適正量にするとともに，プログラミングの事例が分散し，長すぎず，わかりやすいものになるように変更するなどの調整を行いました．さらに，プログラムをタイピングしている最中に部分確定してプログラムが動作していく面白さを生かしたような課題を入れ込んだり，タイピング中に目に入るように理解を促すコメントを挿入したりなど，いろいろな工夫を行いました．そのうえで，これを採点対象とし，予習として課すことでなんとか予習を促すことにしました．
色々やってみていますが，今のところ特に問題なく，また基礎的なミスが少ないことなど，タイピングの効果は表れているように思います．とはいえ，この結果がどうなるかについては，この講義が終わってからしか判断できないと思います．
ちなみに，このサービスかなりよくできてまして，各回のランキング機能などもあって，楽しみつつタイピングすることができます．また，タイピング後にプログラムをコピーしてProcessingにもっていって利用する機能や，エディタを開いてプログラムの値を変更したりして動作を確認することもできます．
超絶便利で，結構効果的なものだと思いますので，プログラミング教育をやっている企業さんや，大学の学部などで導入したいなどありましたらお声がけ下さい．
助け合いと質問のためどのシステムを利用するか？
TAと学生が1対1の関係であれば問題ありませんが，先述の通りTAさん1人につき，学生さんが10～20人つくことになります．そのため，対面が可能であったとしても「隣のひと同士で教えあいましょう！」と促し，それで問題解決を図れない場合にTAさんを呼んでください！としていましたが，これができなくなってしまいました．
さて，遠隔講義といえばZoomが今一番ホットですし，いろいろ試していますが，Zoomはノイズが少ないですし，ラグも少なく，落ちることもほとんどないのでかなり良いと思います．また，座学形式の講義であれば，Zoomを利用してわからないところをComment Screenでフィードバックしてもらい，リアルタイムにフォローすることができます（私が担当している，情報分析と可視化の講義では，わからないところを随時投稿してもらい，そこでフォローする形をとっています）．しかし当然ですが，そんな方法を取るわけにはいきません．
ちなみに，Comment Screenを使った対話型講義は，下みたいな感じでフィードバックをもらいながら進めることができてかなり面白いのでオススメです（以下は，1年生対象のゼミでこの扉を開ける場合，引くか？押すか？と質問している様子）．
少人数の演習科目であれば，まぁなんとかなります．特にZoomには，画面共有だけでなく，相手のパソコンを操作できるという機能もあるので，演習とかのサポートでは便利です．
また，Zoomの場合は顔が並ぶので，少人数の演習講義の場合は，下図のような感じで，「課題ができたらカメラをOFFにしてくださいね．で，全員ができたらみんなカメラONで戻ってきてね」と声をかけると，徐々にみんなが画面OFFになっていくため，全員の課題の達成状況を把握することが容易ですし，焦らせることもできて楽しい感じでした．
しかし，設定など解決に時間がかかるようなものを行ったときに，TAさん2名に参加してもらったものの，10人の学生しかいなかったのに，見事に質問が同時並行で走り，破たんしてしまいました．また，ブレイクアウトルームを作って対応などしてみたのですが，ブレイクアウトルームでも複数の質問が走ることになってしまい，無理でした．
話がそれましたが，いろいろ検討した記録が下記の記事になります．
Zoomのブレイクアウトルームの機能はそれなりによくできてはいるのですが，受講生は自身からブレイクアウトルームへ入ったり，他のブレイクアウトルームに移動したりということができず，その割り当てをホストが担当しなければなりません．そのため，質問してきた学生を把握して，その学生を順番にブレイクアウトルームに招待し，ブレイクアウトルームからその受講生が離れたらまた新しい質問者を配置して...とやっていく必要があり，100人単位の場合には即座に破たんしてしまうものであり現実的ではありませんでした．
また，近くに配置されている人同士がコミュニケーションを気軽に取れて，離れると声が聞こえなくなるというSpatialChatも検討してゼミで利用したりしました．確かに参加者が気軽に自分の場所を移動してグループを構成しつつコミュニケーションできる良さはあり，隣の人同士雑談できるので，助け合える可能性はあったのですが，折角複数のグループに分かれてコミュニケーションとれるのに，画面共有は全体で1人しかできないため，利用は厳しいものでした．また，そもそも50人の制限がありましたのでこの演習講義では使えず，こちらも断念しました．
で，最後にたどり着いたのがRemo Conferenceになります．Remo Conferenceは，学会運営向けに作られているということもあり，全体向けのプレゼンができるうえ，部屋（テーブル）毎にカメラ＋マイク＋画面共有でのコミュニケーションが取れるので，近場の人同士助け合うことができること．また，TAさんが待機するスペースを両サイドに用意しておき，質問があるひとはTAさんの場所に自分から移動していくということができるのが魅力でした．
実際に講義で利用している様子が下図のような感じ．
この画面内では，約60人の学生さんが，自身が割り当てられた部屋に入り，やり取りしています（左側に1～10の数字があり，これがフロアになります．今表示しているのは3階ですが，4階にも同じく約60人の学生さんがいるため，同時に120人近い学生さんが講義を聞き，演習を受講しています）．
ちなみにカメラやマイクのON状況はユーザアイコンの左上のマークで判断することができるため，あっここ雑談してるなとか，ここ助け合っているなとかが見えたりして面白いです．
複数人がかわるがわるプレゼンをするときには，OrganizerがプレゼンするひとをSpeakerとして招待しつつ，やってもらうという感じになります．ちなみに，カメラ＋マイクのどちらかがONになっていると，下みたいな感じで画面内に残り続けてしまうので，誰かがしゃべってるときにはカメラ＋マイクはOFFにした方がよさそうでした．
なお，プレゼンの様子を録画もできるのですがZoomほど作りこまれておらず，カメラをONにしたまま録画すると下図のように横並びにされてしまいました．また，画面共有に関するボタンなどもそのまま収録されてしまうのでなんとも悩ましい感じです．まぁ，ここら辺は仕方ないとは思います．
あと，Zoomとは異なりアプリという実装になっておらず，ブラウザから利用することになるため，安定性にやや不安があることと，ノイズの除去があまり上手じゃないのでZoomに比べてノイズが目立つ感じにはなってしまいます．ただ，そこら辺は仕方がないかなという感じ．
ちなみに，120人の演習講義で連続2コマ（100分+10分休憩+100分）を成り立たせるには，時間の制約からProducerプランを契約する必要があり，月々400ドルかかります．仕方ないと思ってあきらめて契約しています．
座るテーブルはこちらで指定しているので，学生さんにとって当たりはずれのテーブルはあるとは思いますが，こういう状況でなかなか他の学生さんとコミュニケーションとれないこともあってか，待っている間や，課題を解いている最中，採点を待っている最中などに他人と話せることはかなり好評でした．
ちなみに，TAさんの数よりも質問したい学生さんの数が増えた時，その質問の順番を制御する必要があります．この点については，又吉康綱君が下図のような質問に関するチケットシステムを作ってくれていますので，それについては今後また紹介したいと思います（又吉君がいないと，この講義ここまで色々手立てを打てなかったと思いますので，本当に感謝です）．
このチケットシステム，とてもよくできており質問してきた学生さんが貼り付けたプログラムについて，同時編集しつつコメントしていくことができます．素晴らしいものとなっています．
課題をどう収集し，学生にフィードバックを返すか？
さて，課題を解いてもらったとしても，どのように課題を収集するのか，どのように採点するのか，どのようにして採点結果を学生さんたちに提示するのかということが問題となります．
ここで，課題を集めて実際にできているかどうかを確認するためには，学生さんが作ったプログラムを実行してみて，動作を検証する必要があるため，これをどれだけ手軽にするかということが重要になります．例えば，Oh-o! Meijiという授業支援システムを使うことで課題の提出を促すことはできるのですが，そのページにアクセスして課題をダウンロードし，ダウンロードされたファイルを展開し（圧縮されているため），実行するというのはなかなか難儀です．また，Processingの仕様で，プログラム（スケッチ）が同名のフォルダの中に入っていないといけませんので，フォルダをわざわざつくらなければならないという問題もあります．
単純にはクラウド系サービスを使ってファイル共有するという手が考えられるのですが，単純にみんなが編集可能な共有フォルダを使うと，他人の提出物が見えてしまいますし，他人のプログラムを上書きしてしまったり，他人のフォルダに提出してしまったり，うっかり削除してしまったりというミスも生じる可能性があるのでまずいです．自分だけが課題をフォルダ込みでアップ出来て，教員やTAさんがそれをチェックできるという仕組みが重要になります．
この課題の提出においては，一緒に講義を運営する橋本典久先生と高橋治輝先生に主として色々と検討いただき，仕組みを構築していきました．
色々なサービスを検討した挙句，全学生からGoogleのアカウント情報（メールアドレス）を収集し，もっていない学生さんにはGoogleのアカウントを作成してもらい，Google Driveのフォルダを学生毎に作成することで，学生さんが他の学生さんのフォルダを見れないようにしつつ，教員とTAにはその親フォルダへのアクセス権限を与え，学生さんの課題をチェックできるようにしました．また，課題のチェックは提出した順番に実施していくべきなので，フォルダの更新日時を使ってやることとしました．また，Google Driveの共有フォルダで編集されると随時更新日時が変更されて大変なことになるため，提出はWebインタフェース経由としました．
一方，課題の提出状況はその学生さんのフォルダの中を覗きに行かなければわからないので，高橋先生が提出状況を可視化するシステムまで作ってくれました．
また，課題チェックのフィードバックについては，他のサービスを使うと混乱するであろうこと，またその課題について直接行えた方がよいだろうということで，Google Driveの課題フォルダの中に「OKです.txt」や「フォルダ名が違います.txt」「ほげほげができていません.txt」「再提出しました.txt」などのファイルを作ることでフィードバックするという方法にとりあえず至りました．これはまぁ完全ではないとは思っていたのですが，初回講義だし，通常初回は質問も少なく，そこまでトラブルが起こっていないので大丈夫だろうと甘く考えていました．
最終成果発表会をどうするか？
例年，演習講義の最終回に位置づけ，100人を超えるすべての学生さんが自分が作成したお題（「現実世界の模倣をせよ」など）に沿ったプログラムを90秒で発表してもらっており，この場では特にプログラミングできる学生さんがその力を存分に見せてくれたりしていたのですが，当然開発の時間が足りず，発表会のための時間確保も無理となってしまったため，断念することになりました．
この解決策はちょっとアクロバティックで，今年度限定のものになってしまいますが，第1クォーター（4月～5月）に本来実施されているエンタテイメントプログラミング演習を夏休みの集中講義として移動し，こちらの発表会ではHSPではなく，Processingを利用してもらうことで，その自主制作での成長を狙うということになりました．これについては，エンタテイメントプログラミング演習の宮下芳明先生のご協力によるものが大きく，学科内連携が取れてて本当に助かりました．
なお，さすがにこれだけではプログラミング演習1の成績評価として不十分なので，最終課題として何かしら用意することにしました．
初回講義で何が起こったか（失敗の記録）
さて，このような感じで色々と時間をかけて準備を進めてきましたが，実際のところ1回目の演習講義については失敗に終わりました．例年であれば初回は全員が時間内に課題の提出が終わり，最後に時間が余るはずなのに時間内に課題の提出が終わらない学生さんが多発したこと．また，こちらも例年であれば余裕に終わっていた時間内に課題のチェックが終わらなかったこと．そして，いくつかの問題についてTwitterで学生さんたちから不満が出ていたことなどです．
以下には，まずはその失敗について4つに大別して記述したいと思います．
まず1つ目の問題は，単純で「説明不足」が原因でした．
初回講義で全員揃うまで待つ，出席を取る，Googleのアカウントを収集する，オンライン化ということもありガイダンスを丁寧に実施する，課題の提出方法などについて説明を行う，課題の提出フォルダが見えるかどうかを確認するなどに時間がかかってしまい，1コマ目の終わりが見えてしまってやや初回の説明を端折ってしまったこと．また，時間に対する焦りもあったのですが，作り上げたtyping.runを過信したことによって，Processingのエディタにプログラムをみんなで書いて再生ボタンを押して実行してみよう！というこれくらいできるだろうという部分のスキップしてしまったことで，混乱を招いてしまったことがあります．
また，エンタテイメントプログラミング演習が第1クォーターに実施されなかったので，パソコンの操作に慣れていない学生さんが散見され，またプログラミングする，実行するという概念がよくわかっていない学生さんがいたことも原因でした．さらに，メディア教室で実施していれば問題とならなかったProcessingをそもそもインストールしていないことという問題もすっかり失念していました．こうした点については，もう少し気をつけていれば気づけたかなと思うところなので反省が多いです．バタバタしながら設計すると本当に良くないですね．
2つ目の問題は，「課題のレベル設定を失敗した」ことが原因です．
プログラミング演習の課題では，学生さんたちに少しでも楽しんでもらおうと，できるだけ意味のある興味を持てる課題（錯視やユーザインタフェース，数学や物理など）をウンウンうなりながら考えています．初回はプログラミングにおいて命令を書く順番が重要なんだよ！と説明するために色々と探していて，南アフリカ共和国の国旗を見つけ．あっ，順番が重要だし四角形と三角形で実現できるしこれはいい課題だ！と思ってテンションが上って設定してしまったことにあります．
この課題，画面の外から三角形を描く必要があるなど，初回に設定するにはちょっと難易度が高すぎたような気がします．これをもう少し簡単にするなどしていれば，課題をクリアできた学生さんも多かったかもしれません．いい課題だとは思ったのですが反省が多いところです．
3つ目の問題は，「学生さんが自身の置かれた状況が把握できない」ことが原因でした．
例年であれば，下の図のようなシステムの課題提出・チェック状況可視化システムを用いて，他の学生さんの取り組み状況や採点状況，次に誰がチェックされるかや，課題の提出方法に失敗しているとか（フォルダ名・課題名が違うなど）を提示していました（下図で，組番号の背景の色が変わっているものは全部OK，砂時計アイコンはチェック待ち，〇はOK，×はNG，ハイフンは課題がチェックされていないことを意味している）．そのため，例年であればこのシステムの出力結果を見ることで，自分の課題のチェックは通ったのかや，自分はあと何人後にチェックされるのかがわかりやすくなっていました．
ただ，今回はそのようなシステムを用意することができず，Google Drive上で直接ファイルベースでのやり取りとしてしまったため，自分のものに対するチェックは大丈夫だったものの，他の人の取り組み状況が見えないためどんな問題が発生しているのか，どれだけ待たされているのかなどがわからない状況でした．
また，例年であれば，このシステムでどんどん色が変わっていくのを見て，やばいみんな終わりつつあるといったことが見えていたのですが，それが見えなくなっていたので，焦りにつながらずのんびり取り組んでしまったというのもありました．
さらに，上で示した南アフリカ共和国の課題のように，各課題にはスケッチ名（この場合は「FlagZA」）が与えられており，そのスケッチ名でプログラムを作成し，提出することが要求されていたのですが，このルールを守らず「kadai1」「kadai2」などで提出している学生さんが多くいました（これについては，説明資料でサンプルとして「kadai1」や「kadai2」を出していたのに引っ張られたのかもしれません）．そのため，チェックするフォルダを見極めるため，教員・TA用の提出状況可視化アプリを作成いただいていたのですが，学生さんがフォルダ・ファイル名提出ルールを守っていなかったために検知できていませんでした．
こちらも例年であれば，システム上で課題を提出していないことが「ハイフン」で示されているので，「課題を提出したはずなのにハイフンのままだったら課題の提出に失敗している」と学生さん本人が気づけたのですが，それができなかったのも痛かったです．また，例年だと学生さんから「提出したのにハイフンのままなんですけど」という質問を受け，確認するとフォルダ名が違うことが判明し，全体に向け周知するということができたのですが，そうした不満があがってこないので，気づくのに遅れたというのあります．
さらに，意図が伝わっておらず，提出するのはその課題なのに，なぜか250MB（2500個）からなるProcessingのフォルダを提出してくる学生さんが2名もいたりして，同期フォルダが混乱を極め，大変なことになったりもしていました．かなり厳しい感じでした．
ただでさえ課題チェックでGoogle Driveの同期で大変なときに，2500ものファイルが共有され始める様子を想像してみて下さい．なかなかゾッとできます．
4つ目の問題は，「Google Driveの仕様に振り回された」ことが原因でした．
提出された課題をチェックするのは1人だけではなく，複数の教員とTAさんとで手分けをして実施していくことになります．そのため，Google Driveの共有フォルダを利用して，更新日時が古い順に（つまり提出が古い順に）順次チェックをしていくことにしていました．
ただ，Google Driveの仕様で，フォルダに誰かがアクセスするだけで更新日時が変更され，フォルダの並び順序が変更されてしまうため，複数人でチェックをしているとどれが最新のものかわからなくなってしまいました．また，当然ですがチェックによってファイルを作る仕組みとなっているため，それに合わせてさらに時間も変更されてしまい厳しいことになってしまいました．
また，これはGoogle Driveさんの配慮だと思うのですが，課題の再提出をした場合にフォルダ名を一致しないように(1)などをおまけでつけてくれるため，これによって同期された提出課題を直接起動できなくなり（Processingさんはプログラム名とフォルダ名が一致していないと起動できない），面倒なことにもなってしまいました．
といった感じで，うまくいかなかった，失敗に終わったのは以上になります．まだまだ色々あったような気もしないではないですが，とりあえず今は思い出せないのでこれくらいで．ここまでの準備での疲労と，あまりにうまくいかなかったことによるストレスとで，その夜はぶっ倒れてしまって嫁さんを心配させてしまいました．だめですね．
第2回に向けどういった改善を行ったか？
ということで，月曜日に講義を行ってから反省会を開き，橋本典久先生と高橋治輝先生の二人の大活躍により一気に課題提出・チェックシステムを変更することになりました．
まず「説明不足」については，純粋に私のミスだなと感じ，急いで今回の課題を丁寧に解説する動画を作成し，YouTubeに限定公開でアップして学生さんに展開しました．120人の受講生で60再生されているので，半数の学生さんは見ているということになり，この説明不足についてはある程度補足できたのかなと思っています．また，第2回目の講義の冒頭で，改めてProcessingでのプログラミングの方法などについて説明を行い，なんとか対処していくことにしました．さらに，予習が重要であること，なぜ予習が重要なのかといった説明を行いました．
また，説明不足が発生した理由は時間が足りないということもあったので，出欠についてはRemo Conferenceのログ（ログインした時間とログアウトまでの経過時間が残っている）を使うことにして，時間を有効活用することにしました．さらに，時間が足りないのは採点者の数も足りていなかったので，採点者を教員2名に加え，TAさん4名と増員を行い，一方でフロアのTAさんの数が減りました．
さらに，1年生の中でも特にプログラミングができる学生さんたちに声がけさせてもらい，なにか混乱があったら教えてほしいとか，ぜひとも同じ部屋（同じテーブル）の学生さんを助けてあげてほしいなどのお願いをさせてもらいました．
「課題のレベル設定を失敗した」ことについては，解説動画での補足とともに，第2回目の基本課題のレベルをやや落とし，対処することにしました．今後，過去の課題から1問は絶対出すから予習してね！と促したので，第3回目からはみなさん予習に取り組み，課題をそれなりに達成してくれると期待しているので，レベルを戻すつもりです．
「学生さんが自身の置かれた状況が把握できない」という問題と「Google Driveの仕様に振り回された」という問題は実際はセットで，主に課題の命名規則を学生さんが守らない（プログラム名を守らない）という問題と，教員から課題の提出状況・順番がわからないという問題，そして学生さんから課題のチェック状況がわからないという問題に区分できましたので，それぞれについて対応していくことにしました．
まず，命名規則を守らない問題については，プログラムを1から作ってもらうのではなく，中身がほぼ空っぽだけど名前はつけられているプログラム一式を用意し，それを使ってもらうことにしました．これにより命名規則の問題については一旦棚上げできることになりましたし，実際に提出されたものにミスはほぼありませんでした（フォルダではなく，ファイルを提出した事例はたくさんありましたが）．
また，教員から課題の提出状況・順番がわからないという問題については，高橋先生・橋本先生の大活躍によって，課題を提出したあとにGoogle Formをもちいて課題提出を申請してもらうことにし，その状況を学生さんからすると読み込みだけが可能なSpreadsheetを用意して，順番に提示することにしました．これにより，少なくとも教員・TA側からは，学生さんの提出状況・順番を把握でき，次にどの課題をチェックするべきなのかがわかるようになりました．
ちなみに，教員2名＋TA4名で採点するため，競合が発生すると困るため採点する際には，まずそのセルにフォーカスを合わせてカーソルを提示し，それから取り組んでもらうようにしました．
なお，このSpreadsheetを見ながら同期されたフォルダをチェックして課題を開き，Processingを起動して動作チェックし，採点結果を教員とTAさんがSpreadsheetにOKやNG，またそれに対するコメントなどを書き入れてもらいました．
これにより，現在どのようなチェック状況なのか，自分は何人待ちなのか，OKなのかNGなのか，NGの理由は何なのかなどを学生さん側からも手軽に知ることができました．
ちなみに，先程のものだと全員の全課題が並んでて混乱するので，下図のようなその学生さんの課題提出・チェック状況についても一覧で見れるようにしてくれました．高橋先生・橋本先生の活躍に大感謝です．
さらには，講義の前半で課題を提出する練習も行い，その課題のチェック状況を示すことによって，なんとかフォローアップしていきました．いやぁ，エネルギーを随分と注ぎました．
そんなこんなで，多分2回目についてはそれなりに上手く講義ができたと思っています．とはいえ，採点にフロアのTAさんも駆けつけるなど大変だったので，そこは改善が必要です．なお課題のチェック方法については，高橋先生がさらなるシステムを作ってくれているので，3回目からはもっと改善されると思います（これについては，そのうち記事を書くかもしれません）．
というのが，とりあえず遠隔講義となることが予想されるようになってから取り組んできた様々な検討と，準備，そして初回の失敗とその改良の記録になります．まだまだ演習講義は始まったばかりですが，今後どうなるか全く先が読めません．
なお，まだ現時点で抱えている問題として，取り組んでいる学生さんの様子（余裕なのか，悩んでいるのか，諦めかけているのか，どんどんプログラムを入力していっているのか，完全に手が止まっているのかなど）が相変わらず見えませんので，どの程度できているのかがわかりませんし，何に悩んでいるのかもくみ取ることが困難です．これについて，どのようにして改善していくかは今後検討していくことになると思っています．
よろしければサポートお願いします！いただいたサポートは研究室の学生さんの飲み会代に補助として使わせていただきます。