＜第１回＞

校務の情報化とデータベース

兵庫県立西宮香風高等学校　松本吉生

ymatsumoto@hyogo-c.ed.jp

校務の情報化とは

学校で扱われるデータには様々なものがある。生徒に関するものとしては、住所、氏名、生年月日、入学年度、生徒の時間割、出欠、公認欠席や忌引、出席停止の届、定期考査の素点、評価点、部活動の記録、委員会活動の記録、など、授業に関するものとしては、教科科目名、担当教員の名前、単位数、時間割、教室配当、などである。そしてこれらのデータが１年ごとにまとめられ、最終的に生徒が在籍する３年間を通じて集計され、在籍期間や修得単位数によって卒業判定が行われることになる。

これらのデータを処理するために、（１）授業担当が持つ教務手帳、（２）クラスの出席簿、（３）講座ごとに各学期に出欠と成績をまとめる成績伝票、（４）クラスの出欠一覧表と成績一覧表、（５）成績会議資料、（６）生徒と保護者に学習状況を知らせる通知表、（７）生徒の学習状況を正式に保存する学習指導要録、（８）進学や就職に必要な調査書、（９）卒業後に成績を証明する成績証明書と修得単位証明書、などの帳票が作られ処理されている。

これらの帳票には同じデータが繰り返し使われるので、転記を繰り返しながら運用される。担任ならば、まず自分の持つ授業で出欠と成績を教務手帳に記録し、出欠はクラスの出席簿に転記する、学期末にはクラスの出欠一覧表と成績一覧表に転記し、成績会議資料に転記し、通知表にも転記する。年度の終わりには指導要録に転記し、生徒が卒業する年度には調査書に転記し、成績証明書と単位取得証明書に転記するのである。

このように同じデータを何度も転記することが非効率であり、誤記による間違いの可能性があることが容易に想像できる。そこでこれらのデータ処理をコンピュータで行う「校務の情報化」が考えられる。しかしこれが実は簡単ではないのだ。

学校で扱われる出欠や成績、修得単位のデータは単純なように思えるが、実は簡単ではない。その理由のひとつに、データ処理が単年度で終わらない、ということがある。生徒はおおむね３年間在籍し、最終的には３年分のデータが集計される必要がある。さらに学年によってカリキュラムが一部変更になったりするので、去年の一年生は「数学�T」の単位数が３単位だったが、今年の一年生は４単位である、といったことがおこる。また同じ学年でもコース制がある学校の場合は、理系コースは４単位だが文系コースは３単位である、という場合もある。

学校というところは堅苦しいようで、実はかなり柔軟な運用をするところである。例えば「欠席時間数が授業時間数の１／５を超えた場合は履修不認定とする」という規定があったとしても、成績会議において事情を説明され、審議の結果「認定」とされる場合がある。その場合、足りない時間を「補充する」ということが行われる場合があるが、「補充時間」の出欠をどうデータ入力するのか、といった問題が出てくる。欠席時間を出席に書き換えることはできないので、別のデータを補足的に入力することを考えてシステムを作らなければならない。しかし例外措置を網羅的に想定してシステムを作ることは難しい。

ほぼ１０年ごとに教育課程は変わる。今はちょうど教育課程の移行期であり、平成１４年度入学生と平成１５年度入学生とでは違う教育課程になっている。既存の科目の名称も変わっているし、新しい教科「情報」が新設された。必履修科目の科目名や単位数も変わっている。教育課程の移行期には「単位の読替」ということをしなければならない場合がある。例えば、平成１４年度に入学した生徒が１年生を終わり、一年分の単位を修得したが、二年生になって留年した場合、下の学年は新しい教育課程になっているので、全く異なる科目群から学習することになる。この場合、１年生で修得した旧課程の単位を新課程の単位に「読替える」ということをするのである。このような場合、既に修得したデータを変更するという作業が必要になる。

教育課程が変わらなくても、今のように学校の制度が大きく揺すぶられている時代には、各学校の制度が変わることが考えられる。普通科の学校が総合学科になり、学年制の学校が単位制になり、全日制の学校が単位制になることが考えられる。また３学期制から２学期制への変更があれば、定期考査の回数が変わるし、通知表を出す回数も変わる。

いろいろな校務処理のシステムがあるが、ほとんどのシステムは残念ながら使い物にならないことが多い。その理由は、まず、これらの学校独特の処理の流れを理解しているソフトウエア会社が少ないことがある。そして重要な点は、もしよく考えられたシステムがあったとしても、制度や運用が変われば必ず対応できなくなる、とうことである。学校のシステムは無理難題を押し付けられる宿命にある。要は、ある決まった固定的なシステムでは駄目だ、ということだ。

ＳＱＬ Ｓｅｒｖｅｒは汎用のデータベースである。Ｗｉｎｄｏｗｓサーバの上でサービスとして稼動し、ＴｒａｎｓａｃｔＳＱＬという言語でネットワークから問い合わせによって利用できる。データ構造は表形式のリレーショナルデータベースで、アクセスを使い慣れた人なら簡単に理解できる。またエンタプライズマネージャーというＧＵＩの管理ツールを使えば、データをエクセルのような表形式で確認しながら作業をすることができる。エクセルの表、あるいはアクセスのファイルからデータを移行することができる「データ変換サービス」も用意されている。

学校のデータはこのような汎用のデータベースサーバで一括管理されるべきである。校務の情報化を進める場合、生徒の個人情報を守ることにも配慮しなければならない。エクセルやアクセスの作業ファイルが校内のコンピュータに分散した状態では駄目なのだ。クライアントコンピュータにはデータを入力したり表示するアプリケーションだけがあり、データそのものはセキュリティで保護されたサーバにある、といった環境であれば、仮にクライアントコンピュータが盗難にあっても、個人情報の漏洩を防ぐことができる。

ではクライアントアプリケーションはどうすれば良いだろう。．ＮＥＴが発表され、Ｃ＃の合理的なオブジェクト指向プログラミング環境と、広大な名前空間に展開されるモジュールを活用できるようになって、プログラミングの敷居は革命的に低くなった。しかし、そうはいっても、授業や校務と平行して業務アプリケーションを自前で作る、というのは無理があるだろう。そこで活用できるのがＩｎｆｏＰａｔｈである。

ＩｎｆｏＰａｔｈはＯｆｆｉｃｅ２００３に加わった、ＸＭＬベースのデータ共有アプリケーションだ。エクセルやワードとも連携し、ＸＭＬをベースとしたデータの統合化が考えられている。これは「スイート製品」と呼ばれる今までのＯｆｆｉｃｅが、単に「清書のためのワード」や「表計算のエクセル」といった単機能ソフトの「セット販売」であったのとは違い、完全に一体化していく進化を始めたことだといえる。

このレポートはＩｎｆｏＰａｔｈの可能性を、校務の情報化にどう役立つのか、を考えたものである。ＩｎｆｏＰａｔｈとＳＱＬ Ｓｅｒｖｅｒの組み合わせは強力である。ただの１行もコードを書くことなく、クライアントサーバ型のデータベースアプリケーションを構築することができる。私自身ＳＱＬ Ｓｅｒｖｅｒを使い始めたところであり、ＩｎｆｏＰａｔｈについても初心者であるのだが、自分自身の理解を整理する意味を込めて、気がついたポイントをまとめながら、これから使おうとする人に何らかの役に立ったら、という気持ちで書いていく。

一般的にオフィスの事務処理にコンピュータが使われるようになってから、それほど長い歴史はないにもかかわらず、ワープロから表計算、リレーショナルデータベース、Ｗｅｂや電子メール、グループウエアと、活用の場面は確実に進歩してきた。「ワープロができる」「表計算が使える」ことがオフィスワークの常識となり、今やアクセスのような「リレーショナルデータベースが使える」ことが常識になりつつある。ＩｎｆｏＰａｔｈのようなツールが普及すれば「コンポーネントを組み合わせてクライアントアプリケーションをカスタマイズするのはオフィスワークの常識」となり、やがては「プログラミングはオフィスワークの常識」という時代になるだろう。使いやすいツールは個人の能力を高め、業務を「専門職」から「一般職」へ引き下ろすのである。そのことを痛烈に感じさせるのが、このＩｎｆｏＰａｔｈである。

なお、このページでは、特に断りのない限り、サーバはＷｉｎｄｏｗｓ ２０００ Ｓｅｒｖｅｒ と ＳＱＬ Ｓｅｒｖｅｒ ２０００、クライアントはＷｉｎｄｏｗｓ ＸＰ Ｐｒｏｆｅｓｓｉｏｎａｌ と Ｉｎｆｏ Ｐａｔｈ ２００３、を使って説明していく。筆者のメールアドレスはymatsumoto@hyogo-c.ed.jpだ。