vlookup関数で参照先が複数ある時

春学期の成績つける際に書いてあって放置してあった完全に自分用メモです。

成績をつける際に,vlookup関数で名前やIDを参照するというのはよくある作業だと思います。vlookup関数の引数の基本は以下の通り。

vlookup(参照元,範囲,引っ張ってくる列,参照方法)

で,名前の列が1列ならこれだけでいいのですが,スピーキング授業の話の記事で紹介したようにペアでスピーキングテストなんかをやると,得点の列は1列で,名前の列が2列になります。最終的な成績が入るExcelシートでは名前は1列で,vlookup関数は指定範囲の1列目から名前を探してくることになりますから,2列目にある名前は参照されません。そして,誰が1列目で誰が2列目かはわからない状態なので,人によって参照範囲を変えることもできません。そこで使うのがIFERROR関数です。

IFERROR関数は,1つ目の引数でエラーが出た場合に2つ目の引数を実行するという関数です。つまり,この関数の1つ目でペアの1列目から始まる範囲を指定し,2つ目の関数でペアの2列目から始まる範囲を指定すれば解決するというわけです。意外に簡単でした。つまり,

IFERROR(VLOOKUP(名前セル, 参照先1, 引っ張ってくる列, 参照方法), VLOOKUP(名前セル, 参照先2, 引っ張ってくる列, 参照方法))

とすれば良いことになります。参照先1では2列あるペア列の1列目が先頭列になるように指定し,参照先2では2列目が先頭列になるように1列参照列を右側にずらします。そして,引っ張ってくる列も1列ずらして指定します。こうすることで,1列目の中から名前を探して点数を引っ張ってきて,もしここでエラーが出る(つまり1列目に名前がない)場合には2列目の中から名前を探して対応する点数を引っ張ってくることになります。このやり方を応用すれば,ペアだけではなく3人や4人といったグループの場合でも同じことができます。もちろん,Rとかで縦横変換して名前の列はすべて1列にまとめるようなことをしても最終的に名前が1列,点数で1列という形のデータを得ることはできるのですが。今回はEXCEL上で完結させる場合の話でした。

なにをゆう たむらゆう。

おしまい。

 

広告

[R] Rmarkdown(xaringan)で学会発表スライド作るときの超初心者メモ

ちょっと放置してあったので一部思い出しながらですがメモ書きです。もう一ヶ月も前になりますが,発表資料をRmarkdownで作って公開するということをしました。これまでならkeynoteで作ってPDFにしてslideshareやspeakerdeckにしてたのですが,分析が結構モリモリでこの部分はすでにRmarkdownで作ってあったので,その部分をベースにして他のスライドを作ってしまうほうが早いと思ってすべてRmarkdownでいくことにしました(結果的にそれで時間が余計にかかった気も笑)。

Rの講習的なものや、論文投稿時に実験データの分析レポートを添えて出す、という時以外でRmarkdownを使う機会が今までなく、学会発表スライドを作るときにいくつかつまずくポイントがあったので、今後同じことにならないように自分用のメモとして残しておきます。基本的なこともきっと含まれていると思うので、本当に初心者向けです。ちなみに、私が使っているのはオンラインプレビューができるxaringanというやつです。

  1. R chunkオプションでcache =T
  2. 画像を2枚並べて表示する
  3. 画像の埋め込みに注意

Cache = Tオプション

分析の結果を提示する際に、R上で分析したものをそのままスライドに埋め込める(いちいち表にまとめ直してパワポに貼り付けるとかの必要がない)というのがRmarkdownの強みですよね。しかし、中には1つの分析にかなりの時間がかかる場合もあります。その分析コードの部分以外のところを修正したりしてknitすると、分析に時間がかかるので修正したかった部分が反映されたのかとかを見るのにも無駄な時間を費やしてしまいます。特に、xaringanはRmdを保存したら自動的にknitするので、こまめに保存しながらやる癖がついていたらなおさら大変です。分析が1度だけならまだしも、いくつも分析がある場合には数時間とかかかることもあるかもしれません。ベイズとかだったらもっとですよね。

で、これを回避するために、分析コードのRチャンクのオプションとしてcache =Tというのがあります。これをすることで、一度knitして分析をすれば、その計算結果を保存しておいてくれます。よって、分析をいちいちし直すことをしないので時間もかかりません。注意点は,この分析コードのあるチャンク内での変更があった場合と、この分析コードのチャンクオプションに変更があった場合にはもう一度分析をやり直すということです。よって,時間を要する分析のコードは最初にcache =Tにして一度knitしてしまい,細かいところをいじるのは後にするというのがいいのかなと思います。

画像を並べて表示

普通にRで描くプロットを並べて出すには,par(mfrow=(c1,2))みたいにしてあげれば1行2列でできますよね。で,xaringanでこれやってもどうしても2枚横並びの表示になりませんでした。そこで色々調べたところ,出力の際の幅を半分にしてあげればよいというアドバイスを見かけたので,Rチャンクオプションでout.width =”50%”としてあげました。画像の解像度はdpiオプションで調整できるので,この2つの組み合わせでいい感じに仕上げてあげればよいのかなと。

画像の埋め込み

これがxaringan使うときのネックになるポイントなのですが,xaringanは画像ファイルなどがself-containedではないんですよね。よって,ウェブ上にスライドを公開しようとしたときにHTMLファイルだけアップロードすればよいというわけにはいきません。GitHubなどに画像ファイルなどもすべてアップロードする必要がありました。もしかすると何か方法があるのかもしれませんが,結局ウェブにアップロードするしか解決策が見つからなかったのでこういう方法にしました。xaringanはオンラインでプレビューできるという点が強みなのですが,アップロードとかにちょっと手間がかかるというのが難点かもしれません。また,画像ファイルもアップロードすることでオンライン上での閲覧は問題なくなりますが,DLすると見た目が変わる&画像が見れないということになるので,他の媒体でPDF公開されているスライドをDLしてオフライン環境で見ることが多いというような方々にとっては,普通にPDFで公開してくれよめんどいなぁということになってしまうのかもしれません。非常に悩ましいです。

おわりに

私自身GitHub初心者なので,毎回やるたびにどうやってやるのかいちいち調べながらやっていて,もしかすると普通のプレゼンソフトでスライド作ったほうが時間かからないんじゃないか…とか思いつつ,無駄なこだわりでRmarkdownを使って投影資料を作るようにしています。他にもいくつかつまづいたポイントがあったような記憶があるのですが,いかんせんもう覚えていないのでとりあえず上記3点だけメモとして残しておきます。R関係については意外と自分が一番助かっているのではないかと思うくらい自分でよく忘れて記事探すことが多いので,これもきっと未来の自分を助けることになると信じて。そして,こうやって書いて公開すると解決策が見つかったりするかもしれないという淡い期待を抱いて….

なにをゆう たむらゆう。

おしまい。

2019SLRFで発表します

実は海外の学会で口頭するの初めてです。そもそも口頭発表自体がだいぶ久しぶりなので結構緊張しています。スライドの細かいところは多分直前までいじるので変更があるかと思いますが,Github上に資料を置いています。

https://github.com/tam07pb915/2019SLRF

前にJSLARFで喋った博論の話なんでJSLARFにいた方は発表会場立入禁止ですが,資料とかもオープンにしてなかったので個人的には今回が初公開っていう感じです(もちろんウェブには博論の要旨が公開されてるんですが)。JSLARFで喋った時は実験2つの話をざっくりしたのですが,今回はそのうちの1つの実験だけについてで,もう少し先行研究とのつながりをメインに話せるかなと思っています。サラミしているというよりは,投稿する論文にするときにうまく1つにコンパクトにまとめるのが難しく,実験1つで1本の投稿論文として出そうと思うにいたったため,1つの実験だけでストーリーになるようにしているつもりです。したがって,博論全体のストーリーとはちょっと違います。

学期開始直前でガンガンメールがくるし帰国までにやらないといけないこともどんどん増えてきているので,発表終わったら引きこもりすることになるかと思いますが,どうかご理解くださいますようお願い申し上げますm(_ _)m

なにをゆう たむらゆう

おしまい。

「知っている」事の影響を排除するための2つのアプローチ

思いついたことを書き留めておくだけのメモ記事です。粗いところもあるかもしれませんがご容赦ください。

「狭義の」(文法の)第二言語習得研究が目指していることは,母語話者が持っているのと同じ知識を第二言語学習者も身につけることができるのか,できるとすればそれはなぜか,できないとすればそれはなぜか,というのが分野の抽象的で大きな問いであるというのがざっくりとした私の理解です。

で,この問いに迫ろうとしたときに問題となるのが,いかにして「知っている」ことの影響を排除するのかなという点です。母語話者は基本的には言語の規則を意識的には知らない(説明はできない)という状態で,でもある法則に従って規則的な振る舞いをするわけですよね。その規則的な振る舞いを言語理論で説明しようというわけです。そういうことを見ようとすると,学習者が意識的に知っていること(言葉で規則を説明できること)を対象にしていては意味がないじゃん,ということになります。知っているだろうよ,というような現象を対象としている限り,「知っている」からできるという可能性を排除することができません。よって,習っているはずもないのに母語話者と同じような振る舞いを見せる現象があるよ,とか,あるいはそれが第一言語によって同じような振る舞いを見せたり見せなかったりするよ,というような方向性で研究をデザインしていくことになります。そして,それを生成文法の理論から予測していこうとすると。生成ベースの第二言語習得研究をやっている人たちの基本的な考え方はそういうことなのかなというのが私の個人的な印象です(もちろんそうじゃない人もいるとは思いますけれど)。

一方で,SLAの初期からずっとSLA研究者が関心を持ち続けてきたことは,「知っている(=規則は説明できる)のにも関わらず,産出などをさせると間違いが頻繁に起こってしまう」という第二言語学習者に典型的な現象についてどのような説明を与えるのか,ということです。この関心を説明するために生まれたのが,明示的・暗示的という2つの知識源を仮定する考え方でしょう。つまり,知っている=明示的知識はあるけれども,産出などの課題で主に使用されると考えられている暗示的知識が不十分であるために,誤りが生じてしまうというようなロジックです。この考え方でいくと,そもそもの出発点が「知っているのにできない文法項目」(典型的なのが三単現の-s)の振る舞いについての説明を与えることになります。よって,知っていることの影響を排除しようとしたときに,「習っていないであろう項目を対象とする」という理論ベースの考え方は採用されえません。そこでどうなるかというと,測定の方法としてできるだけ「知っている知識」が作動しないような課題を用いるというアプローチを取ることになります。文法性判断課題に時間制限をつけたり,elicited imitationを使ったり,その後の反応時間パラダイム(自己ペース読み課題やword monitoring課題)や視線計測,そして脳系の測定具を使うというように,測定具によって「知っている」ことの影響を排除しようとしてきた,というのがもう一つのアプローチとしてあるのかなと考えています。

私も最初の関心は後者のアプローチにあり,どうすれば明示的知識の干渉を抑えた知識の測定ができるのか,という点にありました。ところが,それでは拉致があかない部分もあります。明示的・暗示的知識系の研究の重大な欠陥だと思っている部分で,それは,「意識的かどうか」についてを直接的に測定してこなかった(できなかった)という点です。反応時間や視線計測というパラダイムを用いたとしても,何らかの反応の違いが観察されたときに,それが「おやっ?」という意識にのぼるレベルの知識を使ったから反応時間や注視時間が長くなったのか,はたまた自分では全く気づいてもいなかったけれどもそうなってしまったのか,については測定していませんでした。よって,暗黙の了解として「反応時間や注視時間の条件間差は無意識なものである」だとか,「因子分析したら文法性判断や誤り訂正課題とは違う因子にローディングするからと自己ペース読み課題や視線計測で測られているものは暗示的知識であるのだ,みたいな想定をしてきたんですよね。それってなんかちょっとそこを当然のことのように受け入れちゃってもいいのかしら。という疑問が生まれてくるわけです。そういうこともあって,私が博士後期課程時代に扱ってきた文法現象は(もちろんこれは草薙さんの影響を大いに受けているのですが),どちらかというと前者の「知っているはずもないような文法」を対象にしているものが多くなっていきました。今必死にディスカッションを書いているthere構文の数の一致 (当時はこれも明示・暗示に当てはめようとしてたんですが今は違う方向性で書こうとしてます)だったり,tough構文の研究  なんかはまさにそういうことだったと言えます。conceptual numberの研究(これは言語習得よりは文処理ですが)も,「そんなことは習っているはずもないけどなんかガーデンパス回避しちゃう」というような話でもあります。

別にどちらがいいとか悪いとかいうわけではないのですが,同じように第二言語の文法習得を対象にしている研究で,「知っていることの影響をできるだけ排除したい」という目的は共有していたとしても,そのときに知っているはずもない現象を対象とするのか,はたまた当然知っているだろうというような現象を扱って測定具の工夫によって知っているという知識の干渉を極力抑えるというアプローチに行くのか,そういう違いが出てくるのは結構興味深いことなんじゃないかなぁということを考えたのでした。

もちろん,これはただの思いつきなので,そもそもの前提が間違っているとか,2つのアプローチは別に同じ方向を向いているわけではないとか色々あるかもしれませんが,こういう整理の仕方ってどうですか?というような投げかけ的な記事でした。

なにをゆう たむらゆう。

おしまい。

 

スピーキングの授業の話

はじめに

私は,1年生対象の共通教養科目のListening&Speakingの授業を昨年度から担当しています。昨年度色々と試行錯誤を重ねて,今年度からはその反省も踏まえて改善できていると感じています。一方で,自分の中で授業の型はそれなりにできてきてはいるのですが,課題もそれなりに感じています。この記事では,授業の進め方と今感じている課題の両方についてまとめておこうと思います。

授業の概要

教科書はPearsonのImpact Issues2というものを使っています。版が新しくなったのですが,色々あって(学務的な意味で)新版ではなく旧版を使っています。細かいミスがちょくちょくあったりとかしておいおいと思うところもあるのですが,なんといっても掲載されているトピックというか「ネタ」がとても面白くてタスク向きなので,それが気に入って使っています。

教科書の構成はおもに,次のようなものです。

  1. 会話や語りのリスニングパート
  2. 内容確認
  3. 4人の視点からそのユニットの問題についてのopinionが提示される
  4. 主にペアやグループで行うディスカッション系のタスク
  5. スピーチ

私は授業では1しか扱っていません。2の内容確認はLMSで予習として行わせていて,授業中では教科書に載っている内容確認問題とは少し違う問題をいくつか提示してその答えに注目して聞くようなリスニング活動をやっています。そして,それ以降はスピーキングタスクのための時間です。スピーキングタスクが終わったら,どのような意見にまとまったか,どういった解決策にたどり着いたかなどを教室全体でシェアし,言語的なフィードバックを与えて授業は終了です。

スピーキングタスク

スピーキングタスクの題材は教科書で扱われているものを元にオリジナルで作っています。例えば,「クラスメイトから嫌がらせをされて困っているが,事を荒立てたくないので黙っていようとする女の子と,誰かに相談したほうがいいよと提案する友達」の話であれば,第三者の視点からこの問題を考えるタスクを作ります。2人の共通の友人という設定で,この問題を解決するためにはどうしたらよいかをペアで話し合い,お互いが納得する解決策を出せたらタスク達成というようなものです。

言いたかったけど言えなかったことリスト

授業で使うワークシートには,毎回「言いたかったけど言えなかったこと」を記入するスペースを設けています。授業中にここに書かれたものを見ながらフィードバックを決めたりしています。ただし,もちろん全部を取り上げることはできないので,あとで集めてリスト化して英訳と簡単な解説を付けたものを「言いたかったけど言えなかったことリスト」として翌週に配布するようにしました。最初はワークシートに直接書いていたのですが,同じようなことを書いている学生もいて同じことを何度も書くのは面倒だし,どうせなら全員で共有したほうが学生にとっても有益だろうと考えてこの形にしました。学生には,「自分が思ったこと」をそのまま書くのではなく,できるだけ日本語で「意味順」の形に落とし込むところまではやるように言っています(なかなか浸透していかないのですが…)。

授業の中で,同じタスクを繰り返してやることは時間の制約上なかなか難しいのですが,中には汎用的な表現も出てきたり(「絶対に嫌だ」みたいなのとか)するので,そういう表現は翌週や翌々週の違うタスクで使ってみている学生がいたりします。また,テストでは同じユニットのタスクにあたる可能性もあるので,こういったリストがあることでスピーキングテストのテスト勉強にも少しは役に立っているのかなと思っています。それ覚えさせて言わせているだけじゃんと思われる方もいるかもしれませんが,私は「覚えろ」という指導は一切していませんし,授業中に表現の口頭練習なども一切していません。ただリストを渡しているだけです(注1)。また,どの場面でどの表現を使うかは完全に学習者にゆだねていますし,会話の流れも流動的なので覚えたら必ず使う場面が訪れるとも限りません。

私が重視しているのは,なにか言えなかったことがあっても,それをワークシートに書けばフィードバックが与えられ,そこで新たなリソースを得て次に少しでも「言えた」と思える機会を増やすチャンスが与えられるということです。手間は確かにかかるのですが,学生からも結構好評なので継続してやろうと思っています。

テスト

このテキストは全20ユニットの構成なので,15回の授業やそれを通年で使うことを考えると微妙に回数が合わせずらいということがあったりします。私はむしろそれを逆手にとって,中間と期末をそれぞれ2週に渡って行うように設定しています。テストはペアでのスピーキングとリスニングテストです。

スピーキングテスト

前述のように,私の授業では,各ユニットごとにそのユニットでの話題に関連したなんらかのスピーキングタスクに取り組むことになります。テストの週では,それまでに授業でやった各ユニットのタスク(具体的にはロールプレイ型の意思決定や問題解決タスク)と同じ内容でやや性質の異なるようなタスクに取り組むことになっています。内容は似ているので表現などはそのまま流用できますが,到達すべきゴールやロールプレイの状況設定が異なっているというようなものです。

ペアは毎授業でランダムに組んでいて,テストのときもこちらがランダムに決めたペアでやってもらっています。ただ,当日になるまで誰とやるのかわからないというのは不安もあるだろうということで,テスト1週目の前の週にはテストの実施要領や評価方法の詳細(ルーブリックの観点は後述)とともに2回のテストで誰とペアになっているかのリストを渡しています。

テストを2週に渡って行うことの理由として15週の授業とテキストのユニット数の数合わせという問題に触れましたが,それよりも大事な理由があります。それは,一度ではどのタスクにあたるかでパフォーマンスが変わるという点と,ペアがランダムなのでペアの相手によってもパフォーマンスが変わってしまうという2つの点への配慮です。

中間テストまでは5つのユニットをこなしますので,5種類の中から2つのタスクにテストとして取り組むことになります(中間テスト後から期末テストまでも同様に5ユニットです)。もちろん各ユニットで難易度に差が出ないように作っているつもりですが,学生によっては内容的な親密度や自分の関心などで自分の言いたいことをパッと思いつくようなタスクとそうではないようなものがどうしても(例え内容は授業である程度カバーされていたとしても)出てきてしまいます(この問題については後述)。そこで1度きりではなく,チャンスを2回与えるというわけです。ペアの問題も同様で,さまざまな要因で話がうまく進んだり進まなかったりということは容易に起こり得ます。ただし,自分が話しやすい人とばかり話すのも私としてはいいことだとあまり思っていません。また,友達は考え方も似ている場合が多いので,特に意思決定タスクのように自分の考えと相手の考えを共有してすり合わせていく必要があるようなタイプのタスクでは情報のギャップが生まれづらいという面もあります。

こうしてスピーキングテストを2週に渡って中間と期末で行う,つまり合計で学期中に4回のスピーキングテストがあることで,学生は授業中でも意欲的にスピーキングタスクに取り組んでくれています。授業で一度も経験したことのない話題についてをいきなりテストで話すのは難しいわけですから当然です。結局,授業中でスピーキングタスクをやらせるだけだとなかなかうまくいきませんが,評価のうちの少なくない割合を占めるテストがスピーキングだということを明示し,それが授業中のタスクに基づいているものだということを繰り返し伝えていくことで,授業中の取り組み具合も変わってくるなというのを今学期は実感しています(昨年度は秋学期からこのやり方を導入)。

ピア評価

スピーキングテストでは,学生同士の評価も取り入れています。よって,ペア2組で1つのグループとして,どちらか一方がタスクに取り組んでいる場合にはもう一方のペアはタスクに取り組むペアを観察し,教員が評価するのと同じルーブリックで評価をつけるようにさせています。評価の観点は,(a) 日本語の使用,(b) 沈黙,(c) 共同的なやりとり,(d) タスクの達成の4観点で,(a) ~ (c)は0-2の3段階,(d)のみは0-3の4段階評価にして重み付けしています。これは私がタスクの達成を重視しているからです。このことはもちろん学生にも伝えています。

リスニングテスト

リスニングテストは,1週目は内容理解を中心としたもの,2週目はディクテーションのテストにしています。詳しい内容は割愛。

スピーキングテスト後の書き起こし

順番が前後しますが,スピーキングテストが終わったらリスニングテストの前に書き起こしをさせています。書き起こしの目的は主に2つあります。1つは文法的または音声的誤りに注意を向けさせることです。テスト中はどうしてもタスク達成のためのやり取りに夢中なため,なかなか言語的な側面に注意を向けることが難しくなります。そこで,録音したものを書き起こす機会を作ることで,発話の内容以外の言語的側面に注意を向けさせようという狙いです。

書き起こしといっても全てを書き起こしさせるのは時間的にも無理ですし,10分となるとかなり長くなるので作業自体もしんどくて飽きもきますので,書き起こす部分を一部分に限定する必要があります。限定するには,どの部分を書き起こすようにするかを選択する必要が出てきます。「最初の数分」というような指定ももちろんできますが,せっかくなのでもう少しこの選択に意味を持たせようと考えました。そこで2つ目の目的として,やりとりの中でうまくできた部分に目を向けさせるようと考えました。こう考えたのにもいくつか理由があります。

1つ目は,やりとりのポジティブな部分に目を向けさせることです。なんとかタスク達成できても,どうしてもできなかった部分にばかり目がいってしまうことはよくあります。これ自体は,「もっとうまくできたのに!」とか「なんでこうできなかったんだろう」のように,次への向上心があるという部分もあるので,一概に悪いことだとは思っていません。そうはいっても,うまくできたポイントに目を向けさせることで,タスク後にネガティブな感情だけが残ってしまうことを防ごうという狙いがあります。

もう1つ,いい側面を書き起こさせる理由は,教員が評価する際に聞くポイントを絞るという点です。学生には,「会話の中で,ここの部分はよくできたので,ぜひこのやりとりに注目してほしい,というハイライト部分を書き起こす」ように指示を出しています。こうすることで,「自分の意見を伝えつつ,相手の意見も尊重しながら解決策を見つけることができた」のように,やりとりの内容的な側面に学生の注意を向けさせることもできます。そして,教員が評価をする際にもその部分は特に注意をして聞くようにすることで,ある程度の採点の負担を軽減する狙いがあります。

課題

採点つらい

これが一番の悩みです。正直,ここの部分以外はかなりうまく授業設計ができてきたなという実感があります。しかしながら,どうしても36人~38人のクラスでスピーキングのテストをやろうとすると個別に呼んでというような方法はなかなか時間的にも制約が厳しく,それ以外の時間を有効活用するのも現状では難しいです。そうなると,授業中に録音させたものをあとから聞いて評価するということをせざるをえません。まだペアにしているので18ペアの10分間で済んでいますが,それでも2週に渡ってやっているので,採点にはかなりの時間がかかります。コメントは聞きながら書いているのでそこまで負担には感じませんが,15回目にやるテスト以外は翌週に結果を返す必要があるので1週間という時間的制約の中で採点するのはどうしても自分の時間の他の部分を犠牲にする必要が出てきます(注2)。LMSを活用して効率化を図りたいなと思う部分もありますが,LMSではペアリングして同じ採点を同時に2人に与えるというところが不得意なのでうまい解決策が見つかっていません。

課題の難易度のばらつき

前述したように,テストに用いるタスクは教科書の内容に基づくので内容的な難しさにどうしても差が出てきます。しかしながら,「難易度」を調整することは非常に困難です。なぜなら,どのような内容を難しいと思うかに個人差があるからです。ある学生はUnit5が一番簡単だと思っていても,別の学生はそのUnit5は話しにくいと思うということは起こりえますし,実際にそういうことが起こっていると思います。教科書で扱われる内容に差があるため,それに基づいた課題を作成するとどうしても内容面やトピックに対しての親密度(どれくらい馴染みのある話か)である課題が別の課題よりも難しいと思ったり簡単だと思ったり,ということが発生してしまいます。テスト作成時にも,なるべく難易度の差がでないように工夫してはいますし,これからその精度をより高めていく努力はするつもりですが,どうしても難易度が同一のタスクを作ることはできません。

この問題の解決のためには全員が1つのタスクに取り組むということが考えられます。しかしながら,そういう形を取ることで,「1度うまくいかなくても次はもっと頑張ろう」,という2度取り組むことのメリットを失ってしまいます。私としては,難易度の問題を解消するためにテストタスクを1つにすることで生じるデメリットよりも,2回取り組むことができるということのメリットを重視しており,2回取り組むことで生じるデメリット(課題の難易度の差)についてはやむを得ないと考えています。

テスト用に教科書の内容とは関係のないものをやろうとすると,語彙や表現のレベルで授業でやったことを活かしづらくなり,授業とテストを関連付けることが難しいという別の問題も発生するため,その方向での改善も難しいかなと思っています。

ペアリングとタスクの組み合わせが複雑

ペアリングとタスクの割り当てをランダムにすると言っても,完全なランダムにはできません。なぜなら次のようなことを考える必要があるからです。

  1. 同じタスクを2週続けてやらない
  2. 同じグループの別のペアがやったタスクはやらない
  3. 同じ相手と2週続けてやらない

1をしてしまうと,相手は違うとはいえ同じタスクを繰り返す方が設定や流れがわかっている分難易度が下がってしまうのであり得ません。また,2についても誰かがやっているのを見ていればやりやすいでしょう。もちろん,原理的には1週目が終わった時点で自分が当たらなかったタスクをやったクラスメイトに内容を聞くことは可能です。そうではあっても,やりとりをすべて聞いた状態と内容だけ聞いた状態ではやはり違うと思いますので,前者は現実的に対応可能なので対応するが後者は目をつむるというようにしています。3は内容的な側面以外でのやりやすさへの考慮です。現実的には,学期の中で1度でもペアになったことがあるのとないのとでも違うと思いますが,さすがにそこまでコントロールすることは不可能なのでその部分にも目をつむっています。また,上の1~3を考慮すると,2週目にスピーキングテストに取り組む際には自分がやったものと相手がやったものは絶対にあたらないことになるので,2週目にどのタスクに当たるのかは3つに絞られます。そうした意味でも2週目のほうが対策を立てやすくなりますが,この点についても全員が同じ条件なので学生間の不公平は生まれないと考えています。

3はそこまで確認が難しいわけではないのですが,誰がどのタスクをやったのか,あるいはやっているのを見たのかを確認して,1と2の条件を満たしてタスクを割り当てるのは多少めんどくさいなと思っています。RやExcelの関数を駆使してある程度自動化できないかなと考えたこともあるのですが,ぱっと思いつかないので手作業でやっています。この部分ももっと楽にできたらいいのになというところで,課題だなと思っています。

おわりに

この記事では,私が2018年度,2019年度と取り組んできた1年生向け共通教養科目のListening&Speakingの授業について書いてみました。タスク中心にするという点と,指導・テスト・評価に一貫性をもたせるという点を意識して作ってきて,ある程度形になってきたかなと思っていますが,まだまだ課題も多いです。余談ですが,テキストが来年度は新版になるので,ベースは維持しつつタスクやテストは1から作り直す必要があるので来年度はまた少し大変になるかもしれません。授業での気づきを反映させながら,自分自身にとっても学生にとっても良い授業になるように,これからも考えていきたいなと思います。

こうして書いていて,Twitterで実践(研究)に興味なくなってきたとかつぶやいたのに「自分だいぶ実践に興味あるな」と思い始めています笑

なにをゆう たむらゆう。

おしまい。

 

注1. 本当なら少しくらい口頭練習してもいいかなとも思いますし,LMSとかで音声モデルを提示するだけでもやったほうがいいかなという思いは多少あります

注2. やはり採点してフィードバックして2回目はそこを改善してほしいというところもありますし,学生からしてもそうでないと何をどうすれば良い評価になるのかがわからないので2回目に臨むモチベーションも上がりにくいだろうと考えています。