Education support system

2001年から数年間、継続的に教育支援システムの設計・運用する機会を得たので、それに際して得た知見を雑感として書き留めておく。

とりあげるシステムはレポート提出を Web インタフェイスで実現する課題提出システムと、比較的一般的な掲示板機能を提供する掲示板システムである。

本稿では、これらのシステムについてどのような点に留意して設計したか、その大まかな指針や実装時の注意点などについて記す。体系的に書くのは労力的に辛いので、思いついたまま順不同に書く。

取りあげるシステムの設計時の出発点は、「なぜ＊＊では駄目なのか」という否定的なところにある。例えばレポートはメイルでも回収できるのに、なぜそれでは駄目で新しいシステムを開発する必要があるのか、と。

システムの特徴を書く代わりに、まずこの否定的出発点から見た設計方針を示す。

メイルによるレポート回収はすべきでない。理由は教員と学生間のトラブルを発生させる、またはそのリスクを増加させるからである。

メイルは必ず届くとは限らない。送信側 PC から受信側 PC に居たる全ての経路上のシステムで不達となるトラブルが発生する可能性がある。そしてそれぞれのトラブルの際にどのような現象が発生し、どう対処すればよいのかを理解することは非常に難しい。

どの段階でどのようなトラブルがあった場合、誰に、どのようなエラーメイルが返るか良く把握出来ている人は少ない。エラーメイルの内容を見て、誰にどのような責任があったか判定することも難しい。そもそもエラーメイルが戻っているのはかなりラッキーで簡単なケースであり、厄介なケースは他に幾らもある ^[1] 。

メイルユーティリティは操作ミスを犯しやすい。誤って Delete キーに触れただけで、一通のレポートが消え、そうした操作ミスがあったことを調べる方法がない（正確には「操作ミスをしていない事を確認する方法がない）。

50 人の受講生から 50 通のレポートを 10 週にわたって受け取った教員が、たったの一通も見落とさず、完全に全て処理できるとはそもそも簡単には信じられない。人間はもっと高いレートでミスを犯すものである ^[2] 。

メイルでは締め切りを越えてから送信してくるレポートを拒絶出来ない。きわどく締め切りを越えて提出されたものも、学生本人は時間内に提出したと主張する場合がままある。真実そうかも知れないし、そうでないかもしれない。

レポート提出の場面で、まことしやかに嘘を並べる学生が存在する ^[1] 。問題に気が付いていないのか、そう言い張れば何とかなると思っているのか、真実は誰にも分からないし、そこを確定するための努力は全くナンセンスである。

メイルによるレポートの回収は、その一方向性（双方向作業でないこと）からくる不達や、操作ミスなどを確認できない点で致命的である。結果としてこれらのトラブルは学生との「間違いなく送った」「いや、届いていない」という押し問答や双方の不信へと置換される可能性が高いのもまずい。

レポート提出（回収）は双方向性の操作による、操作が正しく完了したことを自己検証できるシステムで行われなければならない。また、ミスオペレーションが無かったことを確信出来るシステムでなければならない。最悪のミスオペレーションは教員による提出課題の削除である。つまりその機能は実装してはならない。

WebCT 等市販の LMS ツールにもレポート回収の機能はあるが、レポート回収のためにこれらを導入するのは間違いである。理由は利用者がそれに適さないからである。

設計時点で、このシステムは大学初の大規模に利用される教育支援ツールであった。これを使ってくれる教員利用者がどれだけいるかは全く未知数であり、むしろまずこれから増やす段階にあった。WebCT 等市販の LMS は市場での競争のためにいわゆる満艦飾ソフトウェアとなっており、レポート提出だけを望む教員にとって操作上の敷居が高すぎる。

大学コンソーシアム京都での調査などで、レポート提出が教育支援でのコンピュータ利用の需要、第一位であることが分かっている。そして第二位の掲示板等がそれより圧倒的に低い需要（利用度）であることも分かっている。つまり、大学初の教育支援システムはレポート提出であるべきで、それより遙かに利用者数が少ないと見込まれる他の機能のために敷居を高めて利用者の誘導を困難にすべきではない。

なんとなれば課題提出システムの利用開始から 4 年を経た 2006 年ですら、そのサービス停止という強制力を背景にしても満艦飾的 Moodle への移行に難色を示し、利用を諦める教員が出るくらいである。自分たちの状況をよく見て、理解しなければならない。

クラス運営に用いる掲示板システムに miniBBS のようなよく流通しているものを使ってはならない。理由はその目的の違いから、教員と学生間のトラブルを発生させる、またはそのリスクを増加させるからである。

一般的な掲示板は「ときどき覗きに来る人を相手に、話題を盛り上げる」ことが目的で設計されている。そのため、もっとも盛り上がっている（頻繁に投稿のある）スレッド（等）を最も目立つように配置する。すなわち投稿の少ないものは分かりにくいところに置かれる。

しかしクラスにおける話題の重要度は盛り上がりとは直接関係がない。久しぶりに掲示板を覗いた受講生は、最近の目立つ話題だけ読めばよいわけではなく、クラスの流れを時系列に追う方が望ましい。そして教員は目立つ話題、目立たないものに拘わらず、全ての投稿に目を通す義務がある。

特に教員にとって、全ての記事に目を通すことは重要な義務である。miniBBS のような「通りすがりの人に、よりヒトコト残していって貰いやすい状況を用意する」タイプのシステムは、最も盛り上がっているものを前に出せばそれで良いが、教員はむしろ「非常に久しぶりに投稿された」マイナーなスレッドに注目しなければならない。

そのため未読記事がどこにあるか、一目で分かるようにしなければならない。つまり login し、利用者ごとの既読管理をするシステムが必要になる。

クラス運営のための掲示板には匿名性が必要である。何百人もが登録されているクラスの掲示板で発言することが個人情報の大宣伝になってはならない。出席代わりの感想文の投稿が、事実上のクラス名簿になってはならない。

しかし login する掲示板システムの多く（ほぼ全て）は匿名性をもっていない。理由は登録名（ハンドル名）を実名にしなければ良いからだ。だがクラス運営では発言を成績に直結しないような場合でも、その発言が誰のものであったか、少なくとも教員には明確でなければならない。理由は差別発言やフレームなどのトラブルに対応するためである。

学生という年代から見て、その掲示板では一般的にコミュニケーションの場で起こりる全ての問題が容易に発生することを外すわけにはいかない。クラス掲示板ではメンバー管理と匿名性を両立させる必要がある。

2001年末に非常勤の立場でレポート提出を web インタフェイスで処理する「課題提出システム」の設計に携わり、翌年度からおよそ四年間、その改良と運用に関わったので、その設計時の留意点などについて記す。

専任教員 300 名、学生 13,000 名規模の大学における 4 年の運用で、10 万を悠に超えるレポートを処理したことになる。

システムは直感的な操作で作業を完了出来なければならない。

マニュアルなしで利用できるのが良い。こうしたシステムになれていない教員利用者でも、一度誰かに目の前でランスルーして貰えれば三ヶ月後に独力で操作をしても何とかなる、という程度が良い。そうでなければ年に一度か二度しか利用しない教員や受講生には大変なリスクと負荷を負わせることになるし、「今週このテーマでレポートを出すと効果的だ」と講義の最中に思いついても、不慣れな教員はその実施を決断できない。

準備のなされていない、思いつきでやっているようなクラス運営を肯定するのではなく、思いついたその時にシステムが柔軟に対応できるように設計すべきだ、と理解して欲しい。

また、Web 型アプリケーションにおいては、操作の簡単さはシステム負荷の軽減に直結する。学生のレポート提出までに、フォーム入力なら login を含めて 10 クリック以下にしたい。これが 20 クリックを要するのであれば、システム負荷はそのまま倍増する。

（実際 7,8 クリック程度で login/提出/logout まで完了するし、ほとんどの教員・学生利用者はランスルー時の記憶だけで操作を行っており、マニュアルを閲覧しないで済ませている。）

下手な設計をすると、大規模クラスで利用した場合、教員は人数 x N 回のクリックを要求されてしまう。それは余りに不条理であるし、教員の負担が重すぎる。大量データの回収と一律処理は本質的に機械処理による自動化に有利な局面であるのに、それに大量の手間を伴うことは矛盾している。

まず 200 人の受講者から毎週 10 pages にもわたる論文を回収するクラスはない。教員がそれを読み続けることが出来ないからである。大規模クラスであり得て、かつ自動処理で支援すべき第一のケースは、一人当たり数秒で読めるような短いレポートの大量回収であろう。

そこでフォーム入力によるレポート回収機能をつけ、回収した結果については一覧にして提示する機能を設けた。これによって 100 人から回収したデータを 10 クリック程度で教員は一覧化でき、それをざっと（ディスプレイでも、印刷してでも）眺めることが出来る。多くの回答は一律の出席点といった評価となるだろうから、これを一斉評価できるよう評価機能に付け加えた。一斉評価の後に一部の特別なものだけ赤ペンでチェックするなりして、加点なり減点なりすれば足りる。

ファイルによる提出機能にも、一括ダウンロードの機能を付けて学生IDごとにフォルダに分けて手元の PC 上で扱えるようにした。100のファイルがあるからといって、100 回ダウンロードボタンをクリックして 100 回次ページボタンをクリックし続けるようなことにはならない。

成績処理などは多くが教員の手元の表計算ソフトなどで実施されるものと想像する。即ち評価機能や完全な成績データを作成する機能を用意する必要性はそれほどない。逆に採点補助や評価の方法は教員によって全く異なっており、これを一律にシステム化することは良くない。

故に事後処理のための基礎データを出力する機能の方により注力すべき。

日本語が読めない利用者も居る（最低限教員には多数居る）ので、複数言語のサポートが不可能な構造にしてはならない。最初に二言語で作成しておけば、後で拡張するのはそう困難ではない。

成績評価のために使った材料は何年間といった保存義務が教員には課されている。年月が経ち、システムの運用が止まって以降も、回収したデータなどには容易にアクセス出来なければならない。

そのために一括ダウンロード機能を用意した。必要なデータのすべてにアクセス出来るように静的 HTML 形式でまとめられている。

Moodle はもともと Moodle に戻すことしかできないデータ形式でのバックアップしか用意していないし、現在この大学の運用では年度ごとにデータは消されてしまう。つまり成績基礎データ保存の方針と矛盾している。これは保存責任を個人に負わせるものであるが、利用者には全画面のプリントアウト程度しか実現手段が無く、ナンセンスである。

教員は自分の授業の内容を公開することを嫌う場合がある。同僚に見られるのを避けたい、受講生に過年度の内容を先走って見られたくない、と言った理由で、受講生以外の誰も、クラスの中味にアクセスできないようにすべきである。

セッション維持は PHP のセッション機能を利用しなかった。理由は自己生成したランダム番号の MD5 ハッシュといった方法に衝突の危険を感じたためである。ユーザ ID とランダム番号の両方を照合すれば、この衝突は防げる。

PHP のセッションキー生成は MD5 を使っているので衝突の可能性は（限りなく）低いといった議論が見つかるが、話はそう単純でもない。プログラマの心理としては衝突しない処理方法がある限りそちらを選ぶ。

日本語文字（二バイト文字）によるファイルのアップロードでは常にファイル名の文字化け問題がつきまとう。ブラウザ、OS 等の環境次第で復元できる日本語 encode とそうでないものとが入り乱れている。最終的にはブラウザや OS の状況を調べてそれに合わせた会社の方法を採ることでこれに対応した。

当初「クラスとは一人の教員とひとつの部屋を特定の時間に割り当てるものだ」と
して設計していたが、実際のクラスの運用は遙かに複雑だった。
一人で二つのクラスを同時に一つの部屋で実施する（再履修などで普通に存在）。
二人の担当者で二つのクラスを担当する。前半後半に分け、途中で担当交代する。

上記のクラスの構成にあるように、ある種のクラスは担当者が複数人いたりするので、複数のクラスを複数の教員で対称または非対称に共有することがおきる。ある時間、あるコマには担当者は一人だけとしていたので、これに対応できない。

ゲストスピーカー的教員の参加や、チューター、ゼミの OB の参加などさまざまなことがクラスでは起きるが、それらをフォローする作業が全てシステム管理者の手作業となってしまう。これらは担当教員自身の操作で実現出来るようにすべきだった。

2003 年 7 月にクラス運営につかえる掲示板を web インタフェイスで運用するシステムを作った。

スレッドは単なる投稿順ではなくスレッド・ツリーを追いかけた状態で表示される。一般的な掲示板は最新の記事が最も最初に目に付くところに並べられるが、この掲示板では投稿順に並べられ、最後に最新の投稿が置かれる。

理由は一般的な掲示板が「盛り上がる」ことを目的としたコミュニティであるのに対して、教育向けは「順を追った説明が確実に受けられる」ことを目的としている。そのためには時系列に上から下に向かっており、受講生は最初に投稿の頭から見るのがよい。

ある記事が既読か未読かを記録しておいて利用者に見せることは重要である。一般的な掲示板は、興味を引きそうな記事遭遇出来ればハッピーで、そうでなければ残念、という格好になっているが、授業支援のシステムはこれとは異なる。

投稿された全ての記事を、間違いなく全てを読むことができる点が重要である。学生に対しては「そのアナウンスは知らなかった、気が付かなかった」のは学生自身の fault であるので対応しない、と教員は言えなければならないし、教員は学生の質問などを見落としてはならない。

つまり利用者は、どの掲示板のどのスレッドに未読記事があるか、またはどこも見る必要がないか、トップページを見るだけでそれを判断できなければならない。そうでなければユーザは毎時間毎時間、あちこちのスレッドをチェックして回ることになる。最新記事が何時だったか？といった不完全な情報はほとんどこの作業の助けにならない。

教員は大量の記事があったとき、後からそれを見返したり、コメントをつけたり、また翌日に授業で見せたりするだろう。そのために、目立つマークを付ける機能があると便利かもしれない。

非常ににぎわっている掲示板であれば問題はない。しかし滅多に投稿がない掲示板は問題である。教員は学生からの質問を放置して学生からの信用を失ったりしないために、毎日その必要もないのに（僅かの可能性と大きなリスクのために！）掲示板をチェックし続けなければならない。

これを避けるために投稿があればメイルで通知をする機能があると良い。しかし以下の二つの問題に対応する必要がある。

100 通の投稿に対して 100 通のメイルが届いてはならない。投稿からある一定時間、アクセスがなければ初めて通知を行うようにするべき。またその最後の通知から後にユーザが一度もloginしていない状態で行われた更なる投稿に対する通知は必要ないと考えるべき。しかしある一定期間経過した後でもただの一度も login していないのなら、これについては再度の通知を行うべきであろう。偶然にも最初の通知メイルを受け取り損ねているかもしれないからである。

細かなロジック（仕様）はともかく、そうしたある程度まで知的な通知の方法を採るべきである。

メイルは必ず届くとは限らない。利用者のメイルボックスは受け取れない状態かも知れないし、メイルアドレスの設定に typo があるかもしれない。そしてそれらのエラーメイルは送信者に戻るわけではなくシステム管理者に戻る。

つまり信頼出来ないメイルアドレスに対する通知をシステム全体で頻繁に行うような状態を作ってはならない。メイルサービスに過大な負荷を生じる。

投稿者の個人情報が露出するのは（特に大規模クラスでは）好ましくない。男女間のトラブルを含めて多く問題が起こりがちな年代層の接近した集団に、行動履歴や個人情報を露出するのはまずい。ストーカーなどの事案を誘導しているのに等しい。

少々の数なら個人情報を出したくない投稿者はメイルで教員に送り、教員が代理投稿すると言った方法があり得るが、利用が増えれば増えるほど利用者が苦しむような限界点を設計に最初から折り込むのは愚かだ。

ただし教員は成績評価、またはトラブル防止（暴力的な投稿者をコントロールするといった事）のために投稿者の特定ができなければならない。すなわち全体には匿名として見せ、教員には記名で見せる（またはそのように操作すれば個人特定ができる）ようにするべきである。

課題提出システムのクラス構成で紹介したように、クラスの実施形態は極めて多様である。どのようなクラスが現れても対応できるようにした。

課題提出システムの担当者の配置で問題となったような部分を解決すべく、アカウントをクラス担当者が自分で発行出来るようにした。

課題提出システムのデータの保存で示したように、成績評価資料は保存義務がある。そのために一括ダウンロード機能を用意した。掲示板の内容を静的 HTML 形式に固定してダウンロードできる。教員はこれを手元で閲覧したり、Web で公開することができる。

フレーム、個人攻撃、差別発言など、コミュニケーションの場で発生する問題は数多くある。これらの事態に対応するため、掲示板は簡単な操作で一時閉鎖できなければならない。

の六つの状態が考えられ、そのどれもが適用可能であることが望ましい ^[1] 。

特にトラブルに対応するための閉鎖状態は実利用されないとしても保険として有益であろう。授業運営に新しいシステムを導入する際にこうしたリスク管理のための仕組みは幾つか用意すべきと考える。

各記事に対する閲覧度数（どの記事がどの程度閲覧されたか）といった情報はある程度クラスの掲示板に対するアクセス頻度を測る上で有益であろう。しかしこれを追求しすぎると、個人の行動履歴が得られるような状態にまでなってしまう。

受講生が他の受講生の行動履歴を得られるのは匿名性で述べたように大学環境では問題となろう。しかし教員が受講生の行動履歴を得られることもまたリスキーである ^[2] 。

どこまで詳しい統計情報を提供するかは難しい選択となろう。

セッションキーは課題提出システムと共用とした。いわゆる single sign on 的な格好にしたかったためである。

課題提出システムは DBMS に PostgreSQL を利用したが、掲示板システムは MySQL である。理由は処理が低負荷・高速であるため。掲示板システムはレポート提出システムと異なり、負荷が圧倒的に高い。一人の利用者が継続的に画面遷移・リロードを行う。

また、データは read がほとんどで write の機会が極端に少ない。そのために read 処理が高速なものが良い。

既読情報、マークの情報については実装方法が幾らでもあり得る。ただし問題は負荷の低減（処理の高速化）である。基本的な考え方は以下のとおり。

このままだとビットパターンが爆発するので、ある一定数を決めてそれを越えると積極的に古い記録を切り捨てて、それ以前の記事は全て既読扱いとする。どれだけ切り落としたかを offset として別項目に記録する。

これで各利用者が掲示板に一回アクセスするたびに、ただ一度だけの履歴レコードの取得を実施するだけで既読・マークの情報が得られる。そのかわりビット位置計算などが加わるが、おそらくその程度の CPU 負荷よりも DB アクセスを節約すべきだろう。

実際の実装では可変長文字列は 255 バイトを越えると処理が重くなる事が実験で確かめられたため、それ以前の位置に限界長を定めた。およそ 1000 記事が最大履歴保持数であり、それ以上の記事が投稿された場合、最新から 1000 記事以前の記事は一律に既読と処理される。が、恐らく多くの読者にとってそれほど過去の記事についての記事単位での既読・未読にはほとんど意味がない。

残念なことにどこを間違えたのか理解出来るほどの利用例や経験量が出なかった。

設計時に考慮した細かな要点などというものは仕様書からも何からも落ちてしまって多くの場合埋もれてしまう。記憶から消えないうちに書き留めておく。

	2002	2003	2004	2005
利用教員数	9	49	51	38
提出学生数	813	6,758	6,744	3,505
適用クラス数	24	153	160	85
設定課題数	162	779	1,100	511
提出課題数	5,025	44,441	52,789	17,559

bbs_id	member_id	offset	bit pattern
#123	473088	0	00001111000011111

bbs_id	member_id	offset	bit pattern
#123	473088	7	1000011111