小テストは「作る」より「品質を揃える」が難しい｜A/B/C版と重複率を管理する考え方

小テストを作るだけなら、それほど難しくありません。

問題を何問か選び、

順番を並べ、

印刷すれば完成します。

しかし、

複数クラスで使う。

追試を作る。

A/B/C版を用意する。

同じ範囲で何度も実施する。

となると、問題は「作ること」ではなくなります。

難しくなるのは、

「品質を揃えること」

です。

■ 小テストで起こりやすい問題

複数の小テストを作っていると、次のようなことが起こります。

・同じ問題が重複している

・必要な問題数が足りない

・問題文や解答が空欄になっている

・難易度の構成が偏っている

・A版とB版がほとんど同じ

・以前使った問題ばかり選ばれる

・どの条件で作ったテストか分からなくなる

1回だけなら、人の目でも確認できます。

しかし、

クラス数

実施回数

問題数

バージョン数

が増えるほど、確認作業も増えていきます。

■ 「ランダムに選ぶ」だけでは品質は揃わない

問題庫からランダムに10問選べば、

毎回違う小テストは作れます。

ただし、

違えばよい

というわけではありません。

たとえば、

A版は基礎問題が8問、

B版は基礎問題が3問、

となれば、テストの難易度が揃いません。

ある単元だけに問題が偏ることもあります。

つまり、

ランダム生成

と、

品質管理

は別の問題です。

■ まず問題庫を整理する

小テストを安定して作るには、

最初に問題庫を整理します。

たとえば各問題に、

・問題ID

・単元

・難易度

・問題文

・解答

・復習対象かどうか

などの情報を持たせます。

こうしておくと、

「この単元から5問」

「難易度を指定して10問」

「復習対象だけから抽出」

といった条件で選びやすくなります。

■ 問題IDが重要な理由

問題文だけで管理すると、

少し表現が違う問題を

別問題として扱ってしまうことがあります。

そこで、

各問題に固有の問題IDを付けます。

問題IDで管理すれば、

「同じ問題が2回入っていないか」

を機械的に確認しやすくなります。

複数バージョンを比較するときも、

問題IDを基準にすると重複を確認しやすくなります。

■ 作成後に必要なのがQuality Gate

テストが生成されたら、

すぐ印刷するのではなく、

一度Quality Gateを通します。

最低限確認したいのは、

・問題IDの重複

・問題文の空欄

・解答の空欄

・候補問題数の不足

・難易度構成

などです。

ここで重要なのは、

「テストが作れた」

と、

「印刷して使える状態になった」

を分けることです。

生成できても、

品質確認が終わっていなければ、

まだ完成ではありません。

■ A/B/C版を作るときの問題

複数クラスや追試では、

A版

B版

C版

のように複数バージョンを作ることがあります。

ここで気になるのが、

「どれくらい問題が重複しているか」

です。

たとえばA版とB版が10問中9問同じなら、

順番だけ変えても実質的にはほぼ同じテストです。

一方、

重複をゼロにしようとしても、

候補問題数が少なければ不可能な場合があります。

■ 重複率だけ見ても判断できない

たとえば、

候補問題が12問しかないのに、

A版とB版でそれぞれ10問ずつ使うとします。

この条件では、

2つのテストを完全に別問題だけで作ることはできません。

つまり、

重複が発生したから品質が悪い

とは限りません。

重要なのは、

現在の候補問題数と指定問題数では、

理論上どこまで重複を減らせるのか

を考えることです。

■ 「理論最低重複率」という考え方

候補問題が十分に多ければ、

A版とB版の重複を小さくできます。

しかし、

候補問題数に対して

各テストで使う問題数が多くなるほど、

どうしても共通問題が必要になります。

そのため、

実際の重複率

だけではなく、

現在条件では避けられない

「理論上の最低重複」

と比較して考えると、

より公平に判断できます。

たとえば、

重複率30％

という数字だけを見ると高く感じるかもしれません。

しかし、その条件では理論上最低でも25％程度の重複が必要なのであれば、

30％は

「極端に悪い」

とは言い切れません。

逆に、

理論上かなり重複を減らせる条件なのに、

実際の重複率が高いのであれば、

組み合わせを見直す余地があります。

■ 大切なのは「固定基準だけで判定しない」こと

たとえば、

「重複率20％以下ならOK」

という固定基準だけを使うと、

候補問題数が少ない条件では達成不可能になる場合があります。

そこで、

候補問題数

指定問題数

実際の重複率

理論最低重複率

を合わせて見ます。

これによって、

現在の条件に対して、

その重複率が妥当なのか

を判断しやすくなります。

■ 難易度構成も揃える

A/B/C版を作るなら、

問題の重複だけではなく、

難易度構成

も確認したいところです。

たとえば、

A版

基礎 5問

標準 3問

応用 2問

B版

基礎 2問

標準 3問

応用 5問

では、

問題数は同じでも、

テストとしての難しさが変わります。

そのため、

単純な問題数だけではなく、

各バージョンの難易度構成

まで確認することが重要です。

■ 候補問題不足も事前に確認する

条件を細かく指定すると、

「そもそも候補問題が足りない」

ということがあります。

たとえば、

特定単元

＋

特定難易度

＋

10問

と指定したのに、

問題庫には対象問題が6問しかない。

この状態では、

希望するテストを作れません。

生成後に気づくより、

候補問題数の段階で不足を表示する

方が安全です。

■ 同じ条件を再現できることも重要

毎回完全に違うテストができれば良い、

とは限りません。

たとえば、

「先週使ったB版をもう一度確認したい」

「同じ条件で同じ問題順を再現したい」

という場合があります。

そのため、

条件だけでなく、

組み合わせ番号

のような再現用の情報を残しておくと便利です。

同じ条件と同じ組み合わせ番号を使うことで、

同じ問題順を再現できるようにしておけば、

あとから確認しやすくなります。

■ 実施履歴を残す

小テストは、

作って終わりではありません。

何月何日に、

どのクラスで、

どのVersionを使ったのか。

こうした履歴を残しておくと、

次回のテスト作成時に、

「最近使った問題ばかりになっていないか」

を確認しやすくなります。

問題庫

↓

生成

↓

Quality Gate

↓

Version管理

↓

実施履歴

までつなげることで、

小テスト作成が一回限りの作業ではなくなります。

■ 小テスト作成で確認したい流れ

実務では、次の順番にすると整理しやすくなります。

1. 問題庫を登録する

2. 単元・難易度・問題数などの条件を指定する

3. 小テストを生成する

4. 重複・空欄・候補不足を確認する

5. 難易度構成を確認する

6. A/B/C版を作る

7. バージョン間の重複率を確認する

8. 理論最低重複率と比較する

9. 実施履歴を残す

重要なのは、

「生成」

と、

「品質確認」

を分けることです。

■ ExcelでQuality Gateまで管理する

問題数が少なければ、

手作業でも確認できます。

しかし、

問題庫が大きくなり、

複数クラス・複数Versionを運用すると、

重複確認

空欄確認

候補数確認

難易度構成

Version比較

実施履歴

の管理が増えていきます。

そこで私は、

問題庫から条件を指定して小テストを作成し、

・問題ID重複チェック

・問題／解答の空欄チェック

・候補問題数確認

・難易度構成

・A/B/C Version Planner

・A-B／A-C重複率

・理論最低重複率

・実施履歴

まで一つのファイルで確認できるExcelツールとして整理しています。

Coconalaでは、

「小テスト作成Excel｜Quality Gate・A/B/C版・重複率評価」

として公開しています。

これは、

問題内容そのものの正しさを自動判定するツールではありません。

問題文や解答内容の正確性は、

利用者自身が最終確認する必要があります。

目的は、

「作る作業」

だけではなく、

「印刷前に確認すべき品質項目」

を整理し、

複数Versionの管理をしやすくすることです。

興味がある方は、

プロフィールの出品一覧から確認できます。

■ 最後に

小テストで難しいのは、

問題を選ぶこと

だけではありません。

本当に難しいのは、

毎回の品質を揃えることです。

問題が重複していないか。

空欄がないか。

候補数は足りているか。

難易度は偏っていないか。

A/B/C版の重複は現在条件に対して妥当か。

そして、

あとから同じ条件を再現できるか。

小テストを繰り返し運用するなら、

「作成」

ではなく、

「作成＋Quality Gate＋Version管理」

まで一つの流れとして考えてみてください。