キミのミライ発見」担当rikei-jinzai(a)kawai-juku.ac.jp※(a)を@に変更してメールをお送りください。testing)試行用プロトタイプシステムの仕様策定と構築についてお話しします。評価手法を検討します。それをどのようにCBTに載せていくのか、ということを考え、全国規模で試験を実施するための大規模CBT構築への要求要件を整理していきます。短期目標である今年(2017年)7月の試行試験に向けてのシステムを作成しています。試行試験は、今年7月に大学1年生を対象に実施し、そこでシステムの機能性を確認します。※1)の有無について調べました。試験を実施している団体の方にレクチャーをしていただいたりしました。これと並行して、CBTとしてどういうことがしたいか、そのためにどのような機能を実装したらよいか、ということを考えているのが現状です。)や、評価項目の難易度・識別力を測定するための試験理論。能力値や難易度のパラメータを推定し、データがモデルにどれくらい適合しているかを確かめ、評価項目の適切さを吟味することができるため、試験を開発・洗練させ、試験項目のストックを保守し、複数の試験の難易度を同等と見なす(つまり、いつ受けても安定的に実力が図れるので、複数回受験したり異なる回の結果を正当に比べるたりする)ことができる。TOEIC、TOEFLはこの試験方式。(Wikipediaより改編)今年7月に大学生を対象として試行試験を実施しますが、この試行試験用のCBTシステムがどのように進んでいるかをお話しします。設問の形式は、いわゆるセンター試験などと同様に、大問、例えば第1問があって、そこに小さな問題が入ったり、中くらいの問題同士に一つのストーリーがあるように組み合わされている、といったイメージです。その中には、例えば単純な選択ではなく解答をいくつ選んでもよいものや、マークシート式のセンター試験よりもう少し自由度の高い設問ができる形態になっています。いうものに対応できるプロトタイプを作りました。大学1年生対象で、同時受験の規模は多くても100~200名程度と考えています。パソコンを使って、キーボードとマウスで解答する形です。解答のナビゲーションなど、CBTならではの工夫も加えたいと思っています。実際の問題画面の例がこちらです。大きな設問があって、回答を選んでいくタイプのものです。数値を直接入力するものもあります。WEBですので文の中に直接説明やリンク先を埋め込むというような運用もできます。問題はXMLで記述する予定ですが、Markdownなど他の形式からの変換はどうするかとか、エディターは何を使うかなど様々な議論がありますが、このあたりは今後検討していくことになります。区別を付け、問題文の途中に解答欄を挿入できるようにしています。図表については、今回は簡単にするためにイメージファイルを貼り付けるという方法で実装されています。解答方法は、今までのセンター試験にもあるような、いわゆる〇×式や多岐選択、穴埋めなどです。CBTの特性を活かして、同じ番号ならば一回入力したら次は使えない、という設定もできます。プログラムについては、単語や手順の短冊を並べ替えする形で対応しようと思います。論述については、今回の試行試験では短い文の自由記述について行い、長文の自由記述については、この先拡張していこうと思います。採点については、基本的に記号で答えるものについては自動で行いますが、順不同や組み合わせ、いくつ選んでよいかなどに柔軟に対応できる構造にします。単純な数字や単語単位の記述問題ならば、パターンマッチでゆらぎを吸収する形で、これも自動採点できると思います。これは情報入試模試の時と同様に、同一問題を一括した採点基準のもとに採点する予定です。ここまでが来年度の試行に向けてのお話です。ここからは、さらに次のステップの話になります。CBTを実施するのであれば、やはりIRT方式を検討する必要があります。IRTは、視力検査のようにどのレベルで安定的に正解を出したかでレベルを決める方式です。IRTが入試の方式として正しいかはまだわかりませんが、それも含めて検討していかないといけない。IRTを実施するのであれば、規模にもよりますが、小さい問題を多数作る必要があります。できれば、この方式は来年・再来年で試行試験を行いたいと考えています。インターフェイスに関しては、今のところキーボードとマウスを前提に考えています。これは来年度・再来年度で急に変更することはないとは思いますが、タブレットや手書き入力を使う可能性や、それらを使った場合の可能性ということについては、今後考えていかなければならないと思っています。出題のフレームワークについて。Worldというものがあります。これは二次元のテーブルがあって、そこに数値を入れる(=入力)とプログラム実行後の数値が出てきます(=出力)。この入力と出力を見て、どのような処理をしているかを考えさせるという問題です。これは、よく見ると1が3になり、98が100になる。2が4になり、3が5になる...ということで、これは2を加えているのだな、というようなことを考え、プログラムを作ります。入力例を与えて実行し、正しい出力ができるかを見ます。これは大学入試センターのDNCLという言語で書かれたものですが、ブロックエディターのようなものでもできます。模範解答のプログラムで実行したものと比較して、その結果でプログラムを修正する、という問題も作ることができます。他には、ゲームブック形式という、ストーリーがある設問を連続して出すという出題方法も可能です。実際に、医学系のCBTでは、「臨床の場面でこういう症例の人が来ました。最初の診断ではどうしますか」というのが1問目、「次に検査をしました、ではその検査は...」というのが2問目というようにストーリーでつないでいって、最後は手術まで進むように、1つのシチュエーションを4問程度の工程として、連続して解答していくような設問があります。いったストーリーに沿って考えていく問題もおもしろいと思います。ビジュアルプログラミングや状態遷移図を作らせて動かしてはどうか、という提案もあります。プログラムのデバッグや、ネットワークのトラブルシューティングのようなシチュエーションを設定して実際に解決する、ということも考えられますね。CBTですから、クリックストリームのようなアクセスログを取れるので、解答のプロセスで評価するということもあると思います。自動採点に関しては、今のところはまだ具体的には考えられていませんが、先ほど述べたように多肢選択については問題ありません。記述問題については、語句レベルはパターンマッチで対応可能ですが、採点補助をどうしていくか、ということを考えなければなりません。キーワードを抽出して、アンダーラインを引いたり、出現数をカウントしたり、重要語句に対して重みを付けてスコアを計算する、ということは可能です。私個人の考えでは、ある程度の具体的な採点の結果と、手動採点とを比べることはできますが、記述問題の採点の完全自動化は、入試で使うものとしては難しいところがあるのではないかと思います。アルゴリズムとプログラミングについては、自動採点は十分可能と思います。最後に出題に関しては、自動作題できるプログラムを作っていきたいところです。しないと、例えばIRTで使うような、似たレベルのアダプティブな問題をたくさん作ることに対応できません。計算問題などは比較的簡単に作ることができるとは思いますが、先ほどご紹介したようなフレームワークを使って、より幅広い出題ができたらと考えています。最後に情報の試験として、どの程度の範囲まで出題するのかという点について。萩谷先生がお話しになった参照基準の範囲から万遍なく出題しようとするとなると、まだいろいろな分野の問題の特性に対応できるように考えなければなりません。偏りなく出題するのか。それらを踏まえてシステムとしてどこまでできなければならないのか。今後はそういった辺りを検討していく必要があると思います。本サイトは、経済産業省のキャリア教育事業の一環で作成した「わくわくキャッチ!」の独自コーナーとして、河合塾が作成し、運営しています。編集トップへ戻る閉じる。