arithmetic-timeattack

算数タイムアタック

小学校の算数で、既習事項の習熟を測って伸ばすための Web アプリ群。 Google Workspace for Education と Chromebook での運用を前提にしている。

1回1分。制限時間内に何問正解できるかを競い、 教師側には「どの児童が、どの型で、どれだけ時間がかかっているか」が残る。

なぜ所要時間で測るのか

九九も単位換算も既習事項なので、正答率は早期に天井に張り付き、児童間の差が消える。 差が出るのは想起にかかる時間。だから主指標を平均想起時間(ms)にしてある。

「間違える」のではなく「数えて出すから遅い」子を見つけるのが目的で、 正答率だけを見ていると、この層が見えない。

測るのは「出題から最初のキーを押すまで」で、送信までの時間ではない。 送信までには打鍵と欄移動が乗るので、3kg=□g（4桁）と 5000g=□kg（1桁）を 並べると、桁数の差がそのまま所要時間の差として現れる。 主指標から打鍵を外さないと、型どうしを比べた瞬間に結論が桁数で決まる。

平均と並んで「ゆらぎ」（標準偏差÷平均）を出す。 1.2秒で想起できる時と4.0秒かけて数える時が半々の子は、平均2.6秒で基準内に見える。 一定して2.6秒かかる子と平均が同じだからで、両者は必要な手当てが違う （前者は想起の練習、後者は手続きの短縮）。平均だけでは区別できない。

集計は既定で直近30日ぶん（window_days）。全期間平均にすると、 年間数百試行に対して直近の変化が1%程度に薄まり、伸びも落ちも見えなくなる。

いま動いているもの

アプリ	内容	対象
apps/hub	各アプリへの入口。学年で出し分ける。教師の一部だけが使う単元横断分析（?page=analysis）	全学年
apps/grade3/kuku	九九・わり算（9×9 / 9×16）	3年
apps/grade3/length	km と m の換算・加減計算、まきじゃくの読み取り	3年
apps/grade3/weight	g と kg の換算・加減計算、はかりの読み取り	3年
apps/grade3/divmod	あまりのあるわり算（九九の逆→九九さがし→引き算→ひとつなぎ→誤答判別→わり算）	3年
apps/grade3/bignum	大きな数（万・億・兆、位取り、いくつ分、10倍・100倍と逆算）	3年
apps/grade3/decimal	小数（0.1・0.01のいくつ分、位取り、10倍・100倍と逆算）	3年
apps/grade3/circle	円と球（中心・半径・直径の見分け、半径⇄直径、球の切り口、箱に並んだボール）	3年
apps/grade3/bai	何倍でしょう（もとにする大きさ、テープ図・関係図、式の選択、第1〜第3用法、倍の倍）	3年
apps/grade5/volume	体積（積み木、公式と逆算、m³・cm³・L・mL、複合図形、容積）	5年

構成

common/
  Core.gs        共通エンジン。認証・出題配信・再採点・記録・ランキング・分析
  index.html     共通の児童画面（レイアウト・キー配置・タイマー・送信）
  teacher.html   共通の教師画面（設定・クラスごとの公開モード・集計）
apps/
  grade3/          3年の単元（学年ごとに grade<学年>/ を切る。Unit.gs の grade と一致させる）
    kuku/Unit.gs     九九の出題定義
    length/Unit.gs   長さの出題定義
    weight/Unit.gs   おもさの出題定義
    divmod/Unit.gs   あまりのあるわり算の出題定義
    bignum/Unit.gs   大きな数の出題定義（詳細: apps/grade3/bignum/README.md）
    decimal/Unit.gs  小数の出題定義
    circle/Unit.gs   円と球の出題定義（図は単元が SVG で描く。詳細: apps/grade3/circle/README.md）
    bai/Unit.gs      何倍でしょうの出題定義（詳細: apps/grade3/bai/README.md）
  grade5/
    volume/Unit.gs   体積の出題定義（詳細: apps/grade5/volume/README.md）
  hub/           ハブ（Code.gs / links.html / teacher.html / Analysis.gs / analysis.html / Archive.gs）
docs/
  ARCHITECTURE.md  設計の考え方
  SETUP.md         設置手順
  ADD_UNIT.md      新しい単元の作り方
  ANALYSIS_REQUIREMENTS.md  横断分析の要件定義（未実装）
tools/
  preview/       スプレッドシート無しで Unit.gs をブラウザ確認する開発ツール（tools/preview/README.md）

単元を足すときに書くのは Unit.gs 1枚だけ。 Core は単元を知らない。逆向きの依存を作らないことで、単元が増えても Core が肥大しない。

詳細は docs/ARCHITECTURE.md。

設置

各アプリごとに Google スプレッドシートを1つ用意し、 拡張機能 > Apps Script に該当ファイルを貼ってデプロイする。

手順は docs/SETUP.md。 シートもトリガーも初回アクセス時に自動で用意されるので、 実行するのは承認のための setup 1回だけ。

clasp を使う場合は .clasp.json を各 apps/grade<学年>/* に置き、 common/ のファイルを同じプロジェクトに含める。

設計の要点

• セッション中の通信はゼロ。 開始時に問題列をまとめて受け取り、判定も採点もローカル。 GAS の往復は300〜800msあり、1問ごとに叩くと体感が壊れる
• 点数を送らせない。 解答だけ送り、サーバーがシードから問題を再生成して再採点する
• <input> を使わない。 keydown を直接拾う。IME・オートコンプリート・ フォーカス喪失の3事故が構造的に消える
• 1試行1行。 問題単位で全部残すと1年で破綻するので、 誤答と閾値超えの遅答だけを1セルに圧縮する
• 記録は制限時間ごとに別枠。 60秒の24問と30秒の24問は別物
• 記録されるのは名簿の児童だけ。 名簿に email と氏名がある児童だけが 記録・分析の対象。名簿にない児童も「おためし」として全モードを使えるが、 シートには何も書かれない

教室での運用

• 算数の帯活動として日に数回。当日ランキングの上位3名だけ、自分の画面にメダルが出る
• 他人の順位は見えない。同点は先着優先
• weak_class が一斉指導の的、weak_child が個別支援の対象
• weak_child は児童に見せない前提。 「あなたは7の段が遅い」と名指すと、 遅さを隠す行動（当てずっぽう連打・欠席）が出る
• 練習の「むせいげん」では問題型を1つ選んで続けられる。 弱い型に当たる回数がそのぶん増える（4型のモードなら25%→100%）。 どの型をやるかは児童が選ぶ。 アプリは誰が何を苦手かを画面に出さない。 診断を伝えるのは、教師が個別に声をかける場面のほうで、画面ではない

貢献するとき

Core を変える場合、単元固有の知識を Core に入れないこと。 「この単元のときだけ」という分岐が Core に現れたら、それは Unit に置くべきもの。

出題を追加する場合、自動判定のために答えの桁数を揃える責任は Unit 側にある。 確定に使う桁数は UNIT.digitCap で宣言する。宣言せず実際の答えの桁数で確定させると、 桁数がヒントになるうえ、打鍵数の差が主指標の所要msに混入する。 docs/ARCHITECTURE.md の「自動判定と情報漏れ」を読むこと。

ライセンス

MIT

This site is open source. Improve this page.