教育ダッシュボードのつくりかた④ ～どのシステムでダッシュボードをつくる？～
第1回、第2回、第3回に続き「教育ダッシュボードのつくりかた」の第4回目です。今回で最終回。
これまではダッシュボードでどんなデータを取り扱うのか、それをどう表現するのか、を書いてきました。
最終回の4回目は、技術やシステム構成について書いてみたいと思います。
この記事は主にまなびポケットのダッシュボード機能の開発過程で得られた知見・考えたことなどを公表する形で書いています。
この辺り、12/20に開催されるウェビナーでも詳細話します。もしご意見・疑問・苦情などなどあれば、遠慮なくその場でぶつけていただけたらと。
前回のおさらい
毎度ですが、前回（第3回）のおさらいを簡単に。
GIGAスクール以降で中心的役割になるにもかかわらず、多くの学校が効果的にダッシュボードを使用していないという課題について論じています。
理由には、検討段階での徹底的な調査の不足、データ統合、表現、デザインの問題が含まれます。記事では、クイックな状況確認とより深い分析といった異なるユーザー体験を区別することの重要性を強調しており、これを怠ると混乱を招き、使いにくいサービスになる恐れがあると指摘しています。
さらに、データの重要性だけでなく更新頻度にも焦点を当てること、提示されるデータが具体的で実用的であることの必要性など、追加のデザイン考慮事項にも言及しています。
次の記事では、これらの側面をシステムの観点から探求する予定です。
といのがChatGPTによる要約でした。う感じ。
ということで、最終回ではシステムの観点から探究してみます！
ダッシュボードは何で構築するのか？
ではダッシュボードってどんなシステムでつくるものなのか。
文部科学省の「GIGAスクール構想の下での校務DXについて」では以下のように書いてあります。
ダッシュボードの構築方法に関しては、以下のような様々なパターンが想定される。
➢ 校務に関する重要なデータを蓄積している校務支援システムの一機能としてダッシュボードを実装する場合
➢ 児童生徒の学習系システムの入り口としての役割を担う学習ｅポータルの一機能としてのダッシュボードを実装す る場合
➢ 学校設置者がクラウドで提供されるBIツールを用いてダッシュボード機能を実装する場合
「①校務支援システムの拡張」「②学習eポータルの拡張」「③BIツールでの実装」の3パターン。
それぞれの事例を見てましょう。
3つのパターンの事例を紹介
①の校務支援システムの拡張のパターンの例としては、EDUCOMさんが教育委員会向けのダッシュボードのニュースリリースをしていたりします。
その他でも、文部科学省「次世代の校務デジタル化推進実証事業」にて、校務支援システムを提供する各社がダッシュボードの実証を実施中です。
②の学習eポータルの拡張のパターンの例としては、手前味噌ですが私がプロダクトオーナーを務めているまなびポケットが、ダッシュボード機能をリリースしています。
他でもNECさんのOpen Platform for EducationがMEXCBT連携ダッシュボード機能を提供していたり、コニカミノルタさんが学力調査の分析サービスを提供していたり。
③のBIツールでの実装の例だと、先行事例として有名な渋谷区やつくば市がMicrosoft PowerBIで構築しているようですし、奈良市はGoogleのLooker Studioで構築しているようです。
自社サービスの競合をどんどん紹介すんなって感じですが、選択肢があることは良いこと＝競争があるということは利用者にとっての価値が高まるので、学校現場としては歓迎すべきことなんだと思っていますー。
ではどの選択肢が良いのか。個人的にはこの3パターンの差というより、個々のサービスの差を見た方が良さそう、と思っています。
まずは小さく始めるのであれば、既存で利用している校務支援システムや学習eポータルの事業者に相談するのも良いと思いますし、教育委員会内で詳しい方もいるので自らBIツールをいじりながら試してみる、というのも良いと思います。
ただ、検討段階から教育委員会側で考慮しておくべきことがいくつかあるので、それを記載してみます。
①データの囲い込みが起きないようにする
1つ目はデータの囲い込みが行いようにしていくこと。
ダッシュボードはデータを統合して分析・可視化し、児童生徒や先生、教育委員会や保護者に対しフィードバックしていく機能です。
そのため、当たり前ですがデータを集めることができなければ（集めない方法もあるはありますが少なくともデータにアクセスできなければ）、ダッシュボードをつくることはできません。
今使っているアプリケーションは、多くがデータを外部に提供するように作られていない。でもそうなっているのは、外部提供の要求を誰もしていなから。
なので、取得したいデータを保持するアプリケーションについては、今後のデータ連携に関する見通しを聞き、その計画がないと言われた場合でも次回の契約更新タイミングを見据えて、外部へのデータ提供に関する要求をしておくことをお勧めします。
そしてデータの提供は自動化＝API(Application Programming Interface)を前提にしていることも重要です。
※専門用語が増えて申し訳ないです…。
文部科学省「GIGAスクール構想の下での校務DXについて」においても、以下のように記載されています。
ダッシュボード機能を実装する上では、データを蓄積して いるシステムとダッシュボード機能を備えたシステムとの間で、API（Application Programming Interface）連携※１等に よってデータをスムーズに連携しうることが重要である。
※１ 一定の手続きに従い、システム間でデータ等のやり取りを自動的に行う連携方法。
要は、システム間で自動でデータをやりとりする仕組みを具備しているか。データをCSVで引っこ抜いて、別システムに入力して、なんてのが必須だと現場が持ちません。出欠情報なんて毎日のことなので、手動は現実的ではなく、システム間の自動連携が必須になってくるためです。
この辺に難色を示す場合は、契約更新時の条件にしていくことなどを伝えていくことも視野に、しっかり交渉していくことが必要です。
もし「データを自社で囲い込みしよう」と考えている相手であれば、データを集めることができなくなります。
そうなるとダッシュボードへの道が閉ざされると思っても過言ではないので。
②IDの統合を見据える
2つ目が児童生徒のID統合です。
ダッシュボードを考えるうえで頭が痛い問題が、データの名寄せ問題。
AシステムとBシステムのデータの「誰」を示す識別子がバラバラになっていて、それを名寄せする作業がものすごく大変。
名寄せの辛みが見える報告書として、デジタル庁が昨年度行った「こどもに関する各種データの連携による支援実証事業」だとこんな記載が。
黄色でマーカーしている2, 3, 5は、教育委員会の中の人力での名寄せ作業が見えます（類型1は同様システム内なので名寄せ不要、4はマイナポータルで市民が名寄せしたので不要、ということで除外されている）。
児童生徒数多い自治体なら、この処理だけで専門職員何人必要なの（そして人力だと必ずミスも起きる）って話なので、ここも絶対抑えておくべきポイントです。
じゃあどんな形でID寄せていくのかですが、国の標準仕様や自治体での導入状況を踏まえると、まずは「宛名番号」「UUID」「Google/MSでのID」の3つに寄せていくことが妥当では、と思っています。
ざっと図にすると以下のような感じです。
この辺りをちゃんと説明しようとすると、これだけでも1回分になってしまいそうなので、この構造や全体のアーキテクチャについて詳しく見てみたいという方は、以下の回もお読みいただけたらと。
多くの自治体の立場なら、超ざっくりの直近判断は「行政系（宛名番号）は一旦置いておいて、Google/MSは学習eポータルとSSOしていれば学習eポータル側でUUIDと名寄せ可能。あとは校務と学習系をID連携させる見通しを立てておこう」という感じでしょうか。
校務系と学習系の名簿連携を実現しつつ、学習系は徐々にUUID（標準モデル）に揃えていく感じです。
③校務はSaaS（パブリッククラウド）化する
3つ目は校務支援システムもSaaS（パブリッククラウド）化です。
これも前述している文部科学省「GIGAスクール構想の下での校務DXについて」でも言及され、「校務系・学習系ネットワークの統合」として記載されています。
校務支援システムをSaaS化しておかないと、校務に関するデータを職員室以外で使うのが困難になるし、前述したAPIも基本的には外部ネットワークと接続して自動連携するものなので難しくなります。
現行ではほぼ全ての教育委員会がパブリッククラウド化はしていない状態ですが、次のシステム更新（契約更改）のタイミングでは必ずSaaS（パブリッククラウド化）するべきです。
それってどんなシステム構成にするべきか？という声がきそうですが、10月の「第7回 教育セミナー in おかやま」に一般社団法人教育ICT政策支援機構の谷さんと一緒に登壇した際に、ざっくりのシステム構成を描いたのでこちらに貼っておきます。
※ちなみに当日の資料はこちらから（P21以降が稲田のパートです）
システムでの考慮事項は他にもありますが、、
他にも、ダッシュボードの手前でデータを貯める場所（データウェアハウスを設計・構築しなきゃ）とか、データの正規化作業（データの欠損や外れ値などを前処理する）とか、色々諸々あったりしますが、、、
そもそもダッシュボードの構築って全ての教育委員会の皆さんが行うのではなく、事業者に委託し、協議・連携しながら進めていくものだと思いますので、あまり細かい部分はここでは言及しないようにしたいと思います（長くなりすぎると自分も読み手も辛いと思いますので）。
実は以前にも「ダッシュボードに必要な6つの要素」というのを詳しく解説している回もあるので、より細かく前提などを知りたい方はお読みいただけたらと。
※この回は長文かつ専門用語が多くて恐縮ですが、、
おわりに…まなびポケットのダッシュボードのこと
4回と長い回でしたが、これで「教育ダッシュボードのつくりかた」は一旦連載終了とさせていただきたいと思います。
システム面については、事業者に任せる面が多い部分なので端折っちゃいました。もし「この辺りをもう少し解説してよ」みたいなのあれば教えていただけたらと。
また、今回は先生や教育委員会向けのフィードバックに絞っているので、児童生徒や保護者へのフィードバックについては、どこか別でまた書きたいと思っています。
児童生徒や保護者向けって、いわゆるダッシュボードが適切じゃないと思っており、折を見て書かせていただけたらと。
そして最後に宣伝をしておくと、、、
今回の連載って「まなびポケットのダッシュボード機能の開発過程で得られた知見・考えたことを書いた」と言っていましたが、つまりはこの4回で言及したことは、全てまなびポケットのダッシュボードは考慮されているってことです。
トップダウンとボトムアップでのデータの必要性を検討しまくり、使われるダッシュボードとなるよう体験設計をしっかりデザインし、システムとしては国の仕様などを理解し、将来的な拡張や相互運用を見据えた設計になっています。
来月リリースするものは対象データが少ないので、まだまだお試しの域をでないのが実態ですが、今後も数か月ごとにアップデートを行っていきます。来年度中に、どの自治体・学校でも必ず価値を実感していただけるものにしていきますので、ご期待いただけたらと。
この辺り、繰り返しになりますが12/20に開催されるウェビナーでも話しますので、このnoteの疑問・苦情など含め、遠慮なくその場でぶつけていただけたらと。
では大分長くなってしまったので、今回はこの辺りで。
ではまたー。