タグ別アーカイブ: 授業

Slackを用いた授業外ライティング活動の便利ワザ[Google Spreadsheet編②]

はじめに

下記の前回の記事の続きです。

Slackを用いた授業外ライティング活動の便利ワザ [Google Spreadsheet編①]

前回の記事では,Google Apps Script (GAS)を利用して,Slackに書き込まれた内容をGoogle Spreadsheetに記録し,その記録をもとに語数を数えるという話でした。この記事では,それをもう少し便利にするために,「ある特定の期間で区切って語数をカウントする」というお話です。例えば,1日ごと,1週間ごとみたいな。月ごとの場合は,前回の記事で紹介した方法は月ごとに新しいspreadsheetのファイルができるので楽なんですが,「同じファイル内のシートの中で一定の期間の間ごとに区切りたい」となると,少しだけ工夫がいります。といっても,spreadsheet内で関数を書くだけなのでそんなに大変なことではありません。一度雛形ができればあとはコピペして少し書き換えるだけですみます。

前回のおさらい

少しだけ前回の記事に書いた内容に触れておきます。GASを使ってspreadsheetに取り込まれた状態は,下記画像のようになっています。

Screen Shot 2018-09-24 at 22.50.58

A列が日付,B列が名前,C列が書き込まれたテキスト,D列がもとのJSON形式の情報です。このシートが,チャンネルの数だけ一つのファイルにある状態です。前回は,GASで更新されるこのシートの情報を以下のような手順に沿って使いました。

  1. importrange関数を使って別のファイルにエクスポート
  2. そのシートに語数をカウントするE列を挿入
  3. sumproduct関数で名前列を参照してE列の合計を求める

すると,下記画像のようなまとめシートができます。

sumproduct-example

今回は,そこに「日付の情報も参照する」という情報も付け加えていくことになります。

同じ月内で1週間ごとに語数を数える

では,実際に私がやっている実践に即して,1週間ごとに語数を数えるという作業をやる方法です。先程説明したように,前提は一ヶ月で一つのファイルができ,そのファイルの中にチャンネルの数だけシートがあるという状態です。同じ月内であれば一つのシートの情報で,以下のような作業をspreadsheetにやってもらいます(注1)。

  1. まとめシートのA列にあるセルの名前に当てはまるものだけをフィルタリング
  2. 参照元シートのB列にある日付の情報を参照し,指定した1週間のものだけをフィルタリング
  3. 1と2で絞り込まれたデータのE列の語数を合計して計算する

注意点は,参照するデータのシートでは名前がB列,日付がA列なのに,まとめシートでは名前はA列になっているという点です。どの列にどのデータがあり,どこの列を参照するのかを考えないと混乱するかもしれません。さて,前回はsumproduct関数使ったんですが,今回使うsumifs関数でも同じことが可能だと思うので,全部sumifs関数でやってもいいかもしれません。

先にあとで説明する作業が完了した状態のシートの画像を見てください。1つ前の画像の状態から,下記の画像の状態にすることが今回の目標です(注2)。

Screen Shot 2018-10-12 at 14.12.11

私がこのSlackライティング活動を採用しているのは金曜日の授業で,金曜日から次の週の木曜日までを1週間としています。日付で区切っていて時間で区切っているわけではないので,今回は日付で絞り込みにしています(午後5時までとかそういう切り方だと時間も指定する必要があります)。

では,上の画像のB2の列にはどのような式が入力されているのか見てみましょう。

Screen Shot 2018-10-12 at 14.12.38

画像中の式で最後に”-5″しているのは,最初は必ず”@XXX has joined the channel. “という5語の文が記録されているので,それを排除するためです。

sumifs関数の基本的な引数はsumifs(合計範囲, 条件範囲1, 条件1, 条件範囲2, 条件2, …)のようになっています。合計範囲とは,合計を計算したい範囲のことですので,今回の場合はE列の語数の列を選択します。”Friday2_201809″というのが,金曜2限クラスの9月分のデータがエクスポートされたシートになります。このまとめシートはimportrangeで自動的にデータがエクスポートされるように設定しているspreadsheetファイルの中に作っているので,”Friday2_201809!$E$1:$E$1000″で,「9月分のデータのE列(語数列)」を合計範囲として指定していることになります。コピーしたときに範囲が変わることを防ぐために,絶対参照にしています。

2つ目の引数は,同じ”Friday2_201809″のA列を1つ目の条件範囲にしています。A列は日付の入っている列ですから,日付列を条件範囲としていることになります。そして,3つめの引数で日付の条件指定を行います。最初の1週間は,もともとデータ記録の一番最初(2018年9月21日)が1週間の1日目でしたので,7日目(終わりの日)だけを指定しています。これには等号・不等号の使い方でいろいろなやり方が考えられますので,この例は一例です。

“<“&”2018-09-28”

等号・不等号は必ずそれのみをクォーテーションマークでくくり,クォーテーションマークでくくった日付と&でつなぐようにします。上の式が意味しているのは,「2018年9月28日より前(つまり27日以前)」です。これで,9月28日0時00分以降の書き込みが排除されます。

4つ目の引数は条件範囲2です。”Friday2_201809″のB列を参照しています。B列は名前の入った列ですので,名前の絞り込みをしようというわけです。最後の引数は$A2です。「条件範囲2(元データの名前列)の中で,まとめシートのA2セルの名前に当てはまるものだけをフィルタリングしてね」ということです。指定する順番自体は前後していますが,上にも挙げた以下の3つの作業が1つの関数で実現されたことになります。

  1. まとめシートのA列にあるセルの名前に当てはまるものだけをフィルタリング
  2. 元ファイルのB列にある日付の情報を参照し,指定した1週間のものだけをフィルタリング
  3. 1と2で絞り込まれたデータのE列の語数を合計して計算する

これであとは,列を横に足して,別の日付指定をすれば,あとはその条件に当てはまるものだけが自動的に記録されていくことになります。合計範囲指定は固定ですが、条件範囲と条件の指定は名前が先で日付が後でも構いません。

1週間のはじめとおわりを指定する場合

さて,上のやり方は,1週間の終わりだけの指定でしたが,それが使えるのは最初の1度だけで,次からは1週間のはじめの日も指定する必要があります。「○月○日から○月○日まで」としたいわけです。これをやるには,sumifs関数の条件範囲と条件を1つずつ追加すればいいだけです。画像上では順番が前後しますが,下の画像のD列(10/5-10/11)の1週間を指定した場合を見てみましょう。

Screen Shot 2018-10-12 at 14.13.34

1つ目の引数は同じですが,2番目と3番目の引数で始まりの日付の指定,4番目と5番目の引数で終わりの日付の範囲の指定を行っています。

“>=”&”2018-10-05”

という指定は,「2018年10月5日以降」という指定になります。1週間の始まりですね。

“>”&”2018-10-04”

としても同じです。続いて,終わりの日付は,同じように日付列を条件範囲とし,

“<“&”2018-10-12”

を条件にしています。つまり,「2018年10月12日より前」ですので,2018年10月11日の23時59分までのデータが条件に当てはまることになります。

“<=”&”2018-10-11”

でも同じです(むしろこっちのほうがわかりやすいかも)。これで,始まりの日付から終わりの日付までの間の合計語数が計算されます。ここを任意の幅に設定すれば,1週間ではなくとも3日でも4日でも10日でも同じようにできます。

月をまたいだ1週間の語数

同じ月内でのやり方は上の2つのやり方の組み合わせで対応できます。では,月をまたいでしまうときはどうすればよいでしょう。上述したように,月ごとにシートが異なるわけなので,別々のシートに記録された情報を統合する必要が出てきます。ただ,難しいことはなく単純に足し算すればよいだけです。

Screen Shot 2018-10-12 at 14.13.15

この例では,Friday2_201809というシートに9月分,Friday2_201810というシートに,importrange関数でデータを同期させています。9月分のデータで,9月の終わりの数日間(この例では9月28日~9月30日),10月のデータで10月1日からの数日間(この例では10月1日~10月4日)の語数を計算し,合算するという作業です。

つまり,それぞれの月でsumifs関数を使った式を作り,2つのsumifs関数式を+記号でつないであげれば,月をまたいだ場合の語数が計算できます。不等号のみと,不等号+等号の意味の違いは,上で説明したとおりです。

おわりに

ということで,前回の記事で紹介したGASでデータを引っ張る作業,importrange関数でデータを別ファイルにエクスポートする作業と,今回の記事で紹介したsumifs関数で日付指定する3つのパターンを使えば,一定期間の間の語数記録は簡単にできてしまいます。

エクセルが得意な方はすでにお気づきかもしれませんが,実は,1行目に指定する日付を終わりの日付にし,そのセルを日付の範囲指定に利用することもできます。つまり,上の画像で言えば,B1セルに”2018-09-27″,C1セルに”2018-10-04″,D1セルに”2018-10-11″のようにするということです。ただ,見たときに1週間の範囲がわかるほうがいいかなという理由で,そういうやり方はしていません。

ということで,下処理問題は解決されていませんが,だいたいの語数を記録して,学生がいつでも見れるようにするということについては,前回と今回の記事の内容でだいたいカバーできるのではないかなと思います。今の所第三段は予定していませんが,今後もしも「こういう事が必要だなぁ」という事が出てきたら更新するかもしれません。

なにをゆう たむらゆう。

おしまい。

注1. おそらくExcelのピボットテーブルなら,同じ列に当てはまる複数の条件でのフィルタリング可能だと思うので,Excelならピボットテーブルだけでいけると思います。

注2. 画像で一目瞭然ですが,毎週書き続けられている学生と,すでに脱落してしまっている学生が分かれてしまっているのは問題で,これについては何かしらの介入が必要だと思っています。

広告

Slackを用いた授業外ライティング活動の便利ワザ [Google Spreadsheet編①]

はじめに

便利ワザと言えるのかわかりませんが,とりあえず自分はこんな感じでやっていますというお話です。以下の話の発展です。

授業外でライティングする機会を確保するためのSlack

前提として,どのようにSlackを利用しているのかというお話です。google spreadsheetに書き出したデータの扱いについてにご興味がおありの方はこのセクションは飛ばしていただいてかまいません。私がslackを使おうと思ったのは以下のような考えからです。

授業外で,英語ライティングする機会を与えたい。できるだけ自由に書き込みができ,教員もそれを監視・管理しやすい。

やろうやろうと思っていたのですが,なかなかSlackの使い方もよくわかっていませんでした。共同研究の話等でもSlackを使い始めるようになり(サイボウズのサービス終了のため),自分もSlackに慣れてきたのでこの秋学期から導入することにしました。ここでも何回か記事を書いている外国語学部1回生向けのライティングの授業でのことです。

授業外でのライティングは,前記はLMSにある掲示板機能を使い,そこに私が毎週話題をポストしてそれについて各自意見を書き,お互いにコメントし合うというものでした。以下のリンクでそのことにも触れています。

https://tam07pb915.wordpress.com/2018/04/26/writing-class/

後期は,slackをclosed SNSのようにして使い,自由に英語でやりとりをするということを掲示板でのフォーラムライティングの代わりにすることにしました。前期のフォーラムライティングでは,「1人必ず○人にコメント」などとしたりして交流が生まれるようにしてみましたが,コメントが「テンプレ」化してしまったりしていたので,より自由にライティングのコミュニケーションができていったらいいなと思っています。

使い方のルールとしては以下のようにしています。

  • 一般的なルール
    • 自分のスマートフォンに必ずslackアプリをインストールすること
    • 書き込む情報については,既存のSNSに関するルールと同様,誹謗中傷や公序良俗に反する書き込み以外であれば,何について書き込んでも構わない(写真の投稿も可能)
    • 日本語での書き込みは一切禁止
    • 使い方等についての質問がある場合は,#generalに英語で書き込むこと
    • 他のクラスの人にも話題を共有したい場合には#randomに書き込むこと
    • 誰かの書き込みに返信(いわゆるリプ)をしたい場合は,”Start a thread”を使うこと
    • “Start a thread”機能を使うときは,”Also send to #channel-name”にチェックを入れること(こうすることで,メインのタイムラインでも返信が見れます)
    • 誰かに直接話しかけたいときは,@をつけること
    • 成績に算入するのは,自分のクラスのチャンネルに書き込んだもののみ(#generalや#randomや他のクラスのチャンネルに書き込んだものは語数に数えない)

評価方法は,毎週300語を学期の最終授業日まで続け,平均達成度(%)×5点を最終的な評定に加えるというものです。共通シラバスのため,授業外の課題に割ける評価の割合がもともと15点くらいしかないのでこのようにしています。そのために300語って結構えげつないなと思われる方もいるかもしれませんが,私もそう思っています。今学期の様子をとりあえず見てみて,ハードルが高すぎるために「コスパが悪い」と思われて取り組みが悪くなるということがあれば今後語数の基準を下げるかもしれません。

Slackデータのエクスポート

さて,上述のような形でslackを運用しているわけですが,私の扱い方だと「毎週300語」という設定にしているので,学生の立場からすれば「自分が今何語書き込んでいるのか」がいつでもわかるようになっていてほしいというのは当然でしょう。そのために教員がわざわざデータをチェックしてそれぞれの学生の書き込んだ語数を分析してまとめて報告するというのは無理でしょう。というかやってられません。そこで,エクスポート->語数の記録->まとめ,という一連の作業を自動化して,いつでも学生が見れるようにする必要があります。そこで,上に上げたスライドで浦野先生が紹介しているGoogle Apps Scriptを使うというわけです。浦野先生も紹介していますが,SlackのログをGoogle Spreadsheetに保存するという作業自体は以下の記事を参考にすればすぐにできます。

Slack のログを自動で Google Spreadsheet に保存する

問題は,その先で,語数の記録とそのまとめという部分になります。私自身がGoogle Apps Scriptをいじれないので,とりあえずは上記のリンクを参考にGoogle Spreadsheetにログを保存し,そのあとにGoogle Spreadsheetで頑張るということになります。Rでもログを取ってきてまとめて可視化みたいなことはできますが,自動化の部分が少し難ありです。Rのコードもそのうちここに投稿しようと思います。

Google SpreadsheetでSlackのログをいじる

Google Apps Script(GAS)は,自分で決めたトリガーで定期的に更新できるので,その頻度を好みに設定しておくだけで,定期的にデータを最新のものにするという作業はできます。最初は,ログのspreadsheetファイルにある各チャンネルのシートに列を追加して各行の書き込みの語数を記録し,それを別ファイルにピポットテーブルで吐き出すということを考えました。ちなみに,ログのデータは下の画像のような感じでチャンネルごとにシート1枚で記録されます。

A列が日付,B列が名前,C列が書き込まれた内容,D列はもとのJSON形式のデータです(注1)。最初は,このシートのE列に語数カウントの関数を入れていたわけです(excelで語数のカウント方法についてはググればすぐに見つかります)。ただ,それだとシートが更新されるとうまくいきませんでした。このチャンネルのシートをそのまま別シートで参照し,その参照したコピーのデータを使って…ということもやりましたがこれもうまくいかず。ということで,GASが作るスプレッドシートとは別のスプレッドシートファイルを作り,そこからもともとのスプレッドシートの中の特定のシートの情報を参照するという方法を取ることにしました。で,これexcelにもある関数のなのかは知らないんですが,Googleスプレッドシートには,importrangeという関数があり,これを使うことで別ファイルから参照ができます。以下のサイトなどが参考になりました。

【超便利】スプレッドシートで別シートから参照したり集計したりする方法まとめ

引数の基本は,importrange(“参照元ファイルURL”, “参照元シート名!特定セルor範囲)で,このimportrange関数は特定のセルのみを参照する場合と,範囲を指定する場合があるのですが,私は上の画像でいうA〜D列まですべてもってきたいので,範囲を指定することになります。とりあえず,1000行までを1シートに出すという設定だったような気がするので,A1:D1000を指定します。friday2というのは,金曜2限のチャンネルで,後ろのぼかしはslack上のチャンネルIDです。

このimportrange関数をA1セルに入力すると,シートにAからD列までのデータが取得され,参照元のシートがGASによって更新されれば,こちらのシートも更新されます。E列は手動で以下の画像のような関数を入れると,C列のセルの語数がE列のセルに記録されます。あとは,このE列の語数をB列の名前ごとに合計してくれれば,目的達成です。私は金曜の1限と2限に同じライティング科目の別クラスを持っているので,このログシートが2枚あり,そのまとめのシートも2枚あります。

まとめのシートで合計語数の表示

上画像のシート上でやってもいいんですが,見栄えもあるので別シートにまとめだけを作ります。これは,sumproduct関数をつかいます。sumproduct関数は,sumproduct(参照列=名前, 合計を数える列)のような形で使います。下記画像は,”Friday1_import”というシートに,importrange関数で参照元ファイルのデータをインポートしている場合の例です。A列に名前の一覧(注2),B2にこのsumproduct関数をいれます。あとはB2を下にコピーすれば,人数分の合計語数が表示されるというわけです。”Friday1_import”のシートには自動的にデータが追加されていくので,とりあえず1000行を超えないデータであればこれでなんとかなります。

棒グラフでも出したいということなら,範囲選択して棒グラフ挿入でOKです。あとは,このスプレッドシートのファイルを「閲覧可」の権限で共有してSlackに貼り付ければ,学生は自分の好きなタイミングで語数を確認できることになります。私の場合は「毎週300語」という課題なので,週ごとにデータを扱える必要があります。これはもう少し別の手続きが必要になるので,また次回ということに。今日はここまで。

なにをゆう たむらゆう。

おしまい。

注1: そもそも,ちゃんとした「下処理」をしないと,「@XXXXX has joined the channel」とかも記録されますし,絵文字1つが1語みたいになるので,ここでの語数は「アバウトな」語数ということになります。

注2: 私は試行錯誤しているときにピポットテーブルを使ったので名前の一覧はコピペでしたが,そうでない方はログデータの”@XXXX has joined the channel”の列だけソートして名前の一覧をゲットするなどの方法が必要です。

ピアフィードバックの話(ライティング)

今年度ライティングの授業を持っているという話を以前書きました(https://tam07pb915.wordpress.com/2018/04/26/writing-class/)。その授業では,基本的に4週を一単元として,異なるタイプのライティングをしていくという構成になっています。最初はnarrative,次はdescriptive,今はopinion writingをやっています。授業の基本的な構成は以下のようにしています。

 

1限目

  • 書き方についての枠組みの提示
  • ブレスト・プランニング
  • rough draftの執筆

2限目

  • 構成や言語面についての全体へのフィードバック
  • first draftの執筆
  • ピアフィードバック

3限目

  • first draftを見ての全体へのフィードバック
  • first draft(教員の赤入りのもの)へのピアフィードバック
  • second draftの執筆

4限目

  • second draftを見ての全体へのフィードバック
  • second draft(教員の赤入りのもの)へのピアフィードバック
  • フィードバックを受けたものを見てWritten Languaging

Final draftはLMSで電子的に提出させていますが,それ以前の授業内のライティングについてはすべてハンドライティングです。理由はパソコン室でやっていないというだけで,パソコン室使えるなら全部タイプさせてたと思います(よくわかってなかったので依頼書とか出しそびれた)。

上記の授業内容をご覧いただくとおわかりのように,ほとんどの授業のときにピアフィードバックを入れています。これが意味あるか無いかという話はとりあえず置いておきます。私がピアフィードバックを入れている目的は大きく分けて2つあって,1つ目は,他の人のを読むという行為を通じて自分が書くことへの刺激を得てほしいということです。クラス分けされているとはいえすらすらと分量を書けたり,語彙が豊かであったり,あるいは構造の複雑さも高かったりする学生がいる一方で,そうではない学生もいます。他の人のを読むことでライティングに苦手意識があるような学生には「良い部分は真似してほしい」という思いがあります。もちろん,単なる言語面に限らず「ロジック」とか,「文と文のつながり」という点にも意識は向けさせているので,そういうところにも注意しながら読んでもらえるようにしようとしています。

2つ目の目的は,いろんなケースについて,私の赤やコメントを見ることで,どこをどうすればよくなるのかのヒントを得てほしいというねらいです。私のフィードバックは基本indirectあるいはimplicitなので,誤りが含まれていたりおかしいと思うところに赤線や^をいれるだけで,特に正しいものを提示することはないです(たまにdirect feedbackしますが,説明はしません)。また,コメントは9割くらい日本語で(たまにめんどくさいときに英語で書きます),

こういうトピックセンテンスになっているのにボディがそれをサポートしてない

こっちのアイデアについては情報がたくさんあるのにもう一方については具体例も殆ど出てこない

こことここは本当に原因と結果の関係になっている?

なんかこの結論て最初に言ってたことと違う話になってない?

みたいな,構成に関わるものがほとんどです。そういう赤やコメントを見ながら読むことで,良いものとあまり良くないものの例を積み上げていってもらい,それを自分自身が書くときに生かしてほしいということです(注1)。もちろん,かなりできる学生は私が見逃していたような綴りの間違いや形態素の脱落なんかに気づいたりすることもあるので,ピアフィードバックをすることで形式に注意を向ける機会は得られているのかなと思います(ただしこれが自分が書くときの正確さの向上につながっているかは不明)。

ピアフィードバックをするときには,基本的にはドラフト用紙にコメント欄を設けて記名式でコメントとアドバイス(後者は書き手がreviseするときに必ず参考になるようもの)を出すようにということでやっています。

さて,ここまでが前置きなのですが,そのピアフィードバックをどうやるかという話です。最初の頃は,基本的には個人個人でもくもくとコメントを書くような時間を作っていました。20人弱×2クラスあるので,それを全部まぜこぜにしてランダムに配り,20分~30分という時間の中で最低○人のドラフトを読んでコメントをするという指示を出します。自分のペースでコメントをし終わったら前に戻して別の人のドラフトを持っていき,それにコメントして戻してはまた次の人のを取っていくというスタイルです。こういうふうにすると,自分のコメントに責任を持つことが必要になってくる一方で,なかなか「具体的なアドバイスができない」というケースが発生してしまうということが問題でした。また,個人個人の活動なのであまり盛り上がらないということもあります。実はみんなが静かに読んでコメントしている最中にもそこには「沈黙のインタラクション」があるわけなのですが,それは表面化しませんし,クラス全体の雰囲気もだらっとしてしまったり眠くなってしまったりするということもなくはなかったです。もちろん,1年生にしてはかなりレベルの高い学生なので,個人個人でやらせてもそれなりに読めてコメントも的確に出せるのですが。そんなときに,ある友人から,「ペアでピアフィードバックやらせるとめちゃくちゃLRE(Language Related Episode)出てくるよ」というアドバイスをもらいました。そこで,最近は少し形を変えてペアでやらせるようにしました。ただ,ペアでやらせると言ってもやり方はいろいろあると思います。私が今の所引き出しとして持っているのは次の2つのやり方です。

  1.  教室内でペアを作り,お互いのドラフトを交換して読み,口頭でコメントをし合う
  2.  教室内でペアを作り,2人で1枚のドラフトを読んで一緒にコメントを書く

1の方法をもう少し詳しく説明します。この方法は,他のペア活動をするときと同様にペアリングをし,5分間などの時間を設定した上でその制限時間内にパートナーのドラフトを読んで,口頭でアドバイスを送るというものです。この方法のメリットは,著者に直接コメントができるので,著者にしかわからない微妙なニュアンスや,ワードチョイスなどについて直接質問できたり,意味がわからなかった部分について「これってどういうこと?」などと聞ける点です。質問される側は,わからなかったと言われたところは書き直しが必要かもしれないと考えるでしょうし(この前提は甘い?),難しい単語はパラフレーズしたり説明を加えたりという工夫をしようとするケースもあります。また,自分に自信がなくても,「これってさ,ofじゃなくてinじゃないっけ?」という形で聞くことで,「あれ,どっちやったかな。ちょっと調べてみよか」みたいな感じで共同学習がスタートしたりもしているようでした。

2の方法は,前述のように,1枚持っていって読んでコメントするというのを繰り返すパターンを2人でやるものです。これのメリットは,1クラスしかなくても実施が可能な点がpracticalな点としてはあると思います。20人のクラスでもペアにすれば10ペアなので,1ペアにつき1枚ドラフトが渡っても常に10枚はストックが前にある状態なので,読み終わって手持ち無沙汰になるということがなくなります。フィードバックを出すという点については,ペアの相手と一緒にコメントを考えることで,「自分には見えていなかったところに相手が気づいている」というケースが割と出てくるようで,「他の人の書いた原稿」と「他の人のコメント」の両方から発見があるようです。ひとりで黙々とコメント書くパターンでも,自分の前にコメントした人のコメントは読めるようにはなっていますが,二人でコメントを考えるという作業のほうが自分の視点と他人の視点が対照されやすいのかなという印象です。ただし,この方法の問題点の1つは,ペアリングを工夫しないとふたりともなかなか意見が出てこずに沈黙になってしまうということです。私が観察している限りの印象では,熟達度が低い同士で問題が起こるというよりはパートナーとの相性というか,性格の問題が大きいように思います。クラスサイズが小さいですし,他の授業でも一緒というケースも多いので,割とクラスみんなそれなりに仲良しで誰とでも話せるような雰囲気はありますが,そうはいっても全員がそうというわけではないので,たまにこちらがうまく介入してあげないとなかなかアドバイスを出せないということになってしまうようです。1の方法ではあまりこの問題点は顕著ではないように感じるので,reciprocalな関係性がペアの中にあるということがカギなのかもしれません。

ということで,今回はピアフィードバックの3つの方法について記事を書きました。どれがより良いというよりは,クラスの雰囲気,授業の形態や授業のねらい,学生の様子など,いろいろな要因を考慮しながら使い分けていくのがよいのかなと思いますが,ペアでやる2つの方式は割とうまく機能しているかなという手応えがあるので,これからはそちらを中心にやっていこうかなと思います。むしろ最初はペアでやって,ある程度なれてきたらindividual workに移行するのがいいかもしれません。

久しぶりの更新でした。

注1. 授業内で書いたものを直後にフィードバックさせる場合にはこの部分はないです

なにをゆう たむらゆう。

おしまい。

答えは渡さない理由

タイトルは,答えを「渡せない」理由と言ってもいいのかもしれません。何か問題があって、その答えが1つに決まるようなものの時,私個人としては,学生や生徒に答えやあるいは全訳を渡してしまってもいいと思っています。

ところが,答えを学生が所有している状態をひどく嫌う先生というのが世の中にいるようです。「授業時に渡すのならいいが、授業が終われば回収する」ということもあるようです。残念ながら,私にはどうしてそのことが禁じられるような事なのか理解できていません。よくある理由としては,「学生が答えを写してしまう」であるとか,「学生の間で答えが出回るとよくない」というようなものでしょうか。

私は個人の指導観や授業観のようなものとして,「教師は答えを教え,それを学習者は学ぶ」という形態があまり好きではありません。好きではないというより,それが授業の重要な部分を占めるようなものに否定的といった方が良いでしょうか。

もちろん,学習者が教師の知識を必要とする場面は授業の中にたくさんあるでしょうし,そうした場面がなければ教師は必要ありません。ただし,「答えを知っている存在」というのが教師の存在意義だというような考え方にどうしても馴染めないのです。

「答えを渡したくない」と考える人は,それこそが自分の存在価値であるというように考えているか,あるいは授業とは教師が学習者に答えを教えるという活動がメインであると考えているのかなと思ってしまいます。

しかし,教師だけの責任であるとも思いません。学習者も答えを欲しがります。訳を欲しがります。だからこそ,教師は答えをあげることや自分が訳してあげることに意味があると思ってしまうのかもしれません。あるいは,答えを教えるのが学習者のエンゲージメントを最大化するのだという判断のもとなのかもしれません。

そうであったとしても,問題には答えがあり,それを教師のみが知っていて,それを学習者に教えることが授業だという考えにはやはり同意できないところがあります。例え学習者が答えを知っていたとしてもなお,教師の役割がある,学習者が教師の助けを必要とする,そんな授業をしたいと個人的には思います。そして,答えを写すことや,問題には答えがあり,与えられた問題に答えることが学習である,というような考えから学習者を解放することも教師の役割だと思っています。

他の教科や科目のことは詳しくありませが,英語という教科はそうしたことが可能だと思います。なぜなら,言語の使用場面で答えがひとつに定まるという場合は多くないからです。もちろん,教師個人の努力ではどうにもならないこともあるでしょう。カリキュラムレベルでの目標や組織としての目標と授業設計が常にあり,全ての教師がそこに意思決定権をもたない場合もあるからです。

私は研究者の卵であると同時に,英語教師の卵でもあると思っています(後者については20代後半で卵というのもアレですが)。教員養成課程の出身だということもありますし,英語の授業も仕事だからです。授業研究の専門家ではありませんが,授業のことはこれからも考えていきたいです。

なにをゆう たむらゆう。

おしまい。

タスクは取り入れられない

非常勤先で,「タスク・ベースの活動を取り入れた英語授業」というのをやろうということで色々試行錯誤しています。

そこで,最近ようやく気づいたのですが,「タスクを取り入れた英語授業」はできないなっていうことです。タスクをしっかりやろう,消化不良にならないようにしよう,と考えると,それはもう授業全体をタスク・ベースで構想していかないといけません。

「タスクを取り入れる」といった時,それはほとんどの場合,「これまでに行われていたなんらかのコミュニケーション活動をタスクにする」ということになると思います。しかし,タスクの定義を満たしたコミュニケーション活動を,授業の「仕上げ」あるいは「まとめ」的なところにそのまま配置すると,ほとんどの場合タスクをうまく遂行することができず,結局事前に対話の形式を示したり,入れ替える語彙の選択肢を与えたりしてなんとか活動を終わらせることになってしまうと思います。これはなぜかというと,遂行するタスクを意識したインプットを事前に十分に与えて理解するプロセスを経験させておかないとタスクができないからです。タスクというのはそういうものなのです。

これは現在鋭意改訂中の原稿の中でも書いていることなのですが,「タスク・ベースの英語授業」と「タスクを取り入れた英語授業」の一番の違いは,学習者がタスクを遂行できるようにどのような手立てを取るか,にあると思います。前者では,最終的な目標タスク(現実的場面での目標タスクというわけではなく,教室場面で「達成目標となるタスク」の意味です)を達成できるようにするためにタスクを用います。もちろん目標タスクが学習者に産出をもとめない「理解型タスク」である可能性もありますが,ここでは目標タスクは何らかの言語産出を学習者に求める産出型タスクであるとします。後者では,「取り入れる」という発想を取っているわけですから,通常の授業時間の一部をタスクに割り当てることになります。モジュール型アプローチとも呼べますが,週に1度の英語授業でモジュール制でタスクに取り組ませるとすると,単発で毎週異なるタスクに取り組ませるようなことになってしまいます。今までにやってきたようなバリエーション豊かなコミュニケーション活動の数を減らさなければ,目標タスクに向かってステップバイステップで学習者を導くことは不可能でしょう。もしも通常の授業に関連させてタスクを「取り入れる」のだとすると,ほとんどの場合それはなんらかの目標言語形式があったりします。特に,大学でもfalse beginnerを対象にしていたり,リメディアルと呼ばれるような授業であるほど,教科書も「基礎固め」や「やり直し」と称して中学で習った文法をもう一度教えるようなものが多いです(これ系のリメディアル教材は個人的に99%滅びてほしい)。実際,教材で与えられているインプットを活かしたタスクを作ることにはかなり頭を捻らなくてはなりませんし,基本的に大学用の教科書は1週で1課(または2課)という構成になっているので,同じようなタスクに繰り返し取り組ませる余裕もありません。

一方で,タスク・ベースの授業では,目標タスクで必要となる語彙,文法,表現などを学習者に処理させるような理解型のタスクを最初に用います。そこから,徐々に学習者がそれまでに得たインプットを「借りながら」タスクを遂行できるような産出型のタスクを行います。ポイントは,あくまでどんな表現を使うかの判断は学習者に委ねられていることです。そして,タスク自体を易しくしたり,準備時間を十分に取ったりして難易度が低いかたちのタスクに繰り返し取り組ませ,そこから最終的な目標タスクに取り組みます。これでうまくいかなければ同じタスクにもう一度取り組ませたり,やりとりや発話の性質自体は同じで内容を変えたタスクにもう一度取り組ませたりします。つまり,発話を求めるなんらかのタスクを学習者が達成できるようにすることを考えれば,そこまでにたくさんのインプットを与えなければいけませんし,タスクは一度きりで終わってしまうこともできません。要するに,「取り入れる」なんて言ってられないということです。

タスクだけじゃ一つの授業がもたないし…

と考える人がもし仮にいたとすれば,それはタスクをできるようにさせてあげることがどんなに手間のかかることなのかわかっていません。ポンと投げ込みでいれてワイワイ楽しくやれるというのは,ある程度熟達度が高い学生を対象にしている場合のみで(それでもそんな簡単にいくわけではないと思います),私が今教えているようなレベルの学生(TOEIC Bridgeで100前後)がタスクをやって達成感を得たり,「楽しかった」「できた」と感じることができるようになるのは,そんなに簡単なことではないわけです。

教科書もやらないといけないし…

という人には,「教科書やらなくていいでしょ」と言いたいです。もちろん大学でもそういう状況ばかりではないでしょうけど,初学者向けのタスク・ベースの教科書が少ない(ほとんどないと言ってもいい)以上,教科書なしでどんなタスクができるようになってほしいかを考え,そのタスクができるようになるためにはどんなタスクが必要かを中心に授業を構成していくだけで授業は15回できます。そう考えると,教科書を「メイン」にすることは難しいです。学生に教科書を買わせるからそれを使わないことに罪悪感が生まれるのであって,教科書は買わせなければ良いし,もしどうしても何か持たせたいなら「文法書」を持たせてレファレンスブックとして授業や自習時に参照するように指導するか,辞書を持たせて授業に必ず持ってくるように言うほうが教科書を買わせるよりもよっぽど良いと思います(これはこのブログでも何回か言ってる気がしますけど)。

プリントをファイリングしていけば学習の積み重ねとして最終的にそれが教科書の様になるわけですし,教科書に活動が豊富に掲載されていてもそれに書き込んだものはその都度チェックしにくいです。フィードバックを個別に返すことはできなくても,タスクができたかできなかったか,どのあたりで躓いていてどこにフォローが必要なのかはプリントを見ているだけでもある程度把握でき,それによって授業も臨機応変に変化させられるでしょう。シラバスに沿った授業をしたかどうかをFDでチェックされるから学期中に予定を変更するのがためらわれるという意見も聞いたことがありますが,それって本末転倒でしょう。学生を見ずに立てた予定を守ることに何の意味があるのでしょう。学生にこちらの意図をきちんと説明して予定を変えれば理解されるでしょうし,それをしないことは教師としての怠慢だと私は思います。

話が少し逸れました。教科書があれば教材を作る手間も省けますし,練習問題の答え合わせを授業でやることにすれば一度作ったスライドを教科書を変えない限り使いまわせてとても楽でしょう。ただし,それはタスクにも同じことが言えて,タスクだってある程度蓄積があれば教える学生のレベルや状況に合わせて修正しながら使いまわすことだってできます。目標タスクがあればそこから理解型のタスクを作ることもそんなに難しいことでもありません。中途半端にタスクを「取り入れ」て消化不良になるよりは,タスク・ベースでやったほうが学生にも親切な授業設計になるでしょう。

結論,やっぱり,タスク・ベースでやりましょうよ。そのためにこれまでに扱っていた内容を削り落とさないといけないとすれば,そこは勇気を持って取捨選択しないといけないでしょう。90分×15回の授業でカバーできる範囲はそんなに多くありません。

なにをゆう たむらゆう。

おしまい。

英語の勉強はやめよう

授業の時間は限られている。だからこそ,その限られた時間を有効に使いたい。それを突き詰めると,授業という場,教師と学生が1つの教室に集まるその場所でしかできないこと,その場所でしかできない学習をさせてやりたい。それが私の教師としての思い。あえて授業の時間を割く必要がない学習については授業外に各自で学習させるようにすればよい。それを予習とか復習とかいう名前で呼ぶのはきらい。家庭学習ならまだいいかもしれない。それから,勉強という言葉がきらい。「勉強させる」ということばはもっときらい。もしかすると,私が語学学習という意味での「勉強」が嫌いだからかもしれない。しかし,私は英語の勉強は好きである。それはlearning Englishではなくstudying Englishであり,to master Englishという目的ではなく,to acquire knowledge “about” Englishという目的のためにするものである。自身の研究のためでもあるし,英語を教える者として言語に関する知識は多ければ多いほど良い。純粋に知的好奇心もある。

ただ勉強だけしても英語ができるようになるわけではない。いわゆる「勉強」ってヤツをしないと英語ができるようにならないと思っている人(教師も学生も)がいるようだが,それだからダメなんだ。大学生にもなってbe動詞もできないからbe動詞を「しっかり」教えようとか,「基礎からもう一度やり直そう」とか,そんなことやってるからダメなんだ。彼らは間違いなく「教わった」はずだ(cf. 文法の明示的指導研究について思うこと)。中学だけでなく,高校でも「基礎からもう一度」とやり直すような授業をやったのかもしれない。ではなぜ,彼らは大学生にもなってbe動詞もわからず,代名詞の目的格もわからないのか。それは教えただけじゃできるようにならないしすぐ忘れるからである。こんな当たり前のことにも気づかないのか。リメディアルという名のもとにくそつまらない文法やり直し問題集を大学向けの教科書にしてる場合じゃない。

どんなに話のうまい先生がどんなにわかりやすい丁寧な説明をしたところで,そこで「わかったつもり」になってあとは忘れるだけである。普通の教師が説明しても身につかなくて当たり前。だいたい教師の説明なんてほとんど聞いてない。必死にメモを取っても忘れる。「英語は教わったように教えるな」という若林先生の名言があるが,私はもっとラディカルに,「英語は教えるな」くらい言いたい。ただこれだと語弊がある(若林先生に教えない教師など必要ない。失格だ。と言われてしまう)。教えるなとは言わない。教えてと言われた時に教えればいい。教えてと言われなければ教えなくていい。少なくとも,説明などしなくてもよい。どうしても説明したいなら紙でも配って勝手に読ませれば良い。教師が教室で話す意味はあまりない。少なくとも,何か別の活動に関連した規則についてその活動のあとに説明するなど,何かしらの活動と関連性がある場合を除いては。もし「配っても読まないし」と言うのなら,それを読まない学生は知りたくもないし教えて欲しいとも思っていないのだ。やはり教えなくてよい。どうしても,どうしても教えたいのなら「どうしたら学生が食い入るように文法説明のプリントを読む状態になるか」を考え,そのために必要な活動をやらせれば良い。それを考えずに上手くもない説明を無理矢理学生に聞かせることになど意味がない。

もうひとつ教える場面があるとすれば,それはフィードバックを出すときである。学習者の産出した言語に対してフィードバックを出すのは良い(もちろん文法項目によっては受容面に関してprocessing instruction的なことをやることにも意味はあると思う)。むしろどんどんフィードバックすればよい(どうフィードバック出すかが問題だが)。そこで教師としての力量が問われる。ただし,誤りが害悪だからフィードバックを出すのではない。学習者の誤りはそれ自体が学習者の中間言語体系を表しているからである。学習者がどのように中間言語を発達させているかを見るには誤りを観察するほかない。それがCorder(1967)の“The significance of learner’s errors”の意味である。学生が何かの目的を持って言語を使う。そして教師がフィードバックをする。そこで発生するのはstudyingではない。learningである。いつまでたっても英語ができないのは,教室で英語を勉強する/勉強させるからだ。教室以外のところでは勉強しても良い。learningのために必要なstudyingならさせても良い。ただし教室内では,英語の勉強はやめよう。そういう授業をやろう。

なにをゆう たむらゆう。

おしまい。

3単現の-(e)sは口をついて出るくらいまで練習

馬鹿じゃないのと思った。

今,とある原稿の執筆にあたって(〆切に間に合いそうになくてやばい),中学や高校の教科書のCAN-DOリスト,評価基準,年間指導計画なんかを見ている。そこで,とある教科書の(あえて名前は出さない)年間指導計画の,指導例というカラムに次のような記述があった。

3単現の-(e)sは理屈で覚えるよりも口をついて出るくらいまで文を言い,書く練習をする

まさに,「お前は何を言っているんだ」の気分である。そんな無駄なことをさせるくらいだったらもっといくらでもやること,やれることがあるだろう。これを書いた人は,自分が3単現の-sをまったく落とさない自信があるというのだろうか。3単現の-sは,超高熟達度の学習者でも習得が困難であると言われる文法項目の典型的な代表である。そして,文法的に主語をidentifyする機能はあるが,これがなくても文の理解に支障をきたすことはほとんどないと言っていい。なぜなら,英語は語順がわかれば主語が(ほとんどの場合)わかるからである。また,有生性も動作主-被動作主の関係を表すのに重要な手がかりとなる。3単現の-sが脱落していることが,意味理解を阻害することはほとんどない。過剰使用されている場合もそうだ(実は過剰使用の方が気づきやすいらしい)。

この「文を言い,書く練習をする」というのが,単なるパターンプラクティスのような物を意味していないのだとすれば,それに意味がないとは言わない。しかし,そうであったとしても,そのような活動は3単現の-sの習得を目指して行われるべきものではないだろう。誤解を恐れずに言えば,3単現の-sの習得など目指さなくても良い。それこそ,理屈を知っていて,ライティングの時などにモニタリングして直せれば良い程度のものではないか(それでも見逃すことだって私にはあるが)。3単現の-sが落ちていることにそんなに目くじら立てる必要はどこにあるのだろうかと思う。しかも,あろうことかそのどうでもいい形態素を習ったばかりの中学校1年生に対して,そんな無駄な苦行を強いるなんて言語道断である。もし本当に三単現の-sの習得を目指したいのであれば,それ以外のところにほとんど注意を向けなくとも書いたり話したりできるような訓練をした方がよっぽど良い。そういうことに時間を割いたほうが,全体としての英語力も上がるだろうし,結果的に3単現を落とすことも少なくはなるだろう(それでも母語話者レベルにはならないと思うが)。

私は英語の第二言語話者としてそれなりに機能できる自信があるし,相手の言っていることを理解したり,自分の気持ちや考えを伝えたりすることだってそれなりにはできると思っている(ただし,英語力に自信があるわけではない。語彙とかたぶん5000語くらいしかない)。英語を中学1年から勉強し始め,北米に2年間留学した私でさえ(むしろその程度だからこそ?),3単現はたまに落とす。英語教師として,正確無比な言語使用ができないことはプロとして恥じるべきだとは思うし,実際に毎週英語で授業をしながら「ヤベッ」と思うことがある。それはプロだからである。英語を教えることでお金をもらっているからである。プロを目指してもいない,英語学習を始めたばかりの中学生に(高校生や大学生だってそうだ),「口をついて出てくるまで」きっと無意味な文を言わせるなんて,そんな指導観を持っている人には絶対に教わりたくない。もちろん,そこまでして,情熱的に,なんとかして,英語を身につけさせてやりたいという熱意は素晴らしいと思う。しかしながら,圧倒的にベクトルが間違っている。その情熱はもっと別のところに注ぐべきだ。

余談だが,実はかくいう私も3単現の-sを減点したことがないかと言えば嘘になる。先日のテストのライティング問題である。語数,内容,文法・スペリングという3観点の評価方式を私はよく採用している。昨年度までは,このような形式を取る問題は1問だけで,ほかは文法の間違いは一切評価しない問題も出していた。今年は,そういう問題を出題できる環境でもないので,3観点方式のライティング問題だけを出した。そこで,私の担当しているクラスのうちの1つで,とびっきり出来の良い学生が,3単現の-sを落としたというだけで,99点を取った。私も採点しながら,本当に心苦しい気持ちになってしまった。途中まで採点していて,「これは満点だなぁ」と思っていた矢先,最後の最後のライティング問題で彼の「誤り」を見つけた時,この採点方式を取ったことを本当に後悔した。テストの他の大問も完璧で,ライティング自体もトピックに沿ってよく書けていた。そこにきて,3単現の-sがたった一箇所落ちていただけで,私は彼が満点を取ることを阻止してしまったのだ。そして,翌週テストを返却したとき,答案をみてその学生が言い放った一言を私は一生忘れることがないだろう。

「くだらねえ」

私はなにも言えなかった。そして,自分で問題を作っておきながら,私自身も「くだらねぇ」と思ってしまったのだ。大いに反省した。そして,今度の期末試験では,文法面に関しては「意味理解を阻害するかどうか」という観点で,おおまかにレベルを4段階設定し(Foster & Wigglesworth, 2016を参考にした),意味理解を阻害しない程度の誤りが少数見られる場合は,その観点では満点とすることにした。もちろん,このレベル分けや,誤りのレベルの頻度というやり方も完璧とは言えない。まず,「なにを持って意味理解を阻害しない」と考えるのかは非常に難しい問題である(もちろんいくつの誤りがあれば「少数」とするかも問題である)。意外なことに,第二言語習得研究の知見からこの観点に関して言えることはほとんどないと言っていい。「誤りの重み付け」に焦点をあてた前述のFosterらの研究が「新しい評価法考えたったー!!」と言ってAnnual Review of Applied Linguisticsの最新号に掲載されているくらいだから,本当に研究されてこなかったのだろう。博論が終わったらこういう問題に取り組みたいとは思っているが,誰か「面白そうだな」と思う方がいらっしゃったらどんどんやっていただきたい。というかむしろ誰かやってくださいという感じだ。

かなり脱線したが,3単現の-sは本当に厄介者である。というかむしろ,「数の一致 (number agreement)」という事象自体が実はかなりの厄介者なのである。結論を言うと,文法習得を専門に研究している私から言わせてもらえば

3単現の-sをなめんなよ

である。そして,文法の正確さばかりに目くじらを立てる英語教師(含む過去の自分)は全員引退した方がみんな幸せになると思う。

なにをゆう たむらゆう。

おしまい。