野良ウサギのSCORM（xAPI / CMI5）

eラーニングの仕様の中心となるものは、相互運用性ですが、既存の仕様にはいくつかの問題が残っています。Tin Can API は、現在の仕様で残る多くの相互運用性の問題解決を図ります。

目次を表示する

従来のeラーニングの仕様では、目次を表示すべきかは、必ずしも明確ではありませんでした。そのLMSは、目次を表示するのか？、またコンテンツだけなのか？複数のSCOが、目次に表示されているとき、問題はもっと難しくなります。

どうすればいいか？ Tin Can APIでは、目次を表示したいなら、コンテンツ/アクティビティに、目次を表示します。コンテンツ/アクティビティは単独で動作します。そして、必要なときLRSにステートメントをレポートします。

コンテンツを起動する

混乱しやすいもう一つの分野は、実際のコンテンツの起動です。ウインドウサイズはいくつで開くべきでしょうか？フルスクリーンで起動しますか？

テーマ設定

これは、現在存在する共通する問題の間接的な対処です。LMSの中のコンテンツは、独自のスタイルが作られて、LMS自体も独自のスタイルで作られています。時には、これらのスタイルは衝突して、学習の邪魔をすることが起こりえます。

LRSからコンテンツ/アクティビティを切り離すことで、テーマ設定/スタイル設定は、提供者の好きなようにコンテンツ/アクティビティを設定できます。コンテンツは、さまざまなLMSの中で、どのように見えるか考える必要はなくなります。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-scorm-user-interface-requirements-dont-achieve-interoperability/

NoraUsagiメモ：
SCORMでは、このあたりのことは規定されていないため、LMS側にパラメータを設定することがあります。印象としては、中途半端にLMSがコンテンツにあれこれ介在している感じでしょうか。

eラーニングの仕様の中心となるものは、相互運用性です。よくできていると思いますが、私たちは、いくつか改善の余地を見つけました。Tin Can APIは、現在の仕様に残る、多くの相互運用性の問題解決を図ります。しかし、私たちは、落とし穴を見つけるには、あなたの支援が必要です。

ユーザーインターフェイスの問題

LMSは、すべて独自のユーザーインタフェースを持っています。可能な限り多くLMSと互換性を持たせたコンテンツを作成する場合、LMSが持つユーザインターフェイスの、すべてのバリエーションを考慮することは、必ずしも可能ではありません。Tin Can APIでは、ユーザインタフェースを、コンテンツ/アクティビティ側にゆだねます。こうすることで、コンテンツ/アクティビティの開発者が意図したとおりに、そのコンテンツが経験されるよう保証することができます。

内容の提出（送信）

Tin Can APIでは、学習者にとって「提出（submit）」とは、
「終わりました（I’m done）　これを提出して評価される準備ができている」という意味です。

SCORMには、「提出完了（submitted）」や「提出しない（not submitted）」という概念がありません。（「サスペンド（suspend）」は、入りません）SCORMを使用する場合、データの損失を避けるために自身をサスペンドする必要がありますが、コンテンツが完了してから、サスペンドした場合、LMSはコンテンツが評価される準備ができていると判断します。

もし、LMSが、評価される準備ができたと判断せず、学習者が戻り、完了したコンテンツを見直したい場合はどうなるでしょう。TinCan APIは、LMSが完了・提出で起こしかねない想定すべてを取り除きます。この問題は、「提出完了」または「提出しない」の概念を導入することで解決できます。学習者がコンテンツを完了したことや、提出する準備ができていること、または、コンテンツを完了し戻りたい、提出して評価される前に、見直すといったことをLMSは、判断することができます。

シーケンシング

SCORMでは、LMSで、シーケンシングを行うことは難しく、混乱しやすいです。Tin Can APIは、完全にLMSからシーケンスを取り除きます。LMSは、正しくシーケンス処理をしていないことより、それ以上に相互運用性に問題があります。コンテンツ/アクティビティは、単独で動作します。もし、それがコンテンツ開発者のもとで動作すれば、誰であっても動作しなければなりません。

APIのシンプルさ

一般的に、Tin Can APIは、不明瞭な領域を減らすことができます。推測に頼ることがずっと少なくなります。LRSは推測や想定に頼る必要はありません。全て、明記されており、そうあるべきです。ここでのTinCanAPIの弱点は、動詞の変化ですが、それにはいい解決法を考えています。もうひとつの弱点は、異なる方法でレポートしたユーザーが、本当は同一ユーザだと識別する処理が、LRSに対して負担が増してしまうことです。これは、「activity definitions agreement(アクティビティ定義の合意）」に関することで、それに私たちも、解決法を提案しています。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/tincancapabilities/project-tin-can-phase-3-better-interoperability/

Tin Can APIは、学習者に対して一つのプラットフォーム上（例えば、自宅のコンピュータなど）でアクティビティを開始した後、（モバイルフォン上のネイティブアプリのような）異なるデバイス上で、そのアクティビティを継続することができます。これはシンプルですが、強力な新しい機能です。そして、従来のeラーニング規格ではできませんでした。

レポートは、アクティビティを試行した箇所に基づいて引き出せるように、LRSには十分なデータを格納できるようにします。このアクティビティの20％は、ネイティブのAndroidアプリで経験され、70％がWindows7のInternet Explorerで経験されたなど。レポーティングは、このような細かな情報を取得する必要はありませんが、それができると親切でしょう。一つ言えることは、プラットフォームの移行が可能になり、コンテンツがLMSに格納されないことです。

アクティビティの開発者は、使用する可能性のあるプラットフォームごとにアクティビティの異なるバージョンを作成して、配信をコントロールできます。コンテンツとアクティビティの開発者は、適切なバージョンを提供するために、LMSに依存することはありません。どのように動作するのか？　そう思うでしょう。

“state” APIは、アクティビティが利用する数の key/document をストレージに残すことができます。”state” は、異なるデバイス上の同一アクティビティ全体で、共有する仕組みを作ることができます。プラットフォーム移行のインスタンスにおいて、Tin Can APIは、 LRSに対して、論理的に同一アクティビティの異なるデバイス上の学習活動を確認できるようします。

これは、学習者が1つのデバイスから、同一のアクティビティを持つほかのデバイスに移行したり、アクティビティ全体を通じて、レポーティングしたり、どこで、どのようしてアクティビティを経験したか確認することが可能になります。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-platform-transition/

従来のeラーニングの仕様のほとんどは、コンテンツをトラッキングするために常時接続を必要とします。

コンテンツは、中断や後で再開することができますが、中断している間、コンテンツをオフラインで体験することはできません。ユーザーがオフラインコンテンツを体験できるように、LMSは、APIのオフラインバージョンを提供することもできますが、しかし、それはLMSのために余分な仕事を必要として、すべてのLMSがこの機能を提供しているわけではありません。

LETSI RTWS (run-time web services)では、通信処理をするため、コンテンツプロキシを作成することで、この制約を回避して、プロキシがLMSと通信を行います。これはエレガントなソリューションですが、それには1つわずかな制約があります。コンテンツは、オフラインなる前に接続された環境で起動する必要があります。

この分野で、Tin Can APIを用いて行った仕事は、以前のRTWSの進捗に、直接もとづいたものです。Tin Can APIはRTWSと同じ機能を提供していますが、さらに２、３歩先を進んでいます。Tin Can APIを使用している、コンテンツ/アクティビティの一部は、スマートに、それがネットワーク接続されているかどうかを検出することができます。

もし、ネットワークに接続できず、コンテンツ/アクティビティが、独自のストレージを持っている場合、ローカルにデータを格納して、接続状態になったとき、LRSに戻し送信することができます。加えて、アクティビティは、RTWSとは異なり、オフラインで起動することができます。

Tin Can APIの特徴はまた、一度に数週間の間、SCORMのセッションを維持するのが非現実的なところでは、長時間実行されるコンテンツをトラッキングできることは、優れたところです。シミュレーションまたはシリアスゲームを考えると、ユーザーは数日、数週間にわたってインタラクションが続けられるかもしれません。そのため、各インタラクションごとに、LMSからそのつど起動すべきではありません。Tin Can APIは、この問題に良いソリューションを提供することができます。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-tracking-offlinelong-running-content/

NoraUsagiメモ：

LETSI RTWS (run-time web services)
http://scorm.com/rtws/

従来のeラーニングの仕様は、コースが完了したときなど、デジタルのアクションをトラッキングします。

誰かがスキル学習をしているだけでなく、それを確認したい場合はどうしたらいいでしょうか、現実世界でそれを行うことができるでしょうか？（eラーニングに限らず） 現実世界において授業への積極性など、イベントを記録したい場合、どうしたらいいでしょうか？Tin Can APIは、デジタルの学習を用いた現実世界のアクティビティを統合するための方法を提供しています。

良い例は、地域のコミュニティセンターでは、CPR（心肺蘇生法）の認定が受けられます。コンピュータ上でトレーニングや、さらに一部は、テストを受けることができます。しかし、CPRは、さまざまなダミーを手にとって行う実技テストがあります。SCORMでは、このような一部 実技が入るテストをトラッキングする方法は提供していませんが、Tin Can APIでは行うことができます。

実際、あなたのクリエイティブ次第で、現実世界のどんなアクティビティでもLRS上で、Tin Can APIを利用して個人をトラッキングして記録することができます。

現実世界のトラッキング可能なアクティビティのそのほかの例：

• 手入力で、「トランスクリプト・レコーダー」に入力できる情報
• 誰かが、講義に出席
• 誰かが、ダイビング機材を使用
• 誰かが、ギリシャ語で会話
• 授業出席率
• 授業への積極性（参加状況）

もっとも簡単な実施は、ユーザーが特定のアクティビティを完了したことを、インストラクターがLRSに通知することです。より複雑な例では、トレーニング装置が（少なくとも、時々）ネットワークに接続され、ユーザがそれらの資格情報を用いてデバイスにログインします。現実世界のアクティビティが行われると、デバイスはLRSに結果をレポートします。

あなたが望むものはどんなものでも、デバイスにすることができるでしょう、CPRのダミー、フォークリフト、超音波機器など。私たちは、あなたがクリエイティブになることを期待している領域です、そして、それは間違いなく革新の領域です。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-track-real-world-activities/

シミュレーションやシリアスゲームは、eラーニングで用いられることがあり、トラッキング、そしてレポート機能のほとんどは、それらが動く独自システムの中だけに完結されるものでした。

Tin Can APIは、シミュレーションとシリアスゲームに、Tin Can APIをサポートすれば、どんなLRSでも、トラッキングができるようになる新たな光を当てました。

これは競争を広げ、コンテンツ制作者、学習機関、学習者により多くの可能性を広げます。

Tin Can APIは、シミュレーションやシリアスゲームの性能を向上させるために、特定のレポーティングや、トラッキングの処理をしている訳ではありません。

いくつかの処理をあげると

• 分散コンテンツ ：
  シミュレーションやゲームは、それぞれ独自のサーバー上に置かれ、ステートメントを外部のLRSへ送ることができます。
• 複数の学習者とチームベースの学習 ：
  マルチプレイヤーゲームとシミュレーションは有効です。データは、グループに重要な情報を示し、グループ全体にレポートします。
• Tin Can APIに準拠したアクティビティは、ブラウザの外で多くのシミュレーションとゲームに対応して動作します。また、アクティビティはブラウザセッションの制約を受けないため、非常に多くのデータをLRSへ送信することができます。
• インストラクターとのやりとり ：
  インストラクターは、シミュレーションが行われているときに、やり取りをしたい場合や、シミュレータで実行中のシナリオを変えたいとき、有効です。しかし、そのようなことが起きた場合、直接的な方法は定義しませんでした。それは、ユーザ定義変数を利用することで、対処できるからです。
• ユーザー定義変数 ：
  もっとも自由に利用できる場所です。フライトシミュレータでは、現在のリアルタイムの風速を利用したり、ビジネストレーニングでは、先月の総収入を自動的に引き出し、どのような素材であっても、シミュレーションやゲームなどダイナミックなトレーニングに、実在するデータを利用することができます。
• 古いeラーニングの仕様は、シミュレーションやゲームをトラッキングする方法について固有な問題を抱えています。それは、ゲームやシミュレーションは、よく長時間プレイされるため、同じアクティビティが何度も実行されることです。The Tin Can APIは、古いeラーニングの仕様では不十分なこの分野で、成果をあげるでしょう。

現在、本当の意味では、リアルタイム機能を提供していませんが、それには理由があります。さまざまなことが、本当にリアルタイムで処理できるようになるには、LRSに相当無理な負担がかかるでしょう。一般的なWebサーバで動作させるには、とても費用がかかり、難しいことです。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-simulations-and-serious-games/

NoraUsagiメモ：

アイキャッチの写真は、フランスのBreakAway社のシリアスゲーム、臨床技能 訓練医療専門家のための仮想学習空間 （Tin Can APIを利用しているわけではないです）

• http://www.breakawaygames.com/serious-games/solutions/healthcare/
• Serious Games Futuring Medical Training In France

Tin Can APIの特徴は、LMSから学習を開始しなくても良いことです。実際、LRSは、あらかじめアクティビティやアクター（学習者）が関わっている認識を持つ必要さえありません。

アクティビティが完了すると、アクティビティは、LRSにステートメントを送信します。
LRSは、ステートメントを記録して、そのデータポイントの内容により、activity creator経由で通信を行います。

これは、いくつかの新しい（そしてとても興味深い）ユースケースが広がります。

• ユーザーは、行われた学習を報告するためにブックマークレットを使用することができます。
• ユーザーは、自分の学習を開始することができて、その学習はLRSに報告されます。
• ユーザーに割り当てられていないものでも、インターネット上のものは何でも、経験したとLRSに報告することができます。
• インストラクターは、LMSを介さず、ユーザーに直接アクティビティを送ることができます

※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-learning-not-initiated-in-an-lms/

NoraUsagiメモ： 学習コンテンツの配布は、LMSを経由せず、CD-ROMで配布しようと何でも良くなり、LRSと
の通信は、activity creatorというのが、利用されるらしいです。

簡単に言えば、ユーザー定義変数は、コンテンツの中で動作する動的な情報のことです。
ユーザー定義変数を取り入れるには、2つの方法があります。

1つは、アクティビティが利用する外部情報をLRSに取り入れる方法です。
どのような使い方ができるかいくつか例を示すと

• リアルタイムに銘柄コードを取り入れる株式市場のコース
• 天気予報のフィードから、実際の風速を利用するフライトシミュレータ
• 可変的な情報（スタッフの名前、休日スケジュールなど）がもたらす企業のための「オンボーディング」コース
• フィードやデータベースからリアルタイムに統計情報を利用する、スポーツのコース

ユーザー定義変数を利用するほかの方法は、後でレポーティングで利用できる変数として、学習やアクティビティに関する情報を格納することです。上記の例から、株式市場の数字や風速など、これらの変数は、通常のステートメントには属さない任意のデータとなります。ほかの例として、学生が必要としている店舗の地域データを評価することと、それらの変数に基づいてレビューコースを提供しています。

このように、ユーザー定義変数の活用事例は数多くあります。

※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-user-defined-variables/

NoraUsagiメモ： LRSに対応したコースウェアのコンテンツは、コンテンツ外部の情報を取り入れることができ、その情報をLRSに、ユニークな変数として保存することができるという意味だと思います。

多くのeラーニングの仕様は、コンテンツの一部が完了した後、ランタイム·データが保持される必要がありません。LETSI RTWSは、試行をトラッキングすることができますが、実際のところ、Tin Can APIでできることとは、離れたものです。

Tin Can APIは、LRSにどんなものでも保存することができ、そして容易にアクセスできます。これにより、詳細をレポートするレベルが全体的に引き上がります。

LRSは、どのようなアクター（動作主）、バーブ（動作）、あるいはオブジェクト（目的）でも、それがしようとする、任意の組み合わせでクエリーを実行します。

引き出せる詳細の量は、アクティビティー・ジェネレーターが生成を選ぶステートメントの複雑さによってのみ制限されます。ステートメントがもっと複雑になれば、より多くのデータポイントが生成されます。以前と比べてかなり多大な量のデータを保存できるようになっています。異なるユーザーレベルを決定し、アクセスするユーザーがどの程度のデータアクセスを持てるかは、LRS次第となります。

以前では、できなかったことが、このデータでできるようになったことはたくさんあります。１つの例としては、コース全体に対して、特定の質問やセクションに関したレポートを引き出すことができます。

※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-i-want-access-to-scorm-runtime-data/