法人統合がもたらす
大学情報環境のリノベーション
東海国立大学機構 名古屋大学 青木学聡
2023.8.18 大学ICT推進協議会
教育技術開発部会 第17回研究会

1

自己紹介
• 青木学聡(あおき たかあき)https://orcid.org/0000-0002-5926-4903• 名古屋大学 情報連携推進本部 情報戦略室
兼 東海国立大学機構 情報連携統括本部 情報戦略室
兼 東海国立大学機構 デジタルユニバーシティ室• 今の専門大学情報基盤の戦略＞設計＞導入＞運用

2

自己紹介(ちょっと/ずいぶん昔)• 2016.3～2020.3 京都大学 情報環境機構
研究支援部門として, 全学的な情報環境の設計・導入・運用• 汎用コンピュータシステム(2016.12～2021.8)• 学内データセンター、ハウジングサービス• 全学レベルの研究データマネジメント環境の整備• 大学における研究者情報環境の整備(教員DB)• 2007.2～2016.1 京都大学 工学研究科附属情報センター
研究科レベルの情報インフラ整備• 情報セキュリティポリシー実装• 論文データベース• 入試・学部成績データ分析基盤• 研究データ保存システムの検討プロトタイプ(2015.12～)3

名古屋大学・東海国立大学機構のDX

2020.4 東海国立大学機構発足
東海地域の岐阜大学 Since 1949～
強み

高度専門職業人を育て、グローカルに発展
岐阜師範学校や岐阜高等農林学校など の教育機関が変遷・研究統合し 、学芸学部と 農学部で設立。1952年に県立大学工学部、1964年に 県立医科大学を 移管合併して 工学部と名古屋大学

Since 1939～

構造変革を

2020

医学部を 設置。2004年に国立大学法人岐阜大学となる 。

東海国立大学機構
設立

学術・産業

人・教 育

リードする

自由闊達な学風のもと、世界屈指の知的成果を産み出す。
名古屋藩仮病院・仮医学校を起源とし、最後の帝国大学として開学。1949年、6学部を置いて新制大学に。2018年、世界最高水準の教育研究活動の展開が見込まれる大学として「指定国立大学法人」に指定される。

地域創生

新しい大学モデル

デジタルを活用した、新しい大学の役割の模索

「東海機構」=「大学管理・運営を提供するサービサー」
顧客満足度を高めるため「管理・運営」サービスの• 高品質化
• ユニバーサル化のミッションが明確に

地域社会

岐大向け
•
教育
•研究
支援サービス

岐大独自の
• 教育
• 研究
価値創出・提供

学生教育

教員 医師 研究者

学術研究
名大向け
•
教育
•
研究
支援サービス

名大独自の
• 教育
• 研究
価値創出・提供
教員 医師 研究者

産業振興

国際貢献
6

東海国立大学機構におけるDXの位置づけ• 2020年4月、岐阜大学・名古屋大学が法人統合、機構発足• 規程・運営組織に加え、情報システムの統合も開始(人事給与、財務会計、認証基盤、グループウェア・・・)• DXを単なる「ICT利用による効率化」にとどめず、「サイバー空間における大学機能の拡大」につなげる• 学外のステークホルダも、大学の知と人のプラットフォームを最大限活用できる、「デジタルユニバーシティ構想」を役員会決定

東海機構100万人デジタルユニバーシティ構想

DU構想基本計画におけるサービス・システム
領 域

A.ポリシー

4領域

DU室にて策定し、システム間の連携を確立

9サービス

導入検討チームを組成し、システム導入する

デジタル学修支援

学修環境の情報化

1. 教育・学生支援

コミュニティリレーション

デジタル研究支援2-2.

研究データ管理支援

研究データプラットフォームによる透明化

今後整備予定※3-1.

アカデミック・トレジャー

学術知に基づく共創環境の提供

3-2.

地域人材育成地域発展に向けた教育プログラムの開発

4-1.

4. 管理運営

機構運営のデジタル化（機構内DX）

デジタルによる部署間連携、多様な働き方

4-2.

機構経営支援（機構IR）

機構全体を統合したデータ基盤の提供

デジタル学修システム（機構LMS）

2

デジタルコンテンツ制作

3

学生ステータスシステム

4

ラーニングアナリティクス支援5

学生コミュニティシステム

6

アルムナイネットワークマネジメント

7

デジタル研究アシスタント

8

研究データガバナンス（研究公正含）9

研究データ利活用（コアファシリティ含）

10 協創ポータル
11 知財・研究成果活用システム
12 エクステンションポータル

13 ファシリティマネジメント
14 機構内コミュニケーション
15 戦略的統合データ基盤

１ ２ ３ ４１

機構内情報システム基盤

2-1.

学術研究マネジメントの支援機能

1

総合サービス基盤 （ＭＳ３６５）

1-3.

卒業生・関係者との生涯価値（LTV）を高める

15システム

決済サービス

DU運営ガイドライン

対策/IT-BCP

システム間の相互接続指針

情報セキュリティ

3. 社会連携

ラーニングアナリティクス

学修成果の収集・分析・評価のデジタル化（設計ポリシー）
UI/UX

2. 学術研究

1-2.

人材育成

機構内の人材育成

1-1.

C.

B.基盤

機構内外に向けた統合認証サービス

１ ２ ３ ４サービス

DU構想基本計画におけるサービス・システム
領 域

A.ポリシー

4領域

DU室にて策定し、システム間の連携を確立

9サービス

導入検討チームを組成し、システム導入する

デジタル学修支援

学修環境の情報化

1. 教育・
学生支援

コミュニティリレーション

デジタル研究支援2-2.

研究データ管理支援

研究データプラットフォームによる透明化

今後整備予定※3-1.

アカデミック・トレジャー

学術知に基づく共創環境の提供

3-2.

地域人材育成地域発展に向けた教育プログラムの開発

4-1.

4. 管理運営

機構運営のデジタル化（機構内DX）

デジタルによる部署間連携、多様な働き方

4-2.

機構経営支援（機構IR）

機構全体を統合したデータ基盤の提供

デジタル学修システム（機構LMS）

2

デジタルコンテンツ制作

3

学生ステータスシステム4

ラーニングアナリティクス支援5

学生コミュニティシステム

6

アルムナイネットワークマネジメント

7

デジタル研究アシスタント

8

研究データガバナンス（研究公正含）9

研究データ利活用（コアファシリティ含）

10 協創ポータル
11 知財・研究成果活用システム

１ ２ ３ ４１

12 エクステンションポータル

13 ファシリティマネジメント
14 機構内コミュニケーション
15 戦略的統合データ基盤

2023.4～

機構内情報システム基盤

2-1.

学術研究マネジメントの支援機能

1

総合サービス基盤 （ＭＳ３６５）

1-3.

卒業生・関係者との生涯価値（LTV）を高める

15システム2023.4～

決済サービス

DU運営ガイドライン

対策/IT-BCP

システム間の相互接続指針

情報セキュリティ

3. 社会連携

ラーニングアナリティクス

学修成果の収集・分析・評価のデジタル化（設計ポリシー）
UI/UX

2. 学術研究

1-2.

人材育成

機構内の人材育成

1-1.

C.

B.基盤

機構内外に向けた統合認証サービス

１ ２ ３ ４サービス

(情報システムの)「統合」• (2019.8) 人事給与システム、財務会計システム統合のための共通サーバー基盤導入 (統一システムは 2021年度稼働)• (2021.7～) MS365 共同調達開始• (2021.7～) 統合認証システム• (2023.4～) 機構LMS

このあたりになると「統合ありき」ではなく「時代・技術に即した新しい情報サービス」• (構想中) 施設管理、IR、学生ポートフォリオ、卒業生管理・・・

どうやって作ってく・・・
クラウドサービス

クラウドサービス

クラウドサービス

業務システム業務システム業務システムプライベートクラウド基盤

プライベートクラウド基盤

プライベートクラウド基盤

ネットワークネットワークネットワーク12

機構統合認証13

きっかけは「機構M365 一括調達」
2020.4名古屋大
nagoya-u.jp

2021.42022.72021.7

生協代行による受益者負担(A3)A1のみ

2023.42023.7

利用凍結

終了時期を見極め

全員にA1ライセンス

Officeライセンス, Teams, OneDrive移行

東海国立大学機構
thers.ac.jp

2021.7
一括調達
岐阜大
gifu-u.ac.jp

岐阜大↔MSとの直接契約(A3)

機構契約
A3ライセンス(名大教職員分+学生特典)

岐大先行利用者向けAAD P1

更新

A3ライ
センス
(全機構構成員+学生特典)

A3ライセンス(全機構構成員+学生特典)+A5部分導入

Officeライセンス, Teams, OneDrive移行

機構契約
A3ライセンス(岐大教職員分+学生特典)

A1のみ

両大学の統合認証システム(～2021.7)
CAS
学務
人給

利用者管理システム(偶々)同じ製品だが、カスタマイズ、デー
タの意味付けに差異

LDAP
SAML
(Shibboleth)Azure AD

人給
学務
附属校
学務

利用者管理システム

SAML(SAME)LDAP
Azure AD• IDライフサイクル• LDAPスキーマ• LDAPデータ意味付け
ほとんどすべて異なる

機構M365導入(2021.7~2022.4)
機構アカウント
通知システム

CAS
学務
人給利用者管理システム

LDAP
A3ライセンス切り替え
9末まで(3か月以内)!!

SAML(Shibboleth)Azure AD

M365

Azure ADM365

名大側で名寄せ2021年6月稼働!!

人給機構アカウント&メール付番DB(名大教員作成)

人給
学務
附属校
学務

利用者管理
システム

2021年7月稼働!!

SAML(SAME)LDAP
Azure AD

M365

学務

利用者データ移行後停止予定
利用者管理
システム

附属校
校務

SAML
(Shibboleth)Shibboleth
バックエンド認証を変更

SAML(Shibboleth)M365

機構アカウント&メール付番DB(学外ベンダが構築)

2023.4~

Azure AD

附属校
校務

名大学生

M365
SAML
(Shibboleth)

機構職員

LDAP
2023.4~

学務

名大教員

名大附属校

2023.4~

人給LDAP

Azure AD2021.7~2021.7~

CAS

岐大教員
利用者管理
システム

SAML
(SAME)

岐大学生
岐大附属校

LDAP
Azure AD

M365

機構アカウント(UPN)
機構メールアドレス(EXOのメールエイリアス)

機構統合認証(2022.5~)

CAS
LDAP

学務

SAML
(Shibboleth)

附属校
校務

名大学生

2021.7~

名大附属校2023.4~人給2021.7~

機構アカウント&メール付番DB(学外ベンダが構築)

2023.4~

名大教員

Azure AD

MS365
SAML
(Shibboleth)

機構職員

LDAP
2023.4~

岐大教員
岐大学生

学務
附属校
校務

SAML
(Shibboleth)

岐大附属校

機構アカウント(UPN)
機構メールアドレス(EXOのメールエイリアス)

機構統合認証(2023.8~)

機構統合認証システム構成図

東海国立大学機構
人事給与システム

機構統合
認証
利用者管理
DB

岐阜大学
学務システム

機構情報システム群

東海国立大学機構統合認証システム

利用者情報提供元

岐阜大学附属学校
校務システムクラウドサービスユーザ管理システム(2021.7構築、稼働)

利用者情報配信システム(LDAP Manager)

Azure AD連携

thres.ac.jp
Azure AD
SSO委譲

名古屋大学
学務システム名古屋大学附属学校
校務システム

利用者情報
メタディレ
クトリ

学認対応 機構
SAML IdP
機構統合LDAP

個別利用申請付番済
機構ID・機構アカウント
機構メールアドレス
書き戻し

アカウント管理データ
アカウント管理データ
新規アカウントデータ

名古屋大学統合認証システム
岐阜大学大学統合認証システム
機構アカウント管理窓口

SP1
SP2
SP3
SP4
:
名大SAML IdP
岐大SAML IdPID体系の整理
情報源の属性を紐づけ
個人番号
氏名・所属等機構人給システム
THF:(職員番号)sato.taro.2b@f.mail.nagoya-u.ac.jp
メールボックス

改姓した

yamada.taro.1a@f.mail.nagoya-u.ac.jp

bc.12d.3456@f.thers.ac.jp

yamada.taro.1a@mail.f.thers.ac.jp

人給にいる(RA, TAは除く)

yamada.taro.1a@f.gifu-u.ac.jp

異動した(予約済み)

ab1234567
メールボックス

学務にいる•

機構メール

機構アカウント
機構ID

利用者情報源利用者が機構構成員であることを保証・管理する台帳
それぞれの台帳では別個に個人番号で管理台帳の種別を示すプレフィ
クスを導入

社会人大学院生になった

情報源の属性を紐づけ
個人番号
氏名・所属等

名大学務システム
NUS:(学籍番号)•yamada.taro.3c@s.mail.nagoya-u.ac.jp

gh.78j.9012@s.thers.ac.jp

岐大学務システム
GUS:(学籍番号)•••名寄せした個人単位に付番
名大IDと互換
認証には原則使わない

•
•
•
•
•

情報システムで認証、利用者識別のアカウント
本人確認台帳(人給・学務)に従い付番一個人に複数発行されることもローカルパート(@より前)だけで一意性を担保
ただ、学生・職員・etcの識別は必要、との要求により、身分属性がドメインに付加(f:教職員, s:学生, p:附属校生徒・児童, a:その他一時利用) 。

Azure AD または Shibboleth••••••

機構アカウントに紐づき、本人の存在と到達性を保証する機構公式メールアドレス(にする予定)
識別性を高めるため「姓名情報」「所属情報」を含む。
改姓名時、本人の希望により姓名情報を変更可能
ローカルパートは、所属が変わっても一定(台帳が異なると別のsuffixがつく)
一度割り当てられたメールアドレスは異動、改姓名後もエイリアスとして利用可能
Teamsでの「連絡先」

MS365 Outlook Exchange名大から見た「統合認証ID変更」• 名大ID• ab1234567 (英字2 + 数字7)
• 「生涯ID」として利用• 学生⇔職員と身分が変わっても同じ• 卒業・離籍しても有効• 機構アカウント• ab.12c.3456@f.thers.ac.jp(英字2 . 数字2 英字１ . 数字4 @ 身分)• 在籍期間のみ有効• 学生⇔職員と身分毎に発行• 卒業・離籍して一定期間たつと再発行• 見た目、ブランディングの問題(複数のIDを間違えない)• 「○○ID」→「○○アカウント」• IDを構成する文字列の組み合わせ• 運用ポリシーの問題• 在籍者/離籍者の明確な区分け• ID管理==個人情報を保有・管理する• これまでの名寄せDBは残したい• 名大ID運用の(当面の)継続• 高度なステークホルダ管理(真のCustomer RelationshipManagement)
への足掛かり21

認証システム切り替え作業• 大規模基幹システムの切り替え• 人給・財務会計・学務(両大学) は2023年度内に切り替え• 岐阜大学• 多くの業務システム群の更新に合わせて一斉切替(2023.8)• 名古屋大学• 名大統合認証に接続するシステム数： 120以上• レガシーなシステムの棚卸もかねて調査(取得できるLDAP属性の見直しも併せて実施)• 40システムは移行せずサービス停止• 約20システムが移行済み• 名大統合認証は2025.3に停止の予定22得られた価値は?
• Azure ADによる認証の利便性向上• 新しい認証技術への迅速な対応(多要素認証, FIDO2, ・・・)

• TCOに見合った情報ガバナンス強化• 監査機能• 端末管理• 統合された「機構事務組織」への対応• M365でのTeams、業務組織単位での共有メール• (名大) 「大学公式のメール通知経路」の確立• 今まで「全学メール」「部局ドメインメール」が混在
23

機構LMS24

経緯・背景• 2020年度末「デジタルを活用した大学・高専教育高度化プラン(Plus-DX)」
事業採択を契機に実現へ
LMSプラットフォーム
Sakai 20.3

2023.9

岐大LMS AIMS（Canvas）
移行難易度、自動化の見極め

名古屋大学LMSNUCT (Sakai 12.6)

名大学務
岐大学務

機構LMS

京都大学オープンソース
LMS (Open PandA)

機構LMS (Sakai 20)

機構LMS（単体機能構築）
移行難易度、自動化の見極め自動・手動移行(供用開始)（システム間連携）
機構統合認証LA・Teams

自動・手動移行

名大LMS NUCT（Sakai 12）

PLUS-DX
2021.42022.42023.425

利用者から見た「LMS変更」• 岐阜大学: CANVAS から Sakai への全面的なシステム乗り換え• 教員各自によるコンテンツ移行を全学的に依頼(2023.2)• (2021年度内)機械的な移行支援を検討、しかし手順が煩雑となり断念• 岐大執行部には2022年度当初より非公式に相談• LMS利用支援スタッフを配置、大規模移行の支援(2023.2-3、約100件)• 名古屋大学: Sakai(v12) から Sakai (v20) へのバージョンアップ
• 教員各自によるコンテンツ移行作業を全学的に依頼(2023.2)• 「最終的には教員がコンテンツをチェックし、責任を持つ必要がある」の原則
26

運用・利用者支援体制• 「岐大－名大」×「教育－情報」 4者間の協業体制が必要に• 「LMS=大学教育インフラ」として、将来構想は「教育サイド主導」で情報はシステム運用支援に• 2023年度現在、サービス主体を情報→教育に移管中

27

学務システムとの関係• 人の識別: 機構統合認証システム上では• 岐大学生: GUS:「学籍番号」• 名大学生: NUS:「学籍番号」• 講義コード(コースサイトID)• g_, n_ のプレフィクスをつけて識別• 岐大・名大共同開講講義は?
• 現状では、• 岐大・名大それぞれの講義コードに沿ってコースサイトが作成• 履修者登録のコースサイト登録も別々• 学務システムで「教室」を登録できるなら、「LMSコースサイト」も両大学申し合わせの上、共通化できるはず28

現在の状況
• コースサイト設置数(2023年4月-6月での速報値)
講義システム連携

プロジェクトサイト(学科内連絡・e-Learning等)

岐阜大学

793

14807

名古屋大学

2408

150 2558

3201

164 3365• 「授業評価アンケート」「Instructor」と独立したロールでアンケート(顕名・匿名小テスト)を実施
29

その他雑多な話システムの「上」「下」30システムをどこで構築する?
• 「機構クラウド」の設計ポリシー未決定• HW機材調達の時間が間に合わない• 他大学の先行事例を参考にAWS上で構築• 特にLMSでの安定運用を重視• 2021.12 構築開始

• VPC構築、VPN接続作業業務委託• 最小限リソースのオンデマンド契約• 機構LDAP, Shibboleth (EC2 x 4, ALB/NLB x 2)
• 機構LMSプロト (EC2 x 2, ALB x 1, RDB x 1)

• 2022.12 リソース3年分一括契約• LMS Webフロントエンドスケールアップ (EC2 x 10)• LMS 周辺システム (ユーザ・科目登録中間DB、LMS_APIサーバ、LRS、etc.)• 2023.4 機構LMS本番運用

31

利用者サポートどうする?
• Zendesｋで「1次対応受付」「課題管理」の共通化• 1契約で複数の「ブランド=サポート対応窓口」を設置できる• 「機構統合認証+M365」「機構LMS」のヘルプデスクを設置• スキルフルな「1次対応スタッフ」が複数案件に対応(※Zendeskは「カスタマと直接対話できる」エージェント毎に課金2次受けの支援要員は無料)• 「ユーザ・カスタマサポート」プラットフォーム化へのきっかけに・・・• 「AI活用のためのナレッジ集約」「カスハラ・パワハラ対策」「カスタマ対応の均質化と底上げ」等• 「情報」に限らず「大学業務全般」への展開を模索中
32

まとめ

33

どうやって作ってく・・・????
クラウドサービス

クラウドサービス

クラウドサービス

業務システム業務システム業務システムプライベートクラウド基盤

プライベートクラウド基盤

プライベートクラウド基盤

ネットワークネットワークネットワーク34

「ビジョン・ポリシー」レベルでのすり合わせ
ビジョン・ポリシー

ビジョン・ポリシー

ビジョン・ポリシー

クラウドサービス

クラウドサービス

クラウドサービス

業務システム業務システム業務システムプライベートクラウド基盤

プライベートクラウド基盤

プライベートクラウド基盤

ネットワークネットワークネットワーク35

「機構=サービス提供者」地位の確立
価値観の共有ビジョン・ポリシー

ビジョン・ポリシー

ビジョン・ポリシー

クラウドサービス

クラウドサービス

クラウドサービス

業務システム業務システム業務システムサービスの提供
プライベートクラウド基盤

プライベートクラウド基盤

プライベートクラウド基盤

ネットワークネットワークネットワーク36

システム統合の壁(運用者サイド)

遠い目標• 「統合するとコストダウン」は実は• システム数は1.5倍• しかし、それぞれの大学から見ると、単純に「お世話するシステム」が 倍

2• 文書化、アウトソースできる状態で運用していないと、「相互理解」「課題発見」すらままならない• (「従来にない」サービスならきっと・・・)

法人統合は教育をどのように変えるか？
• 法人発足から3.5年• 統合されたシステムの本格運用: 1~0.5年• 機構統合認証+M365: 1年• 名大教職員の機構M365切り替え: 2021年7月• 岐大教職員の機構M365合流: 2022年7月• 機構LMS: 0.5年

• システム統合を契機に業務体制・運用ポリシーの見直しが実質化

ビジョン ⇔ サービス運用 ⇔ システム運用
38

個人的な、「法人統合のインパクト」• 「大学運営のサービサー」としての東海国立大学機構• 「大学を運営する」機能そのものへの問いかけ• 個人的には「大学ICTスタートパック」を定義できるか? 今ならどのように設計するか?
を考える貴重な機会• 単に「システム統合」の話だけでは、「モチベーションも運営体制も維持できない」という危惧• 少なくとも「ITSM」レベルでの包括的+堅実な議論• 中長期戦略の立案の両立が可能な能力(Capability)が必要
39