IT活用能力のアセスメントテスト開発

アセスメント体系の設計

当時、最初に与えられた仕事は「テストの評価体系の検討」でした。しかも、このテストのコンセプトは、実務内で発揮されるIT能力の評価であったため、業務プロセス×汎用的なITスキルという構造にならざるを得ませんでした。

まだ新人で、かろうじて業務経験と言えるのは「学生時代のアルバイト？」といった程度でしたので、経験から体系を推定することは不可能であったため、知識・情報量でカバーするしかありませんでした。書籍、新聞、ネットなど媒体を問わず、ある程度仕事の進め方やフレームについて言及している情報を集め、そこから構成要素を整理・選別し、評価項目の候補にしていきました。ITスキルについては、もともとその分野が得意だったこともあり、業務について調べていく中、その時々で必要なスキルや使われるシステムについて、追加で調べる程度で済んだのは幸いでした。

勿論、上司や外部の専門家との連携もあったため、ひとりですべて考えるというわけではなかったので、最終的な品質についてはそこまでプレッシャーを感じずに済みました。ただ、自分以外はほぼ立場もあり、他の仕事も忙しくされている面々だったので、基本的に手を動かして、情報整理、ドキュメント化するのは、ほぼ自分が実行部隊として動かざるを得ず、ひたすらに情報収集、項目抽出、要件整理、推定、検証を行っていました。

とにかく世の中にないものを探る仕事だったので、最終的には縦に業務シーンを十数項目、横にITスキルを同じく十項目前後並べたマトリックスを作成し、そのマスを埋めるということにも挑戦したことを覚えています。これは、あまりに効率が悪いということで、主要な要素を6割程度埋めたところで、中断し、それを素材によりシンプルな構造を再設計しました。ただ、ここで細かく洗い出したことにより、後々大きな枠組みで体系立てをしていく中で、それらが何を含むのかが想定できるようになったため、今では有益な作業であったと感じています。

その後、いくつかの試作を経て、おおよその方向性が見え始めたところで、国内外の職能指標や情報処理能力基準などと突き合わせ、検証とブラッシュアップを行うことになりました。今でこそ、そういった情報も手に入りやすくなっていますが、当時はまだe-Japan戦略やIT新改革戦略など、国内ではITインフラや基本的なスキル養成にフォーカスが当たっていた時代。海外の情報に至っては原典を当たるか、国内研究者の論文やリーチレターなど、情報の入手先が限定されており、大変苦労しました。この段階になると、自分の能力だけではどうにもならず、当時の上司にずいぶん助けていただきました。

その後、なんとか商用ベースの評価項目として、体系がまとまり、何度かのプロトタイプ制作とモニタリングを経て、商品化に至りました。

また、そこから派生して当該能力の学習体系や、上位となるビジネススキル体系の構築を行い、関連商品の開発やプロモーションなどにも従事することになります。

【参考フレームワーク】
　・ITスキル標準（IPA）
　・COBIT（ISACA ＆ITGI）
　・PMBOK（PMI）　など

問題の開発

前述の評価体系の開発と並行して行っていたのが、実際のテスト問題の開発です。

このテストは実務におけるIT能力を測るということで、問題構成も独特でした。よくあるITに関する知識やルールを直接的に問うものではなく、できるだけ実務に近いシチュエーションでの判断能力を問題にするという方針だったのです。そのため、問題制作においては測定したいIT能力の設定→それが発揮されうる業務シーンの推定、業務シーンの文章化→問題状況の埋め込み→選択肢の検討・・・と、単純に知識の有無を問う問題に比べて、非常に手間のかかる制作工程でした。

また、測りたい能力にフォーカスしすぎるとシチュエーションとして不自然になり、逆にシチュエーションのリアリティを追求すると何を問う問題なのか不明瞭になるという、バランスの難しい作業でもありました。さらには、業務上のIT活用は極論、個人によって千差万別な面があり、専門家をはじめとする他者のレビューによって、一般性、汎用性のなさを指摘されることも日常茶飯事でした。

ただ、これらの経験により、実際に体験していない業務や特定の状況での作業について想定する力は相当磨かれ、今の能力の基盤となっていると思います。当時は相当辛い側面もありましたが、結果的にとても有益なトレーニングになったと思います。

問題の出題構成にも紆余曲折があり、初期のプロトタイプでは〇×で基礎知識を問い、単問のシチュエーション問題があり、最後に特定のシチュエーションに基づく4～5問の連門があるという、1回の受験が途中休憩含め120分という、かなり重たい試験でした。ただ、これは一介のベンダー試験としては、受験者の負担が大きすぎるという点と、実際の顧客として想定する企業・大学での受験オペレーションとして、導入ハードルが高すぎるという面で、見直しがかかり、最終的に1時間程度で単問のシチュエーション問題のみで構成する仕様に着地しました。

そうして、試作と改善を繰り返し、1時間で50問程度のテストが完成し、市場にリリースしたのですが、課題として定期的な出題問題の更新が発生します。当然、試験として受験者の方々の能力を評価させていただくので、問題を更新しないと何度も受ける受験者が有利になります。それ以前に、問題更新されないということは試験としての品質の問題です。そのため、リリース後数年かけて、チームで約300問以上の問題を開発し、上司ともに、ほぼその全ての問題のチェックを行いました。

ただ、これにはやはり限界を感じざるを得ませんでした。試験1回あたりの問題を開発するのに、少なくとも半年は専念する必要があり、その間他の業務を受け入れるキャパシティが足りなくなります。そのため、試験としての作りを根本的にアップデートすることになります。

テストのアップデート

このテスト事業において、もっとも苦労したのはこの評価システムのアップデートでした。前述のように、試験問題の更新には多大なコストがかかっており、それらを中長期的に継続するのはコスト的にも体制的にも限界が見えていました。とはいえ、お客様に同じ問題を提供し続けるのはテストとして許されないことです。そこで、打開策として検討の俎上に上がってきたのが、「最適化テスト」という概念でした。最適化テストとは、端的に言うと、受験者の能力に合わせて、最適な問題を出題することによって、能力測定の効率化を図ろうというものです。すなわち、受験者によって出題される問題が最適化＝個別化されるため、1シーズン毎に問題群を新規開発するコストを圧縮できるのではないかと考えたのです。

ただ、実装には課題がありました。そもそも最適化テストに関するノウハウが一切ない状況からのスタートだったので、どうすれば実装できるか？そこからのスタートだったのです。まずはそこからの調査でした。調査を進めるうちに、最適化テストの実現方法として、いくつかの手段がある中、項目応答理論（IRT）を用いたテストが妥当だろうというところを見出しました。ただ、この理論は従来の加点ないし減点方式のテストとは異なる評価視点の持ち方をしていました。例えるなら、視力測定での「これは見えますか？」という項目指示を、問題のパラメータによって推定するという仕様でした。

このころ、スタッフの中に数学や統計に長けたものがおらず、唯一ある程度統計の素養があり、また発案者でもあったため、自分がこのアップデートのプロジェクトを担当することになりました。全く知識のないところからのスタートであったため、専門書や論文、Web上の断片的な解説を踏まえて何とか理解し、このテストへの応用を検討しました。

実際、テスト時間と出題問題数の関係や、診断項目数の課題もあり、課題は多かったですが、いくつかの工夫を盛り込むことで、なんとか実用レベルにまで構成し、基本的な評価アルゴリズムを開発しました。また、従来の診断結果と互換性を保つための調整アルゴリズムの開発も行いました。

これらは実際に実装され、今日でもそれをベースにテストは運用されています。さらに、評価に用いるパラメータの自動更新アルゴリズムも開発しましたが、これは顧客に対する影響が読めないということで、実装は見送られました。

【参考理論】
　・項目応答理論（IRT）
　・古典的テスト理論
　・ネットワーク型テスト理論　など