Institutional Research in Practice
教学 IR データ基盤をつくる
東京都市大学で 2025 年度から構築している、学籍・成績・出席・講義のデータを 1 か所に集める仕組みの記録です。 中退予測の研究を学内の運用につなぐには、研究者の手元ではなく大学の中にデータの土台が要ります。その土台をどう作ったかを、専門外の方にも分かるように書きました。
なぜ作ったか
大学には、入試・教務・学生支援・キャリアといった部署ごとに別々のシステムがあります。それぞれが独自の形式でデータを持っているため、「学科ごとに出席率と成績を並べて見たい」という部署をまたぐ問いに答えるだけで、何日もかかっていました。
中退予測の研究も同じ壁に当たります。分析のたびに各部署からファイルを集め、列名を揃え、欠けを埋める作業を研究者が手作業でやっていては、予測を毎学期の支援に返す循環は回りません。
ひとことで言うと、学内に散らばっていたデータを、クラウドのデータ基盤の上に自動で集め、分析にすぐ使える形に整える仕組みをつくりました。退学者削減、学修成果の可視化、アセスメントという 3 つの取り組みを支える共通の土台です。
全体像
データがどこから来て、どこへ行くのか。流れは 3 段階です。
もとのシステム
教務システムと出席確認システム。学籍・成績・講義は月次、出席は日次で出力する。
受け渡し場所
決められた置き場にファイルを置く。人が触るのはここまで。
データ基盤（Microsoft Fabric）
自動で受け取り、生のまま貯める → 点検して整える → 分析に使える形にする、の 3 層を通す。
- Bronze 生のまま貯める
- Silver 点検して整える
- Gold 分析に使える形
使う
用途と相手に応じた複数のダッシュボード。今後は早期警戒の通知や学生向けアプリへ。
自動実行は、学籍・成績・講義が毎月 1 回、出席が毎日 1 回。人が操作しなくても決まった時刻に動きます。
集めたデータ
2026 年度までに取り込みの経路を整えたのは 4 種類です。
| データ | 性質 | 更新 | これで分かること（例） |
|---|---|---|---|
| 学生情報 | 台帳（マスタ） | 月次・差分 | 学科別の在籍者数、学年構成 |
| 成績情報 | 記録（トランザクション） | 月次・差分 | 成績の分布、取得単位数、GPA |
| 出席情報 | 記録（トランザクション） | 日次・差分 | 出席率の推移、欠席が増えた学生の把握 |
| 講義情報 | 台帳（マスタ） | 月次・差分 | 講義の一覧、開講状況 |
「台帳」はあまり変わらない一覧、「記録」は日々増えていくデータです。差分更新は変わったところだけを反映するやり方で、処理が速く履歴も保てます。出席だけを日次にしたのは、中退の予兆がいちばん早く現れるのが出欠だからです。
3 層で整える ― なぜ 3 回も置き換えるのか
基盤の中では、データを Bronze → Silver → Gold の 3 層に順番に流します。倉庫にたとえると分かりやすくなります。
| 層 | 倉庫でいうと | やること |
|---|---|---|
| Bronze（生） | 届いた荷物を開けずに置く荷受け場 | もとのファイルをそのまま貯める |
| Silver（整備済み） | 中身を検品し、不良品をよける作業場 | 点検して正しい行だけを残す |
| Gold（使う） | すぐ売れる形で並べた陳列棚 | 分析に使える形に整える |
なぜ分けるのか。もとのデータを直接いじってしまうと、間違えたときに元に戻せません。層を分けておけば、もとのファイルは Bronze にそのまま残り、やり直しがいつでもできます。不備のあるデータをどこで除いたのかも追えます。
もうひとつの要が列名の対応表です。「学籍番号」という日本語の列名を英語の名前に置き換える一覧表を Excel で持ち、処理はその表を見て動きます。もとのシステムの列名が変わったときに、プログラムではなく Excel を直せば済むようにしてあります。
品質を守る
集めたデータをそのまま使うと、抜けや誤りが混じったまま分析してしまいます。Silver 層で 4 つの観点から点検し、条件を満たさない行だけをよけます。
- 必須違反: 学籍番号や氏名が空欄
- 一意性違反: 同じ学籍番号が重複
- 論理違反: 得点が 0〜100 の範囲を外れる
- 参照違反: 成績に出てくる学生が、学生の台帳に存在しない
ここで学んだことが一つあります。当初は 1 行でも不備があるとファイルごと弾く仕様にしていました。すると、得点が空欄になる認定科目が原因で、成績データが 1 件も通らない状態になりました。不備のある行だけを除き、正常な行は通す方式に改めて解決しています。品質ルールは厳しければよいわけではなく、データの実態を見て決める必要があります。
出口は一つではない
基盤を作るときに決めたことの一つが、可視化の道具を一つに縛らないことでした。データを 1 か所にまとめる目的は、全員に同じ画面を使わせることではありません。見る人も、問いの立て方も違うからです。
- 定例で見る指標は、更新が自動で走るダッシュボードに置く。毎月同じ形で見たい在籍状況や出席率がこれにあたります。
- 探索的な分析は、分析者が手を動かしやすいツールで行う。仮説を立てて切り口を変えながら見る場面では、作り込んだ画面より自由度が要ります。
- 学生や教員に返す画面は、業務システムやアプリの側に埋め込む。IR の画面を見に来てもらうのではなく、日常の動線の中に置くほうが届きます。
- 授業で扱うときは、学生が学ぶ道具に合わせる。データサイエンス教育で使う可視化ツールは、実務で使うものと同じである必要はありません。
こうした使い分けができるのは、Gold 層に整えたデータが特定のツール向けの形になっていないからです。どの道具から見ても同じ数字になることが、基盤を分けて作った一番の利点だと考えています。逆に、ツールごとに集計の仕方が違って数字が食い違うと、議論はデータの正しさの話に戻ってしまいます。
誰が何を見られるか
学生の氏名や成績を含むため、見られる範囲を役割ごとに分ける設計を最初から組み込みました。
- 作業部屋を 3 つに分ける。つくる場所（開発）、動かす場所（本番）、見せる場所（公開）。開発中のものが利用者の目に触れません。
- 権限は個人ではなくグループに付ける。大学の既存アカウント基盤のグループを使うので、新しい ID を配る必要がなく、異動や卒業のたびに一人ずつ設定し直す必要もありません。
- 同じ画面でも人によって見える行を変える。行レベルセキュリティという仕組みで、サインインした本人が誰かを条件に表示する行を絞れます。学生には自分の分だけ、教員には担当分だけ、学部長には学部全体、という見せ分けを 1 つの画面で実現できることを、実データで確認しました。
役割は 5 区分です。システム管理者、データ管理者、データ開発者、データ分析者、そしてデータ利用者。利用者はさらに教職員・学生・保護者に分かれ、決められた範囲だけを参照します。
研究との接続
この基盤は、研究の地図で言えば「土台」にあたります。出席と成績が毎日・毎月自動で揃うことで、中退リスクの予測を学期の途中で繰り返し更新でき、支援の対象を早い時期に学生支援の部門へ渡せます。介入の効果を測って次の予測に返す循環は、手作業のデータ収集の上では回りませんでした。
関連する論文・報告
これから
| 分類 | 内容 |
|---|---|
| データを広げる | 進路、外部アセスメント、担任、入試、授業評価アンケート、各種調査 |
| 指標の定義を作る | 出席率、GPA、在籍者の絞り込みなどを、誰が集計しても同じ値になる共通定義として Gold 層に置く |
| 使う画面を作る | 退学防止のダッシュボードと通知、学生自身が自分の学びを振り返る画面、学科・学部の分析 |
| 運用を固める | 失敗時の通知、問い合わせ窓口、保守の体制。基盤は作って終わりではなく、動かし続ける仕事が残る |
他大学へのヒント
- 最初の 4 種類で止める。学籍・成績・出席・講義があれば、中退防止と学修成果の可視化の大半は始められます。全部署のデータを最初から集めようとすると終わりません。
- もとのデータは触らない。層を分けて、やり直しができる構造にしておくと、後から要件が変わっても壊れません。
- 列名の対応は表で持つ。プログラムに埋め込まず、事務職員が直せる場所に置くと、運用が属人化しません。
- 権限設計を後回しにしない。個人情報を扱う以上、見せ分けの仕組みは最初に決めます。既存のアカウント基盤に乗ると、ID もパスワードも増えません。
- 品質ルールは実データで調整する。厳しすぎるチェックは 1 件も通さなくなります。行単位で除く方式が現実的です。
- 可視化の道具は一つに決めない。整えるところまでを共通にしておけば、見せ方は相手ごとに選べます。どの道具から見ても同じ数字になることのほうが大事です。
同様の基盤づくりや、研究と実務の接続についての相談は、連絡先からどうぞ。業績の全体は researchmap にあります。