データサイエンス・アイデアコンテスト

3大学（関西・中央・法政）共催 データサイエンス・アイデアコンテスト（協賛 マイナビ）の最終選考会に出場した4チームのうち，iDS飯尾ゼミから出場した2チームが特別賞を受賞しました．おめでとう！

大学からのニュースリリースはこちら，「開催報告：３大学（関西・中央・法政）共催 データサイエンス・アイデアコンテスト（協賛 マイナビ）最終選考会」です．

最終選考に残らなかったチームも，頑張りました．惜しかった．次回は全員入賞を目指すぞ！

ビデオ授業の難しさ

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が溜まればそれはひとつの財産になるし，重複した質問を避けられる利点があるからである．

散歩のすすめ

昨日，半蔵門で地下鉄を降りて市ヶ谷に向かっていたら「エクセル麹町」というマンションの前を通りかかった．そして今日，巣鴨から駒込までぶらぶら散歩していたら，「エクセル巣鴨」を発見．昨日の今日なので，驚いた．

調べてみたら，エクセル早稲田やエクセル大塚，エクセル駒込，エクセル千石，エクセル茗荷谷など，エクセルシリーズが街ごとにあるらしい．

散歩しているとこういうことに気づく．散歩していないとなかなか気づかない．散歩は面白い．

OSS万歳＼(^o^)／

事の発端はこれ．学生たちがTwineというツールを使い，とあるシミュレータを作ろうとしているのだが，操作ログを記録してユーザの挙動を分析したい，なんてことを言っていた．TwineではHarloweという簡易なスクリプト言語というかマクロ？を利用でき，それを使えばできそうだなとやってみた．

(history:)というコマンドがあって，最後のページでそれを評価すればユーザの操作履歴は追える．しかし，残念ながらタイムスタンプまでは記録されない．したがってタイムスタンプ付きで記録を取るには，自前のスクリプトを書く必要がありそうだ．少し考えた末，(current-time:) というコマンドを使って，変数に逐一記録していけばできそうだと試してみた結果が次の画面である．

できるにはできたが……惜しい．なんということか，(current-time:)の粒度が粗すぎる．さて，ではこの(current-time:)をなんとかしようか，と手を出してしまったのが，今回報告する顛末の発端である．

Twineを調査

まずは，Twineのソースコードを調査する．GitHubから同プロジェクトのソースコードをダウンロードしてきて，"current-time"をキーワードにgrepしてみるも，それらしいコードが見当たらない．

そもそもHarloweのスクリプトをレンダリングしているのはどこのタイミングなんだろう？これがよくわからない．Google ChromeでF12キーを押してWeb開発ツールでデバッグしてみようにも，どうにもよくわからなくてお手上げである．

そこでHarlowe関連のドキュメントを探ってみた．ん？Harloweって，Twine関係ないんじゃないの？と気付いたのが迷路から脱出できた鍵となった．決定打は「Where can I find the "Twine engine code"? #649」というGitHubのイシュー．「Twine engine code」がキーである．

なんということはない，Harloweスクリプトは，Twineが出力するHTMLに埋め込まれた難読化されたTwine engine codeのJavaScriptが解析し，その動作を決定していたというわけだ．そこで，次はHarloweのソースコードにあたる．こちらをダウンロードして，解読した．

Harloweエンジンの調査

ここから先は一本道だった．Harloweのソースコードを入手，展開し，再び"current-time"をキーワードにしてgrepする．

BINGO！当該コマンドを処理するソースコードに辿り着いた．案の定，new Date() して日付オブジェクトを取得したあと，時間と分を得て，文字列を生成している．ここに秒を取得するコードを追加すればよいだけである．

以上の追跡結果から，Twineの出力に埋め込まれた難読化JavaScriptの該当部分にパッチを当てれば望んだ出力が得られるということがわかった．

これで問題は解決したのだが，ここまで3時間．やはり，他人様の書いたコードを解読するのは難儀な仕事よのうと思ったとか思わなかったとか．

AのBのCのD問題

「AのBのCのD」と題したが，「α of β of γ of δ」でも同様，すなわち，日本語でも英語でも避けるべき表現で，多くの言語に共通する話題である．

あるXのポストがちょっとした話題になっていた．次の図はそのキリトリである．なお，IDを特定できる部分は，自分のアイコンを除いて，モザイクをかけた．

ここで問題になっているのが，「高校の国語の教員の妻」という表現である．「の」の数が間違っているのはご愛嬌として，この表現が悪文であるとの指摘に私も異論はない．

悪文の理由

なぜこのような表現が悪文とされるのだろうか．ひとつには，〜の，〜の，〜の……という，単調なリズムの問題がある．これは若干，感覚的なものかもしれないが，文章において単調なリズムが繰り返されると，違和感を覚える．

よく例に挙げられるのは，「Aである，そしてBである，そしてCである，そしてDである」というような表現．「そして」という接続詞で文を淡々と繋げる表現は「小学生の作文じゃあるまいし」と指摘されるだろう．

文末が同じ表現で続くような文章も同様である．上記の「〜である」が続くのも端的な例であろう．文を書き慣れている人であれば，それを避けるために，形容詞で終わらせたり，多様な動詞で終わらせたりといった工夫を自然と加えているはずである．

「『の』や『of』で繋ぐのは安易だ」という指摘もできよう．上記の「高校の国語の教員の妻」という表現は，「高校で国語を教えている妻」と言い換えられる．「の」を一切使わずに同じ意味を表現できる．

曖昧性の忌避

上記の言い換えに関し，「え？意味変わってね？」と思われた方もいるかもしれない．それは，おそらく「高校の国語の教員の妻」を「高校の国語教員（をしている人）の妻」と解釈していた方だろう．

このように，「AのBのCのD」と「の」を重ねた表現は，解釈の多義性が生まれかねないリスクを孕む．もっと別の例で考えてみよう．「前の会社の管理職の妻」ではどうだろうか．

• 「以前勤めていた会社で管理職として働く妻」
• 「以前勤めていた会社の管理職である人の妻」
• 「目の前にある会社で働く管理職の人の妻」
• 「目の前にある会社で働いている管理職である妻」

など，いろいろな解釈が可能で，もはや収集がつかない（他にも考えられるはず．考えてみてください）．

文脈に強く依存しがちな日本語

さて，当該スレでは議論が盛り上がっていて，リプ欄を追っかけていたら，この文章は曖昧で複数の意味に解釈できるから悪文であるという指摘に対して「日本人なら一意に解釈できるでしょ」って噛みついている人がいた．

「いいと思う？最低です．高校の国語の教員の妻も同意見です」という元文章だけだと分かりづらいが，私なら次のように考えるだろう．

何かについて「最低だ」と言っていて，妻も同意見だと補足している，話題に出ているのは「日本語の作文技術」っていう本で，あーだから高校の国語の教員なのか，じゃあ，本人が教員だったら，あえて「妻も同意」っていうのはおかしいな？と考えると，教員なのは奥さんなんだな……

このような推測に基づき，多くの日本語話者が「高校の国語の教員をしている奥さん」と考える．だから「日本人なら分かるでしょ」となる．

日本語は主語を省略してもよいくらい，文脈に強く依存する言語である．そのことに鑑みれば，カミツキ氏の主張は分からぬでもない．しかし，読み手に負担をかける，認知負荷を強要するという点で，避けるべき表現であるという指摘は譲れない．なので，上記のように考えなかった人も悲観することはない．ご安心を！

いずれにしても，どのような言語にしても，分かりやすい文章表現と分かりにくい文章表現はあり，分かりやすい表現を心がけないといけない．そう考えると，やはり「AのBのCのD」のような表現は避けるべきである．私なら「AのBのC」も避ける．「の」に限らない．同じ助詞が続くような表現は使わないように気をつけている．英語でも同じである．

今日の教育ぷちDX

例年，ちょっとした反転授業というか，履修者から提出された課題のフィードバックを次の授業時間の冒頭でそれなりに時間をかけて念入りに解説するようにしている．履修者の満足度は高く，それゆえに学習効果も高くなるであろうことが期待される手法と考え，数年前から導入している方法である．

ところが，実際にこれをやろうとすると，その準備がけっこう大変である．提出物を一括してダウンロードするところまでは，LMSの機能を用いれば簡単にできる．そのファイルに対して，例年は，匿名化し，順序をシャッフルしたうえで一つのファイルにまとめ，誰の提出課題かわからないように示すという作業を，手で行なっていたからである．

手作業でやっていた理由は簡単で，例年の履修者が10数人といった規模だったので，手作業でやってもせいぜい30分くらいの作業で済んでいたから，なんとなく惰性でやっていたにすぎない．

ところが今年は，なぜか履修者数が50名を超えた．1回めの受講状況はその6割といったところで，課題提出者は30数名であった．しかし，30もあると手作業でやるのは，やや，しんどい．

というわけで重い腰を上げて，簡単なスクリプトを書いて処理することにした．

まずはファイルをランダムに並べ直してファイル名を匿名化するコードを考えた．Rubyのshuffleメソッドを使えば簡単に実現できるな？と思って書いたスクリプトが次のものである．LMSからダウンロードした履修者のファイル，そのファイル名は，学籍番号コード文字列の後に履修者が提出したファイルの元の名前が続く，という仕様になっているため，2桁の数字の後に「G」が続くという学籍番号の特徴を利用して，それらのファイルだけを選択してファイル名を変えるようにした．

#!/usr/bin/env ruby

system("rm reportlist.xlsx")

files = IO.readlines("| ls | grep [123][0-9]G")

files.shuffle!

files.each_with_index{|filename,i|

  filename.chomp!

  (body, ext) = filename.split('.')

  system("mv \"#{filename}\" file%02d.#{ext}" % i)

}

続いては，ファイル内に記載された指名と学籍番号の削除である．これも実にいい加減なクイックハックで，提出されるファイルが「こちらがあらかじめ用意したワークシート」であることをいいことに，2行目と3行目に書かれるであろう氏名と学籍番号を，単純に削除するだけのもの．こちらはPythonのpython-docxライブラリを用いた．

#!/usr/bin/env python

import docx

import sys

filename = sys.argv[1]

doc = docx.Document(filename)

doc.paragraphs[1].text = ''

doc.paragraphs[2].text = ''

doc.save(filename)

あとは，binディレクトリに置いておいた先のファイル名変更スクリプト（rename.rb）と，こちらの匿名化スクリプト（removeid.py）を，シェルスクリプトのバッチファイル（batch.sh）で回すだけである．

#!/bin/sh

../bin/rename.rb

for f in file*.docx; do

  /bin/echo -n "processing $f ... "

  ../bin/removeid.py $f

  echo done

done

実に簡単．手間いらず．LMSからダウンロードした提出物を展開して，このバッチファイル一発かますだけ！

今日は少し時間と手間を掛けてしまったが，来週から準備も楽になるなーと思うと，少し楽しい気分になる．