私からは、情報科の学力評価のためのCBT(computer based testing)試行用プロトタイプシステムの仕様策定と構築についてお話しします。

今回の大学入学者選抜改革推進事業では、これまでの入試で主に問われていた知識・技能に加えて、思考力・判断力・表現力の評価手法を検討します。そして、それをどのようにCBTに載せていくのか、ということを考え、全国規模で試験を実施するための大規模CBT構築への要求要件を整理していきます。

まずは短期目標である今年(2017年)7月の試行試験に向けてのシステムを作成しています。試行試験は、今年7月に大学1年生を対象に実施し、そこでシステムの機能性を確認します。

私たちは、まず既存のCBTについて、出題形式や解答形式、評価方法、採点方式などを調査しました。特に評価方法では、IRT(Item Response Theory ※1)の有無について調べました。また、現在CBTでMOS(マイクロソフト　オフィス　スペシャリスト)や統計検定、簿記検定など試験を実施している団体の方にレクチャーをしていただいたりしました。これと並行して、CBTとしてどういうことがしたいか、そのためにどのような機能を実装したらよいか、ということを考えているのが現状です。

今年7月に大学生を対象として試行試験を実施しますが、この試行試験用のCBTシステムがどのように進んでいるかをお話しします。

まずは、私たちが情報入試研究会(現・情報処理学会情報入試委員会)で作成・実施してきた情報入試全国模試の問題が実施可能であるシステムであることを最低条件として、ここからスタートしました。

情報入試全国模試の設問の形式は、いわゆるセンター試験などと同様に、大問、例えば第1問があって、そこに小さな問題が入ったり、中くらいの問題同士に一つのストーリーがあるように組み合わされている、といったイメージです。

その中には、例えば単純な選択ではなく解答をいくつ選んでもよいものや、マークシート式のセンター試験よりもう少し自由度の高い設問ができる形態になっています。まずそういうものに対応できるプロトタイプを作りました。

7月に実施する試行試験では、受験者は 大学1年生対象で、同時受験の規模は多くても100～200名程度と考えています。パソコンを使って、キーボードとマウスで解答する形です。解答のナビゲーションなど、CBTならではの工夫も加えたいと思っています。

実際の問題画面の例がこちらです。大きな設問があって、回答を選んでいくタイプのものです。数値を直接入力するものもあります。また、WEBですので文の中に直接説明やリンク先を埋め込むというような運用もできます。

問題はXMLで記述する予定ですが、Markdownなど他の形式からの変換はどうするかとか、エディターは何を使うかなど様々な議論がありますが、このあたりは今後検討していくことになります。

問題文は、先ほどお見せしたように、私たちがこれまで作ってきた問題のように、大問・中問・小問の区別を付け、問題文の途中に解答欄を挿入できるようにしています。図表については、今回は簡単にするためにイメージファイルを貼り付けるという方法で実装されています。

解答方法は、今までのセンター試験にもあるような、いわゆる〇×式や多岐選択、穴埋めなどです。CBTの特性を活かして、同じ番号ならば一回入力したら次は使えない、という設定もできます。プログラムについては、単語や手順の短冊を並べ替えする形で対応しようと思います。論述については、今回の試行試験では短い文の自由記述について行い、長文の自由記述については、この先拡張していこうと思います。

採点については、基本的に記号で答えるものについては自動で行いますが、順不同や組み合わせ、いくつ選んでよいかなどに柔軟に対応できる構造にします。単純な数字や単語単位の記述問題ならば、パターンマッチでゆらぎを吸収する形で、これも自動採点できると思います。残りは手動採点です。これは情報入試模試の時と同様に、同一問題を一括した採点基準のもとに採点する予定です。ここまでが来年度の試行に向けてのお話です。

ここからは、さらに次のステップの話になります。

CBTを実施するのであれば、やはりIRT方式を検討する必要があります。IRTは、視力検査のようにどのレベルで安定的に正解を出したかでレベルを決める方式です。IRTが入試の方式として正しいかはまだわかりませんが、それも含めて検討していかないといけない。また、IRTを実施するのであれば、規模にもよりますが、小さい問題を多数作る必要があります。できれば、この方式は来年・再来年で試行試験を行いたいと考えています。

これは大学入試センターのDNCLという言語で書かれたものですが、ブロックエディターのようなものでもできます。また、模範解答のプログラムで実行したものと比較して、その結果でプログラムを修正する、という問題も作ることができます。

他には、ゲームブック形式という、ストーリーがある設問を連続して出すという出題方法も可能です。実際に、医学系のCBTでは、「臨床の場面でこういう症例の人が来ました。最初の診断ではどうしますか」というのが1問目、「次に検査をしました、ではその検査は…」というのが2問目というようにストーリーでつないでいって、最後は手術まで進むように、1つのシチュエーションを4問程度の工程として、連続して解答していくような設問があります。こういったストーリーに沿って考えていく問題もおもしろいと思います。

自動採点に関しては、今のところはまだ具体的には考えられていませんが、先ほど述べたように多肢選択については問題ありません。記述問題については、語句レベルはパターンマッチで対応可能ですが、採点補助をどうしていくか、ということを考えなければなりません。キーワードを抽出して、アンダーラインを引いたり、出現数をカウントしたり、重要語句に対して重みを付けてスコアを計算する、ということは可能です。

私個人の考えでは、ある程度の具体的な採点の結果と、手動採点とを比べることはできますが、記述問題の採点の完全自動化は、入試で使うものとしては難しいところがあるのではないかと思います。アルゴリズムとプログラミングについては、自動採点は十分可能と思います。

最後に出題に関しては、自動作題できるプログラムを作っていきたいところです。そうしないと、例えばIRTで使うような、似たレベルのアダプティブな問題をたくさん作ることに対応できません。計算問題などは比較的簡単に作ることができるとは思いますが、先ほどご紹介したようなフレームワークを使って、より幅広い出題ができたらと考えています。