CMI5

cmi5 プロジェクト

cmi5 とは何ですか? それは xAPI の「拡張ルール」です。

cmi5は、伝統的な学習管理システム(LMS)と xAPI を利用するための「プロファイル」です。

cmi5

 xAPI は、多種多様なユースケースをサポートするために汎用的な仕様になっています。そのため特定のユースケースをサポートするために(プロファイルと呼ばれる)「拡張ルール」のセットには、まず相互運用を保障する必要がありました。cmi5プロファイルは、学習コンテンツと LMSシステムとの間でプラグアンドプレイとしての相互運用が保証されます。

 cmi5プロファイルが適用されたユースケースでは、学習者は、LMSのユーザインターフェイスから学習コンテンツ / アクティビティを起動します。

 cmi5は、次の分野に相互運用性の規則を定義します。

  • コンテンツの起動メカニズム
  • 認証
  • セッション管理
  • レポート
  • コース構成


目標

 cmi5のミッションは、とても柔軟で現在の AICC / SCORM規格に対して、より良い代替手段を提供することです。そして堅牢であり今日の技術に適応できることです。

1 – 単純化されたトラッキング・データ・モデル

 SCORM と AICC のデータモデルは、あまりにも複雑であり、使用されなくなった多くのオプションのデータ要素を持っていました。シンプルなデータモデルとして、あるべき姿は、ラーニングドメイン間で動作するデータ要素の定義を必要最低限にとどめることです。(例えばスコア、ステータス、時間)

2 – コンテンツの定義データを記録したり、レポート/取得する機能

 必須とされるデータ要素が少ないわりに、強い制約があるためデータを収集することに制限がありました。大抵、本当に必要だったことは、LMS の中でコンテンツからデータを記録して、分析のために後でそれを取り出せればいい程度のことでした。コンテンツの定義データを記録したり/取得できるようにするための目標は、コンテンツの設計者が機能を追加しても、きちんと相互運用ができることです。

コンテンツの定義データは、テキストデータかデジタルデータかのどちらかです。

  • 拡張可能なデータモデル(コンテンツのテキストデータによって定義される)
  • デジタルデータのアタッチメント


3 – サービスとしてのコンテンツ(CaaS)モデルの配信をサポート

 コンテンツが他のドメイン上に(LMSが稼働するサーバのドメインとは別のところに)格納することができます。

4 – デバイス/ OS /ブラウザからの独立性

 コンテンツが通信をしたり、起動する動作に対してブラウザが依存しないようにします。

5 – 学習活動におけるデータ共有

 同一コースに登録される学習者間で学習活動のデータを共有することができます。

経緯

 cmi5 プロジェクトは、もともと2010年に AICC(Aviation Industry Computer-Based Training Committee)の中で活動を開始したものです。cmi5 は、豊富な機能を備えた堅牢なソリューションのため AICC や SCORM規格の置き換えとして期待されていました。それは、AICC と SCORM規格は技術的な問題や制約など、かなりの重複があったためです。

 AICCは、2012年にcmi5 のための SOAPベースの通信メカニズムが完成間近まで来たところ、ほぼ同じタイミングで ADL のなかで(いまではxAPIと呼ばれる)Tin Can APIの研究プロジェクトが立ち上がりました。

 AICC と ADL の関係者は、すぐに2つの仕様には、かなりの共通部分があると判断しました。xAPI は cmi5 よりも広範な適用を持っていたため、ADL と AICC は cmi5 のより具体的なユースケースのニーズを満たすために “xAPIプロファイル” に協力することで合意しました。cmi5 プロジェクトは2012年に「再始動」されて、SOAPアーキテクチャは xAPI に置き換わりました。cmi5 プロジェクトは、いまも本来のゴールに向かって進んでいます。

 2014年にAICCは、cmi5 プロジェクトを解散して、正式にADLに移行いたしました。

※ この記事は、githubのThe cmi5 Project「README.md」の一部を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) https://github.com/AICC/CMI-5_Spec_Current

(参考)Content as a Service (CaaS)
https://www.contentful.com/r/knowledgebase/content-as-a-service/

Tin Can API TinCanAPI 翻訳資料

もっと深く : Verbs

ステートメントへのインクルージョン

 動詞は、ステートメントの一部として必要で、動詞を含めることはとても簡単なことです。ある経験により発生する行動を示すステートメントの動詞オブジェクトを verb プロパティとして設定するだけです。 動詞オブジェクトは、URI(IRI) を示す一つの id プロパティで構成されます。例えばこのような形式です。

{
    id: "http://adlnet.gov/expapi/verbs/experienced"
}


 これだけでも十分ですが、人は多少なり自身の母国語に近いものを好むようです。そのため、id プロパティと同じように、display プロパティを含めてください。display プロパティの値は言語マップ(対応する文字列の値を持つ言語コードの一覧)であり、 Tin Can API を国際化させるために必要な相互運用性の中心となります。これは同じ意味を持つ動詞ですが、人間が読み取れる display 値となります。

{
    id: "http://adlnet.gov/expapi/verbs/experienced",
    display: {
        "en-US": "experienced"
    }
}


 言語値の追加は、RFC5646 の言語タグを使用して容易に言語マップに追加することができます。上記の “en-US” は、アメリカ英語の例です。

経緯

 仕様策定の初期段階において、あらかじめ定義された動詞セットがありました。0.95バージョンの仕様策定において、動詞は自由に作成できることが適切と考え、id の完全な URI を持つリストは、オブジェクト フォームに移動されて仕様の範囲外になりました。これらの動詞が他の目的でも、もう使用されることが無いにもかかわらず、ADLは特にラーニング コミュニティ向けにデザインされた動詞リストを、まだ維持しています。 しかし、「attempted」 (履修した)、「experienced」 (体験した)、「passed」 (合格した)、「failed」(失敗した)、「answered」 (答えた)、そして「completed」 (完了した) などの動詞は、(もちろん URI の形で)従来の仕様とうまく適合するため、Tin Can で利用される動詞の中でも、共通的に使用される動詞になっています。Tin Can を利用するコミュニティは、その実践コミュニティの中で、認知されて利用するような、独自の動詞をコミュニティ依存の動詞セットとして作り出すと予想していました。そして例外として、ステートメントが無効になる特別な役割を果たす、事前に定義された動詞が仕様内に1つ含まれています。ステートメントを無効にするには、http://adlnet.gov/expapi/verbs/voided の id を持つ特別な動詞を含む新規のステートメントを、ステートメントのリファレンス(詳細は今後の投稿で説明)とともに、そのステートメントを受信すると思われる LRS に送信します。

過去時制

 動詞は過去時制でなければなりません。Tin Can は本来、時系列に基づいて経験をトラッキングするように設計されています。ステートメントは経験のための記録(それは過去時制であり)したがって、動詞は過去の時制になります。直ちに記録された経験であろうとなかろうとも、体験そのものは既に過去のものでなければなりません。(これがステートメントがもはや「進行中」といったものを示さない理由の一つです。) 時間経過の概念は、一連の行動の繋がりの中で、潜在的には同じ体験内に存在します。それは積み上げられたステートメントから、意味を引き出すために必要とする相当量の複雑性がありますが、同時にコンテンツ作成者の想像力を高める柔軟性をもたらします。

実行可能性

 URI として動詞ID が持つ意味は、多くの動詞はロケーション(URL)を解決できること、そのときに、それらにメタ情報を追加できることです。メタ情報は、少なくとも JSON として要求されたとき、仕様に従い、「name」(名称)と「description」(説明)プロパティを持つオブジェクトを含む必要があります。これらのプロパティは特に、動詞そのものについての説明(「display」プロパティの目的といったもの)ではなく、動詞についての情報を与えるために使われます。これはよいスタートで、動詞と Tin Can が進化するにつれて、動詞(と URI を使用するほかのアイテム)に関する情報を拡張できる手段を持つでしょう。私の中で、インターネットの純正主義者の信念に従うなら、動詞はURI であり、そして URL になる URI を選べるならば、すべての動詞は解決すべきです。ですが仕様では、動詞は解決する必要はなくオープンです。(そのとおり、私は常に純正主義者というわけではありません)

動詞を作るか、作らないか

 本質的にそれは大した問題ではありません。最終手段として、どうしてもという以外は新しい動詞を作ることは避けてください。そうですね、Tin Can 導入がまだ時期尚早の段階で最終手段というのは、ちょっと言い過ぎかもしれませんが。動詞セットというものは、徐々に固定化されていくでしょう。Actor, Verb, Object のステートメントで利用する3つの構成要素を考えてみてください。このなかの動詞だけが、一貫して人々の経験を横断して一致させることができて、同じ actor の経験のさまざまな行動を示します。そのような2つの側面は、行動をレポーティングするときの基本であり、これから全ての新しい経験が、全く新しい動詞セットでレポーティングされてしまっては、その役割を果たすことができません。実践コミュニティが必要なのはこのためです。適応を通して動詞は牽引力を持ちます。動詞の自然な関連付けが増え、牽引力を持つようになるとシステム作成者は、Tin Can のような仕様が提供しようとしている相互運用性の基礎となるセマンティックな意味づけが頼りになります。ステートメントの作成者は、既に動詞がないかよく探して、あるならば活用すべきです。

レジストリ

 私たちは、動詞(そして、ほかのURIベースのコンポーネント)リストのことを registry(レジストリ) と呼び、その動詞リストを一つ作成しました。具体的には The Registry というもので、ここで元となる「動詞」を見つけることができます。現状、The Registry は ADL の動詞リストから構成されていますが、相互運用性を低下させる動詞の激増を防ぐために、ユーザーがきちんと整備されたプロセスを通して新たな動詞を作成できるように、(ブログ記事を書いていないときに)機能性の向上について取り組んでいます。もちろん私たちは、人々が新しい動詞を作成して、その動詞を利用することを防ぐことはできません。そして新しい動詞は時間の経過とともに必要になるでしょう。私たちは、これらの動詞が永続的(ステートメント作成に必要であるため)に使われること、そして問題解決に役立つ事を望んでいます。そのため、URI ベースの id で利用するドメインの名前空間 id.tincanapi.com を立ち上げました。The Registry の中で作成された動詞(及び他のアイテム)は、仕様で定義される、動詞に関連するメタデータを提供する解決可能なURLを持ちます。

意味というのは単語でない

 動詞は手強いです。そして英語は(他の言語も、きっとそうだと思いますが)、それらの動詞を更に手強くする至上の言語です。これまでは、相互運用性を可能にするために、可能な場合は動詞を再利用すると言いましたが、しかしまた、独自の動詞セットを採用する実践コミュニティがあるだろうとも言いました。これらの2つのベストプラクティスは、相反する葛藤を含んでいます、それは一つの動詞がステートメントに応じて、異なる意味を持つ可能性があるということです。類義語と呼んでもいいでしょう。これがどれだけインパクトのあるものなのか、もう一つ言えば、動詞オブジェクトは、特定の単語ではなく、1つの意味に直接マップする識別子を持ちます。それゆえに特定のIDによる動詞オブジェクトの意味を見出すとき異なるケースでは、動詞の意味に一致する単語と意味が合わないことがあるということです。

 Fired という単語は、よく引き合いに出されます、それは恐らく、ひとつに指定される単語だからでしょう。Fired は、状況によっては全く違う意味になり得ます。その文面が表す状況により、意味合いが全く変わることから、その動詞ID の意味を作り出す単語が鍵を握っています。問題はどのようにその単語を識別するかです。例えば、fired a gun (銃を発射する) と fired a cannon (大砲を発射する) は異なった動詞でしょうか?両者ともに発射物が急速に弾き出て行く様を意味するものです。したがって同じ動詞である、と主張する人もいるでしょう。つまり、白黒がはっきりしないグレーゾーンが残り、その部分をはっきりさせるにはステートメントを処理するシステム、そして究極的には私たちのような不確かな人間が、難解な意味を持つ文脈の関係性を考慮しながら、判断を下し、言葉の意味付けをしていかなければなりません。動詞や類義語を新たに、そして正しく作成するには、時間そしてどの意味を採用していくか、この二つが本当に唯一必要なことなのです。

※ この記事は、CC BY 3.0のもと、tincanapi.com の Deep Dive: Verbs を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/2013/06/20/deep-dive-verb/

TinCanAPI 翻訳資料

もっと深く : Actor / Agent

誰も経験者がいない場合、LRSにステートメントは記録されますか?


抽象的な概念に伴う問題

 Tin Can API は経験情報を記録するためにデザインされていますが、1つの前提条件として、個人あるいはグループが経験者として存在しなければなりません。アクタを書くことは、Tin Can のステートメント上、それは 「I (私)」 として扱われ、つまり文法的には主語になります。

 Tin Can ステートメントを作るとき、抽象的な概念がたくさん出てきます。そして、一見してステートメント 「I (私)」 の定義は単純にみえるため、手始めにそこから始めることは現実的です、しかし残念ですが実際は、そう単純ではありません。「私はいったい誰なのか?」という問いかけは、世代を超えて問われ続けるような大きなもので、Tin Can であっても小さくならない問いかけです。そのような問題と折り合いをつけるには、あなたが 「I (私)」(もしくは 「royal we(私たち)」)を定義するだけでなく、相手の誰かに自分が誰であったのかを伝えられなければなりません。そして、さらに問題を複雑にすることに、あなたは「 I 」を アクタとせず、あなたの仲間 「me」(あるいは何人かの仲間 「us」)をアクタとして定義するケースがあることです。 「 myself 」 もいいでしょう。さて、代名詞については十分話しましたので、アクタに話しを戻します。

 ステートメントの アクタの部分を理解するには、客観的に JSON オブジェクトの値(代入の右辺)に対する、キーやプロパティ(代入の左辺)が何になるのか、理解することです。最終的にステートメントは、値が代入されたプロパティの集まりから構成されます。アクタはそのようなプロパティの一つで、アクタは「 Agent 」(あるいは「 Group 」)でなければなりません。

これはアクタは、あとから値が決定されるプレースホルダー(あるいはポインタ(参照))のため、それ自体に特別な意味を持たないためです。

 言い換えれば、私たちはアクタを意味を持った名詞、あるいは、何らかのオブジェクトタイプであると考えてはいけません。アクタは特定の値を指しているポインタ(参照)として考えます。また、ステートメントのプロパティとプロパティが保持する値の形式は、(小文字の)「 actor 」と大文字の「 Agent 」を使い区別している点に気が付いてください。ただ私の妻は、セマンティックスを振り回しているだけと私に指摘するのですが、もし彼女が開発者なら、セマンティックスは、私(私達)の作業にとって非常に重要なことで「正しいことだ」と、言い返したいところです。(ただ、彼女は開発者ではないので、すべて言い返すようなことはしません、頭が上がらない立場なので。)

エージェントとグループの定義

 エージェントとは、オブジェクトタイプの一つで確実に言えることは、逆関数識別子で表現しなければならないため一貫性があり、同一のエンティティ(実体)までトレースバックできる一意の ID を指します。逆関数識別子は、エージェントを表すいくつかの形式をとることができ、メールアドレス(またmbox)が最も分かりやすい形式です。人であれば読み取れるメールアドレスに加えて、1つのエージェントは、メールアドレスに含まれる SHA1 ハッシュによって指定することもできます(ハッシュは IRI でなければならないので、「 mailto 」の部分も含まれます。)

{
        mbox: "mailto:info@tincanapi.com",
        objectType: "Agent"
}


{
        mbox_sha1sum: "f427d80dc332a166bf5f160ec15f009ce7e68c4c",
        objectType: "Agent"
}


 電子メールアドレス以外にも、エージェントは OpenID の URI を利用して一意に指定することができます。電子メールが、まだかなり広く受け入れられている状況でも、 OpenID は、いくつかの領域でうまく行っています。仕様書では、エージェントは対象システムが持つ固有識別子で特定できるコンビネーションを使い、多くのシステムが持つ特有のバリエーションを使用することができます。Twitter.com で言えば、「Twitter handle(ツイッター ハンドル)」が、そのシステムでの固有表現になり、そのコンビネーションは、単に「 Account(アカウント)」として知られているものです。いくつかのシステムが、現れては消えていくなかで、やがて電子メールアドレスの終焉を目にするかもかもしれません、システムの固有IDに加えそのシステムのエンテイティ(概念としてのアカウント)の固有ID の概念は、その仕様が存在する限り十分に柔軟性を持たせる必要があります。


{
    account: {
        homePage: "http://twitter.com",
        name: "projecttincan"
    },
    objectType: "Agent"
}


 注意すべき重要な点は、エージェントは、利用可能な複数の逆関数識別子を持つことができたとしても、エージェントオブジェクトが、逆関数識別子にリンクして関連を持つことで、プライバシーの理由などから LRS が要求を拒否してしまうことを避けるためにも、一つだけを含むべきです。また、私たち人間がもっと簡単に利用しやすくするために、エージェントに「 name(名前)」を関連付けることが出来ます。


{
    mbox: "mailto:info@tincanapi.com",
    objectType: "Agent",
    name: "Info at TinCanAPI.com"
}


 上記の例では、明示的に ObjectType プロパティを Agent にしました。そのプロパティは、Agent か Group かの、いずれかである必要があり、また初期値が Agent の場合は、いつでも省略することができます。( actor プロパティの オブジェクトタイプみたいなものです。)

 グループは、エンティティ(実体)を表現するオブジェクトタイプという点で、エージェントによく似ていますが、構成の全て、または一部、特に member プロパティを、列挙できる追加プロパティを持ちます。グループは、objectType プロパティに、グループ値を与えなければなりません。そして グループには、2つの種類があり、指名と未指名(匿名)があります。前者の場合、指名グループは、エージェントのように、逆関数識別子(または、固有識別子)を持っていて、member プロパティを含んでも含まなくても構いません。また指名グループが、リストを持つ member プロパティを含んでいても、それが完全なリストであると判断すべきではありません。これは、あるステートメントが、経験したメンバーエージェントの特定のサブセット(一部の人)のみ呼び出すことがあるためです。(おそらく、著名なメンバーエージェントや、最大寄与数を持つメンバーエージェント、最も整理されているメンバーエージェント、または、最初に到着したメンバーエージェント。)後者の例では、未指名、つまり匿名グループは固有に指名された情報との関連付けがありません。そのために逆関数識別子を持ちませんが、member プロパティを含まなければなりません。バージョン1.0.0 の時点での仕様では、この場合のメンバーリストは完全なリストである必要はなく、オープンなままをベスト·プラクティスとしています。これは、ほかのメンバーエージェントとステートメントのその部分を関連させる方法がないからです。未指名グループを、同一のグループとして同じ一組のメンバーエージェントと関連付けることは自然と成りうる傾向ですが、仕様上、実装するシステムは、このような想定を行うべきではないことに注意してください。更に言えば、どちらの種類のグループメンバーリストもエージェントのみ含むものでなければなりません。そのため、グループを入れ子にすることはできません。

{
    mbox: "mailto:info@tincanapi.com",
    name: "Info at TinCanAPI.com",
    objectType: "Group",
    member: [
        {
            mbox_sha1sum: "48010dcee68e9f9f4af7ff57569550e8b506a88d"
        },
        {
            mbox_sha1sum: "ca3ffdb44c4727137e29ebf42ee80c2afdd8d328"
        },
        .
        .
        .
    ]
}


{
    objectType: "Group",
    member: [
        {
            mbox_sha1sum: "90f96ca8c3ae315f0e40df4e16772eb6d05e3937"
        },
        {
            mbox_sha1sum: "ca3ffdb44c4727137e29ebf42ee80c2afdd8d328"
        }
    ]
}


ステートメントに話を戻して

 さて、ここまで、私たちは Agent/Group オブジェクトについて学び、actorプロパティのオブジェクトと理解したところで、次を見てみましょう。※ただ、ステートメント内には他にも、同じようにエージェントを使用することがあります。例えば、前述した“me 私”の例では、“ Sam (エージェント1) helped me (エージェント 2) ”(サムは私を助けた)といった同じようなステートメントを作るために、object プロパティの中に自身の Agent または Group (“us”) を置くことができます。その場合は、そのステートメントは、2つのエージェントを使用します、actorプロパティは、今までどおり1つ含み(この場合 Sam )、object でもう一つ使います(この場合 Brian(または me ))。エージェントやグループはステートメントの” instructor “としてステートメントの ” context ” の中に含めることができます、そうすることで、Brian (アクタ) learned Tin Can from Ben ( instructor ).”(「ブライアン(アクタ)はベン(instructor)から Tin Can について学んだ」)というステートメントを作ることができます。また、context は team プロパティをも含めることができますが、その場合は Group である必要があります。

 最後に、エージェントはステートメントの authority プロパティを設定するために利用されますが一般的にステートメント作成でその記述がない場合、それは LRS によって作成されます。(” authority “(認証)に関しては今後詳述します)

ステートメント以外のこと

 エージェントはステートメント構造において、最も重要な役割を果たす部分であり、クエリ可能である必要があります。エージェントオブジェクトは、 actor や object プロパティに一致するステートメントを取得するために、エージェントのクエリパラメータを通じてステートメント API に渡されます。他の可能性がある場所として1つでもエージェントが存在するステートメントを見つけるために「 related_agents 」のクエリフラグをオンにしてリクエストを送ってください。エージェントは、Agent Profile として呼ばれる、独自のAPIメソッドを持つすばらしいものです。Agent Profile は将来に向けて自分自身のポストを保証するものですが、今は LRS において特別なエージェントと任意のデータを関連付けることができることを知っておけば十分でしょう。1つのユースケースでは、ユーザプリファレンスを格納しています。Agent Profile と共に、エージェントはまた、API ステートコールに組み込まれています。

潜在的な問題

 多くの場合、たくさんのグループに所属するだけでなく、最近では、人はいくつもの逆関数識別子を持っています。私は個人的に、Eメールアカウント3つ持っていますが用途に応じて使い分けてをしています。ひとつは個人用で、もうひとつは仕事用、そして最後のひとつが、いろいろな用途に使うものです。それらは技術的にドメインエイリアスを持っていて、約10個のドメインネームがあります。これらはそれぞれ、別個の逆関数識別子と考えることができ、そうすると、私は単にEメールだけでも約30 もの識別される手段を持っていて、そして、さらに少なくとも10もの公開しているプロフィール( Twitter、Github、 Facebook、 LinkedIn、 Google+ など)を持っています。それら、全てが「アカウント」という概念を持ち、Tin Can APIとのやり取りで利用できます。そして、それらは公共のものです。ここで重要な点は、Tin Can API で動作するシステムは、実際のところ「人」の特定識別子をいくつでも有することができる点を考慮する必要があります。

 それに加えて、すべての逆関数識別子の場合において、私たちは Eメールアドレスあるいはアカウントが共有されているかどうかまで知ることはできません。そのため、エージェントが人とゆるく結びついている可能性がある一方で、一つのアカウントがひとりの人間を表現していると想定すべきではないのです。このことから私たちは、アカウントはひとりの人であると決めてかかるべきではないでしょう。さらに時間の問題やメールアドレスやアカウントは、所有者が変更される可能性があるという現実があります。例えば “ info@tincanapi.com ” というメールアドレスはあらゆる人に送信することができますが、“ brian@example.com ” というメールアドレスは Brian Miller から Brian Smith に所有者が変わるかもしれません。結局、それが timestamp プロパティが存在する理由のひとつになります。しかしそれについては後の記事で触れようと思います。
さあ、ステートメントを作ろう!。

※ この記事は、CC BY 3.0のもと、tincanapi.com の Deep Dive: Actor/Agent を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/2013/06/05/deep-dive-actor-agent/

TinCanAPI 翻訳資料

第4レイヤー : トレーニングに相関するジョプ・パフォーマンス

 Tin Can APIは、アクティビティストリームと呼ばれる仕様をベースにしています。これは、GoogleやFacebook、Microsoft、IBMなどの企業により形成された、ソーシャル・ネットワーク上のアクティビティの記録に用いられるフォーマットです。

 アクティビティストリームは人の行動をすべて記録することができます。Tin Can APIは、学習体験を収集しやすいように、アクティビティストリームの仕様を拡張したものです。 Tin Canステートメントの中心的なオブジェクト Actor、Verb、Object(“I Did This”(私はこれをやりました))というものは、中核をなすアクティビティストリームの仕様から由来しています。

 Facebookのウォールを見ると、そこにはアクティビティストリームの一連のステートメント(だれそれが何をした)があります。例を挙げてみると。

  • 「マイクは写真を投稿した」
  • 「ティムはマイクの写真にコメントをつけた」
  • 「ベスがマイクの写真について「いいね」を付けた」

 アクティビティストリームは、ソーシャルネットワーク、企業の双方で、人々のアクティビティを収集する方法として注目を集めています。言い換えるなら、実際 仕事のパフォーマンスデータとトレーニングデータは同一に収束していきます。私たちは、学習体験のデータ収集に、企業がそのほかの体験を収集する手段と同じやり方を用いています。これは大きな強みです。

 アクティビティストリームの例を挙げてみると。

  • 看護師ジュディーは、eラーニングモジュールの「CPR(心肺蘇生法)の原則」を修了しました。
  • 看護師ジュディーは、ダミーを使い、心肺蘇生のシミュレーションを修了しました。
  • 看護師ジュディーは、12回中9回の心肺蘇生に成功しました。

 これらのストリームを企業間で、もしくは産業界全体で収集を開始することで、どのようなトレーニングパスが最も良い結果を生み出すかを見極めることができます。言い換えるなら、もっとも問題のあるトレーニングパスを見極めることができるのです。現在、トレーニングプログラムの有効性を決定し ROIの効果測定を行うことができるのです。

そのほか考慮すべき含み

  • Yammerのような内部ソーシャルネットワークからのアクティビティストリームとTin Canのアクティビティストリームを組合わせると、どうなるでしょう?学習体験と同僚との会話を基にして、私たちは組織内で専門家を見つけることができます。
  • 組織でもっとも成功したパフォーマのアクティビティストリームを見て、若手社員が見習うべきモデルとして、それらを活用することができるでしょうか?逆に、失敗した人が辿ってきた道を危険信号として見ることができるでしょうか。

 これらのビジョンが完全に達成されるには長い道のりが必要でしょう。Tin Canはその実現に必要な基礎をレイアウトして、制約を取り除こうとしています。

 しかし、もちろんそれだけではありません。まだ他に何ができるのか誰も気付いていないだけです!Tin Can APIは大きな新しい可能性を切り拓きつつあります。eラーニングを画期的に変えてくれることは間違いありません。5年後にどうなっているかは誰にも予想できませんが、楽しい旅になるのは間違いありません。一緒に歩んで行きましょう。

※ この記事は、CC BY 3.0のもと、tincanapi.com のLayer 4: Correlate Job Performance with Trainingを翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/layer-4-correlate-job-performance-with-training/

TinCanAPI 翻訳資料

第3レイヤー : データを開放する

 今までに、SCORMのデータが、どこかのブラックホールに入り消えてしまったと、思うことはなかったでしょうか?。SCORMは、とにかくLMSにデータを送ることが仕事でした。LMSが、それをどのようにデータを利用しようと、表示しようと、レポートしようと、規定はありません。Tin Canも、そのようなシステム上の規定はありませんが、決定的に違うことがあります。それは Tin Can は、LRSのデータにアクセスできることを要求している点です。

 そのため Tin Can API は、LRSへのデータ書き込み・読み取りの双方が可能です。書き込みしたものは、読み取ることができるのです。LRSは、レポーティング・ツールや分析ツール、また他のLRSとの間でデータのやり取りができます。この機能は、自身で構築するシステムをどうするか、共有データをどうするかといったシステム構成に、重要な意味を持ってきます。

 LMSのレポーティング・ツールに満足している人は、まずいないでしょう。一般的なレポートでも、十分な場合もありますが、別の方法でデータを細分化したり分けたくなるときもあります。業界が異なれば、ニーズも異なり、用いる用語、順守すべき要件も変わってきます。Tin Can APIなら、どのようなLRSからもデータを引き出せるため、高度なレポーティング・ツールを開発することが可能です。これらのツールは、特定のビジネスインテリジェンスツール向けであったり、さまざまな種類の学習体験、異なる業界向けなど、カスタマイズすることが可能なのです。データはアクセス可能なので、好きな方法で分析することができます。

 コンテンツの作成者は、教育効果を評価し、欠点に対処して、そして改善策を講じる手段を常に模索してきました。改善すべき部分を見つける唯一の方法は、学習者がコンテンツ自体にどのような関わり方をしているか理解することです。実際、何が起こっているのかを理解しなければ、作成者には、不備のある箇所が見えてきません。Tin Canは、コンテンツの分析ツールにより、LRSから実際の利用データを抽出し、情報に基づいた判断を行い、インストラクショナル効果をより上げるために、作成者に必要な情報を提供することができます。

 システム間の通信に加え、Tin Can APIは、一つ以上のLRSに対して、ステートメントをレポートすることが可能です。LMSと学習体験との間には緊密な相互依存関係がないため、学習体験の情報伝達は、制約なく複数のLRSにステートメントを自由に送ることが可能です。

 マルチLRSのレポート機能で、もっとも興味深い使い方は、「パーソナルデータロッカー(学習者個人が所有するクラウド上のストレージ)」の活用です。学習者が一つのトレーニングを受ける時、なぜ学習体験は、雇用者のLRSだけに記録されてしまうのでしょうか?。その学習体験は、他の事柄や今後の仕事に関連することはないでしょうか?なぜ、その学習体験は、学習者に帰属されないのでしょう?Tin Canを使えば、学習者は学習体験を雇用者にレポートするだけでなく、同時にこのイベントを「パーソナルデータロッカー」に記録することができます。

 論理的に次の思考を考えると、なぜ学習体験は、一番に学習者の「パーソナルデータロッカー」に記録されないのでしょう?まずは、学習者に自身のデータを所有させて、そして次に、そのデータを共有する相手を決めてみては。

 学習体験の記録は、履歴書よりもその人の経験を多く語ることになりませんか?

 学習体験を公開することで、助言、質問、仕事さえも求められたり、特定の分野で専門家であることを知ってもらうのに役に立ちませんか?

 あなたの組織は、その仕事についてだけでなく、一個人として学んだこと全てを知ることで、利益になりませんか?

 このビジョンを達成するには、さまざまな課題を乗り越えなくてはなりません(技術的にも制度的にも)。しかし、Tin Canは、こうした課題全てを克服して、それ以上を達成するための基盤となるでしょう。


 少し驚きましたか?潜在的に持つ変化の可能性に?Tin Canは、今後 産業を再形成するでしょう。しかし、もちろん、それだけではありません…


※ この記事は、CC BY 3.0のもと、tincanapi.com のLayer 3: Free the Dataを翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/layer-3-free-the-data/