- はじめに
この度，平成15年度に向けた岩見沢校オンライン・シラバスの構築を担当することとなった。それは，ウェブをベースとし，データベースと連携する形のシステムになる。すなわち，シラバスはホームページとして実現され，各ページはデータベースと連携して動的に生成される。
さてこのシステムは，構造上，教務システム（あるいはそれよりさらに大きなシステム）へと自ずと拡張される性格のものになる。実際：
- 授業時間割，教室使用の時間割，教官ごとの授業時間割 (「何曜日何時限は何の授業で使われている」という情報) が，自動的に生成される。
特に，これらに関するダブルブッキングのチェックが簡単。
- 「学生」および「受講」レコードを追加し，学生に受講のオンライン申請を行わせれば，
- 受講票，各授業の受講生名簿，学生ごとの授業時間割といったものが，自動的に生成される。
- 受講申請の内容の不備をチェックするプログラムを含めることで，受講のオンライン申請の時点で警告・指導を自動的に返すことができる。
特に，それの不合理性が問題となる「受講登録変更期間」(授業開始から25日程経過後/岩見沢校) を無用にできる。
- 教務係から提出を求められる「受講状況調査書」のようなものも，自動的に生成される。
- さらに「成績」レコードを追加して，授業者が「オンライン出欠記入簿・成績記入簿」の形で成績を入力/編集できるようにすれば，
- 授業ごとの「成績通知表」が，自動的に生成される。
- 授業者から教務係への「成績提出」を，「教務係が成績をオンラインで回収する」という形に変えることができる。
- 学生ごとの「成績表」が，自動的に生成される。
- さらにデータが毎年蓄積されていけば，
- 科目データに含まれている「要先修科目」を用いれば，学生の受講票入力の段階で欠格者をはねることができる。
- 卒業要件充足状況，免許資格，成績表等の打ち出しが，オンラインで随時行えることになる。
- その他
- 「休講案内」の機能を簡単に含めることができる。
- 学生データとの連携で，ケータイメールを利用するプッシュ型の通知（休講通知，求人等）ができる。
- 授業者データからは，「職員録/電話番号簿」が自動生成される。
また，授業者データを拡張すれば，「個人情報・業績」「各種委員会委員名簿」といったものも自動的に生成される。
- シラバスのデータベースは授業と授業者のデータで構成されるものなので，学部を想定しているこのシラバスに大学院のシラバスを含めることは造作がない。
こういうわけで，シラバスの構築は，スケーラビリティ (拡張性) に特に留意して行うこととした。実際，「スケーラビリティ」は，「ウェブ=データベース連携」の真骨頂だ。
- サーバーシステムの構成
教務システムをその中に構築しようとするサーバーは，つぎのような構成になっている：
教務システムのデータベースは，この図の「データベース」の中につくられる。
シラバス等のページは，データベース連携で動的に生成される。この生成のスクリプトが「PHP(PHTML)文書」としてつくられる。
ケータイ・メールは，プッシュ型の通知に使える。
ストリーミングは，教務関連でもいろいろな活用法が考えられる。ただし今回のシステム構築では，これの使用を考えない。
- データベースの構造
教務システム・データベースは，つぎのように関連し合う「教官」「学生」「科目」「科目担当」「受講」を基本的なクラスとする：
科目 ID
- 「科目は，位置づけは複数であり得るが，物理的存在として一意」をルールとして，科目名をこの一意的存在の ID としてそのまま用いる。
- 実際，ID を別に導入（例：通し番号，分類番号）するのは，この場合，管理をかえって困難にする。科目のカテゴリーは複雑なので，整理機能をはたすような ID をつくるのは無理だ。
- したがって，科目名は文字コードのレベルで一意に定める必要があり，この規則が導入される。
- 半角文字，全角文字の使い分け，特殊記号の使用禁止，等。
「科目担当」のレコードは，科目 ID と授業スタッフの ID の対。
「受講」のレコードは，科目 ID と受講学生の ID の組。
- 従来，各授業で個々の学生が授業者に提出していた「受講票」に相等）
科目データの分割
- 科目のレコードを大きくしないためと，データ処理の自由度を高めるために，科目データをつぎの３つのクラスに分割する：
- 科目区分（科目カテゴリー）
- 授業の期・曜日・時限，場所，受講条件等
- 授業内容・計画等
- ユーザ権限
レコードを管理する主体，管理するレコード，そして管理形態 (作業ページでの処理) は，つぎのようになる：
レコードの
管理主体 |
管理するレコード |
管理形態
(作業ページでの処理) |
レコードが
属するクラス |
対象レコード |
管理する部分 |
システム
管理者 |
「教官」 |
すべてのレコード |
ID, 仮PW |
新規作成/編集/削除, 表示 |
| 「学生」 |
すべてのレコード |
すべて (ただし PW は仮PW) |
新規作成/編集/削除, 表示 |
| 教官 |
「教官」 |
自分のレコード |
ID以外の部分 |
編集, 表示 |
| 「科目」 |
自分が担当する科目の
レコード |
すべて |
新規作成/編集/削除, 表示 |
| 「科目担当」 |
担当者が自分になって
いるレコード |
|
担当科目のレコードの新規作
成で，自動的につくられる |
| 「受講」 |
自分が担当する科目の
受講生レコード |
つぎのもの以外：
学生ID，受講科目のID部分 |
編集, 表示 |
| 学生 |
「学生」 |
自分のレコード |
PW |
編集 |
| 「受講」 |
受講科目のレコード |
|
受講申請のページで科目指定
をすると，自動的につくられる |
これに示されるように，特に授業担当者には，強力な権限が与えられている。これは，「個々のユーザーのデータ入力によって，ひとりでに完備に向かう」ようにすることを，本シラバスの設計の立場としたことによる。
- ウェブ = データベース連携
ウェブサーバとデータベースとの連携で生成されるページとしては，以下のようなものがある：
- 一般者に対し
- シラバス，全科目時間割，教室使用時間割 (表示)
- 教授スタッフ情報 (表示)
- 各教官に対し
- シラバス (表示/編集)
- 個人情報 (表示/編集)
- 担当科目一覧/担当科目時間割 (表示)
- 各担当科目について
- 受講状況 (表示)
- 受講生一覧/名簿 (表示)
- 受講生成績 (表示, 編集)
- 教室使用時間割 (表示)
- 各学生に対し
- 受講申請 (表示, 編集)
- 受講科目一覧/受講科目時間割 (表示)
- 受講科目成績一覧 (表示)
- 教務係は，以上のすべてのページの表示が自由。
- Shift-JIS の採用
UNIX ワークステーションでは日本語文字コードとして EUC を用いるのが標準であり，また，Postgres も Shift-JIS をサポートしていないが，本データベースは，ユーザーのＰＣから入力される Shift-JIS コードをそのまま受けるようにしている。
これを可能にするためには，PHP スクリプトにおいて，エスケープコードの操作を明示的に書く必要がある。
エスケープコードの処理が問題になる場面は，つぎの三つ：
- POST 後の整形
- Postgres の query に入れるための整形
- ページに表示するための整形
- ページ構成
本システムのウェブ・ページ構成は，およそつぎのようになる：
- 表示画面 (ユーザ・インタフェース) の実際
ここで，「シラバス編集作業」の画面 (ユーザ・インタフェース) の実際を紹介する──但し，常勤の授業担当者用。
- ユーザは，ログインによって作業環境に入る。
- 個人の作業ページが生成される：
- 担当科目が科目区分つきで表示される。各科目に，編集作業へのリンクボタンがつく。
- 科目情報編集へのリンクボタン「編集...」をクリックすると，つぎの編集メニューのページが生成される：
- 編集する科目情報を，「期，曜日，時限，履修要件等」「授業目標/内容/計画，参考書等」「授業担当者」「科目区分」に区分している。
- つぎは，「期，曜日，時限，履修要件等」の編集ページ：
- 以前に入力した内容を修正するという形で編集するようになっている。
- 選択のフォームを使用して，入力ミスや，書き方が個人でバラバラになることを，なくしている。実際，データ処理で条件に用いられる項目の入力については，このような方法によって厳格化することが必要。
- 期，曜日，時限の入力は，自分の授業時間割に直接反映される：
- また，使用講義室の入力は，施設使用時間割に直接反映される：
- ここで，施設を選択して表示ボタンをクリックすると，その施設の使用時間割（何期・何曜日・何時限に，何の授業によって使われているか」）が表示される。
- おわりに
今回構築したシラバス・システムでは，科目数(781)，科目区分数(101)，科目属性数(20)，授業者数(常勤57＋非常勤147) が，組み合わせ的に処理対象になる。そしてこれを含む教務システムでは，さらに「学生」と「受講」が処理対象に加わる。
これを見ると「大学業務の効率化は教務の電算化 (ディジタル化) に大きくかかっている」の感を強くするだろう。そしてこの種の効率化は，教官雑務の軽減に，したがって本業 (研究と教授) へのエネルギー傾注の回復とアップに，つながっている。一日の多くを雑務で費やされる本校教官の現状は，何としても改められねばならない。そして「効率化」を実現する方法は，(学校統廃合という大鉈を振るう以前の) 現状では「電算化」しかないようだ。
ただ，実際にシステムを構築してみるとわかるが，この種のシステム構築を業者に委託するというのは，やはり相等に無理がある。「意味を知らずに形はつくれない」というわけだ。意味を十分伝えるのも労多いことで，かえって作った方が早いということになる。
ちなみに，わたくし個人では，「学生」と「受講」を取り込んだウェブ = データベース連携のシステムを 1998年に構築し，その年度の後期から実際運用してきている。またこの間，システムの改良を進めている ([1], [2])。したがって，今回構築し供与したのはシラバス・システムだが，本論敲の中で述べてきた限りの「教務システム」は，「学生」と「受講」のモジュールの組み込みを手控えているだけということで，すでに実現できている。このことも報告しつつ，本論敲を閉じるとする。
- 参考文献
|
PDF
