広 報

第 １ 号

２００８年３月

大阪府立工業高等専門学校

情報システム統括室

目 次

巻頭言 情報システム統括室長 大西 章 ･･･ １ 現行システムの概要 乾 達巳 ･･･ ２ 《投 稿》 ＸＯＯＰＳサイト構造による情報発信教育の試み 福嶋茂信 ･･･ ６ 中尾 洵 学内情報提供システムの構築 窪田哲也 ･･･ １１ シラバスの情報管理および入力支援システムの構築 窪田哲也 ･･･ １５ 計算機を利用した授業時間割編成システムの提案と開発 和田 健 ･･･ １９ 松浦史裕 パソコン甲子園２００７でグランプリを受賞して 浜田悠樹 ･･･ ２２

岩見宏明

巻 頭 言

情報システム統括室長 大西 章 インターネットの普及が始まったのは今から僅か１２年ほど前ですが、その後、コンピュ

ータのソフトウエアとハードウエアおよびネットワーク技術は飛躍的に進歩し、コンピュー

タは、従来からの自動処理とシミュレーション分野利用に加えて、情報伝達・コミュニケー

ション手段として欠くことのできないものになりました。このような情報技術の発達と社会

の情報化に教育を対応させるために、本校情報処理教育設備は１９９３年のリフレッシュ計

画に基づくシステム更新で、汎用機システムに替わって LAN による分散処理システムが導入

され、その後、６年ごとの２回のリプレースを経て現在に至っています。情報処理教育の内

容も、１９９１年度からすべての学科において１学年から情報処理教育が実施されるように

なり、２００３年の教育課程改正で各科共通の情報リテラシー教育が本格的に導入され、現

在では、２００５年の総合工学システム学科への改編によって教育課程が一新され、低学年

から高学年にわたって１０科目から成る共通情報基礎科目を柱とした広範囲な内容の一貫教

育が行われています。 新教育体制の実施にともない学校組織も大きく変更され、共同教育研究センターの情報処

理部門は情報システム統括室に名称変更され、図書館とから構成される総合情報センターに

組織変更されました。さらに、来年度からは総合情報センターは廃止され、情報システム統

括室は教務担当副校長直属の組織として位置づけられることになっています。このような過

渡的経緯のため、一時的に広報誌の発行が中断することとなりましたが、統括室としての教

育・研究への支援、設備の有効利用の促進など広報活動の重要性に鑑み、本年度、情報シス

テム統括室広報第１号を発行することになりました。なお、新しい試みとして省資源と学生

を含むより多くの方々への情報発信を考えて、従来の印刷物ではなく、Web ページ上で公開

することにいたしました。 総合工学システム学科への改編にあわせて、学内ネットワークシステムは同年９月に新シ

ステムに更新されました。 新の情報システム環境を活用した教育・研究への取り組みは着

実に進められていますが、さらなる高度活用と学内普及には専門分野教職員にあっても継続

的な 新情報知識・技術の修得と実践が必要で、全学的な連携と協力が不可欠な状況にあり

ます。今後さらに本校において、教材コンテンツの共有化や e-Learning の導入等、国の重要

施策である ICT を活用した教育を進めていくためには、課題が山積しています。皆様方もご

存じのとおり、 近のインターネット技術の発達と普及によって、情報専門分野の人間のみ

にとどまらず、情報処理教育に直接かかわっていない教職員にとっても、情報リテラシー能

力のいっそうの向上が要求される情勢にあります。情報システム統括室は今後ともいっそう

のサービスと支援に努め、本校と地域社会の発展に寄与したいと考えております。

-1-

現行システムの概要

情報システム統括室 乾 達巳 平成 17年 9月 1日にシステム更新された現行システムの概要と特徴的な３つ

のＷｅｂアプリケーションについてご紹

介いたします。 １．システムの概要 1．1 ネットワーク機能の増強 図 1にシステム全体の構成を表したネットワーク概念図を示します。校内光ネ

ットワークを 100Mbpsから 1Gbpsに増強しました。また、マルチホームの外部

イ ン タ ー ネ ッ ト 接 続 は 専 用 回 線

256Kbps と 128Kbps から光 100Mbpsと ADSL50Mbpsのベストエフォート回線に増速しました。現在、実測で光回線

上り下り 20～40Mbps、ADSL回線下り20Mbps 前後の回線速度があります。HTTP､HTTPS などの Web アクセスはプロキシサーバにより、これらの 2回線に自動的に負荷分散されています。 1．2 セキュリティ機能の強化 ファイアウォールとプロキシサーバは、

従来UNIXサーバ上でそれらの機能を実現していましたが、今回は専用のアプラ

イ ア ン ス マ シ ン （ Netscreen と

BlueCoat）を導入しました。Web ブラウザによる設定が可能になったことで、

利便とセキュリティのバランスなどを考

慮した設定変更に柔軟かつ迅速に対応で

きるようになりました。また内蔵ソフト

ウェアのアップデートがほぼワンクリッ

クで自動化されており、セキュリティホ

ール等への対応を速やかに行うことがで

きます。 プロキシサーバを通過してインターネ

ットへアクセスする際、すべての利用者

は、ユーザ認証する必要があり、ログに

は閲覧サイトとユーザ名がセットで記録

されます。ユーザ認証の必要なプロキシ

サーバに対応していないアプリケーショ

ンがありますが、ファイアウォールと協

調した設定をすることにより可能になる

場合（サイトの特定や相手側認証が条件）

とオフラインによる対応が必要となる場

合（アプリケーションのライセンス自動

認証など）があります。 1．3 共通仕様のパソコン導入 旧システムのパソコンは、CADルームには高解像度パソコン、CAIルームにはアップルマッキントッシュを導入するな

ど、目的に応じた特色あるアーキテクチ

ャを採用していましたが、総合工学シス

テム学科の一学科制への移行による共通

科目の増加に対応するために表 1に示す共通仕様の Windows アーキテクチャを採用したパソコンに変更しました。これ

らのパソコンは Windows サーバによってユーザ認証、ホームフォルダなどのネ

ットワークドライブそしてプリンタ利用

（枚数制限）等が管理されています。ま

た、教員機 1台＋学生機 46台の従来の 3教室に加え、専攻科等による授業増加に

対応するため事務室を改修して 24 台のHPCルームを増設しました。

-2-

図１ ネットワーク概念図

表１ 共通パソコンのハードウェア仕様とソフトウェア

共通ハードウェア 共通ソフトウェア

コンピュータ本体 IBM PC 互換機 OS Windows XP Pro

CPU Pentium4 ３GHｚ リテラシ MS Office2003 Pro

メモリ １GB 3 次元 CAD Pro/Engineer Wildfire

ハードディスク ４０GB 技術計算支援 MathCAD

ディスプレイ 19 ｲﾝﾁ液晶 ウィルス対策 Symantec Antivirus

LAN 100BASE-TX PDF 生成 瞬簡 PDF

その他の主なソフトウェア（ライセンス数）

2 次元 CAD AutoCAD（49) 建設デザイン VectoｒWorks（25)

2D 変換ソフト STHENO/Pro(100） 美術支援 Paintshop Pro(47)

制御設計支援 Matlab（55） 化学支援 Chem Draw(47)

数学支援 Mathematica(47) Toeic 受験支援 Toeic テスト（47)

-3-

２．Webアプリケーション システム更新にあたり Web ブラウザから電子メールを操作するWebメール、ネットワークドライブにアクセスする

Webファイル（本校での通称です）そして外部インターネットからのアクセスを

可能とする SSLVPN 機能の３つのアプリケーションを新規に導入しました。 2．1 Webメール 多数の利用実績があるトランスウェア

の Active!mail2003を採用しました。電子メールの利用は、パソコンのアプリケ

ーション使用が主流ですが、送受信に問

題が発生した場合、そのアプリケーショ

ンの違いによって対応が異なる場合があ

ったり、また一部のネットワークに長時

間の障害が発生して電子メールが利用で

きないなどの事例が過去にあり、サポー

ト向上とどこからでも電子メールを利用

できることを目的として導入しました。 Active!mailには基本的な送受信機能、メール転送設定機能、POP受信機能などの他、学習型フィルタによる迷惑メール

対策機能があります。また学生の利用者

は教職員と違うドメイン名のメールアド

レスを発行していますが、同じWebメールのシステムで対応しており、複数ドメ

イン対応機能も特徴のひとつです。 図 2 は、ログインした直後の Web メールの画面を示します。

図２ Webメールの画面例

2．2 Webファイル Web ブラウザを介してネットワークドライブへアクセスする機能を Web ファイルと称しています。これは富士通ビ

ジネスシステムのWEBコラボレーションという製品で構築されています。図 3にWebファイルの操作画面を示します。

Web ブラウザからファイルサーバをアクセスする機能として WebDAV がありますが、これはパソコンのファイル選

択画面を介してファイルをアップロード

する必要がありますが、WebファイルではファイルをWebブラウザとの間で、ドラッグアンドドロップするだけでファイ

ルの送受信を行うことができます。残念

ながらWebファイルの利用は、Windowsのインターネットエクスプローラからの

みとなります。

-4-

図 3 Webファイルの画面例

2．3 SSLVPN機能 Web ブラウザの SSL 暗号通信を利用してインターネットから本校内のイント

ラネットサーバに VPN を構築する機能です。F5ネットワークのアプライアンスマシン FirePassを採用しています。

FirePass はクライアントとしてWindows以外のMacintosh、Linuxそして携帯端末に対応しているのが特徴です。 接続時のセキュリティを確保するため、

キーロガー対策にバーチャルキーボード、

クライアントのウィルスチェックソフト

の状態を検知するなどのエンドポイント

セキュリティ機能があります。 現在、SSLVPN機能を利用して校内用ホームページの一部や、Web メールやWeb ファイルにアクセスすることができます。また希望のあった校内Webサーバへのアクセスを許可しています。それ

以外に計算サーバとの VPN では、リモートソフト VNCを介して Xアプリケーションを利用することができます。 図 4は、SSLVPNへログイン直後の画面を示します。

図 4 SSLVPNの画面例

おわりに 新システムは、旧システムに比較して

管理サーバやアプライアンスマシンが増

加し、それぞれの管理はWebブラウザからの管理などで容易になっているものの、

多様なサービスのためにそれぞれを最適

な運用状態に調整することや十分機能を

発揮させるために詳細を知ることなど、

かなりの時間を要しており、更新して 2年以上が経過した現在でも日々試行錯誤

が続いています。 また、今回のご紹介には登場していま

せんが、各教室からの VLAN認証接続、計算サーバの増強やパソコン教室を使っ

た PC クラスタの取り組みなども行っています。次回の機会には、それらの紹介

のほか、実践報告もしてまいりたいと思

います。 （そういっている間に、次期システム

についての情報収集も始めなければなら

なくなりそうです。）

-5-

XOOPS サイト構築による情報発信教育の試み

大阪府立工業高等専門学校 システム制御工学科

福嶋 茂信 中尾 洵

1．はじめに 最 近 の ICT (Internet Communication

Technology) の進展に伴い，インターネット

上で情報発信をする機会が増大している．

インターネット上での情報発信は，これま

で HTML ファイル作成によるホームページ

作成を指していた．これに関しては，内容，

読みやすさ，デザインなどの要素が重要で

あるが，そのノウハウ本も数多く出ており，

手法としてはかなり確立している．さらに，

商用ソフトウェアを使用すれば，テンプレ

ートファイルを変更することで作成するこ

ともできる．簡便さの反面，作成されたホ

ームページは，画一的になりがちであると

いう問題がある． しかし，最近は，ブログや Wiki など次々

と新しい技術が生まれてきている．そして，

このような新しい技術によって，よりイン

パクトのあるものが次々と世の中に提供さ

れている．ICT を使った情報発信について

教育しようと考えた場合，単なる技術の使

いこなしにとどまることはもったいない．

そもそも ICT 自体が日進月歩であり，今現

在の最新技術について教育することがどれ

だけ意味があるか分からない．より重要な

ことは，未知の技術を取り入れ，適切に組

み合わせるなどして，新しいものを創造す

ることである． このような創造する能力を体験的に習得

することを目的として，われわれは，本校

の製作実習科目の最終報告を，Web サイト

構築を通して行った．作業環境として，機

能拡張性に富む XOOPS [1][2] を用いた．

XOOPS は，CMS（コンテンツ・マネッジメ

ント・サービス）の一種であり，掲示板や

ブログなどの複数の機能を一つのサイトに

持たせることができる．さらに，モジュー

ルと呼ばれるプラグイン型プログラムを追

加することで，多様なサイトを構築するこ

とができる．学習者は，サイト構築に関す

るすべての権限を与えられ，独自のサイト

を構築することができる． 本報告では，これに関する試行と，試行

結果であるサイト構築についての分析，分

析結果に基づいた教育方法の改良について

述べる．

２．情報発信教育の試行 ２．１ XOOPS サイト構築による最終報告

まず，試行について述べる．平成 19 年度

の本校システム制御工学科 5 年次前期科目

「設計製作Ⅱ」において行った．この科目

は，4 年次通年科目「設計製作Ⅰ」と組に

なった，総合学習的な製作実習科目である．

図１ サイト構築に用いた

動物型ロボット例

-6-

学習者は，グループ単位で動物型ロボッ

トの製作に関するすべての工程，すなわち，

製作目標決定，基本仕様作成，設計，部品

発注，組み立て，調整，性能評価，最終報

告を行う．期間は，合計 1 年半であり，1

週あたりでは 4 コマ（200 分）の実習が行

われた．図 1 に製作されたロボットの例を

示す．

製作ロボットに関する最終報告を，

XOOPS サイト構築という形で行った．約 5名で構成する各グループに対し，標準的な

インストールを行った XOOPS サイトを一

つずつ割り当て，サイト管理の全権限を与

えた．グループ数は 8 である．約 25 時間の

実習で，全グループがサイト構築を終えた．

構築されたサイトのトップページの一例を，

図 2 に示す． ２．１ 構築されたサイトの評価

学習者からの評価と，作成コンテンツの

評価を行った．学習者からの評価は，サイ

ト構築終了後，学習者からのアンケートを

とることで行った．4 項目についての質問

から評価した．各項目について，5 段階で

評価し，1 を最高，5 を最低とした．アンケ

ートの項目は，以下に示す 4 項目である． ・習得の容易さ（XOOPS を使った報告書

作成は習得することは簡単でしたか） ・使用の容易さ（習得後，使用すること

は簡単でしたか） ・制御の容易さ（思い通りにサイト構築

ができましたか） ・楽しさ（通常の報告書作成と比較して

楽しかったですか） 表 1 に，学習者からの評価を示す．肯定

的な意見（表中の 1，2）が 39%～60%であ

るのに対し，否定的な意見（表中の 4，5）は 13%～24%であった．使い勝手やおもし

ろさといった，学習者の満足度に関しては，

十分な結果を得た． 一方，構築されたサイトについては，す

べてのグループが，最終報告として必要な

データを掲載したサイト構築を完了した．

また，すべてのサイトで静止画や動画など

のマルチメディアデータの利用が見られた． XOOPS では機能拡張は基本的にモジュー

ルの追加によって行う．このため，作成コ

ンテンツの独自性に対する評価として，各

図２ 製作された XOOPS サイトのトップページ例

-7-

サイトにインストールされたモジュールの

個数で評価する．下表 2 に示す通り，モジ

ュール数はせいぜい 3 であり，全くモジュ

ールを利用しないグループもみられた．こ

れから，XOOPS の機能を十分活用している

とはいえず，独自性のあるサイト構築とい

う点では，不十分な結果となった．

表 1. 学習者の評価 （回答数を割合で表示）

回答番号 1 2 3 4 5

習得の容易さ 5% 32% 39% 16% 8%

使用の容易さ 13% 39% 24% 13% 11%

制御の容易さ 5% 34% 42% 13% 5%

楽しさ 26% 34% 26% 8% 5%

（解答：1(肯定的)～5(否定的) ）

表 2．構築サイトの独自性評価

モジュールの個数 0 1 2 3

全体に占める割合 13% 25% 25% 38%

３．情報発信教育の改良

３．１ 適応的コンテンツ配信

製作実習科目で行ったサイト構築の試行

から，構築されたサイトの独自性が不十分

であることが課題として残った．XOOPS で

は，基本的にモジュールを追加することで

機能拡張を行うため，独自性のあるサイト

構築を促すには，モジュールについての情

報提供を行うことが効果的である．しかし，

学習者に同じ内容の情報を提供しては，構

築されるサイトは画一的になると思われる． そこで，構築状況に合わせてモジュール

の情報提供を行う，適応的コンテンツ配信

制御の仕組みを考えた．これまでにも，数

学の問題を例題として，適応的かつ自動的

なコンテンツ制御についての研究[3][4]がある．

この研究では，数学の問題の解法を例題と

し，設問に対する正誤をもとに，配信コン

テンツの制御を行っている．しかし，従来

研究での手法を本研究に応用するには以下

の問題がある．

(1) 評価の難しさ 学習結果は構築されたサイトであるため，

明確な目標が無く，評価も難しい． (2) 独自性のあるサイト構築への配慮 本研究では，独自性のあるサイト構築を

する能力の育成が目的である．このため，

提示する情報の度合いの制御が必要である． これらの問題を解決するため，以下の特

徴を持つコンテンツ配信制御を行う． ・学習者が作成中のコンテンツに対する

定量的な評価と教授者からの評価を併用す

る． ・サイト構築の進み具合に合わせて配信

を行う．

表 3．項目とモジュールの対応

項目 モジュール名 モジュール概要

テキス

ト

Bwiki Wiki 形式文書作成

TinyD HTML 形式文書作成

静止画 MyAlbum-P 画像管理

動画 X_MOVIE CUSTOM 動画投稿

その他

sitemap サイトマップ

piCal カレンダー

xhnewbb 掲示板

３．２ 配信コンテンツの分類

学習者に配信するモジュールを，その扱うも

のに応じて，テキスト，静止画，動画と，そ

れ以外の４項目に分類する．その他の例は，

カレンダーなどである．XOOPS には多数の

モジュールが公開されており，すべてのモ

ジュールについてコンテンツ配信をするこ

とはできない．今回は，表 3. に示す 8 つの

モジュールに，サイトのデザインを変更す

るテーマを加えた 5 項目に関してのコンテ

ンツ配信を行う．

-8-

３．３ 配信制御の実現

配信制御では，項目とモジュールをあら

かじめ関連づけておき，利用の度合いが少

ない項目について，関連するモジュールの

情報提供を行う．このための手順を以下に

示す． 手順 1. 各グループの構築状況の確認 手順 2. 各グループの構築状況に合わせた

モジュールの選定 手順 3. 各グループへのコンテンツ配信 手順１，２，３が 1 組であり，1 回の講義

内で行われ，これが講義ごとに繰り返され

る．配信のブロック図を図４に示す． 手順１では，5 項目(テキスト，静止画，

動画，その他，テーマ)のサイト内のコンテ

ンツに関して，その分量を定量的に評価す

る．こうして，項目ｍ に対する評価値 I(m) （ただし，0～1 の値に正規化する）を得る． 手順２では，前述の分量を示す評価値

I(m)と，各項目の重要度 w(m)，教授者が与

える評価値 p(m)から，次式に示すように優

先度 C(m)を求める．

C(m) ＝ (1 - I(m)) w(m) p(m) 重要度 w(m)は，項目ごとに予め固定的に

与える．教授者が与える評価値 p(m)は，教

授者がサイト構築状況を見て，手動で補正

するときなどに使用する． 5 項目の優先度

C(m) (m = 1～5) を比較し，優先度が高い項

目についてコンテンツ配信する． 配信制御を行うプログラムは PHP 言語で

作成した．配信するコンテンツは，教授者

の XOOPS サイト内に，各項目に関する情

報提供用ページの形で予め作成しておく．

グループのサイトからのリンクを設定・解

除することで，配信を行う． ３．４ 配信制御の評価

情報発信の試行時に作成したサイトを用

い，コンテンツ配信の評価を行う．ただし，

教授者が与える評価値は一定とし，項目の

重要度には，適当な値を仮に与えた． 結果を下表 5 に示す．サイトの中身に応

じて，配信される項目が変化するのが確認

できた．

優先度 C(m) 算出

利用モジュール の分析

教授者サイト

教授者評価

p(m)

サイト評価値

I(m)

編集

リンクファイル

リンク生成

学習者

１

サイト

学習者

２

サイト

学習者

N

サイト

教授者

モジュール

説明用

ページ(1)

モジュール

説明用

ページ(2)

・・・

・・・

図４ コンテンツ配信制御ブロック

項目ごとの w(m)

-9-

表 5．各グループに配信される項目

グループ名 コンテンツ配信される項目

A テキスト 静止画 動画

B テキスト 動画 静止画

C テキスト 静止画 動画

D 静止画 テキスト 動画

E 静止画 テキスト 動画

F 動画 テキスト 静止画

G テキスト 動画 静止画

H その他 テキスト 静止画 ４．おわりに

本研究では，発表技術教育に XOOPS を

用いた．発表技術教育の「試行」と「改

良」を行った．前者の試行での評価を以下

に示す．

・学習者から満足度の点で，高い評価が得

られた． ・サイトの独自性を示すモジュールの使用

数が不十分であった．

後者の改良では，サイト構築の試行の結

果から，サイト構築状況に合わせたモジュー

ルの情報提供を行った，適応的コンテンツ配信

制御の仕組みを考えた．サイトの構築状況を

把握するために，サイト内のコンテンツを

５つの項目に分けて評価した．また，各項

目の評価値に加え，重要度による重みと教

授者による評価を加味し，必要な情報を適

応的にコンテンツ配信した．コンテンツ配

信制御のプログラムは PHP で作成した． 本報告では，改良したコンテンツ配信シ

ステムの実際的な運用と評価については，

まだである．これに関しては，平成 20 年度

の設計製作Ⅱにおいて行っていく予定であ

る． 参考文献 [1] GIJOE & matchan : カスタマイジング・ズ

ープス, 毎日コミュニケーションズ (2005). [2] XOOPS Cube 日 本 語 サ イ ト , <http://xoopscube.jp/>

[3] 金西計英・林賢太郎・光原弘幸・矢野米

雄・:教材知識に基づき WBT 上で演習問題を生

成する機能の実現,教育システム情報学会, Vol. 20, No. 2, pp.71-82 (2003). [4] 吉田賢史・宮崎光二・中上香代子・中山弘

隆：e-Learning における適応的コンテンツ配信制

御 , メディア教育研究 , Vol. 2, No. 1, pp.81-91 (2005).

-10-

学内情報提供システムの構築総合工学システム学科

窪田哲也

1 はじめに

現在，本校では休講や時間割の変更，学生の呼

び出し等の情報伝達手段として，掲示内容を貼り

付ける掲示板を使用している．掲示板の性質上，そ

の大半が自分に関係のない情報や，放置されたま

ま残ってしまっている古い情報であり，必要な情

報が埋もれてしまっていることがある．そのため，

既存の掲示板では，閲覧者にとって必要な情報の

みを容易に見つけ出すことが困難となっている．ま

た，情報の確認や，掲示内容を更新する場合，設

置場所に行く必要がある．さらに，掲示板が教室

に近いとは限らないため，学生が頻繁に掲示の確

認を行わないと思われる．

富士通エフ・アイ・ピー株式会社が提供してい

る，「モバイルキャンパス」[1]を導入している大学や短大がある．このモバイルキャンパスとはイン

ターネットを利用して，PC と携帯電話から学校側が発信する休講情報や学校行事などの情報を確

認できるサービスである．このシステムでは，個

人を対象とした情報は個人用掲示板に掲示すると

メールでも通知を行ってくれるので，情報を検索

する手間がかからず，必要な情報のみ確実に入手

できる．しかし，「モバイルキャンパス」の導入に

は，初期費用 60万円と，月額で 100円×ユーザ数の料金が必要となる．また，携帯端末の使用の際

に掛かる通信料は利用者の負担となってしまうと

いう問題がある．福島大学では，学校側からの情

報をPowerPoint等を用いて電子化を行い，大型プラズマディスプレイを用いて表示する「お知らせ

配信システム」[2]を導入している．同様に，津山高専でも掲示板全ての上部の壁に液晶モニターを

備え付け，情報を画像化したものを一定時間毎に

スライドショーで学生に提示している [3]．スライドショーの優先順位は情報提供者がフレキシブル

に変更可能である．しかし，情報を順次切り替え

ながら表示しているので個人を対象とした情報の

表示には適していない．また，目的の情報が表示

されるまで画面の前で待たなくてはならないとい

う問題点がある．

そこで本研究では，ユーザ認証が行われていな

い場合は「お知らせ配信システム」のように公開

してもかまわない情報を順次表示し，ユーザ認証

後は，モバイルキャンパスのように個人を対象と

した情報の表示が行えるといった双方の特徴を生

かしたシステムを提案する．

2 現状分析と提案システム現在の掲示板は教室から遠い場所にあるため，

ほとんどの学生が登下校時にのみ掲示内容の確認

を行っている．高学年の自転車通学者にいたって

は，掲示板の前を通らずに駐輪場に行ってしまう

ため，ほとんど掲示内容の確認を行っていない．こ

れらの問題は，学内のさまざまな場所に掲示板を

設置することで解決が可能だと考えられる．しか

し，掲示板の設置場所を増やすと，今でも手間と

なっている情報の掲示・更新作業がさらに増えるこ

ととなり，既存の掲示板という方式では増設は不

可能と考えられる．そこで，掲示板を電子化する

ことでさまざまな場所に設置可能になると思われ

る．図 1に学内各所に掲示板を設置した場合の概略図を示す．この図にもあるように学内には既に

図 1: 学内ネットワーク

ネットワークが張り巡らされており，これを利用

することで掲示内容の管理・投稿を一元的に取り扱

うことが可能になる．さらに，全ての端末まで同

じ情報が表示され，高学年の学生も容易に情報の

取得が可能となる．また，いたる所に設置するこ

とで情報の閲覧頻度も向上すると思われる．しか

し，掲示内容を電子化することで，掲示板の代わ

りに新たな情報表示端末を廊下や図書館等に設置

- 11 -

する必要がある．そのため，設置にかかる初期導

入のためのコストが発生してしまう．しかし，こ

れによる学生サービスの向上は計り知れないもの

と思われる．

今回提案する学内情報提供システムでは，学生

は近くの情報表示端末から情報を得ることが可能

となる．さらに，教員は掲示板に掲示物を貼り付

けるのではなく，自室のPCから学生への連絡・呼び出しの情報を全学に配信可能となる．そのため

のシステムの構成や技術的なことについて 3で述べる．

3 学内情報提供システム (N-Board)

3.1 システムの概要本システムの構成を表 1，2に示す．本システム

では図 2に示すように，投稿者が掲示内容の投稿用アプリケーション，またはWebブラウザを利用して掲示内容を作成し，データベースに情報の登

録を行う．そして，閲覧者はWebブラウザや携帯

図 2: システムの構成

表 1: システムの構築環境 (専用端末)

OS Windows XP Professional

Frameworks .NET Frameworks 2.0

DLLlibpasori.NETMySQL Connector

libusb-win32 0.1.12.1

FeliCa R/W RC-S320

電話，さらに掲示板の代わりに設置するタッチパ

ネル式の情報提供専用端末 (以下専用端末とする)から情報の取得が可能となる．また，ユーザ認証

を行うことで閲覧者を特定し，データベースから

関連した情報のみを取り出し提供することが可能

である．

表 2: システムの構築環境 (サーバ側)

OS Debian GNU/Linux 4.0

CPU AMD Athlon 64 3500+

メモリ 1GByte

Webサーバ Apache2.0

データベース MySQL 5.0.32

アプリケーション Mongrel rails 0.3.12

3.2 データベースの設計本システムでは，掲示板の掲示内容・利用者の情

報を管理・保存しておくデータベースが必要とな

る．そこで，初めにデータベースの設計を行った．

ただし，データベースは情報の冗長性をなくすた

めに当研究室で行っているシラバス入力支援シス

テムと共有することを考えて設計しており，本シ

ステムに必要な部分を図 3に示す．次に，テーブルを大きく 3つに分けて説明を行う．

図 3: 本システムに必要なテーブル

3.2.1 利用者情報利用者の名前や学年，クラス，学科やパスワー

ドを入れておくためのテーブルである．ここに登

録してある情報を基にして，ユーザ認証や掲示内

容の作成時に対象者を選択することに利用する．

3.2.2 掲示内容情報掲示情報のタイトルや内容，作成者，作成日，添

付画像のURLといった情報を保存しておく．掲示内容はWebアプリケーションから入力可能であるが，個人のPowerPointなどを使って掲示内容を作成し，画像化してシステムへ投稿したいという要

求があると思い，添付画像のテーブルを追加した．

- 12 -

3.2.3 掲示内容の対象者を特定するための情報掲示内容の作成時に，掲示内容と対象者を結び

つけるための情報で，掲示内容の対象を設定する

ことで自動的に生成される．また，このテーブル

には利用者がその掲示内容を閲覧したかどうかの

状態を示すフラグを用意してある．

3.3 システム利用の流れ本システムは，情報登録用のコンピュータ，デー

タベースサーバ，専用端末から成り立っている．こ

こでは，情報の登録から表示までの流れを説明する．

3.3.1 利用者の登録・編集本システムでは，あらかじめ教員と学生の名

前や学年，初期パスワードといった情報が管理者

によって登録されており，パスワードは個々に変

更可能となっている．また，メールでの情報配信

サービスを受けるためのメールアドレスと，専用

端末で利用する際ユーザ認証を容易にするために

利用する FeliCaの固有番号については，利用者の同意によって登録することが可能である．

3.3.2 掲示内容の作成掲示板に表示する内容は，専用の掲示内容作成ア

プリケーションを用いて作成するようにした．今回

はWebアプリケーションとWindowsアプリケーションの 2種類を用意した．図 4にWindowsアプリケーションの入力画面を示す．図にあるように，

対象者とカテゴリを選択し，タイトル，本文，掲

載期限を入力し登録ボタンをクリックすることで

内容の登録ができるようにした．Webアプリケーションでも同様のことが出来るようにした．

図 4: 掲示内容作成画面

3.3.3 情報の登録掲示内容をデータベースに登録すると同時に対

象者の idと掲示内容の idの関係 (Relation)を作成し，データベースに登録するようにデータベース

設計を行った．例えば，掲示内容番号 (notiece id)１の情報が対象となる利用者を表示すると，図 5のようになる．これは user idが 18，64，22，75，96の 5人の利用者が掲示内容１の対象者であることを示している．掲示内容の表示には，このRelationを利用して行われるようにした．

図 5: 掲示内容番号と対象ユーザの組み合わせ

3.3.4 情報の表示情報の表示はWebアプリケーションまたは専用

端末上で行うようにした．Webアプリケーションではログイン後に，カテゴリ検索によって掲示内

容の検索を行うことができ，閲覧したい内容を選

択すると図 6のように掲示内容の詳細が表示される．専用端末では，ユーザ認証前は図 7のような一般的な情報が順次表示されるようにした．登録

しておいた FeliCaをカードリーダに読み込ませると自動的にユーザ認証を行い，図 8に示すような内容の一覧がカテゴリ毎に表示される．その中か

ら，見たい内容を選択すると図 9のように情報が表示される．また，FeliCaをカードリーダから放すと自動的にログアウトされ，図 7のような画面に戻るようにした．

図 6: 掲示内容の詳細 (Webアプリケーション)

- 13 -

図 7: ログイン前の画面 (専用端末)

図 8: 掲示内容の一覧（専用端末）

図 9: 掲示内容の詳細（専用端末）

4 まとめ

本研究では，既存の掲示システムの代わりとなる学

内情報提供システムの構築を行った．WebアプリケーションとWindowsアプリケーションではユーザ認証を実装した．さらに Windows アプリケーションでは，パスワードによる認証方法だけでは

なく FeliCaによる認証方法も実装した．今後，システム全体として未実装になっている

専用端末で掲示内容の添付画像の表示，記事作成

時の Relationを行えるようにすることが必要であると考えられる．また現在構築している専用端末

用のアプリケーションでは，FeliCaのみのユーザ認証となっている．最近では，おサイフケータイ

やカード型乗車券などで FeliCaを所有している人は多いが，全ての人が所有しているとは限らない．

本システムでは，既存に発行された FeliCaを利用するが，FeliCaを所持していない人は現在の専用端末用アプリケーションにおいてユーザ認証が行

えない．そのための FeliCa以外でのユーザ認証方法についても実装していく必要がある．

参考文献

[1] モバイルキャンパス，

http://jp.fujitsu.com/group/fip/services/education/mobilecampus/

[2] 福島大学お知らせ配信システム，http://kyoumu.adb.fukushima-

u.ac.jp/fibs.htm

[3] 宮岡樹，衣笠昭弘，岡田正，Webベース業務効率化システムのオープンソースソフトウェアに

よる開発，津山工業高等専門学校紀要，第 49号，2005，pp.59-66

- 14 -

シラバスの情報管理および入力支援システムの構築

総合工学システム学科

窪田哲也

1 はじめに

大学，短期大学，高等専門学校といった高等教

育機関はその教育研究水準の向上に資するため，教

育研究，組織運営および施設設備の総合的な状況

に関し，7年以内毎に，文部科学大臣が認証する評価機関 (認証評価機関)の実施する評価を受けることが義務付けられている [1]．認証評価機関による評価の際にはさまざまな書類が必要であり，その

一つに認証評価を受ける高等教育機関が作成する

シラバスがある [2]．シラバスとは，教育機関において開講される各授業科目の詳細な授業計画書で

ある．学生に対して授業目的や計画等の情報を提

供する仕様書としての役割や評価方法について学

生との契約書のような役割を有する．また，学位

授与審査の際の修得単位の内容確認にもシラバス

は利用されている．このように，高等教育機関に

おいてシラバスの重要性は大きい．

本校では現在，各授業科目の担当教員にシラバ

ス作成用のWordテンプレートファイルを配布し，担当教員がそのファイルを編集するという方式で

シラバス作成を行っている．このテンプレートファ

イルは全科目に対して共通であるため，全ての情

報を担当教員が自ら入力しなければならない．し

かし，単位数や科目名，学習・教育目標，学習達成

目標といった情報は教員がシラバスを作成する際

にはすでに決まっている．このような情報は個々の

教員がいちいち調べて入力しなくともコンピュー

タシステムを利用すれば自動的に入力可能な項目

である．さらに，現在の方式では提出状況の把握が

困難という問題がある．担当教員は作成したシラ

バスファイルを電子メールに添付して取りまとめ

の担当者に送信し，それを担当者が処理するとい

う流れになっている．電子メールを利用した方式

では提出されたファイルを見逃す可能性がある．ま

た，シラバスファイルが頻繁に修正されると，どの

ファイルが最新のものなのかわからなくなる．この

問題は，シラバスに関する情報を DataBase(DB)に格納して一元的に管理することで解消すること

ができると考える．

そこで，本研究ではシラバスに関する情報を一

元化するとともに，教員の記述する項目を限定し

たシステムを提案し，教員が入力する部分をWebアプリケーションとして構築する．

2 システム開発技術シラバスを作成する各教員が使用しているオペ

レーティングシステムはさまざまである．そこで，

開発するシステムは OSに依存しないようにWebブラウザを用いて利用するものとする．また，1．で述べたようにシラバスに関する情報は DBに格納する．以上の点を踏まえると，本システムはDBを利用したWebアプリケーションとして構築するのが望ましいと考えた．DBを利用したWebアプリケーションの構築には多くの着手法が存在する

が，本システムの構築にはRuby on Rails(RoR)を利用することとした．

2.1 Ruby on RailsRuby on Railsはオープンソースのプログラミン

グ言語Rubyを用いて開発されたWebアプリケーション開発のためのフレームワークである．Webアプリケーション開発の際によく使われる機能が

あらかじめ実装されており，システム開発者はア

プリケーション固有の部分を実装するだけでよく

なっている．

RoRを特徴付ける概念として Convention overConfiguration(CoC)がある．CoCとは「設定より規約」という意味であり，RoRにおいては規約に則ってコードを書くことで余分なコードを記述す

る必要がなくなる．例として，次節で説明するモ

デルクラスに対応付けた DBのテーブル名をモデルクラス名の複数形として定義することで自動的

にモデルクラスと DBテーブルが対応付けられる[3]．

2.2 Ruby on RailsとMVCRoRは図 1に示すような，MVC(Model-View-

Controller)アーキテクチャに基づいて設計されている．MVCアーキテクチャとはアプリケーションをモデル (Model)，ビュー (View)，コントローラ(Controller)という 3種類のコンポーネントに分割して設計・実装することをいう [4]．

- 15 -

図 1: RailsのMVCアーキテクチャ

モデルはアプリケーションで使用するデータそ

のものとデータの操作方法・制約条件を定義するコ

ンポーネントである．また，DBとのデータのやりとりもモデルが行う (�)．RoRにおいてはActiveRecordというライブラリに定義された ActiveRe-cord::Baseクラスを継承することによりモデルを作成する．このモデルのオブジェクトが DBテーブルの各行に対応し，各列はオブジェクトの属性

が対応する．

ビューはモデルに格納されているデータに基づ

いてユーザにデータを表示するコンポーネントで

ある (�)．データを表示するだけでなく，ユーザがデータ入力を行うためのインタフェースもビュー

が提供する．RoRにおいては HTMLや XMLといったさまざまな形式のビューを作成することが

可能である．HTML形式のビューを作成する場合，HTML内に Rubyコードの断片を埋め込むことにより動的にコンテンツを作成することができるの

が特徴である．

コントローラはアプリケーション内の調整役に

位置するコンポーネントで，ユーザの入力を受け

取り，モデルとやり取りをし，適切なビューをユー

ザに表示する (�)．RoRにおいてはユーザからのリクエストをアクションと呼ばれるコントローラ

内の１つのメソッドに対応付ける．

3 システム概要今回作成した Web アプリケーションは，Mi-

crosoftWordを用いて作成していたシラバスをWebブラウザによって作成できるようにすることを目

的とした．そのため，シラバスに関する基本的かつ

変更して欲しくない情報 (科目名，単位数，学習・教育目標など)はあらかじめDBに登録しておくものとし，Webアプリケーションからは編集できないようにした．また，学内ネットワークに接続し

ている PCなら，どこからでもアプリケーションにアクセスできるように設置したため，ユーザ認

証を実装し，各教員にアカウントとパスワードを

発行することで学生がアプリケーションを利用で

きないようにした．

3.1 DB設計アプリケーションの開発に先立って，まず DB

の設計を行った．作成した DBの ER図を図 2に示す．

図 2: 作成した DB

今回作成したアプリケーションは最終的には当研

究室で開発を行っている学内情報管理システムと同

一の DBを用いることを想定しているため，usersテーブルには学生，教員の両方がアカウント登録

される．そのためユーザの詳細情報を登録してお

く user infosテーブルには教員には関係の無い学年やクラスといった情報も登録できるようになっ

ている．

subjectsテーブルにはシラバスに関する全情報が格納されている．担当教員情報は元々usersテーブルと関係を持たせることで管理する予定だった

が，クライアントから担当教員を素早く変更でき

るようにしてほしいという要求があったため，テ

キストとして持たせるようにした (�)．このため，ログインした教員に関係のある科目のみを表示す

る機能の実装が困難な状況となった．

3.2 ユーザ認証ページユーザがシステムを利用する際にはユーザ認証

を行う必要がある．図 3に作成したユーザ認証ページを示す．なお，ユーザ認証を行わずにユーザ認

証ページ以外にアクセスするとユーザ認証ページ

に強制的にリダイレクトされるようにした．現状

- 16 -

のシステムではユーザ認証機能の実装はできてい

るが，パスワード変更や新規ユーザのパスワード

設定といった機能の実装が行えなかった．そのた

め，現在はこちらの発行するパスワードでのみロ

グイン可能となっている．

図 3: ユーザ認証ページ

3.3 シラバス一覧表示・検索ページユーザがシラバスの編集を行う際に，編集した

いシラバスを容易に探し出せることは重要である．

当初 3．2で述べたように教員に関係する科目のみ一覧表示する予定であったが DB変更に伴ない困難となった．単純に全シラバスの一覧を表示した

だけでは目的の授業科目を見つけるのは容易では

ない．そこで，一覧表示ページに検索機能を実装

することでユーザの求める授業科目を検索できる

ようにした (図 4)．

図 4: シラバス一覧表示・検索ページ

検索条件には，科目名 (日)，学年，担当教員の3種類が指定できるようにした．また，シラバス情報は毎年蓄積されるので表示したい授業科目の開

講年度を選択できるようにもした．現状では，過

年度のシラバスの内容を反映させる機能の実装に

は至らなかった．さらに，各シラバスが完成して

いるかどうかもシラバス一覧のページから確認で

きるようにした．

3.4 シラバス編集ページシラバス編集ページはテンプレートでの編集に

近づけるために，実際のシラバスと同じような構

成で入力欄を表示するようにした．シラバス編集

ページは 2つのページで構成されている．2つの

ページは授業内容を記述するページ (図 5(a))と，それ以外を記述するページ (図 5(b)) に分かれている．ユーザの操作性を考慮すると，Webアプリ

(a) 授業内容の編集

(b) 概要等の編集

図 5: シラバスの編集ページ

ケーションはページ遷移することなく全ての情報

を編集できることが望ましい．しかし，本校のシ

ラバスは A4用紙 1枚にまとめなければならない．さらに，シラバス全体の体裁も整えなければなら

ない．これらの制約を満足させるために，記述部

分の行数を揃える必要がある．行数を揃える方法

として授業内容部分に不足行数分の空白行を挿入

するという対策を施すことにした．しかし，編集

ページが 1ページだけでは現在入力している文字数や行数をリアルタイムで把握することは困難で

ある．そのため，あとどの程度の文章を書けば行

数がオーバーするかシステムによる補助機能が実

装できない．そこで，行数あわせをする授業内容

だけは最後に編集するようにした．ページ遷移す

ることで残り何行で 1ページを超える文章になるか表示させることが可能となった．また，2ページ目では授業時間数の合計と行数を確認するボタン

を設置した．図 6(a)は両方が正しく入力された場合である．それに対して，図 6(b)，(c)は正しく入力されていない状態を表している．

3.5 シラバス表示ページDBに格納されたシラバス情報は，主事室担当

者にのみ提供するWindowsアプリケーションから

- 17 -

(a) 問題無し (b) 要修正 (c) 要修正

図 6: 行数・時間数の確認

読み込まれ，Wordファイルとして出力される．本校で最終的に利用するのはWordファイルを変換した PDFファイルなので，ユーザはWebアプリケーション経由で PDFファイルを確認できるようにすることが望ましい．しかし，WindowsアプリケーションをRoR側から実行し，PDFファイルを作成してユーザに提示するのは不可能である．そ

こで，Webアプリケーションでは HTML形式で表示するようにした (図 7)．しかし，現状では行端にカンマ記号が存在したり，半角英数字が入るこ

とで行数のカウントがおかしくなる可能性がある．

図 7: シラバス表示ページ

シラバスの入力が完了した際，このPreviewページにおいて完成ボタンをクリックすることでDBの編集完了フラグをたてることができる．それ以降，

シラバス一覧ページと編集ページにおいてシラバ

スが完成していることが表示されるようにした．

4 まとめ本研究では，Webブラウザを利用してシラバス

を作成するアプリケーションをRoRを用いて開発した．アプリケーションは本研究室のサーバにて

現在稼動中であり，これを利用し来年度のシラバ

スが作成される予定となっている．実用面での開

発は概ね終了しており，今後はユーザの利便性，操

作性の向上を目的とした開発が必要であると考え

られる．

今後の課題としてユーザ認証機能の強化が考え

られる．現在は学内情報管理システムと共通のDBを利用していないので，アカウントは教員のもの

しかないという前提でユーザ認証を行っている．そ

のため，学生のアカウントが登録されるようにな

ると学生も教員と同様にユーザ認証を行うことで

シラバスを編集できるようになってしまう．また

現状では，認証されたユーザは全てのシラバスを

編集できる．これについても検討する必要がある

と考えられる．さらに，現在Windowsアプリケーションで行っているシラバス情報の登録について

もWebアプリケーションから登録できるようにすることも検討する．

参考文献

[1] 大学評価・学位授与機構 ｜ 大学評価事業，

http://www.niad.ac.jp/n hyouka/index.html

[2] 高 等 専 門 学 校 評 価 基 準

(機関別認証評価)，大学評価・学位授与機構，http://www.niad.ac.jp/ICSFiles/afieldfile/

2007/05/31/no6 1 3 kousenkijun20.pdf

[3] [ThinkIT] 第 1回 : Railsが注 目 さ れ て い る 理 由 (1/3)，http://www.thinkit.co.jp/free/article/0605/2/1/

[4] Dave Thomas et al.，“RailsによるアジャイルWebアプリケーション開発第 2版”，株式会社オーム社，2007，pp．10–16

- 18 -

計算機を利用した授業時間割編成システムの提案と開発 システムデザインコース 和田 健

システム制御工学科５年 松浦 史裕

1. 緒論 時間割編成問題とは，教員や講義室が競合しな

いように時間割表上に授業を配置していく問題であ

る．高専をはじめとして，小学校から高校・大学，さ

らには予備校に至るまで，教育機関に勤務する者

にとっては身近な問題として知られている．しかしな

がら，この問題は，数学的には組合せ 適化問題と

して位置づけられており，その求解には極めて大き

な労力が必要となる．近年では，その労力軽減を目

的として，時間割を自動編成するソフトウェアも市販

されている２ ) - ３ )が，「複雑な制約条件が取り扱えな

い」「特殊なクラス構成・授業形態に対応していな

い」「操作や設定が複雑である」「満足できる時間割

が得られない」といった問題から，現在でも手作業に

よる編成を行なうところは多い．本校においても「専

攻科を含めて 7 学年ある」｢学科・コース編成が複雑

である｣といった特殊な設定に加え，「非常勤講師が

多い」「共有する講義室が多い」などの制約条件が

多数存在することから，これまで自動編成ソフトの利

用は考えられてこなかった．そのため，現在でも手作

業を中心とした時間割編成が行なわれており，担当

教員にとっては大きな負担となっている． このような背景から，本研究では，本校における時

間割編成作業の労力軽減を目的として，（計算機

による時間割の完全自動編成ではなく）編成者とコ

ンピュータの連携により効率的な時間割編成を行な

うシステムの提案と開発を行なった．そして，実際の

時間割編成作業を通じて提案するシステムの有効

性についての評価を行なった．

2. 本校における時間割編成作業の現状 本校の授業時間割編成の特徴と手順について，

ヒアリングを通じて情報の収集を行なった．ヒアリング

は，実際に時間割編成に携わった経験を有する教

員 2 名に対して行なった．得られた情報について整

理したものを次に示す．

2.1 本校時間割編成の特徴 本校の時間割編成では，（総合工学システム学

科という学科体制をとっていることから）学科ごとに

独立して決定することができない 5 クラス／6 コース

／4 学科の 7 学年を同時に扱わなければならないこ

と（つまり、非常に大きなサイズの問題を扱うこと）に

加え，｢学科・コース編成が複雑である｣｢授業可能

な時間帯が限定された非常勤講師が多い｣「学科・

コースで共通して使用する講義室が多い」といった

極めて多数の制約を考慮しなければならない．

2.2 本校時間割編成の手順 本校の時間割編成では，まず，各コースから選出

された編成委員が，当該コースの授業について担

当 教 員 や開 講 時 期 をコース内 で協 議 ・調 整 し，

Fig.1 に示すようなマグネットを作成する．

Fig.1 マグネット

次に，各コースの委員が集まり，（例えば「非常勤

講師の授業から」といったような）段階を踏みながら

作成したマグネットを Fig.2 のように白版上に貼付け

授業配置を決める．その際，教員や講義室に競合

が生じていないかを確認し，問題があれば委員同士

で協議し，授業配置の調整を行なう．

Fig.2 時間割編成用白板

このようにして，その段階における問題がなくなれ

ば，次の段階（例えば，特別教室を使用する授業）

のマグネットを貼り付ける，という作業を繰り返しなが

ら段階的に時間割を完成させる．しかし，先述したよ

うに制約条件が多いことから，制約を満足する時間

割が得られず，前の段階に戻ることはもちろんのこと，

クラスの持ち替えや開講時期・教科担当者の変更

が行なわれることもある．さらには，教員の競合など

深刻な制約違反を除いて，連続講義時間が 6 時間

を超えないようにするといった緩い制約条件につい

-19-

ては委員の判断で妥協されることもある． なお，上記の手順の中でも，競合の検出と解消に

大きな労力が費やされている．この問題の解決とし

て，数年前より，エクセルのマクロで組まれた競合検

出ツールが利用可能となっているが，テキストベース

のデータ入力・操作が必要であることから委員全員

が積極的に使用するには至ってはいない．

3. 時間割編成システムの提案 時間割編成作業の労力軽減を目的として，本校

の時間割編成において実際に利用可能な編成シス

テムの提案を行なう． 先述したように汎用の自動編成ソフトを，本校の

時間割編成に使用することは難しい．これは汎用の

ソフトが， (1)一般的な小・中・高校を想定して設計

されており，本校のような７学年（５クラス→６コース→

４学科）という構成に対応していないこと，(2)時間割

編成作業の実務者として強い決定権を有した 1 人

のユーザを想定しており，本校のような複数人体制

による編成には馴染まないこと，(3)すべての制約条

件を満たす実行可能解が存在していることを前提に

設計されているため，編成の前提条件である担当

教員の変更や，いくつかの制約条件の妥協が必要

となる本校の時間割編成には適さないこと，が原因

である． これらのことを踏まえ，提案するシステムは，学年・

クラス構成に柔軟に対応可能で，（計算機による時

間割の完全自動編成を行なうのではなく）編成者に

対して有益な情報を提供することで編成作業を支

援することをコンセプトとして設計した．また，システ

ムは，現行の時間割編成体制・手順に十分に沿う

ものとなるように設計した．

3.2 システム構成 提案する時間割編成システムの構成図を Fig.3

に示す．システムにおいて各要素は次のように位置

づけられる． (1) 授業時間割編成支援ツール『Sche っ人』

システムの中核となる編成支援ソフトウェアであ

り，簡単なマウスの操作のみで時間割を編成する

機能，競合を検出する機能，各種帳票出力する

機能を有する． (2) 編成者

Sche っ人が提供する情報を参考に，授業の

配置を行なう．提案するシステムは，この編成者を

支援するためのものであり，時間割を編成に関す

る意思決定を行なうのは，あくまで，編成者自身

である． (3) 基本情報

時間割編成に必要な基礎データであり，教員

情報，講義室情報，教科情報，クラス情報などか

ら構成される．これらは，膨大なデータとなるため，

見やすく，扱いやすいエクセルファイルフォーマッ

トを採用した．なお，これらを編集することで，小学

校や中学校の時間割編成にも対応できる． (4) 授業配置情報

授業の配置情報に関するデータである．これを

出力することで編成作業を中断し，読込むことで

編成作業の再開が可能となる． (5) 授業時間割表 (HTML)

Sche っ人により出力される HTML 形式で整形

された授業時間割表である．Web にアップロード

することで，ブラウザを通じた時間割表の確認が

可能となる． (6) 授業時間割表 (Excel)

Sche っ人により出力される Excel 形式で整形

された授業時間割表である．印刷して紙媒体で

配布することなどが可能である．

4.時間割編成支援ツール｢Sche っ人｣ 編成システムの中核となる「Sche っ人」は，簡単

なマウス操作より，白板にマグネットを貼り付ける感

覚で時間割を編成する機能を提供する．具体的に

は，基 本 情 報 の読 込 むことによって生 成 される

Fig.4 に示すような授業タグ（マグネットに相当）を，

マウスのドラッグ＆ドロップにより Fig.5 に示すような

編成ウィンドウ上に配置していくことにより，時間割

の編成を可能とする．なお，配置を変更した際に，

教員や講義室に関して競合が生じると，Fig.6 に示

すように，授業タグ周囲の色を変えて編成者に競合

の発生をリアルタイムで通知する．

出力(HTML)

入力

印刷

出力(Excel)

意見

入力教員情報

講義室情報

教科情報

Excel

時間割表

・ 学年別・ 曜日別・ 教員別・ 講義室別

Excel

Data授業配置情報

競合の自動検出

（教員・講義室etc.）

授業時間割の編集1 2 43 5 6

Y学科　編成員 X学科 教員

授業時間割(案)

1 2 43 5 6

時間割編成員X学科

a

e http://.....

閲覧・確認

-Local Page -

編成

時間割表（紙）

a

Scheっ人人

Time...

インポート

エクスポート

Fig.3 システム構成図

-20-

Fig.4 授業タグ

Fig.5 時間割編成ウィンドウ

Fig.6 競合情報の通知

また，授業タグが移動されると，別に開かれている

教員別・講義室別・クラス別の時間割ウィンドウ上で

も配置がリアルタイムに更新される．これらの機能に

より，白板を眺めながら競合の有無をチェックする手

間と，競合が発生した場合にどこに移動させれば競

合が回避されるかを探し出す手間が大幅に減少さ

せることができる．さらに，Sche っ人では，そのまま印

刷して時間割表として配布可能なエクセルファイル

を出力することができる． また，時間割表を HTML形 式 で 出 力 す る 機 能 も 備 え て お り ， 出 力 し た

HTML ファイルを Web サーバー上にアップロードす

ることが可能となる。これに，Fig.7 に示すようにイン

ターネットブラウザを通じて時間割表を閲覧・確認す

ることが可能となる．

Fig.7 HTML として出力された授業時間割表

5. システムの評価 提案するシステムを使用して 2007 年度 (前期 )の

時間割を作成した．この際，競合を効率よくチェック

しながら，実際に時間割を作成できることを確認し

た． また，時間割編成委員に対してシステム導入の

提案を行ない，その結果，2008 年度の編成作業に

白板を使用したシステムと併用する形でシステムの

導入が実現した．手作業では見逃しがちな競合を，

リアルタイムに確実に検出する機能，編成途中であ

っても時間割表を出力する機能（持ち帰って作業を

続けることが可能）は，好評であり，システム全般に

ついても概ね好評であった．しかし，白板上の時間

割と Sche っ人上の時間割の間で食い違いが生じ，

それらを修正する作業に大きな時間が費やされると

いった問題が発生した．また，ディスプレイ領域の制

限，マウスが 1 つであることに起因して，複数人で同

時に作業することには難があった．特に，これらの問

題は，配置変更が頻繁に行なわれる序盤で問題と

なった．そのため，序盤では白板が主として利用さ

れていたが，半分以上の授業が配置されて競合が

頻発する中盤では白板と Sche っ人の併用となり，

終盤では編成作業は Sche っ人に一本化された．こ

れらの結果，効率的に編成作業を行なうためには，

前半に従来式の白板を利用し，後半に提案するシ

ステムを投入することが望ましいといえる． この他，編成委員からは，システム（Sche っ人）に

対して次のような改善要求が挙げられた． • Sche っ人から担当教員や使用教室の変更が行

なえるとよい（現状では，担当教員や使用教室の

変更は基礎データを変更しなければならない）． • 基礎データの作成が煩雑である． • 基礎データから白板用のマグネットを自動作成す

る機能が欲しい． 現在、Sche っ人を下記 URL にて公開している．

http://wada-server.ipc.osaka-pct.ac.jp/wiki/index.php?TimeTableEditor

6. 結論 本研究では，本校における時間割編成作業の省

力化を目的として計算機を利用した時間割編成シ

ステムの提案と開発を行なった．そして，提案したシ

ステムを使用することで，時間割編成にかかる労力

が軽減されることを実証的に検証した．また，試験

運用を通じて，今後の課題点を明確にした．

参考文献 1）田中雅博 , メタヒューリスティック手法による時

間割編成の自動化 , システム制御情報学会誌 , Vol.45, No.12, pp.725-732 (2001) 2）株式会社システム 21, タキオン , http://www.kks21.co.jp/tachyon 3）株式会社イデアシステム , AI 時間割 , http://www.ideas.co.jp

-21-

パソコン甲子園 2007 でグランプリを受賞して

総合工学システム学科３年 浜田悠樹・岩見宏明 今回、パソコン甲子園 2007 でグランプリを受賞することが出来ました。この賞を受賞し

たことを通じて、私達は何かに挑戦すること、努力することの大切さを知ることが出来ま

した。 私達が初めてパソコン甲子園に参加したのは、2006 年度の大会でした。パソコン甲子園

は、年に１度、福島県にある会津大学で行われる、高校生・高等専門学生を対象とした、

全国大会です。この大会は制限時間以内により多くの問題を解くことを競うプログラミン

グ部門と、ショートムービーを作る、デジタルコンテンツ部門などがあります。私達が参

加したのは、プログラミング部門です。私達はこの大会で、昨年度は 6 位という結果に終

わってしまいました。結果だけを見れば、6 位というのはそう悪くは無い結果かもしれませ

んが、上位のチームとの間には大きな点差がありました。私達はこの大会での大敗を通じ

て、自分たちの力の無さを実感しました。この悔しさをバネに、次年度の大会では、絶対

に勝ってやると意気込みました。それから、私達はアルゴリズムや数学の勉強を自分たち

で進めていきました。そうして、2007 年度の大会に挑み、勝利を得ることが出来ました。 この経験を通じて、努力し、挑戦し続ければ必ず報われる時が来る、何か、かけがえの

無いものを得ることが出来るのだと実感しました。だから、後輩の皆さんにも、何でもい

いので、何かに挑戦し、努力し続けて欲しいと思います。自分の趣味に没頭できるのは学

生のうちだけですので、社会人になる前に、自分の好きなことを見つけ、没頭して欲しい

と思います。

-22-

編集後記 投稿していただきました方々には、お忙しいところありがとうございました。 新システムにリプレースされてから、２年半になりますが、情報技術分野の進歩は日進月歩で、

まだ、学内全体で十分に広く活用されているとは言い難い状況です。情報システム統括室では、

本校ネットワーク設備をより有効に活用していただけるよう、今後ともいっそうの利用環境の 整備とサービスに努めてまいりますので、皆様方のご協力をよろしくお願いいたします。

発行日 ２００８年３月（第１号）

編集発行 大阪府立工業高等専門学校 情報システム統括室 大西 章 乾 達巳 森山泰秀

〒572-8572 大阪府寝屋川市幸町２６番１２号 Phone 072-821-6401（代表） Fax 072-821-0134（代表）