教師の道具箱

振り返ると、N88-BASICで始めた成績処理プログラムは、MS-DOSの時代を経てWindows版へ。専用アプリやExcelを使い、共有フォルダで集計をするようになり、成績処理への負担はずいぶん改善されました。

現在はクラウドを使ったウェブ版が主流です。漏洩リスクの低減、排他制御・一貫性の確保、更新・保守の一元化など、ウェブ版のメリットはたくさんあります。

自治体レベルでの導入が進み、学校間での差異も縮小しました。転勤しても同じシステムを使うことができ、学校独自のシートの使い方を覚える必要がなくなりました。しかし、大規模な成績処理の市場は納入数としては小さく、割に合わないことから撤退している業者もあります。学校で動いている処理は案外多様で複雑です。裏を返せば、ムダな作業が多く残っているのに、工程を減らさずに情報化しようとします。情報化のメリットを生かそうとはしません。

自治体が大規模な成績処理を導入するにあたっては、既存の処理システムの流れに合うように仕様書を作成します。仕様書どおりに作られたシステムは、確かに仕様書が求めている計算はしてくれますが、とにかく使い勝手が悪い。機能は階層化されていますが、階層化の仕方が時系列ではなく、どこに何が隠れているのかさっぱりわかりません。統一感もないため、ストレスが溜まる一方です。分厚いマニュアルが必要になるわけですが、余計な作業が増えている気がします。学校単位で使い方マニュアルを作成するという事態にもなっています。

最近の傾向として、評定算出処理の回数は5回から3回、3回から2回と減っています。負担は減るわけですが、だれもが導入された成績処理システムのエキスパートではないので、成績処理シーズンになると頭がリセットされていて、操作に戸惑うのです。

成績処理は、過去の偏差値から求めるものから到達度で計算するものへと変わったので、計算自体は非常に単純です。なのに操作が複雑になってしまった大きな要因は、保護者対応ではないかと思います。保護者への説明が簡単になるように、質問がなくなるように、処理工程を複雑化します。

たとえば、観点が全部Aなのになぜ5にならないのかと一部の保護者が疑問を持てば、「AAAは5になる」という処理になります。そうでなくても、AAAが5にならない理由を記述するとか、AACなど離れた観点項目があれば理由を記述するとか、なぜうちの子は1なのかという問い合わせがあれば1の生徒全員に理由を記述するとかの作業が増えてしまいます。たったひとつの問い合わせがあれば、類似した生徒にはすべて理由を記述して提出となります。

それらは、成績処理システムの作り方次第で、わざわざ理由を記述しなくてもよいわけです。データを見ればわかることですし、それよりも今後どうしたら成績を改善できるかを提示するほうが重要です。データが多くを語ります。

教師側のコンピュータへの理解が問題になることはあります。欠席をした生徒にデータを入れなければ0点です。そこに適切な見込み点を入れるのか、0点のままが適切なのかを教師が判断すべきなのですが、計算はコンピュータが一瞬でやってしまうので、うっかり放置してしまう先生がいます。見込み点は本来、他の項目やテストの実績から「この生徒ならこうだろう」と推定できるはずですが、手入力では負担が大きく、見送られがちです。

ミスを防ぐための対策としては、エラー表示やビジュアル化が考えられます。ミスを探すための点検作業はありますが、目視で探すよりコンピュータが探したほうが圧倒的に速いです。求めるチェック項目は機械的なものです。だとすれば、教科担任の時点でエラーを表示し、修正を促せばよいだけです。なぜ目視での点検を重要視するのかといえば、点検をしたという既成事実を作るためです。

教科担任が提出した評定一覧と学級ごとに転記された一覧表が一致しているかどうかの点検があります。同じデータから出力されたものを目視で一致しているかを調べるなんてナンセンスですが、実際におこなわれていることです。紙の一覧を提出したあとに、変更する可能性があるなら、編集をロックしてしまえばいいだけです。

成績処理で重要なのは、算出された評定がその生徒に適切なものになっているかどうかです。さらに、今後の指導の指針になることが重要です。

Windows版の成績処理AYUMIでは、それらの多くの対策を提供する機能を実装しました。導入した学校や先生方からは好評だったのですが、自治体レベルでの校務支援の導入で、個別の成績処理システムは一掃されました。それは先に述べた理由によるもので、時代の流れです。

そこで、Windows版で培った機能をウェブ版として再現しようというのがこのプロジェクトです。校務支援システムのメリットと、成績処理システムとして有用な機能を併せ持つものを構築したいと考えました。

このシステムは、自治体や学校法人レベルで導入できるように設計しました。もちろん架空の自治体名を作成し、自分の学校だけで使うこともできます。自治体レベルですでに導入されている場合は、あくまでも学校レベルでは試用だけです。小さい自治体や学校法人なら、組織レベルで試用することもできます。

ただし、第一の目的はこのシステムを採用してもらうことではなく、校務支援システムを扱っている業者にパクってもらいたいのです。忙しい先生方に本来の業務ではないところに労力を使うのではなく、成績処理の真の目的は「評定を出すこと」自体ではなく、生徒の学習状況を可視化して、次の指導につなげること。「指導へのフィードバック」の機能が備わった成績処理システムとしてほしいのです。

以下は、成績処理 AYUMI ウェブ版のシステムをAIが評価し、実装した内容について解説したものです。

次世代の成績処理に求めるものは、次のとおりです。

1. 計算そのものは単純であること（到達度に基づく評定）。複雑さの多くは、保護者対応や既存フローの踏襲から生まれた工程です。
2. 使いやすさを優先すること。仕様どおり動くだけでは足りない。操作が直感的で、シーズンごとに思い出さなくても使えること。
3. ミスは機械が先に見つけること。未入力・見込み点・割合の誤りなどは、教科担任の段階でエラー表示やビジュアルで気づけること。欠席セルには、他項目の実績から見込み点を自動で提案できること。
4. データが説明し、指導に活きること。理由の手書きを増やすより、なぜその評定になったか・今後どう伸ばすかを画面で読み取れること。
5. ウェブの利点（安全・一貫性・保守の一元化）を備えつつ、Windows版AYUMIで評価された点検・分析の考え方を引き継ぐこと。

情報化は「今の作業を画面に移す」だけでは不十分です。工程を見直し、教師が評定の妥当性と指導の指針に集中できるところまで持っていく必要があります。このプロジェクトはそのための試行です。

上記の問題に対して、成績処理 AYUMI ウェブ版では次のような工夫を入れています。

操作の道筋を浅くする。 成績処理は「観点割合 → 満点・割合 → 評定算出 → 個人分析 → 印刷」と、タブで一本の流れにしています。深い階層のどこかに機能を隠すのではなく、いま何をしているかが画面上部でわかるようにしました。平常点・見込み点の入力と評定処理は入口を分け、シーズンに入っても「どこから始めればよいか」で迷いにくくしています。

ミスは教科担任の段階で機械が見つける。 未入力のままでは0点として計算されてしまう問題に対しては、空欄の強調や、学級全体の入力が進んだあとに残る未入力（組・人数・出席番号）のアラートを出します。欠席は「*」、未提出は「/」として明示し、見込み点を入れるのか・0点のままが妥当なのかを判断できる状態にします。定期テストの見込み点も、実得点と見た目で区別し、手でひとつずつ埋める必要がないよう自動見込み点を用意しました。

自動見込み点で、欠席・空欄を0点にしない。 平常点入力では「*」（欠席）のセルだけを、定期テストの見込み点入力では実得点も見込みもない空欄だけを対象に、ボタンひとつで見込み点を一括算出します。算出の考え方は、同じ学年の他の平常点項目や他回の定期テスト観点における、その生徒の到達度（得点率）とクラス平均との差(いわゆる偏差)を使います。たとえば平常点の小テストでいつも平均より高い生徒が、別の平常点項目で欠席していれば、その項目のクラス平均にその生徒の偏差を足した値を見込み点として提案します。同じ観点の別テスト回、同じ教科の他項目、学年全体のデータを順に参照します。年度始めなど、今年度の個人データがまだ足りないときは、前年度の到達度（同じ教科・観点の記録）を利用します。それでも資料がない(何も資料がない)ときは、無理に推測せず 「*0」（欠席のまま0点）とします。記号項目（A○〜E）にも対応し、見込み点は「*」付きで表示されるので、実得点と混同しません。自動で入った値はあくまで提案です。保存前に教師が目を通し、手で直せます。0点のまま放置して評定が不当に下がる事態を、手作業の負担を増やさずに防ぐのが狙いです。

割合は「満点のまま」ではなく、到達度のあとの重みで見る。 平常点の満点が低い項目を、集計割合にそのまま載せてしまう誤りを防ぐため、観点割合と項目・テストの満点割合を一覧で編集し、到達度に変換したあとの重みがどう効くかを円グラフなどで点検できるようにしました。学期の割合などを学校で統一したければ、学校側で設定したうえで教科担任が変更できないよう固定してしまえばよいのです。観点割合・集計割合を全校共通にし、教員側は閲覧のみにする設定がそのための仕組みです。各自が別々の割合で動くばらつきを、工程を増やすのではなく権限で止めます。

評定の妥当性を記号と絞り込みで点検する。 算出一覧では到達度・評定に加え、カットポイント付近のボーダー（＋／－）、比較元からの上下（▲△▽▼）、学年末の整合性（☆／★）を記号で示します。ボーダー・上下・整合性だけのフィルタや到達度順のソートで、「目視で全員を探す」作業をコンピュータに委ねます。学級ごとの評定分布も横に置き、クラス間の偏りに気づけるようにしました。

説明の主軸をデータに置く。 保護者対応のために工程や手書き理由を増やす代わりに、個人分析で「なぜその評定になったか」を見せます。到達度のバー、素点から到達度への内訳、定期と平常の比較、ボーダーや上下などの注目点を画面上の解説にまとめます。備考メモは必要なときだけ短く残し、3年間の評定の振り返りで指導の連続性にもつなげます。

学年全体の抜けと帳票もサーバ側で。 学年処理では教科×学級の入力状況を一覧し、完了と一部入力を区別します。評定一覧やテストの得点通知は PDF として出力し、手元のExcelやプリンタ依存を減らします。計算・権限・データはサーバに一元化し、共有フォルダ時代の二重起動やファイル壊れのリスクから離れます。

要するに、ウェブ版の利点（安全・一貫性・保守）を土台にしつつ、「計算は単純でも、点検と説明と指導に時間が取られる」部分を画面が引き受ける設計です。仕様どおり動くだけでなく、教師が評定の妥当性と今後の指針に集中できるところまで持っていくのが狙いです。