ビデオ授業の難しさ

RubyとRuby on Railsの基礎に関するオンライン授業を担当し3年目になる．全学部の希望者を対象としたビデオ授業，いわゆる，オンデマンド型オンライン授業という形式で実施している．この分野は進化が激しく，また，学生のレベルに合わせて内容を調整しながら進めているため，今年は3年目にして動画解説を撮影しなおしている．いちど動画を撮影してしまえばあとはラク……というわけにはいかないので，なかなか大変である．

ビデオ授業のため，教室での教員と学生のインタラクションが実現できない．そのため，LMSの掲示板を利用して質問を受け付けるようにしている．なにしろ100人を超える受講者がいるため，質問も頻繁に投稿される．そのため，質問対応にTAの手を借りているが，私もちょいちょい掲示板を覗いて回答するように心がけている．

上に挙げた例のように，ビデオ講義の動画でしっかり説明しているにも関わらず，それらの内容について質問してくる学生は多い．これはいったいどうしたものか．

ある学生との対話による気付き

あるとき，「どうしてもうまくできないんです」と研究室を訪ねてきた学生がいた．その意気やよし，というところだが，「エラーの状況を再現してみ？」というと，動画を小刻みにスキップして参照しながら，作業を進めようとする．

それじゃダメだよ……

物事には順序があり，とくにプログラミングにおいては順序どおりやらないと，うまくいかない．動画をスキップしたところでも，重要なポイントが説明されているはずだ．そのとおり進めないからエラーになるのである．

教室での講義であればしっかり聞いているかと問えば，そうでもないだろう．しかし，教室で演習をしていれば，つまづいたところでは周囲と助け合ったり，その時点で誤りを指摘できたりと，確認しながら進められる．しかし，オンデマンド講義で，しかも2倍速で視聴していたり，必要そうなところだけ摘み食い的に視聴していたりしているのでは，漏れがあるのもさもありなん，というところだろう．

いかに漏れなく伝えるか

とくにプログラミングに関する授業では，「必要なことをいかに確実に伝えるか」という配慮が教員側にも必要になる．A→B→C→D→……という作業手順があるとして，なぜこの順番でやるのか，あるいは，A，B，という手順がなぜそれでよいのか，という個別のポイントを，丁寧に伝えられるかという技量が求められる．

作業に慣れている，原理を理解している教員側は，さも当たり前のこととして「A→B→C→D→……」という作業手順を説明する．しかし，初見の学生は，なぜそれでよいのかとか，それを行うための前提知識などがわからない．そのため，「前提知識がないこと」を前提として，必要以上に丁寧に説明するように心がけがほうがよい．

それだけ配慮していても，説明が漏れることがある．そのうえで，ビデオ授業だと，先に述べたような視聴態度をとる学生は，A→C→D（Bをすっ飛ばす）というような理解をする．それではうまくいくわけがない．

このような，情報の欠如をいかに防ぐか，これは学生だけの問題ではなく，教員側の配慮も必要になろう．

なお，補足する手段として掲示板での質問を推奨している．掲示板での質問が活性化することは，基本的にはウェルカムである．しかし，無駄な質疑はできるだけ避けたいところ．そのために，全受講者に対してオープンな掲示板で質問しなさいと指導している．Q&Aが溜まればそれはひとつの財産になるし，重複した質問を避けられる利点があるからである．

オンライン・プログラミング演習がいよいよスタート

かねてよりここで報告してきたように，オンラインでプログラミングの学習を行う演習（ゼミ）が軌道にのってきた．準備そのものをオンラインでやるのはなかなか難しかろうと，初回と二回目は教室に集まってもらったが，（いろいろと事情があり）第三回目は教室に集まったのは3名だけで，残りのメンバーはオンラインで参加するという状況になった．

この図は，オンラインで講義資料を配信しつつ，各学生による実習の様子をモニタリングしているところである．左側が配信している資料の画面，右側が学生の作業をモニタリングしている画面である．

学生と共有している画面のアップデートがあるとフォーカスが移動するような設定になっているのか，ときおり，不自然な動作が起こるとか，あるいは，コンテンツの共有がうまくできている学生とそうではない学生がいるとか，不可解な動作を示すところも残っているが，全般的には，想定したとおりのイメージで演習を進めることができた．

このMultiViewとGoogle Colaboratoryを併用したプログラミング指導は，オンラインだけでなく，教室に集まって授業をするときでもそこそこ有効に使えそうだということもわかった．このアイデア，Google Colaboratory以外にも，文書作成画面をGoogle Docsなどで共有するとか，いろいろな場面で使えるかもしれない．まさに発想次第といったところか．

しかし，教室に来た学生の次の一言も印象的だった．やはり，オンラインでは情報量が圧倒的に制限される．教室の良さ，F2Fコミュニケーションの意味を，彼女は噛み締めていたのかも．

「わたし，教室に来なきゃ，たぶん置いてかれるわ……」

オンライン演習までの（厳しい）道のり

この4月から，プログラミング系の演習をオンラインで実施するという（なかなかにチャレンジングな？）試みに挑戦している．多摩，後楽園，市ヶ谷と分かれている本学において，全学からメンバーが参加する全学対象ゼミが始まったからである．さらに，来年度には法学部が茗荷谷に移転するので，多摩，後楽園，茗荷谷，市ヶ谷と4拠点を結んだオンラインゼミナールを実施することになる．

本学ではFLP（Fuculty Linkage Program）として既に全学ゼミの実績が十分にある．本プログラムは，AI・データサイエンスセンターが実施するiDS（intermediate program on the Data Science and AI）プログラムと呼ばれるもので，新たにAIやデータサイエンスを学ぶ演習プログラムとして用意されたものだ．2年生から卒業まで，3年間みっちりとゼミ形式でAIやデータサイエンスを学ぶプログラムである．理工学部，総合政策学部，文学部，国際情報学部（iTL．私）所属の教員4名がそれぞれ各ゼミを担当する．

いよいよ初回が始まったが，さすがに最初は，市ヶ谷キャンパスの教室に集まってもらって，自己紹介から始めた．いきなりオンラインかつ全てオンラインでは友情も育まれないであろうという配慮である．さらに，オンラインで円滑に学習を進めるための準備は，さすがにオフラインでやらねばならなかろうという意図もある．

オンライン演習実施の工夫

これまで「オンライン演習実施のためのヒント」「オンライン演習どうするどうやる？」「続・オンライン演習どうするどうやる？」で紹介してきたように，オンラインで演習を実施する工夫として，OBS（Open Broadcaster Software）を使って学生のデスクトップをシェアしたり，拙作のちょっとしたソフトウェアMultiViewを用いて学生のノートブックをシェアしたりという方法を考えた．OBSとMultiViewを用いたオンライン演習環境については，参考文献（Iio, J. 2022）も参照されたい．

せっかくソフトウェアを作り込んだ（というほどでもないが）ので，MultiViewの利用を優先的に考え，初回では学生にMultiViewの存在と，プログラミングの演習はGoogle Colaboratory（以下，Colab）を使うよと伝えた．まずはHello Worldからということで，ColabでHello Worldするところまでは，うまくいった．まあ，それほど難しい話でははない．

さて，ではそのノートを共有して，というところで問題が発覚した．それは，基本的に学生のドキュメントは，学内アカウントでログインしたアカウントでしか共有できない設定になっている，ということである．用意していたMultiView環境は学外のアカウントだったので「とりあえずテストだからリンクを知っていれば誰でも共有可能にして」と指示したところ，学生から「できませーん」と声が上がったという次第である．

試行錯誤で問題解決へ

しかたがないので，私の学内アカウントでMultiViewを使うべく，用意をしようとした．MultiViewをGoogle Chromeから使うには，「Ignore X-Frame headers」という拡張機能を入れなければならないのだが，今度は「Googleウェブストアにはアクセスできません」というエラー．学内アカウントではウェブストアにアクセスできない設定になっていたのである（図）．

どうやって拡張機能をインストールすんのよ？といろいろ調べたら，拡張機能のソースコードを直接参照することで，導入できることがわかった．そして，幸にして，入れなければならない拡張機能はそのソースコードをGitHubで公開していたので，git cloneして必要なソースコードをダウンロードし，ブラウザの拡張機能として次の手順で導入できた．

その手順とは，拡張機能設定を開き，「デベロッパー・モード」をオン，「パッケージ化されていない拡張機能を読み込む」ボタンを押し，マニフェストファイルとソースコードが置かれているディレクトリ（manifest.jsonが置かれている場所）を指定する，という方法である（図）．

正直，いろいろと障害があるなあという感じで，苦労は絶えない．これでMultiViewが利用可能になったので，次は，実際に使ってみてその使い勝手を自ら，そして学生からも，評価していこうというところである．

参考文献

Iio, J. (2022) OBS Share and MultiView: Two Methods for Sharing Student Work in Distant Teaching, The 20th International Conference on e-Society (ES2022), pp. 253-257, Online.

因果と相関を混同すべからず

次のグラフを見ていただきたい．このグラフは，反転学習において，学生たちがいつ予習コンテンツにアクセスしていたかを示すグラフである．「プログラミング基礎」という必修科目において第2回から第13回まで反転授業方式で授業を実施した．

反転授業なので，教室での授業が終了後すぐに，次回の講義内容に関する予習動画をLMSで公開した．縦軸は，公開して何日後にその動画にアクセスしたかを示す．ただし，公開時間に多少のブレがあったため，全ての学生たちのなかで最初にアクセスがあった時点を起点とした．なお，公開するとリマインダーが送信されるため，必ず直後に誰かからのアクセスが発生した．そのため，公開時間とほぼ一致しているとみなしてよい．

縦軸が0から6となっているのは，0日後（公開した日）〜6日後ということである．したがって，下にいくほど積極的に予習動画にアクセスしていることになる．教室での授業の直前，ギリギリに視聴するほど，数値は上に位置することになる．

さて，このグラフでは二つの線が描かれている．それぞれ，学生たちをA群とB群，二つのグループに分けたときの，アクセス時間の平均値をプロットしたものである．

A群とB群は，第14回に実施した力試しテストの成績における上位群（A群）と下位群（B群）である．なお，このテスト結果は成績評価には使わないこと，LMSのデータを分析する目的にのみ使うことを学生には示して実施した．

A群の平均とB群の平均では統計的に有意な差があることを確認できた．また，このグラフから，B群の平均値は回が進むにつれて遅くなっていることがわかる．このことから，A群は最後まで積極的に予習を行い，B群は内容が難しくなるにつれて予習がおっくうになってきたのでは？ということが推測される．

ただし，予習動画への積極的なアクセスと成績には，相関関係はあっても因果関係にあるとはいえないということには注意しておきたい．

すなわち，予習動画へ積極的にアクセスすれば成績がよくなるというわけではないということである（次図A）．容易に推察できる構図は，授業に対する興味という第三の要因があり，それが予習動画への積極的なアクセスと成績にそれぞれ影響を及ぼしているというものである（次図B）．

この例は，相関関係と因果関係のよくある誤謬を示す典型的なものである．気をつけるようにしたい．

反転授業，予習の実際

オンライン対応の副産物として反転授業をやりやすくなったということについては，以前，何回か紹介したし，拙書「オンライン化する大学」でも論じた．実際に学生がどのような予習活動をしているのか，LMSのアクセスログを仔細に調べてみたら，興味深い事実が見えてきた．

反転授業として実施し，アクセスログを調査した科目は「プログラミング基礎」，1年生の必修科目で，受講学生は20名である．初回は事前学習させる術がないため，初回のオリエンテーションと最終回の力試しテストを除き，第2回から第13回までを反転授業の対象とした．

教室で，その回の授業が終わった直後に次回の講義資料と講義動画を公開する．学生は次回までにその資料をダウンロードし講義動画を視聴する．教室ではそれに基づいて少し高度な内容を補足するという手順で，反転授業を実施した．なお，1回の講義コンテンツは5〜7ページほどに分割されており，それぞれアクセスの記録が残る．基本的に，各ページに一つの動画が埋め込まれており，簡単な説明が動画に付随という作りになっている．

manabaの資料へのアクセスログは，最終アクセス時刻が記録される．したがって，復習のために再度ページへアクセスすると，アクセス時刻が更新されてしまう．正確な予習時間を計算するために，manabaからアクセスログの全てを取得し，各資料にアクセスした初回のタイムスタンプを取得した．

予習状況を確認するためには，予習が終了した時刻を測定する必要がある．しかし，終了したことはLMSのアクセス状況から察知することはできない．したがって，各回に出した課題の他に，プレ課題と題するレポート課題を各回，学生に提出されることにした．プレ課題では，動画を見終わって質問やコメントがあればそれを提出せよとし，とくにない場合は「動画を見ました」だけでよい，とした．

このグラフは，プレ課題提出のタイムスタンプから初回アクセスのタイムスタンプを引いた結果のヒストグラムである．横軸の単位は「日」，縦軸は件数である．

グラフから，次の事象が読み解かれるだろう．

• 多くの学生が，1日（12時間以内）で予習を片付けている．6〜7日のところにあるピークを無視すれば，予習期間の長さは指数分布に従っているようにみえる．これは待ち行列理論おけるイベント発生期間の分布が指数分布に従うこととも合致する．
• 5.5〜7.0のところに小さなピークがある．これは，とりあえず予習コンテンツが公開された時点でアクセスした後に放置し，次回の授業直前になって思い出したように報告する，あるいは，実際には予習を終えていたにもかかわらず，報告を忘れていて慌てて報告した状況も少なからぬ割合で発生したことによるものと推定される．
• 期間がマイナスになっているケースがいくつか発生した．本来はあり得ない状況である．「動画見ました」の報告よりも初回アクセス記録が後になっているケースで，学生による虚偽の報告によるものかどうかは現在調査中である．

なお，この期間イコール予習時間，ではないことには注意しておきたい．あくまで，初回アクセスから予習終了までの時間を計測したものにすぎないため，実際の予習時間は，より短いものとなっているはずである．

追記：予習期間がマイナスになっているケースは，調査の結果，学生による虚偽の報告が原因であるということが判明した．本人が正直に告げてきたので「嘘はいかん」と説諭して本件は終了．