大学カリキュラム変更 奮闘記

>100 Views

March 14, 23

スライド概要

インターネット大学のシステム部に勤務していた頃に経験した、カリキュラムの大変更の体験談です。

大学の単位制度や科目マスタのデータ移行のやり方について詳しく解説しました。

profile-image

Webエンジニア Python、Go言語を使用したバックエンド開発の経験が長い​ スクラムを使った開発に通算7年携わり、デイリースクラム、スプリント計画、スプリントレビュー、振り返りなどのファシリテーターも担当していた​ 米国認定アドバンスドスクラムマスター(A-CSM)の資格も取得しており、スクラムやCI/CD、TDD、コードレビュー、ペアプロなどのアジャイル開発技術に詳しい​ AWSをはじめとしたクラウド・コンテナ化のトレンドにも追随しており、6年にわたってAWSを使ったインフラの運用に携わってきた経験あり​ 正確さや丁寧さが求められるデータ移行やシステムリプレイスなどの業務に強みあり

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

大学カリキュラム変更 奮闘記 2023年3月14日 石田 武 Copyright © 2023 Takeshi Ishida All Rights Reserved.

2.

今日のお題 とある大学のシステムの仕事で経験した データ移行の話を紹介します

3.

大学カリキュラムの大幅刷新が決定した ある年、私が勤める大学で科目やカリキュラムを大幅に制度変更した 1. 選択必修科目を導入した 従来は必修と選択の2種類のみだったが、 この中に「選択必修グループの中で○単位の取得が必要」 という選択必修科目が加わった 2. 既存科目の単位区分変更や科目の新設・廃止も行った 3. 科目の分割も行った (例:4単位の科目を2単位の二つの科目に分割) ※後述の補足資料「大学の単位制度」も参照ください

4.

運営上、多大な影響が見込まれる この制度変更を行うと、以下のようなケースが起きうる • • • 在学生の修得済み単位数が減る、または増える 変更前に卒業要件を満たしていた学生の単位数が足りなくなる 必修単位が選択や選択必修に変わり必修要件を満たせなくなる ※この問題を考慮して必修要件を引き下げると、 新入生と在校生の間で必修要件の単位数が異なる状態に

5.

制度変更に必要なシステム作業 1. 2. 3. 4. 5. 履修登録の画面の改修 単位区分、卒業要件、必修要件といったマスタの更新 学生の修得済み単位数のデータ移行 科目・カリキュラムの新しいデータ投入(新入生向け) 既存の科目・カリキュラムのデータ更新(在学生向け) ※過去に遡った制度変更のためデータ移行が非常に複雑で難しい

6.

作業を進める際の課題 1. システム開発部に依頼が来たのが履修登録の一ヶ月前 (変更の影響度に対して準備期間が明らかに足りない) 2. 新カリキュラムの案が頻繁に変わる (新しい制度の検討なので、毎週教授会で変更要望が出る) 3. 大学運営・教務担当者も制度変更の影響を想定しきれない (この人たちに聞いても分からないことが多い) ※自分たちで想定しうるケースを可能な限り洗い出し、 カリキュラム案の変更を何度でも受け入れ可能な方法で 準備する必要があった

7.

変更を何度でも受け入れ可能な方法とは? 1. サンドボックス環境の整備 本番作業の前に不明点や考慮漏れを出し切っておく。 バックアップから検証用のデータベースを作成しデータ移行作業のリハーサルを行う。 リハーサルも一度だけでなく、なるべく沢山やる。 2. 原則としてデータ移行を手作業で行わない オペミスを防ぐため。 例えば、教務担当が作成したカリキュラム案のExcelファイルをDBに反映する際、手作業でデータ加工· 投入をせず、プログラムを書いて行う。 3. Four eyes principleとファイルの共有 データ移行作業を絶対に一人でやらない。必ず共同作業者を付けてFour eyesチェックを通す。 作業に用いる手順書やプログラムのソースコードはGoogleドライブ、Wikiツール、Githubなどに共有する。 (特定の個人のローカル端末に最新のファイルがあり、他のメンバーに共有されていない状態を防ぐ) ※上記によって短い納期の中でもシステム作業を無事完了させることに成功

8.

実際のデータ移行の段取り 1. 検証用データベースを設ける (ここでデータ移行のリハーサル等を行う) 2. リハーサルは何度でもやり直して良いルールとする (DBのバックアップから何度でも復元してやり直せる状態を担保) 3. 手順書は共有ドキュメントとして管理を徹底 (最新の作業手順を共有するためローカルファイルは禁止) 4. データ移行用のSQLは手順ごとに識別可能なファイルに分け、 Githubで管理する (手順書と同様に最新の内容を共有するため) 5. データ移行作業後のチェック要件を定義し、整合性チェックの手順や検 証コードを準備 (本番当日にアドリブで目視確認する程度では確認しきれないことが容易に想定されるため)

9.

カリキュラム 変更 奮闘記 • 大学カリキュラムの大幅刷新が決定した • 制度変更に必要なシステム作業 • 作業を進める際の課題 • 変更を何度でも受け入れ可能な方法とは? • 学生に対するケア

10.

システム作業は無事に完了できたけど… 学生は自分の単位がどうなるのか見当もつかない状態 単位の修得もれは無いか·卒業要件に対してこのままでも 大丈夫なのかといった事柄を把握しようがない

11.

すべての学生に単位の比較資料を配布 DBのデータからすべての学生の単位比較資料を自動生成した。 それを大学教務と学生の間の履修相談に利用し、制度変更前後の混 乱を最小限に抑えた。 ※配布資料のイメージ 卒業までに必要な単位 100 / 136 卒業までに必要な単位 100 / 136 必修単位 必修単位 選択単位 40 / 40 60 / 96 16 / 16 選択必修グループA 8/8 選択必修グループB 8/8 選択必修グループC 8/8 選択単位 60 / 96

12.

まとめ

13.

まとめ • • • • データ移行は事前のリハーサルや計画的な準備が大切 サンドボックス環境を使って事前にミスや失敗を出し尽くしておくと 安心して本番を迎えられる Four eyesチェック、手順書の共有、手作業の排除を心がける 自分たちの作業だけでなく、ユーザーに対するケアも考慮する

14.

補足資料 ー 大学の単位制度 ー

15.

単位区分について • 必修科目:指定されたすべての科目の単位を取ることが必要 • 選択科目:指定の単位数以上となる組み合わせなら自由に科目を選択可 • 選択必修科目:科目群ごとに決められた単位を取ることが必要 必修科目 指定されたすべての科目の単位を取ることが必要 例:以下が必修科目に指定された場合 法学Ⅰ(2単位) 法学Ⅱ(2単位) ローマ法(1単位) 卒業には3科目 すべての単位 取得が必要 選択科目 指定の単位数以上となる組み合わせならば自由 例:選択3単位が必要な場合の履修パターン 選択必修科目 すべての科目群の単位数を満たすことが必要 例:以下が選択必修群が指定された場合 法学Ⅰ (2単位) 法学Ⅱ (2単位) ローマ法 (1単位) 合計 単位 卒業 可否 法律科目群(3単位) 財政科目群(3単位) 修得 ー 修得 3 ○ 法学Ⅰ(2単位) 財政学(2単位) ー 修得 修得 3 ○ 法学Ⅱ(2単位) 貨幣論(2単位) 修得 修得 ー 4 ○ ローマ法(1単位) 租税法(1単位) 修得 修得 修得 5 ○ 修得 ー ー 2 × 決められた単位数を取れればすべての科目 を履修しなくても良い それぞれの選択必修群の中で決められた単 位数の取得が必要

16.

卒業に必要な単位数 これは「124単位以上の修得が必要」などと法令で決まっており、大学 が恣意的に卒業要件の単位数を減らすことはできない。 また、学生が一年に履修できる単位数にも上限を設け、各年次にわ たって適切な学習量に収めるよう大学に対して努力義務が課せられ ている。 (=履修登録のときに半期〜1年といった短期間で卒業単位をすべて 取得するといった行為ができないよう制限をかけたりする)。 ※法令:学校教育法や大学設置基準のこと

17.

単位修得と単位認定 単位の取得方法は二種類あり、システム上も区別を要する 1. 単位修得 科目を受講し、出席回数・試験・レポート提出といった条件をパスし てその科目を正式に学習したものと大学から認めてもらうこと 2. 単位認定 他大学からの転入や学部・学科の転向をしたとき、前の所属におい て修得済みの特定の科目を新しい所属のカリキュラムの中の単位 として大学に認めてもらうこと。その他、公的資格を持っている場合 に単位認定されることもある。

18.

以上