ダッシュボードに必要な6つ要素：学校教育の全体アーキテクチャの解説
今回は前々回ぐらいからやるやる詐欺になっていた、学校教育の全体アーキテクチャの解説①をやってみます。
全体アーキテクチャの概略は以下ですので、よろしければご確認いただけたらと。
ダッシュボードの実現に向けて
全体アーキテクチャの1つ1つの要素について、技術仕様や文書を解説していっても読み辛いと思うので、ストーリーや目的を持って解説してみたいと思います。
なので今回は、教育データの利活用という意味では注目度が高くなっている「ダッシュボード」を実現していくに際してのデータの流れから解説してみたいと思います。
全体アーキテクチャの図の中では
赤の「可視化/通知」をダッシュボードとして捉えていいただけたらと。
そのうえで、青の部分のデータの流れを解説してみたいと思います。
（追記）
書いてみたら、今回は超長い文章になってしまっています。
お時間あるときに見ていただけたらと。（分割すればよかった…。）
ダッシュボード実現に必要な6つの要素
ダッシュボードを実現するためには、以下の6つの要素が必要です。
（これ以外の方法もありますが、国政策の標準仕様外になり、手間＆コスト高になりがちだと思っていただけたらと）
校務と学習のID(利用者識別子)の統一化
学習系ソフトウェア間でのID(利用者識別子)の統一化
学習データの標準規格による蓄積
アクセス制御を前提とした校務系・学習系ネットワークの統合
各システムでのデータ連携のためのAPI実装
データ基盤＆可視化機能の構築
これら全ての要素が必須なのか、というとそうでもありません。
「1と4をやって、2と3はできる限りでGoogleやMSのIDとの名寄せも並行させつつ、5はある程度手動でやりつつ、6でダッシュボード化する」みたいなところから現実解（意味不明な人多数だと思いますが、、最後のほうにここも補足しますね）だと思いつつ、まずは理想形に近い国の標準仕様を前提にした正当なものを書いてみます。
では、1～6をそれぞれ解説してみますね。
1. 校務と学習のID(利用者識別子)の統一化
1つ目は校務と学習のID(利用者識別子)の統一化、です。
いわゆる「ダッシュボード」をつくるには、データを集めるだけでなく、誰に関するデータなのかを明らかにする必要があります。
校務系と学習系で「誰か」を識別するためのIDを揃えておかないと、めっちゃ頑張って目視・手動とかで「IDの統合＝名寄せ」をしないといけなくなります。これ、めっちゃ大変ですし、毎年続くならシステムとして統合しておくべきものです。
そしてダッシュボードに必要なデータは、校務系と学習系に散在しているので、大きくはその2つのシステムの利用者識別子＝IDを揃えることになります。
全体アーキテクチャでは以下の赤い手書きの丸の部分。
参照している文書・標準仕様等は以下になります。
教育情報システムの在り方に関する調査研究（文部科学省）
学習eポータル標準モデル（文部科学省）
OneRoster Japan Profile（日本IMS協会）
ここはOneRosterという規格を使って連携することになります。OneRosterは、1Edtechという国際標準を作っている団体の規格で、その日本版であるOneRoster Japan Profileを用いて連携することになります。
さらに学習系ソフトウェアと連携していくために、学習eポータル標準モデルに則って、利用者識別子の規定などが追加されることになります。
具体的には、上記仕様の名簿出力機能を持っている校務支援システムからCSVファイルを出力させ、学習系システム（主に学習eポータル）に読み込ませることになります。
詳細は各仕様を見ていただくのが一番ですが、ざっくりどんなものかというと、こんな項目などがあるCSVです。
本当はこの辺もCSVではなくAPIで連携していくことで、先生方の手を煩わせずポチっと自動化としていきたいのですが、現時点ではCSV連携のみとなっています。
（APIのことは後述します。いきなり横文字略称登場させてしまって申し訳ないです。）
これでまずは校務系と学習系のID(利用者識別子)が統一化されます！
このOneRosterによる連携は、どこかでこのテーマだけに絞って書いてみたいと思っています。重要な反面、誤解が多そうテーマでもあるので。
2. 学習系ソフトウェア間でのID(利用者識別子)の統一化
2つ目は学習系ソフトウェア間でのID(利用者識別子)の統一化、です。
IDを統一しないと、の理由は前述した校務と学習のIDの統一化と同じです。これをやらないと名寄せでめっちゃ大変になります。
全体アーキテクチャでは、以下の赤い手書きの丸の部分。
参照している文書・標準仕様等は以下になります。
教育情報システムの在り方に関する調査研究（文部科学省）
学習eポータル標準モデル（文部科学省）
LTI(Learning Tools Interoperability) （1Edtech）
ここでは、LTI(Learning Tools Interoperability)という規格を使って連携することになります。LTIは、OneRosterと同じく1Edtechという国際標準を作っている団体の規格です。
さらに学習系ソフトウェアと連携していくために、学習eポータル標準モデルに則って、利用者識別子の規定などが追加されることになります。
LTIは、各々提供している学習ツールと学習プラットフォームを一体的に利用できるようにして、先生や学習者の利便性を上げようとするための技術規格です。
日本の現状だと、プラットフォーム＝学習eポータルとデジタル教材等との連携、が主になります。
各々のデジタル教材へのログインを不要にし、ID(利用者識別子)や属性情報を伝達することや、プラットフォーム側で教材内容を検索し配信できたりするような規格です。
いわゆるシングルサインオンを行っていく際にIDをデジタル教材等に伝達するため、利便性の向上と同時に学習系ソフトウェア間でIDの統一化ができます。
ちなみに「LTIを使ったシングルサインオンを導入するとなると、今のGoogleやMicrosoftでやっているログインIDやシングルサインオンをやめないといけないのか」という質問を受けることがありますが、この辺は誤解でして。
学習eポータル標準モデルでは、別の認証機能(ここではGoogleやMicrosoft)とのシングルサインオンのことも記載されており、多くの学習eポータルはGoogleやMicrosoftとのシングルサインオンもサポートしています。
これで学習系ソフトウェア間でのID(利用者識別子)の統一化されます！
3. 学習データの標準規格による蓄積
3つ目は学習データの標準規格による蓄積、です。
現状は各デジタル教材で発生する学習データは、各々のデジタル教材の解釈・形式で保存されています。例えば、教材の利用開始、テスト問題の正誤についても、解釈も違う可能性があり、データ形式もバラバラ。そのため、複数のデジタル教材のデータを横串で分析することが困難です。
そのため、統一化された規格で学習データを蓄積しよう、という感じです。
全体アーキテクチャでは、以下の赤い手書きの囲いの部分。
参照している文書・標準仕様等は以下になります。
教育データ標準（文部科学省）
学習eポータル標準モデル（文部科学省）
Experience API(xAPI)（ADL）
ここでは、xAPI(Experience API)という規格を使って学習データを蓄積していくことになります。xAPIは、ADLという国際標準を作っている団体の規格です。
さらに学習系ソフトウェアと連携していくために、学習eポータル標準モデルに則って、利用者識別子の規定などが追加されることになります。
前述の通り、現状は各デジタル教材でバラバラの解釈・形式で保存されているため、それらを横串で分析しやすくなるようxAPIでは「誰が(主体)」「何を(内容情報)」「どうした(活動情報)」の記述ルールでデータ化していきます。
文部科学省の「教育データ標準」では以下のように書かれています。
これらのxAPIで記載された学習データはLRS(Learning Record Store)と呼ばれるシステムに蓄積されます。うーむ、横文字ばかりで嫌になりますよね。そいうものだとざっくり理解で良いのかも、です。
このxAPIでの標準ですが、まだまだ議論途上ということもあります。文部科学省の教育データ標準でも、デジタル教材関連の活動情報はまだ公表されておらず、デジタル庁の教育関連データのデータ連携の実現に向けた実証調査研究で一部学習アプリの事業者が実装している例があるぐらいです。
今後の部分はまだまだありますが、xAPIで統一化していくことで、学習データの標準規格による蓄積が実現でき、横串での分析がしやすくなります！
4. アクセス制御を前提とした校務系・学習系ネットワークの統合
4つ目はアクセス制御を前提とした校務系・学習系ネットワークの統合、です。
ダッシュボードを構築するには、校務系と学習系からデータを集めて可視化する必要があるのですが、ネットワークが統合していない、特に校務系が閉域網（VPN）にあるとデータを連携するのにも多大なコストかかってしまいます。
それ以外にも、校務処理をする場所が職員室だけになってしまう、などの弊害もあり、文部科学省の「GIGAスクール構想の下での校務DXについて」でも、校務系と学習系のネットワーク統合を進めるよう記載されています。
全体アーキテクチャでは、以下の赤い手書きの囲いの部分。
参照している文書・標準仕様等は以下になります。
教育情報セキュリティポリシーに関するガイドライン（文部科学省）
GIGAスクール構想の下での校務DXについて（文部科学省）
校務系と学習系のネットワークを統合するということは、一般的には閉域網（VPN）で個別構築されている校務系を、いつでも・どこでも利用可能なインターネットアクセス可能なシステムにすることです。
そのためには、これまでのセキュリティ対策を、アクセス制御を前提としたゼロトラスト型のセキュリティに変える必要があります。
手前味噌ですが、ゼロトラストの概要やアクセス制御＝ゼロトラストでのシステム構成の例などは、以前の記事をご覧いただけたらと。
※2021年のバズワードって書いていますが、2023年のバズワードっぽい。予想が早すぎで外れた…。
アクセス制御を前提としたゼロトラスト型のセキュリティとは何か、というと具体的には「統合的な認証・認可機能」を提供していくことです。
例えば「校務支援システムへのアクセスにはID・パスワードに加えて生体認証を求める(多要素認証)」のようなことを行う機能です。
さらに、厳密に本人であることが認証されたうえで、その人の役割や権限に応じたデータへのアクセスになる（認可）されるような機能です。
教育情報セキュリティポリシーに関するガイドラインで示されているシステム構成図だと、以下の赤丸部分です。
「アカウント認証」となっている部分が認証基盤です。校務系・学習系の両方に対する認証機能になっていることが示されています。また、下段の学校の先生端末には「多要素認証等」と記載があり、校務支援システムへのアクセスで多要素認証を求めることが意識されています。
アクセス制御を前提としたゼロトラスト型のセキュリティは、校務支援システムの更改時に導入されることが一般的なはず。なのでダッシュボードを考えている教育委員会の方で、校務支援システムを更改する時期が来たら、この方式を検討に入れることを強くおススメします。一度システムを個別構築で導入してしまったら、通常は5年は動かすことができないと思いますので。
手前味噌ですが、例えば私がプロダクトオーナーをやっている「まなびポケット」でも、この統合認証サービスをオプションとして提供しています。校務支援システムを更改するときには、選択肢の1つとしてもらえると幸いです。
これでアクセス制御を前提とした校務系・学習系ネットワークの統合され、データ連携が容易になります！
5. 各システムでのデータ連携のためのAPI実装
5つ目は各システムでのデータ連携のためのAPI実装です。
ダッシュボードを提供していくためには、データを集める必要があります。各システムから毎回必要なデータをcsvでもらって、みたいなことをやっていると運用が超大変。手動では誤りも発生しやすいですし、リアルタイムに状況を確認することは困難になります。
そういう場合に役に立つのが、API(Application Programming Interface)です。また横文字かって感じですが、簡単にはシステム間でデータをやり取りしたり、連携して動作させるための仕組み、と思っていただけたらと。
全体アーキテクチャでは、以下でたくさんある「API」という四角の部分。
この辺りをしっかり書いている文書はあまり無いのですが、一部言及されているのは以下でしょうか。
GIGAスクール構想の下での校務DXについて（文部科学省）
上記では、以下のような書き方でAPIが登場しています。
ダッシュボード機能を実装する上では、データを蓄積しているシステムとダッシュボード機能を備えたシステムとの間で、API（Application Programming Interface）連携等によってデータをスムーズに連携しうることが重要である。
校務支援システムや学習eポータル、デジタル教材において、APIを外部公開しているサービスは少なく、ここもまだまだこれからという部分です。
一方で、例えばGoogle WorkspaceやMicrosoft 365ではしっかりAPIが利用できるようになっています。
まずはGoogleやMicrosoftなどはAPIで連携しつつ、その他は手動で、みたいな選択もありそうです。
今後、ソフトウェアやシステムを採用する際には「APIの提供を予定しているか、その場合はどのデータまで出せるようにするつもりなのか」は確認しておくと良いかも、です。
データを囲い込んで出さないようにするベンダだった場合、データ連携が困難になってダッシュボードが提供できない、またはそのベンダに頼まないとできない＝ベンダロックインとなってしまう可能性があるためです。
APIをうまく利用することで、手間少なく、リアルタイムに近い形でデータ連携が可能になります！
6. データ基盤＆可視化機能の構築
最後の6つ目はデータ基盤（データを貯めて計算できるようにする場所）＆可視化機能（データをダッシュボードとして可視化する機能）の構築、です。
全体アーキテクチャでは、以下の赤い手書きの囲いの部分。
集めたデータを分析しやすいように蓄積し計算可能な仕組みにするのが「データウェアハウス／データレイク（Data WareHouse／DataLake）」で、それを使ってダッシュボード化するのが「可視化/通知(ダッシュボード)」、という感じです。
以下の文部科学省の文書でも、ダッシュボードについては言及されているのですが、「データウェアハウス／データレイク」についてはあまり記載されないのですよね。
GIGAスクール構想の下での校務DXについて（文部科学省）
構造的には以下のような感じです。
左側のオレンジ色のデータベースが、校務支援システムや各デジタル教材で、それを統合して計算しやすい状態でデータを持つのがデータウェアハウス。そしてそのデータをダッシュボードとして可視化する、という感じです。
文部科学省の文書では、データウェアハウスのようなデータ基盤の言及は無いですが、実際に構築する際には必須になるので気をつけておく必要があります。
そしてようやく登場するダッシュボード。ダッシュボードの構築について、「GIGAスクール構想の下での校務DXについて」では以下のように記載されています。
ダッシュボードの構築方法に関しては、以下のような様々なパターンが想定される。
➢ 校務に関する重要なデータを蓄積している校務支援システムの一機能としてダッシュボードを実装する場合
➢ 児童生徒の学習系システムの入り口としての役割を担う学習ｅポータルの一機能としてのダッシュボードを実装す る場合
➢ 学校設置者がクラウドで提供されるBIツールを用いてダッシュボード機能を実装する場合
①校務支援システムの一機能
②学習eポータル一機能
③個別にBIツールを導入
の3通り。
「教育データ利活用に関する有識者会議」の第12回で紹介されていた渋谷区の例は③。
これまた手前味噌ですが、「教育データ利活用に関する有識者会議」の第9回で私が発表した資料の一部(学力調査と意識調査の掛け合わせ)はダッシュボード的なもので、これは学習eポータルで実現しているので②に該当します。
この辺は、各社どんどん充実させていく部分なのだと思います。
ここまで来て、やっとダッシュボードが実現です。いやー、読んでくださった皆さん、お疲れ様でした。
6つは揃わなくても、やれることからでも。
この6つの要素が全部揃った方が良いですが、そうするといつまでも始められないと思うので、つまみ食い的に取り入れてダッシュボードを実現するのもアリだと思っています。
前半に
「1と4をやって、2と3はできる限りでGoogleやMSのIDとの名寄せも並行させつつ、5はある程度手動でやりつつ、6でダッシュボード化する」みたいなところから現実解（意味不明な人多数だと思いますが、、最後のほうにここも補足しますね）だと思いつつ
みたな書き方をしていましたが、自分が今やるとしたら
校務と学習eポータル間はOneRosterでID統一をやる（1の部分）
LTIの接続はできるデジタル教材のみ（2の部分）
xAPI対応はMEXCBTのみでも仕方なし（3の部分）
校務支援システム更改時にはゼロトラスト化をしておく（4の部分）
GoogleとMicrosoft部分はAPI使って、他はできるアプリのみ（5の部分）
上記を整理して、①～③で良さそうなのを探す
みたいな方法になるのでは、と思います。これを最初に書いた方が良かったですかね。でも、ここまで読まないと、上記の意味も分かり辛いですよね…。なかなか難しいなぁ。
そのうえで、6つの要素を書いたのは「理想形はこういう感じ」というのを理解してもらいたいから、でした。
もし「やれることから」とした場合でも「理想形はこういう感じ」が意識できていると、「では今後導入するアプリはAPIでの連携を視野に」みたいなことを検討できるようになり、回り道や無駄の少ないシステムにしていくことができるのでは、と思ったためです。
ダッシュボードを検討している学校設置者の方は、必要に応じてこのnoteを出入りの事業者に送ってみてもらえたらと。少しは将来を踏まえたシステム設計のタシになるかも、です（笑）
パッと見良さそうの壁を超える
そして何より、この6つの要素はある意味で手順の話でして、肝心のダッシュボードの中身は別の話になります。
いくつかの教育委員会で学校・学級・児童生徒ダッシュボード的なものをつくり始めていますが、本当の意味で先生方が、子どもたちが、教育委員会の方々が、日々の授業に、学習に、業務に役立てるものになっているのか、はまだまだ疑問の余地があるように感じています。
「パッと見良さそう」なダッシュボードを壁を越えて、日々の営みの一部になり、先生方、子どもたち、教育委員会の方々を支援し、行動変容となるようなモノにしていくには、相当な知恵が必要そうです。
それもつくって終わりではなく、日々改善していくことによって目標に近づいていくことになりそうです。
この辺、自分がやっているまなびポケットでもチャレンジを始めているので、秋ごろを目途にご期待に沿えるよう頑張ってみます。
おわりに
できるだけ短く、簡単にしようと、これでもかなり端折って書いていたのですが、、、めちゃくちゃ長くなり、かつ専門用語連発の難しい内容になってしまいました…。
うーむ、範囲が広く深く説明しないといけない内容だったので、1回の記事で書くこと自体が無茶だったようです。
6つの要素を1回ずつで書いたほうが良かったのかも。いや、それだと一気に読めないし、、なかなか難しいですね…。
次回は全体アーキテクチャの残りの部分をやるか、他の話題にするか。
残っているのは
ガバメントクラウドを用いた行政系システム
行政・福祉システムとの連携によるプッシュ型支援
児童生徒(保護者)個人でのデータ管理（パーソナルデータストア）
データ活用者向けのセキュアな連携（データ連携基盤）
の4つの要素か。うーむ、これもそれぞれ1回ずつ書くぐらい重い…。
どこかでしっかり書いておくようにしたいと思います。
ちょっと長すぎてしまっているので、今回はこの辺で。
ではまた！
この記事が気に入ったらサポートをしてみませんか？