使用状況報告

[たかはし]

たかはし＠中学校 です。

学校評価についての保護者アンケート（約３００部）と生徒アンケート（約３００部）
および教科の授業アンケート（全校、全教科で約３５００枚）での使用感その他を紹介します。

保護者アンケートは鑑文とともに各家庭に封筒（Ａ４が折らずに入る大きさ ＝角２）に入れて配布。
封筒は昨年のものを再利用しました。３～４年は使えそうです。再利用することを印刷してあります。
回答は無記名で回収率は約８割。
表がマークシート面、裏が自由記述です。
回収後、自由記述があるものと無いものに分け、あるものからナンバリングを打ちました。
スキャンは表面だけとし、自由記述は実物を見ながら打ち込みました。
スキャン速度は約１秒／枚です。東芝の複合機を使用しています。
　＃　昨年度、マークが裏にもあったので両面スキャンをしたら、結構時間がかかったのです。
自由記述があったのは９０枚強。一人でテキスト起こしをして５時間ぐらい。分担すれば大したことない量です。
調査票（.sqs）は表側だけとし、MarkReaderでの処理も当然表面のみです。
処理速度は約０．５秒／枚でした。（MobileAthlonXP １．０GHｚ）

.xls に書き出して読みとりミスをチェックし、読みとり画像を修正して再度MarkReaderで処理。
ここでナンバリングが役立ちます。
.xls上で集計して（countif 関数を使用）、別のソフトでグラフ作成し、１枚のＡ４に全項目のグラフが入るようにしています。

１学年約１００人の教科アンケートの処理にかかった時間は
　原稿チェック・・・向きをそろえ、薄いマークや消し残しの修正
　ナンバリング
　調査票スキャン
　スキャンデータの転送・・・複合機からＰＣへはＬＡＮで。
　データのリネーム・・・複合機でのファイル名生成が「～1、～2」になるので「～001、～002」のように変更
　MarkReaderでの読み取り
　.xlsの確認
　読み取り画像の修正
　MarkReaderでの再処理
　.xlsの確認・集計
　別ソフトでのグラフ作成
までで約１時間でした。読み取り画像の修正が一番手間のかかるところです。

また、調査票を印刷するのにリソグラフを使ったのですが
調査票の上下にある「黒四角」が薄いとMarkReaderでの処理に悪影響を及ぼすので
濃いめに印刷しようとすると、今度は用紙が印刷機の中で舞い上がり、エラーが多発します。
インクが多量について、用紙がドラムに貼りついてしまうようです。
調査票の下側（黒四角が正方形でない方＝面積が小さい方）を印刷時に前方にとすることで
このエラーが軽減されるようです。

以上、これから利用する方への参考になれば幸いです。

[久保裕也]

たかはしさん、

くぼです。

お返事遅くなりました、
情報ありがとうございます！

2008/11/30 19:21 たかはし <sqs-...@juy.dip.jp>:

>
> たかはし＠中学校 です。
>
> 学校評価についての保護者アンケート（約３００部）と生徒アンケート（約３００部）
> および教科の授業アンケート（全校、全教科で約３５００枚）での使用感その他を紹介します。

なかなか大規模ですね！

私の勤務している大学の学部でも、
200人x4学年x10コマx2ページx回答率約60%で、
1万枚弱の規模の授業評価アンケートを、年2回実施しています。
集計作業は、学生にアルバイトでやらせています。

来年度からは、同様に、
大学院や他学部での授業調査などでの導入を打診されており、
一気にこの10倍の規模の仕事量になりそうな予感。
学生アルバイトをそれだけ手配できるかどうかが不安なところです。

> 保護者アンケートは鑑文とともに各家庭に封筒（Ａ４が折らずに入る大きさ ＝角２）に入れて配布。
> 封筒は昨年のものを再利用しました。３～４年は使えそうです。再利用することを印刷してあります。
> 回答は無記名で回収率は約８割。
> 表がマークシート面、裏が自由記述です。
> 回収後、自由記述があるものと無いものに分け、あるものからナンバリングを打ちました。
> スキャンは表面だけとし、自由記述は実物を見ながら打ち込みました。
> スキャン速度は約１秒／枚です。東芝の複合機を使用しています。
> ＃　昨年度、マークが裏にもあったので両面スキャンをしたら、結構時間がかかったのです。
> 自由記述があったのは９０枚強。一人でテキスト起こしをして５時間ぐらい。分担すれば大したことない量です。

ごくろうさまです…

> 調査票（.sqs）は表側だけとし、MarkReaderでの処理も当然表面のみです。
> 処理速度は約０．５秒／枚でした。（MobileAthlonXP １．０GHｚ）

3600枚の処理ならば、30分弱といったところですね。

なお、現在表に出ているMarkReader2.0alphaでは、
グリッドでの分散並列処理の機能を殺してあるわけですが、
いろいろテストを済ませたので、また次回リリースでは
復活をさせようかなと思っています。

2台,3台…で処理をすれば、画像修正と再処理のサイクルも短くできますからね。

> .xls に書き出して読みとりミスをチェックし、読みとり画像を修正して再度MarkReaderで処理。
> ここでナンバリングが役立ちます。
> .xls上で集計して（countif 関数を使用）、別のソフトでグラフ作成し、１枚のＡ４に全項目のグラフが入るようにしています。

グラフ作成については、みなさん、いろいろノウハウをお持ちのようですね。

ちなみに、今年度末にリリースする予定の最新版では、
SQS2005のように、それぞれの設問の単純集計結果の静的ファイルとしての
書き出し機能を復活させています。
このときの書き出しHTMLは、テンプレートファイルを編集することで、
ユーザが自分で自由にカスタマイズ可能にしています。
また、円グラフ・棒グラフは白黒印刷に対応させるための、
網掛け式での表示や、Google Chart APIを利用したグラフ表示を
それぞれ実現していて、必要に応じて表示内容を選ぶことができます。

関連して、これから、
countif関数で集計をした「後」の形式の.xlsファイルを自動生成する
ということを考えていますが、どのような体裁がよいでしょうかね。

> １学年約１００人の教科アンケートの処理にかかった時間は
> 原稿チェック・・・向きをそろえ、薄いマークや消し残しの修正
> ナンバリング
> 調査票スキャン
> スキャンデータの転送・・・複合機からＰＣへはＬＡＮで。
> データのリネーム・・・複合機でのファイル名生成が「～1、～2」になるので「～001、～002」のように変更
> MarkReaderでの読み取り
> .xlsの確認
> 読み取り画像の修正
> MarkReaderでの再処理
> .xlsの確認・集計
> 別ソフトでのグラフ作成
> までで約１時間でした。

今年度末にリリース予定の最新版では、
待望の、マーク読み取りしきい値設定を、
スライダー式のGUIでできるようにしました。
(しきい値は、それぞれの処理対象フォルダ個別の値と、
新規処理対象フォルダについてのデフォルトの値の、
2種類を設定できます)

また、そうしたそのときどきでの設定での読み取り状況について、
「無回答エラー(黄色)」「多重回答エラー(オレンジ)」のそれぞれの総数を、
MarkReaderの画面内で、処理中にリアルタイムに表示するようにしました。

> 読み取り画像の修正が一番手間のかかるところです。

おっしゃるとおりです。
この部分、読み取り画像の修正用の外部の画像処理ソフトの起動用パスを
MarkReaderに登録して、画像修正のときにはボタン一発でソフト起動、
というようにしようかなと思っています。

あるいは、Javaで書かれた軽い動作のお絵描きアプリを組み込んで、
MarkReaderのアプリケーション内で、
画像の回転・平行移動・切り抜き・明るさコントラスト調整・白黒ペン修正
などの作業をできるようにする、というほうがいいのかな…。

> また、調査票を印刷するのにリソグラフを使ったのですが
> 調査票の上下にある「黒四角」が薄いとMarkReaderでの処理に悪影響を及ぼすので
> 濃いめに印刷しようとすると、今度は用紙が印刷機の中で舞い上がり、エラーが多発します。
> インクが多量について、用紙がドラムに貼りついてしまうようです。
> 調査票の下側（黒四角が正方形でない方＝面積が小さい方）を印刷時に前方にとすることで
> このエラーが軽減されるようです。

おっしゃるとおり、 調査票の上下にある「黒四角」が問題で、
私のほうでも、濃い目に印刷することと、用紙づまりでの印刷エラー多発の
トレードオフに悩まされていました。

MarkReader2.0シリーズでは、実は、調査票の上下の「黒四角」は、
以下のようにページ四隅の４つだけを記載する形でも、
問題なく読み取りをできるようにしています。

http://sqs-users.googlegroups.com/web/pi2008-autumn.pdf

そういうわけで、次回リリース以降では、調査票の上下の「黒四角」は、
ページ四隅の４つだけになります。

空いたスペースには、今後、2次元バーコードを記載して、
多種類の調査票を混在させた状況・上下裏表反転の状況であっても、
インテリジェントに仕分けしながら集計できるような機能を加えていく予定です。

> 以上、これから利用する方への参考になれば幸いです。

ありがとうございます、今後ともよろしくおねがいします。

くぼ

[たかはし]

くぼ さん、コメントありがとうございます。

たかはし＠中学校 です

> なかなか大規模ですね！
３学級×３学年（計 約３００人）なので 決して大きい方ではありませんよ。

> 集計作業は、学生にアルバイトでやらせています。
総勢 何人ぐらいでしょうか。小中学校ではたぶん１～数人の担当で全部やる
所が多いと思います。
SQS（または類似のシステム）がないと到底こなせないでしょう。

> 来年度からは、同様に、
> 大学院や他学部での授業調査などでの導入を打診されており、
できる所に 仕事は集まるものですね。

> 2台,3台…で処理をすれば、画像修正と再処理のサイクルも短くできますからね。
楽しみです。

> このときの書き出しHTMLは、テンプレートファイルを編集することで、
> ユーザが自分で自由にカスタマイズ可能にしています。
> また、円グラフ・棒グラフは白黒印刷に対応させるための、
> 網掛け式での表示や、Google Chart APIを利用したグラフ表示を
> それぞれ実現していて、必要に応じて表示内容を選ぶことができます。

こちらの機能も 楽しみにしています。

> countif関数で集計をした「後」の形式の.xlsファイルを自動生成する
> ということを考えていますが、どのような体裁がよいでしょうかね。

集計部分は上部がいいと思うのですが、
（データ数にかかわらず決まった位置になると その後の自動処理･･･各ユーザー
による･･･にも発展可能かも）
その他の詳しい点は・・・すぐには出てきません。

> 待望の、マーク読み取りしきい値設定を、
> スライダー式のGUIでできるようにしました。
> (しきい値は、それぞれの処理対象フォルダ個別の値と、
> 新規処理対象フォルダについてのデフォルトの値の、2種類を設定できます)

すごいですね！

> また、そうしたそのときどきでの設定での読み取り状況について、
> 「無回答エラー(黄色)」「多重回答エラー(オレンジ)」のそれぞれの総数を、
> MarkReaderの画面内で、処理中にリアルタイムに表示するようにしました。

これもうれしいです。

> この部分、読み取り画像の修正用の外部の画像処理ソフトの起動用パスを
> MarkReaderに登録して、画像修正のときにはボタン一発でソフト起動、

> あるいは、Javaで書かれた軽い動作のお絵描きアプリを組み込んで、
> MarkReaderのアプリケーション内で、
> 画像の回転・平行移動・切り抜き・明るさコントラスト調整・白黒ペン修正
> などの作業をできるようにする、というほうがいいのかな…。

今は、フォルダ内の画像を mspaint.exe で編集しているのですが、はっきり
言って 使いづらいです。
画像の縮小表示ができず、スキャン時の解像度を上げると 修正作業にストレ
スを感じます。（今は複合機初期値の200dpiです）
また、修正用のペンの初期設定が小さく、起動ずるたびに変更するのも面倒で
す。
各ユーザーが様々なソフトを使用した時の固有のトラブルが出るよりは、「組
み込み」の方が問題が少ないかも。

> MarkReader2.0シリーズでは、実は、調査票の上下の「黒四角」は、
> 以下のようにページ四隅の４つだけを記載する形でも、
> 問題なく読み取りをできるようにしています。

なるほど！

> 空いたスペースには、今後、2次元バーコードを記載して、
> 多種類の調査票を混在させた状況・上下裏表反転の状況であっても、
> インテリジェントに仕分けしながら集計できるような機能を加えていく予定です。

これも楽しみな仕様ですね。
でも、小・中学校では（高校も？）二次元バーコードに落書きされそうですね。
落書きされても、こちらも気づかない・・・・
（今でも 黒四角が書き加えられていたりするんです）

たかはし

[久保裕也]

たかはしさん、

くぼです。

たかはし さんは書きました:

> くぼ さん、コメントありがとうございます。
>
> たかはし＠中学校 です
>
>> なかなか大規模ですね！
> ３学級×３学年（計 約３００人）なので 決して大きい方ではありませんよ。

全学年・全クラス・全科目での実施、というのは、
なかなか大変なことだと思っています…。

>> 集計作業は、学生にアルバイトでやらせています。
> 総勢 何人ぐらいでしょうか。小中学校ではたぶん１～数人の担当で全部やる
> 所が多いと思います。

SQSでの合計1万ページくらいの調査票の集計では、
1～2名が、1日6時間作業をして、2～3日、
といったくらいの量の仕事として、こなしています。

なお、印刷後・配布前に、あらかじめ、
調査票の左上を斜めに切り落とすという工程を加えています。
また、回収用の封筒には、
調査票を袋に入れるときの紙の向きを、
斜めに切り落とした部分を使って図示する形で印刷しておいています。
こうするだけで、回収後・スキャン前に、
調査票のページの裏表・上下まちがいを直す手間が激減し、
作業の所要時間を大幅に減らすことができます。

>> このときの書き出しHTMLは、テンプレートファイルを編集することで、
>> ユーザが自分で自由にカスタマイズ可能にしています。
>> また、円グラフ・棒グラフは白黒印刷に対応させるための、
>> 網掛け式での表示や、Google Chart APIを利用したグラフ表示を
>> それぞれ実現していて、必要に応じて表示内容を選ぶことができます。
> こちらの機能も 楽しみにしています。
>
>> countif関数で集計をした「後」の形式の.xlsファイルを自動生成する
>> ということを考えていますが、どのような体裁がよいでしょうかね。
> 集計部分は上部がいいと思うのですが、
> （データ数にかかわらず決まった位置になると その後の自動処理・・・各ユーザー
> による・・・にも発展可能かも）
> その他の詳しい点は・・・すぐには出てきません。

こちらで考えているのは、
現在出力している.xlsファイルの別のシートとして、
集計後の内容を加えてみてはどうか、ということです。

データ数によって、位置が変化してしまうのはしかたがないかな、と。
自動処理のためには、
.xlsとは別に、集計結果をXHTMLの表として出力しているので、
こちらを使ってもらうほうが、簡単かもしれません。

>> 待望の、マーク読み取りしきい値設定を、
>> スライダー式のGUIでできるようにしました。
>> (しきい値は、それぞれの処理対象フォルダ個別の値と、
>> 新規処理対象フォルダについてのデフォルトの値の、2種類を設定できます)
> すごいですね！

2.0シリーズでは、
マークの濃度(マーク欄全体ではなく、
マーク欄の中の局所的濃度の最大値)について、

・塗られていない: 1.0,
・しきい値: 0.94
・塗られている: 0.0

というように判断するのをデフォルトにしていますが、

この「しきい値」の値を変更できるようにした、ということです。

さらに今回、
同じ択一式設問の選択肢マークで、
しきい値よりも濃く塗られているマークが複数個ある場合で、
最も濃く塗られているマークと比べて一定以上薄いマークについては、
それらマークは「塗られていない」と判断する、という機能を加えています。

この、最も濃く塗られているマークとの濃度差の値についても、
同様に、スライダー式のGUIで変更できるようにしました。

>> また、そうしたそのときどきでの設定での読み取り状況について、
>> 「無回答エラー(黄色)」「多重回答エラー(オレンジ)」のそれぞれの総数を、
>> MarkReaderの画面内で、処理中にリアルタイムに表示するようにしました。
> これもうれしいです。

数を表示するだけではなくて…

マーク欄の部分を抽出した矩形画像を濃い順に並べて、
ヒストグラムのようにレイアウトした画面を作りたい。
さらに、この画面の上で、
「しきい値」のバーをマウスドラッグで上下させたり、

実際に認識された濃さを無視して
「塗られている・いない」をマニュアル指定したいマーク欄を
ドラッグアンドドロップで指定するような、

より感覚的に操作可能なしくみを実現したいところです。

>> この部分、読み取り画像の修正用の外部の画像処理ソフトの起動用パスを
>> MarkReaderに登録して、画像修正のときにはボタン一発でソフト起動、
>> あるいは、Javaで書かれた軽い動作のお絵描きアプリを組み込んで、
>> MarkReaderのアプリケーション内で、
>> 画像の回転・平行移動・切り抜き・明るさコントラスト調整・白黒ペン修正
>> などの作業をできるようにする、というほうがいいのかな…。
> 今は、フォルダ内の画像を mspaint.exe で編集しているのですが、はっきり
> 言って 使いづらいです。
> 画像の縮小表示ができず、スキャン時の解像度を上げると 修正作業にストレ
> スを感じます。（今は複合機初期値の200dpiです）
> また、修正用のペンの初期設定が小さく、起動ずるたびに変更するのも面倒で
> す。
> 各ユーザーが様々なソフトを使用した時の固有のトラブルが出るよりは、「組
> み込み」の方が問題が少ないかも。

そうですね…「組み込み」の方針で、考えることにします。

>> MarkReader2.0シリーズでは、実は、調査票の上下の「黒四角」は、
>> 以下のようにページ四隅の４つだけを記載する形でも、
>> 問題なく読み取りをできるようにしています。
> なるほど！

トナー・インキの節約にもなりますしね。

>> 空いたスペースには、今後、2次元バーコードを記載して、
>> 多種類の調査票を混在させた状況・上下裏表反転の状況であっても、
>> インテリジェントに仕分けしながら集計できるような機能を加えていく予定です。
> これも楽しみな仕様ですね。
> でも、小・中学校では（高校も？）二次元バーコードに落書きされそうですね。
> 落書きされても、こちらも気づかない・・・・
> （今でも 黒四角が書き加えられていたりするんです）

2次元バーコードには、パリティビットをつけておいて、
印刷やスキャン時でのノイズや、落書きなどによる汚れを
検出できるようにするつもりなので、大丈夫です。

くぼ

[たかはし]

たかはし＠中学校 です

> 全学年・全クラス・全科目での実施、というのは、
> なかなか大変なことだと思っています…。

授業評価をやるとなれば、全校体制になると思います。
社会を地理と歴史に分けている場合は同じクラスでも教員ごとに実施したり・・・。


> 現在出力している.xlsファイルの別のシートとして、
> 集計後の内容を加えてみてはどうか、ということです。

別シートなら扱いやすいですね。

> 同じ択一式設問の選択肢マークで、
> しきい値よりも濃く塗られているマークが複数個ある場合で、
> 最も濃く塗られているマークと比べて一定以上薄いマークについては、
> それらマークは「塗られていない」と判断する、という機能を加えています。
> この、最も濃く塗られているマークとの濃度差の値についても、
> 同様に、スライダー式のGUIで変更できるようにしました。

今は、回収後に１枚１枚確認して、塗り直したり消し直したりしているので
たぶん大幅な省力化につながるでしょう。

> マーク欄の部分を抽出した矩形画像を濃い順に並べて、
> ヒストグラムのようにレイアウトした画面を作りたい。
> さらに、この画面の上で、
> 「しきい値」のバーをマウスドラッグで上下させたり、
> 実際に認識された濃さを無視して
> 「塗られている・いない」をマニュアル指定したいマーク欄を
> ドラッグアンドドロップで指定するような、
> より感覚的に操作可能なしくみを実現したいところです。

いいですね！

> 2次元バーコードには、パリティビットをつけておいて、
> 印刷やスキャン時でのノイズや、落書きなどによる汚れを
> 検出できるようにするつもりなので、大丈夫です。

安心しました。

たかはし