1. 検定のすゝめ
  2. 検定ノウハウ
  3. 試験運営のシステム化を考える
代表野口の資格・検定研究ラボ - 検定のすゝめ
検定ノウハウ

試験運営のシステム化を考える

Exam Management System

今回は、試験におけるシステム化を検討できる部分について考えていきましょう。全てのワークフローがシステム化されたCBTモデルは一旦おかせていただき、マークシート等で実施するPBTモデルについてシステム化すべきポイントをご紹介します。

申込に関して

まず、受験者の申込、受験料の回収といった申込に関するシステム化です。この部分で考えなくてはいけないことは、

  • (1)決済の仕組みとしてクレジットカードやコンビニ支払い等の支払方法を複数用意すること。
  • (2)個人情報、会場等の予約スケジュールを確定できること。
  • (3)PCだけでなく、現代ではスマホでの申込ができること。利便性と無人化によるコスト削減、データ処理化を図るべき要素です。
  • 上記に加えて(4)領収書や受験票、合否結果発表等もできるマイページ化がより良い仕組みと言えるでしょう。
  • (5)団体受験が多い検定試験であれば団体管理の仕組みも必要です。

当日運営準備として

  • (6)受験者の会場座席割当、受験番号の発番等のデータ処理、
  • (7)名簿や座席表等の帳票資材の印刷、
  • (8)資材の準備、送付状況や会場の手配等タスクの進捗状況を管理するワークフロー管理機能等

これらが挙げられます。ワークフロー管理は試験当日も資材確認や試験監督の到着管理、進捗確認等にも必要です。

試験後の処理として

  • (9)マークシートの採点処理、
  • (10)採点結果の分析処理(数的理論が必要。合格者判別や問題分析等を行う。)
  • (11)合格者データの作成(合格管理番号発番、合格証印刷用データ作成等)
  • (12)合格者データの管理
  • (13)ファイナンス処理・管理等

更には、合格者管理後に、更新試験制度や会員制度等が考えられ、それらを一元管理するデータベースのシステム構築が望まれることでしょう。受験者管理の中には、事務局への問い合わせ内容の履歴管理(コールセンター履歴管理)等の機能があると試験運営の効率化がより一層進みます。

細かい作業レベルにおいても例えば一斉メールを受験者に送信したいと思えば、メール一斉ソフトが必要になりますし、メルマガ会員を作りたいとなれば、会員登録・管理するシステムが必要となります。顔写真を便利にシステム化したいとなれば、顔写真をスキャンニングし、適正な形に切り取るトリミングシステムが必要となります。

このようなシステム化の要因は、挙げれば切りがなく、これら以外にも様々な箇所でシステム化が必要となります。そのため、重要なことはどれを「選択」し、「いつまでに」「どの優先順位で」システム化するのかを決めることが大変重要となります。

当社の開発方針

当社は創業以来9年に渡ってこのようなシステム化を行ってきているのですが、開発方針として
(A)スクラッチ開発をせずにパッケージを導入する。
(B)際限なく要件を実現せずにシンプルな作りを目指す。
という二点を重視しています。

(A)によりメイン機能は開発工数をかけなくても一通りの機能が揃います。またパッケージですので、例外処理に対しての機能も ある程度想定された作りになっています。
要件定義時にエンドユーザー側で要件に気付かなくても、想定される業務要件をカバーする機能が搭載されているため大変便利な上に効率的です。開発のベースとなるプログラムを低価格で導入できることが 最大のメリットです。

(B)は、シンプルな作りにすることで今後も継続して使えるプログラムを作る意識を持つことが重要です。駄目なプログラムとは例外パターンを作り過ぎて、いわゆるスパゲッティ・プログラム化してしまい、修正をすることが難しくなったプログラムを指します。

例えば条件によりA、Bの2つに分岐するプログラムを開発する場合、ある1パターンに対して作る場合は、開発も2ヶ所、テストも2ヶ所の規模ですが、 既に分岐が沢山作られてる例えば16パターンの分岐のヶ所に2パターンの分岐を追加する場合、16×2で開発も32ヶ所、テストも32ヶ所の規模を行う必要があります。

こうなってしまうと同要件の修正にも関わらず カスタマイズの開発費用は大きく異なります。 したがって、こうならないプログラムの開発方針が 重要となります。

開発方針の実現には、プログラムの書き方の技術も必要ですが、そもそも例外パターンを要件に盛り込み過ぎないという考え方が重要になります。

要件を検討するのに大事なことは、それらがシステム化された場合に、どれだけの効果があるのか?という費用対効果です。特に発生頻度が重要で、毎日発生し年間で1万件を超えるような処理を自動化することと、年に1回発生するかどうかどうか分からないが、ゼロではないので念のため作成しておこうというレベルのこととは優先度が大きく異なるのは明白です。コスト的にもプログラムをシンプル化する視点からも後者はシステム化しない方が良い要件となります。

このように要件を絞りプログラムを複雑化しないことで、将来の要件変更や追加要件の際に低コストで変更が可能な良質なプログラム状態を維持することが可能となります。まとめますと、以下が重要となります。

  • スクラッチ開発ではなく、パッケージ製品の導入を考えること。
  • 必要最低限にカスタマイズ項目を絞し、発生頻度と効率化で優先度を選択すること。
  • 導入後の保守を考え、将来の変更に対して柔軟に対応できるシンプルなプログラムを目指すこと。

是非、今後のシステム化の視点として、ご参考になれば幸いです。

© 2018 CBT-Solutions Inc - 無断転載・複製を禁ず