Integrated Validation Framework for Educational Module Development (IVF-EMD): A Systematic Evidence Synthesis of Validation Practices and Methodological Gaps

教育モジュールとは、教師や教育機関が学生を特定の主題へと導くために使用する、学習教材の構造化されたパッケージのことです。新しい言語を学ぶためのデジタルアプリであれ、地域の歴史を理解するための印刷されたガイドであれ、あるいは理科の授業のための一連のアクティビティであれ、これらのツールは特定の教育的課題を解決するために設計されています。モジュールが広く普及する前に、開発者はそれが機能することを証明しなければなりません。「バリデーション（妥当性確認）」として知られるこのプロセスには、コンテンツが正確であること、利用者にとって意味が通じること、そして実際に学生の学習に役立つことを確認することが含まれます。数十年にわたり、研究者たちは、これらのツールを構築するためにADDIEモデルのような確立された設計図（ブループリント）に依拠してきました。これらの設計図は、製品を構築すべき順序を開発者に示します。まずニーズを分析し、次に解決策を設計し、それを構築し、最後にテストするという手順です。しかし、製品を構築するための計画と、その製品が良いものであるという証明との間に、溝が生じています。設計図はモジュールの作り方を教えてくれますが、必ずしもすべての証明のステップが連結していることを保証するわけではなく、開発者が断片的な証拠しか持たない状況を生み出しています。

マレーシア大学の研究チームは、この証明が現在どのように集められているのかを正確に理解するために着手しました。彼らは、多くの異なる研究を注意深く収集・分析して全体像を見出す手法である「系統的レビュー」を実施しました。彼らは、教育モジュールの作成とテストについて記述した51の個別の研究を調査しました。彼らの目的は、これらのツールをテストするための新しい方法を考案することではなく、既存の方法がどのように使われており、どこにギャップがあるのかを見極めることでした。彼らは、研究者が通常収集する9つの特定の種類の証拠を探しました。それは、モジュールが必要かどうかを確認するニーズ分析から始まり、専門家の意見、コンテンツの正確性の確認、使いやすさの確認、小規模な試行テストの実施、測定の一貫性の確認、使いやすさの検証、実際の教室での動作確認、そして最後に、それが実際に学習成果を向上させるかどうかの測定へと続きます。

研究者たちは、この分野が善意に満ちている一方で、接続性の欠如に苦しんでいることを発見しました。彼らがレビューした研究のほぼすべて、すなわち98パーセントが、モジュールの必要性の特定から始めていました。また、大多数の約78パーセントが、設計をレビューするために専門家を招き入れ、72パーセントがコンテンツの正確性を確認していました。これらの初期段階は非常に一般的でした。しかし、プロセスが進むにつれて、証拠はバラバラになっていきました。モジュールが学生にとって使いやすいかどうかを確認した研究や、小規模な試行テストを実施したり測定の一貫性を確認したりした研究は、さらに少なくなりました。最も顕著な減少が見られたのは、研究者がモジュールが実際の教室で機能し、実際に学習を向上させることを証明しようとした時でした。多くの研究がこれらの最終ステップを行ったと主張していましたが、それらは多くの場合、それ以前のチェックを完了させることなく行われていました。研究者が、これら9つのステップすべてを連結した形で行った研究を探したところ、わずか4件しか見つかりませんでした。これは、初期のアイデアから最終的な結果に至るまで、完全な証拠の連鎖を提供している研究が8パーセント未満であることを意味しています。

特定された核心的な問題は、研究者がモジュールのテストに失敗していることではなく、テストを断片的に行っていることです。ある開発者は完璧な専門家レビューと明確なコンテンツチェックを持っているかもしれませんが、その後、学生が実際にそのツールを使えるかどうかのステップを飛ばしてしまうかもしれません。また別の開発者は、コンテンツが正確であるか、あるいはツールが使いやすいかを確認することなく、いきなり教室でモジュールが機能するかどうかを確認するかもしれません。これにより、完全な全体像が欠けているにもかかわらず、単一の証拠に基づいてモジュールが「バリデーション済み」と宣言される状況が生じます。研究者たちは、バリデーションとは単にチェックボックスに印をつけていくようなチェックリストではなく、各証拠が特定の主張を裏付ける「ケース（事例）を構築するプロセス」として捉えられるべきだと主張しています。もし開発者が、自身のモジュールは教室で使用できると主張するならば、使いやすさの証拠が必要です。もし学習を向上させると主張するならば、有効性の証拠が必要です。現在の慣行はしばしばこれらの繋がりをスキップしており、その結果、「バリデーション済み」のモジュールが実際に何を意味するのかを正確に知ることを困難にしています。

これを解決するために、研究者たちは、これらのチェックを整理するための新しい方法、「教育モジュール開発のための統合バリデーション・フレームワーク」を提案しました。このフレームワークは、既存のモジュール構築用設計図に取って代わるものではありません。代わりに、それは設計図と並んで存在し、証拠のための地図として機能します。このフレームワークは、9つの種類のチェックを4つの連結されたドメイン（領域）にグループ化しています。第一は「基盤バリデーション（Foundation Validation）」であり、製品に真のニーズがあることを保証します。第二は「設計バリデーション（Design Validation）」であり、専門家のレビューとコンテンツのチェックがそのアイデアを支持していることを確認します。第三は「製品バリデーション（Product Validation）」であり、完成したツールが使用可能で、一貫性があり、試行の準備ができているかに焦点を当てます。最後のドメインは「フィールドバリデーション（Field Validation）」であり、ツールが実際の教室でどのように機能し、望ましい学習成果を達成するかを検証します。

この新しい構造は、これらのドメインが相互に連結しており、後の段階からの証拠が初期の段階にフィードバックされることを強調しています。例えば、モジュールが実際の教室で失敗した場合、それは設計に欠陥があったか、あるいはコンテンツが不明確であったことを意味する可能性があり、開発者にそれ以前のステップを再確認することを要求します。このフレームワークは、開発者が提示する主張の強さに応じて、必要な証拠の量も変わるべきであることを示唆しています。単純なプロトタイプであれば、それが良いアイデアであり、見た目が適切であることを証明するだけでよいかもしれませんが、全国的な使用を目的としたツールであれば、実際の教室で機能するという証明が必要です。このように証拠を整理することで、このフレームワークは、研究者や開発者が自身のモジュールができること、およびできないことについて、より誠実かつ精密になれるよう支援します。研究は、教育モジュールをテストするためのツールは存在するものの、この分野にはそれらを連結するためのより優れたシステムが必要であり、それによって最終製品が完全で一貫した証拠の物語によって支えられるようになる、と結論付けています。