ホチキス先生

今年は昨年と少し趣向が変わったTechEdのコミュニティ・プログラム。「ライトニング・トーク」というプログラムで「簡単! InfoPath と SQL Server でリッチなインターフェイスのクライアント サーバー システム構築」という話をさせてもらえることになった。

5分程度ということで詳しい説明はできないが、いま業務としてやっているデータベースについて話す。InfoPathをクライアントのフロントエンドに使い、データベースSQL Serverに接続するクライアント・サーバー・アプリケーションについてだ。

俺はもともとプログラマーではなく、どちらかといえば管理運用の仕事をしている立場にいる。学校のデータベースを日常業務の空き時間を使って構築してきた経験から、実際の業務に直接携わっている人間、運用についてよく知っている人間がデータベースを構築することが、最も効率よく成功するシステムを構築できると確信している。

マイクロソフトのSQL Server、InfoPathやAccessといったオフィス製品、Active Directoryなど使いやすいシステムを組み合わせて利用することで、たいていのデータベースは自前で構築できる。その可能性を実感してもらえれば嬉しい。

マイクロソフトTeceED 2008 Yokohama公式サイト
http://www.microsoft.com/japan/teched/2008/default.mspx

Birds of a Feather & ライトニング・トーク
http://www.event-marketing.jp/events/te08/special/bof.htm

生徒の基本情報の中には、入学してから卒業まで全く変更のないフィールドがある。それは「性別」「生年月日」「入学年月日」などである。これらのデータは「生徒基本情報」テーブルに一つのフィールドを設けて登録すればいい。

これに対し「住所」などは転居によって変更しなければならないデータである。また「保護者」なども場合によっては変更があるし、生徒本人の「姓」、あるいは昨今「名」すら変更したいというケースがまれにある。戸籍の氏変更にともなって姓の変更は当然にしても、「名」さえ変更があり得るとすれば、履歴をきちんと管理しておかないと、そもそもその生徒がいったい誰だったのかわからなくなってしまう。

これら変更履歴を記録しなければならないデータについては次のような管理が考えられる。

（１）別テーブルで管理する

「生徒」テーブル　[学籍番号],[住所管理番号]
「住所」テーブル　[学籍番号],[住所管理番号],[住所]

というように「住所」だけを記録するテーブルをつくり、最新の「住所管理番号」を「生徒」テーブルの「住所管理番号」フィールドに記録して関連づける。「住所」テーブルを「学籍番号」でクエリをかければ、その生徒の住所変更履歴がわかる。

（２）住所履歴を別テーブルにするが、トリガで「生徒」テーブルに変更を反映させる

「生徒」テーブル　[学籍番号],[住所]
「住所変更」テーブル　[住所管理番号],[学籍番号],[住所]→Insertトリガで「住所」を「生徒」テーブルへ記録

「生徒」テーブルに直接「住所」を記録できるようにし、住所変更があれば「住所変更」テーブルに記録する。そのときInsertトリガによって「生徒」テーブルに住所を記録するようにする。住所変更の履歴は「住所変更」テーブルに「学籍番号」でクエリを行えばわかる。

教科書的には（１）の処理が正しいと思うが、住所というような基本データは、さまざまなビューで使うことになるので、別テーブルにした場合、常にテーブル間の連携を意識しなければならない。どうしてもビューが複雑になる。（２）の方法では「住所」データが重複することになるが、「生徒」テーブルには常に最新の住所が入っていることになり、他のビューを作るときにわかりやすい。

InfoPathは2003 SP1から「改ページ」が挿入できるようになったようだ。

Microsoft Office Online 「改ページを挿入する」
http://office.microsoft.com/ja-jp/infopath/HP010957061041.aspx

Microsoft Office Online 「ページ区切りを挿入する」
http://office.microsoft.com/ja-jp/infopath/HP100240281041.aspx

Microsoft Office Online 「InfoPath 2003 Service Pack 1 の概要」http://www.microsoft.com/japan/office/previous/2003/infopath/prodinfo/sp1.mspx

InfoPathをSQL Serverに接続してクライアント・サーバーシステムにしている。InfoPathの弱いところは印刷だが、特に複数ページわたる印刷物を作成したいときに、改行の自由度が小さいところだ。

データベースに生徒データと講座データ、それを関連付ける受講データがある。ここから各生徒の時間割個票を出力したい。このときInfoPathならクエリフィールドの学籍番号を使って、一人の生徒の時間割個票を出力するのは簡単だ。しかし担任が自分のクラスの生徒の時間割個票をまとめて印刷したい、というような場合がある。

Accessなら接続先のデータのうち「学籍番号」を「グループヘッダー」にして「改ページ」しておけば、自動的に一人ずつの時間割個票がまとめて印刷処理できる。InfoPathでもこのようなグループ処理ができればいいのだが。

InfoPathをクライアントにして、SQL Serverデータベースシステムを作っている。InfoPathはデータの入出力には得意だが、印刷の自由度が小さい。そこでクライアントにAccessを使い、アクセスプロジェクトでSQL Serverに接続することも併用している。

いろいろとやってみると、これが結構便利だ。Accessのレポートで表を作ることも面倒だが、Accessはよく使っていて慣れているので、手際よく作るコツはわかっている。

もしかしたらSQL ServerとAccessだけでクライアントサーバーシステムを構築する事例もあるのではないか、と思うようになってきた。ちょっと調べてみると、Microsoftや@ITなどの記事はあるが、具体的な事例を書いたページは見当たらない。実際にやってみると工夫のしがいもあるので、またここに書いていきたい。

Microsoft Office Online 「Access プロジェクトについて (ADP)」
http://office.microsoft.com/ja-jp/access/HP052731031041.aspx

@IT「データベース・サーバのフロントエンドとしてAccessを利用する」
http://www.atmarkit.co.jp/fwin2k/win2ktips/346dbaccess/dbaccess.html

@IT 「AccessをMSDEのフロントエンドとして利用する」http://www.atmarkit.co.jp/fwin2k/win2ktips/404accessmsde/accessmsde.html

Microsoft Office Online 「アクセスプロジェクト」
http://office.microsoft.com/ja-jp/access/CH062526761041.aspx

熱い夏がまたやってくるくる～とは「子供バンド」の「サマータイムブルース」。作曲はエディ・コクランで多くのミュージシャンがカバーしている曲だ。今年もTechEdの夏がやってきた。

仕事との関係があるので決定ではないが、今年も全日程フル参加したいと思っている。昨年はリアルタイムで書けなかった「TechEdレポート」を今年は書こうと思っている。

んな訳でカテゴリ名も「TechEd 2007」から「Tech Ed 2007-2008」に変更した。

また似たようなエラーが出るようになった。今回は順調に稼動していたマシンで、あるときからInfoPathが使えなくなった。

データは「従事時間調査」というものを行うもので、単にひとつのテーブルだけがデータ接続になっている。テーブル構造の概要は次のとおり。

[職員番号],[氏名],[月],[日],[従事時間]・・・

フォームは「月」でクエリを行い、一月ごとの従事時間入力を行うようにしている。ここである教員が、4月や6月のデータは読み出せるのだが、5月のデータを読み出そうとすると「一部の動作規則を適用できませんでした」というメッセージが出てエラーになる。詳細は以下のとおり。

----------------------------------------------------------------------------

「一部の動作規則を適用できませんでした」

ドキュメント オブジェクトの query メソッドに失敗しました。
指定されたクエリを実行できません。
ファイルは有効な XML ドキュメントではありません。

無効な文字で名前が始まりました。

行 197、位置 3

--^

学籍管理のデータベース開発を行いながら同時にインフラ運用もやっている。ひとつの学校という閉じられたシステムなのでそれほど複雑ではないのだが、問題が重なるとかなり辛い状況になる。

データベースの開発では、要求にあう処理を合理的に行うために、業務の流れと役割分担に応じたセキュリティの設定、合理的なテーブル構造、ビュー、ストアドプロシージャ、トリガなどどの手法で解決するのが妥当か、既にあるデータとの整合性はどうか、これらを緻密に考えなければならない。また重要なのは、当面の処理ができるだけでなく、今後数年間にわたってデータと処理の耐久性があることも重要だ。そうなると、当面必要ではないが、おそらく後に表面化してくるであろう業務ニーズを予想しながら作るという視点も必要になる。

ネットワークインフラ運用では、TCP/IT、アクティブディレクトリ、ファイルサービス、プリンタサービス、ウェブサービス、ウィルス対策など、個々に確立した技術を組み合わることになる。つまり個々の技術の集合体として全体を俯瞰する能力が必要になる。それぞれの技術は年々進歩するため、必然的に見直しながらすすめるしかない。システム全体として5年先10年先まで使えるものを望むことは不可能なのだ。Active Directoryを使えば、とりあえず作って運用しながら見直す、ということもしやすい。

両方をやっていて思うのだが、開発という仕事は思考を一点に集中する能力が必要であるのに対し、ネットワークインフラ運用は全体を俯瞰しながらも個々の技術にのめりこまず、柔軟に切り離したりつないだりする能力が必要だ。古いものは思い切って切り捨て、新しいものに乗り換える。それを常に意識しながら、今あるものを使うという姿勢。

ネットワークインフラ運用では「とりあえず使える」という解決策をとることがよくある。プリンタが壊れれば別のプリンタを「とりあえず」繋ぎ変えて動かす、ファイルサーバーの具合が悪ければ「とりあえず」別のサーバーを立てる、などだ。しかし開発では「とりあえず別テーブルを作る」なんてことはやらない。何か不都合なことがおきれば、その原因を突き止め、根本的なところで修正しなければならない。

このように考えてみれば、SEという言葉でくくられる「開発」と「運用」は、実は似て非なる仕事であるに違いない。

いろんな経緯があり、なかなかシステムの再構築を行う機会がなかったが、現在の勤務地に異動して以来の本格的な再構築を行うときがやってきた。

これまでのシステムでインターネット接続系のものは、基本的に次のような構成だった。

ファイヤーウォール・・・WindowsNT Servwer,FireWall1
ウェブプロキシ・・・Windows 2000 Server,Microsoft Proxy Server
DNSサーバー・・・Windows 2000 Server
メールサーバー・・・Windows 2000 Server,SendMail
ドメインサーバー・・・Windows 2000 Server

システム構築当時のサーバーのスペックやソフトウエアの限界、構築の定石というものがあり、このような冗長な構成になっていた。これをよりシンプルで機能的な構成にしたいと思っていた。

ファイヤーウォール&ウェブプロキシ・・・Windows Server 2003 R2,ISA Server 2006
ドメインサーバー&DNS・・・Windows Server 2003 R2
WSUSサーバー・・・Windows 2000 Server
ファイルサーバー・・・Windows 2000 Server

改善の主眼は、なんといってもウェブアクセスの統制だ。ファイヤーウォールとプロキシの機能が低かったことをまず改善したいと思った。これをISA Serverを用いて、ActiveDirectoryと統合してウェブアクセスを管理し統制する。WSUSによって修正プログラムの適用を一元管理する。

これを機会にFloppy DiskやUSB Storegeなどのリムーバブル・ドライブの使用をすべて禁止する。

InfoPathのセカンダリデータ接続でサブクエリーを書いてデータを絞り込む手法を紹介した。

InfoPathでSQL Serverから自分の氏名を取得するには（データ接続にサブクエリーを書く）
http://blogs.sqlpassj.org/hotikisu/archive/2008/06/12/25016.aspx
セカンダリデータ接続で必要なデータだけを取得するには（データ接続にサブクエリーを書く）http://blogs.sqlpassj.org/hotikisu/archive/2008/06/12/25018.aspx

このサブクエリーを書く方法は、SQL Serverにビューを作ってもできる。次のようなテーブルがSQL Serverにあるとする。

　　生徒（学籍番号,生徒氏名,担任ユーザーID）

このとき、次のようなビューをSQL Serverに作る

　　select 学籍番号 from dbo.生徒 where ('（ドメイン名）' + 担任ユーザーID = (select suser_sname() as Expr 1))

もし担任ユーザーIDにドメイン名も含んだユーザーデータを作っておくなら次のようでいい

　　select 学籍番号 from dbo.生徒 where 担任ユーザーID = (select suser_sname() as Expr 1)

このビューに対してInfoPathでセカンダリデータ接続を作る。つまり、SQL Serverに書かれたビューも、それを呼び出すアクティブディレクトリユーザー名に対してsuser_sname()関数が正しく実行されるのだ。

InfoPathではメイン接続以外にセカンダリデータ接続を作ることができ、でデータを取得することができ、セカンダリデータ接続で取得したリストをフォームのドロップダウンリストボックスなどで選択要素として利用できる。これはとても便利だ。しかしセカンダリデータ接続では動的にクエリを行ってデータを選択することができないため、対象のテーブルの全部のデータを取得するしかない。このときに問題となるのが、ある程度のデータ量を超えたとき、フォームの実行速度が極端に低下することだ。フリーズしたのではないか、と思うほどパフォーマンスが低下する。これはぜひ後のバージョンでは解決してもらいたいが、現状では次のようなサブクエリを使って、動的にクエリを行う工夫ができる。

たとえば生徒40人のクラスが30学級あれば、全校生徒のデータは120人になる。このうち自分の担任するクラスのリストだけをセカンダリデータ接続で取得したいときには、次のようにする。

（１）次のテーブルを作る
　　生徒（学籍番号,生徒氏名,担任ユーザーID）
（２）InfoPathでデータ接続ウィザードを実行し、SQL文を次のように書き換える
　　　select "生徒氏名" from "dbo"."生徒" as "生徒" where '（ドメイン名）' + 担任ユーザーID = (select suser_sname())

つまりSQL Serverから自分のアクティブディレクトリユーザー名を取得するsuser_sname()関数を利用してサブクエリーを書き、生徒テーブルから自分のクラスの生徒データだけを取得するのだ。

このとき、テーブルの担任ユーザーIDにドメイン名も含めてデータを登録しているなら次のようでいい

　　　select "生徒氏名" from "dbo"."生徒" as "生徒" where 担任ユーザーID = (select suser_sname())

ここでは学校のクラスで担任が自分のクラスの生徒名をリストとして取得する例を説明したが、一般企業でも社員の中から自分が所属する支店の社員情報だけのリストを取得したい、といった事例が考えられるだろう。

以前、InfoPathのデータ接続でSQL Serverからアクティブディレクトリのユーザー名を取得する方法を書いた。

http://blogs.sqlpassj.org/hotikisu/articles/16073.aspx

ここで使ったsuser_sname()関数を使って、InfoPathでSQL Serverから自分の氏名を取得するデータ接続を作ってみた。方法は次のとおり。

（１）SQL Serverに次のようなユーザー情報のテーブルを作っておく
　　ユーザー（ログオンID,ユーザー氏名）
（２）InfoPathでデータ接続を作る
（３）ウィザードで適当なテーブルを選択し、SQLの編集を行う
（４）SQL文を次のように書き換える

select "ユーザー氏名" from "dbo"."ユーザー" as "ユーザー" where '（ドメイン名\）' + ログオンID = (select suser_sname())

もしユーザーテーブルのログオンIDにドメイン名も含んだデータを格納しているなら、次のようでいい。

select "ユーザー氏名" from "dbo"."ユーザー" as "ユーザー" where ログオンID = (select suser_sname())

 つまりInfoPathのデータ接続にサブクエリを書くだけでいいのだ。この手法は応用がきくだろう。

たとえば住所管理において、昨年度までの旧システムでは次のように「生徒」テーブルに「生徒住所」、「保護者住所」というフィールドで登録していた。

生徒（学籍番号,生徒住所,生徒電話番号,保護者住所,保護者電話番号）

しかし（１）生徒本人や保護者以外の住所を管理したい業務上の要求があること、（２）フィールドをダイレクトに更新するので、履歴が残らないこと、（３）電話番号も複数記録したいこと、などにより、次のようにテーブル構造を変更した。

生徒（PK学籍番号,生徒住所番号,代表保護者住所番号）
住所（PK住所番号,学籍番号,住所分類,住所）
電話（PK電話管理番号,住所番号,電話番号）

これでひとつの学籍番号に対して複数の住所を記録でき、生徒住所と保護者住所の住所管理番号を生徒テーブルに記録することで、関連付けを行うことができる。保護者の住所を複数登録することもでき、そのうちの代表保護者住所に対して郵送物を送るなどの処理ができる。電話番号も複数記録することができる。

このように住所管理を始めたが、住所にかかわるデータ処理を行うとき、いつもこれらのテーブル間連携を意識しなければならなくなった。結果としてビューの構造が一目で把握しずらいものになってしまう。

そこで次のようにテーブル構造を変更するとともに、トリガを利用して、テーブル間のリレーションを考えなくともよいようにすることにした。

生徒（PK学籍番号,生徒住所,保護者住所）
住所（PK住所管理番号,学籍番号,住所分類,住所）INSERTEDトリガ→UPDATE生徒（生徒住所or保護者住所）
電話（PK電話管理番号,学籍番号,電話番号分類,電話番号）

住所テーブルは一般の教員に対してINSERT,SELECT権限だけを与え、UPDATE,DELETEは許可せず履歴を残すことにする。住所テーブルにINSERTがあったときにトリガを起動して生徒テーブルの住所をUPDATEする。

このことで常に最新の住所データが生徒テーブルに更新され、それ以外の住所データもフレキシブルに記録できるようになる。ビューを使う必要がないので、データ構造がシンプルになる。

いくつものビューを組み合わせ、ビューのネスト状態と言っていいほどのビューを作ってしまった。作ろうと思えばいくらでも複雑なビューができてしまうので、気をつけないといけない。ついにクライアントのInfoPathから接続してもタイムアウトになってしまうくらいのビューを作ってしまった。

InfoPathからSQL Serverの複数のテーブルを参照するにはいくつかの方法がある。ひとつはテーブルを結合してひとつのビューにし、それに接続する方法だ。この方法の利点は、データ構造がSQL Serverに依存するので、InfoPathのメンテナンスが必要ないことだ。ビューを変えたければSQL Server側だけで変更すればよい。しかしこの方法はInfoPathからデータの送信ができない。

ふたつ目の方法は、InfoPathのメインデータソースに複数のテーブルをバインドする方法。この場合は、主キーさえ間違いなく設定すれば送信可能なフォームができる。しかしデータ構造を変更しようと思えば、InfoPathのフォームを編集し、データ接続を再設定しなければならない。InfoPathのデータ接続ウィザードは構造の視認性が良くないので、あまり複雑な構造は実際には作れないだろう。

そしてもうひとつは、セカンダリデータソースとしてメインデータソースと分けて接続する方法だ。これならメインデータソースは送信可能だし、セカンダリデータソースは元のテーブルやビューと一対一で接続するので構造がわかりやすい。しかしメインデータソースとセカンダリデータソースの連携には制約がある。この点については、おそらくVSTOなどで開発するとある程度融通が利くのではないか、と想像しているのだが。

複雑なビューについては、自分では合理的に作っているつもりだが、本当はもっと効率のよいクエリの書き方があるのだろうと思う。それと、SQL文として複雑であるか否かという問題と、処理速度が早いか遅いかは別問題であるので、クエリの実行速度についても検討しなければいけない時期にやってきた。ましてや今年は単年度だけの処理をやっているが、来年、再来年と年を経るごとにデータ量は増えていくわけで、そのこともパフォーマンスに影響するはずだ。というか、影響しないように作らなければならない、と言うべきか。

ある意味でシステム構築は初期のステージを過ぎ、次のステージへ進んだといえる。

システムができあがってくると、様々な要求に応じてテーブルやビューを作ることになる。さて、この増えてきたテーブルやビューをいかに整理するか。

まず命名法を決めておくこと。これは絶対に必要。でも意外に難しい。

ひとつは、その目的に応じて名前を付けるという方法がある。例えば「出欠一覧」とか「クラス名表」とか。しかしこれだとテーブルやビューの関連がわからなくなり、後のメンテナンスに支障をきたす気がする。

もうひとつは、テーブルとビューの依存関係がわかるような命名法。もとのテーブルが「出欠」だったら、「出欠_クラスごと一覧」とか「出欠_クラスごと一覧_通知表用」とかいった具合に。この方法では、テーブルやビューの依存関係が把握しやすくなり、しかもエンタープライズマネージャーのエクスプローラーで名前順にソートしたときに関連するビューが並んで表示されるから具合がいい。しかしこれだと名前がどんどん長くなる。

コードネームのような名前を付けたテーブルを作った部分もある。教科科目を保存するテーブルを、c_k1、c_k2、c_k3・・・といったように名前を付けた。この方法は覚えてしまえばエレガントなのだが、テーブル名に意味がないために、やたら使うと収拾がつかなくなるだろう。きちんとドキュメントを作っておかないと、しばらく使っていないと自分でも必要なテーブル名を探せなくなってしまいそうだ。

テーブルやビューの命名法について、実際に開発の経験豊富な人に聞いてみたいものだ。おそらく人によって違うだろうから、ベテランの人でも他人の命名法を聞くと参考になるのではないか、と思ったりもする。

学習ではなく、初めて実際的なストアドプロシージャを書いたのは、やはり正規化に関するものだった。データベースとして扱いやすいデータ構造は正規化されたものだが、帳票など実際に人間が目で見る形というのは、正規化でない形が通常である場合が多い。特にデータ数が多いほど、見易さを追求すれば非正規型にならざるを得ない。

最初に作ったストアドプロシージャは、時間割表を作るものだった。カーソルを使うものだから、最初から敷居は高かった。何度も何度も失敗し、作り直しながら完成するまで何日もかかったことを思い出す。

講座のデータは正規型で次のようになっている。

講座コード,講座名,曜日,時限

ここで週4時間ある講座コード0001の日本史Bならば、次のように4件のレコードで構成される。

0001,日本史B,月曜,1限
0001,日本史B,月曜,2限
0001,日本史B,水曜,1限
0001,日本史B,水曜,2限

これを次のような時間割表の形にするのだ。

　　　　月曜　　　　火曜　　　　水曜　　　　木曜　　　　金曜
1限　日本史B　　　　　　　　　日本史B
2限　日本史B　　　　　　　　　日本史B
3限　　　：　　　　　　　　　　　　　　：
4限　　　：　　　　　　　　　　　　　　：
　：

時間割表のテーブルを別途作っておき、カーソルを使ったストアドプロシージャで正規型のデータを拾いながら格納する、というストアドプロシージャだった。

このように正規型のデータを非正規型にする、あるいは逆に非正規型のデータを正規型にする、といった処理は、本来のデータ処理とは違ったフォーカスにある処理だが、実際には比較的多いように思われる。これをカーソルで処理したが、単にビューを作って処理する方法もあるだろう。どちらが良いかはケースバイケース、であるのだろう。

公認欠席や忌引き、出席停止の登録をするために、次のような「出欠処理登録」テーブルを作った。

学籍番号,日付,処理コード,1時限2時限,3時限,4時限,5時限,6時限,7時限,8時限,9時限,10時限,11時限,12時限

テーブルからわかるように、本校は多部制なので授業は1時限から12時限まである。学籍番号と日付、「公欠」「忌引」「出停」の処理コードを入力したら、対応する時限のフィールドに「はい=1」を登録する。非正規型ではあるが、データ登録に際しては1日のレコードが一件で完了するので、このようなデータ構造が登録しやすい。

しかし他方で出欠管理をする「出欠」テーブルは以下の構造となっている。

学籍番号,日付,処理コード,時限

つまり「出欠処理登録」テーブルでは1日の処理が1件のレコードでよいのに対し、「出欠」テーブルは正規型であるので、時限数と同じ数のレコードが生成しなければならない。この処理をするためにトリガを書いた。

トリガを実装すると、思惑通りにテーブルのデータが更新される。とても面白い。これこそプログラミングの醍醐味といえる。

携帯電話が水没し、機種変更をするならWindows Mobileにしようと思ってソフトバンクに行った、家の近所のショップでは在庫がなく、他店の在庫状況を調べてもらい、その店に行った。

こちらは機種を決めていたので、X02THが欲しい、といったのだが、「この機種は通常の携帯とは通信方法が違うので、パケット代が何倍にもなります」と脅かされた。「メールしか使わないので、それほどかさむとは思わないんだけど」と言っても、「メールだけでもパケット代は高額になります。」と言い切る。「それに修理のときも手間と時間がかかるし、修理代も高額で困ったことが実際あったんです」と譲らない。

本当にパケット代はそんなに高額になるのだろうか。結局買うのをあきらめて帰ってきたが、どうも腑に落ちない。

繰り返しテーブルを作ると、テーブルの罫線とセル内のテキストボックスの周囲が淡いグレーに設定される。これはフォームをプレビューしたときに、画面上でテーブルやテキストボックスを確認しやすいための設定だろうと思われる。しかし印刷時にはあまり美しくない。

自分で罫線を設定するには、表を右クリックして「罫線と網掛けの設定」で行うが、バリエーションがあまり多くない。決定的に困るのは、線の太さの最低が1pxであることだ。この罫線は太すぎる。たとえばAccessのビューでは、1ptの実線の罫線より細い「細線」があるし、Excelでも実線以外により細い罫線が用意されている。Wordではより細かい設定があり、0.25pt、0.5pt、0.75ptなど0.25ポイント刻みで罫線の太さが選択できる。しかしInfoPathには1pt以下の実線はない。また点線を選ぶこともできるが、なぜか点線は太さの最小値が2.25ptである。

このようにデフォルトでは太すぎる繰り返しテーブルの罫線だが、罫線を淡いグレーに変更することによって、細い奇麗な罫線に見えるようになる。ただしプリンタによっては印刷の具合は異なるかもしれない。

（１）テキストボックスの枠線をとる
表内のテキストボックスを選択し、右クリックして「罫線と網掛けの設定」を選択する。「罫線」タブでプリセットから「なし」を選択して罫線を取る。

（２）テーブルの罫線をグレーにする
繰り返しテーブルを選択し、右クリックして「罫線と網掛けの設定」を選択する。「罫線」タブで「スタイル」は実線のまま、「色」をクリックしてパレットの右端上から3番目の淡いグレーに変更する。「線の太さ」は1ptのまま。プリセットから「外枠」と「内側」をクリックして罫線を設定する。

本校は「生徒指導要録のコンピュータによる記入に係る研究指定校」になっている。生徒指導要録の電子化は、生徒の学籍管理、単位の履修修得などと一体であるので、本校のシステム構築の一環として研究を行ってきた。その報告書を書いた。

その概要は以下のとおり

1.研究推進組織
　総務部システム管理課
2.研究内容
　(1)これまでの取り組み
　　A.校務のシステム化・・・校務のシステム化に関する全般的な知見
　　B.システムの分析・・・本校が運用してきたシステムの問題点を分析
　　C.生徒指導要録に必要なデータ構造・・・履歴の記録など必要なデータ構造を整理
　(2)実施上の効果
　　A.正確な記録・・・情報を一元管理し、正確で最新の情報が共有できる。
　　B.情報の散逸防止・・・印刷された書類として情報が散逸することを防ぐことができる。
　　C.事務処理上の利点・・・蓄積された情報を効率よく利用できる。
　　D.生徒理解を支援する・・・情報の蓄積によって生徒の多面的な理解ができる。
　(3)実施上の課題
　　A.指導要録の様式変更への対応・・・指導要録の様式が変更になっても対応できなければならない。
　　B.押印の対応・・・印刷は卒業年度であり毎年の押印に対応できない。
　(4)その他課題解決に向けての方策
　　A.指導要録の様式変更への対応・・・担当者の運用構築技術の研修が必要
　　B.押印の対応・・・一枚目のみ毎年印刷して押印を保存する運用が実際的である。

以上

携帯電話から水が滴り落ちるほど、完全に水没した。

自分のミスなので仕方がないが、問題は、携帯でしか連絡がつかない知人がいることだ。困った。

昨年の12月には、新支援システムに登録された平成20年度の講座情報に基づき、在校生が受講登録を行った。そして4月には新入生の基本情報を登録し、新入生が受講登録を行った。このとき、ある問題が発生した。在校生の一部が、新年度になってから受講登録を行ったり、一度行った受講登録を変更したりしたのだ。

受講登録のデータ入力は担任の先生で行うこととしている。そのため、入力フォームでは、クラスで絞り込んで生徒を選ぶことができるようにしている。これが災いした。在校生は平成19年度のクラスで登録がされている。しかし、平成20年度になってしまうと、まだ新クラスを登録していないため、学籍番号を選択できないという問題が発生したのだ。

これはある意味で運用の問題であるともいえる。在校生は前年度に受講登録する、という運用さえ守られていれば問題ないのだ。しかし実際は運用の例外が発生する。いろんな事情で受講登録が新年度にずれ込むことは避けられない。またフォームの入力支援の問題でもあるといえる。クラスで絞込み氏名で選択する、という入力支援は便利だが、これを実装したために生徒が選択できなかった。単純に学籍番号を手作業で入力することに留めておけば問題は発生しなかった。

生徒とクラスの関係は、学籍番号,年度,クラス、というデータを作っている。結局のところ対応策としては、クラスを絞り込むクエリで、年度＝(今年度-1)という強引な手法で別のフォームを作って使ってもらった。しかしこの緊急フォームは来年も使うことになるだろう。

近い将来は、受講登録は生徒がログオンして行うことにしたい。それならWindowsログオンIDをSQL ServerからSUSER_SNAME()関数で取得して、InfoPathのフォームに落とし込むことができるからだ。この手法は役に立つ。

繰り返しテーブルで表を作って整形するというケースは多いと思われる。このとき、マウスでドラッグして行間を変えることもある程度できるが、繰り返しテーブルとセルの中にあるテキストボックスなどのコントロールの「すき間」の調節ができないなど、マウス操作だけでは思ったとおりの表にすることができない。ここでは繰り返しテーブルの行間に限ってまとめる。

繰り返しテーブルの行間に関係する値には次のものがある。（１）繰り返しテーブルのセルの高さ、（２）繰り返しテーブルのセルに設定する、中のコントロールに対する余白である「セル内のスペース」、（３）コントロールの高さ、（４）コントロールの中のテキストに対する間隔をあける「スペース」、（５）コントロールに設定する、周囲の余白を設定する「余白」。

（１）繰り返しテーブルのセルの高さ
繰り返しテーブルを右クリックし「表のプロパティ」を開き「行」タブで設定する。デフォルトで「自動的に行の高さを設定する」になっており、セルの中に書かれた文字のフォントやコントロールの大きさによって高さが伸縮する設定である。文字のフォントやコントロールの大きさ如何にかかわらず行間をあけたいときは、行の高さの最小値に値を入力して決める。

（２）セル内のスペース
繰り返しテーブルを右クリックし「表のプロパティ」を開き「セル」タブで設定する。デフォルトでは上1ピクセル、下1ピクセルに設定されている。この値は、セルの罫線と中に書かれた文字やコントロールの間の余白の値である。

（３）コントロールの高さ
セル内のコントロールを右クリックし「プロパティ」を開き「サイズ」タブで「高さ」を設定する。デフォルトでは「自動」になっており、フォントサイズによって自動的に調節される設定である。高さを決めたいときはここに数値を入れる。

（４）スペース
上記と同じくコントロールの「プロパティ」の「サイズ」タブで設定する「スペース」は、コントロールの内側のテキストとの間に間隔をあける値である。

（５）余白
上記と同じくコントロールの「プロパティ」の「サイズ」タブで設定する「余白」は、コントロールの周囲の余白を設定する値である。

セルの高さやコントロールの高さ以外に行間を決める要素として、余白に関する値が3つある。このうち「スペース」は、コントロールの中に表示されるテキストの上下にできる間隔であるが、コントロールの一般的にはセルの中に一つのコントロールまたは一つの文字列が入るので、「セル内のスペース」と「余白」は同じ余白を設定する値のよう思えるが、これらは別の設定値である。

例えば一つのセル内にテキストボックスを縦に2つ並べて作ったとき、セルに対して「セル内のスペース」を上30pxにすると、上のテキストボックスとセルの上罫線の間だけに30pxの間隔ができる。テキストボックスの「余白」を上30pxにすると、両方のテキストボックスの上に30pxの間隔ができる。

行間の狭い表を作るためには、余白に関与するこれら3つの値を、すべて0に設定すればよい。

私が現任校へ赴任したとき、生徒の学生証は磁気カードだった。専用の磁気カードライタを使って作るのだが、この磁気カードライタが接続されたコンピュータは、学校のデータベースと繋がっていなかったので、生徒の氏名や住所はシステムとは別に管理をしていた。この学生証には顔写真を入れていたが、この顔写真データを作成するためには、プリントアウトされた写真をスキャナで一枚ずつスキャンしてデジタルデータを作る、という作業をしていた。磁気データは学籍番号を記録した。

毎年280人の生徒が入学するので、年度初めには写真をスキャンするだけで何日もかかった。朝から晩までひたすらスキャンし、画像を切り抜く。まったく非人間的な業務だった。いま思い出すだけで背筋が寒くなる。この仕事を、一言も愚痴らず黙々としていたのは、私よりも1年前に赴任していた同僚のM先生だった。まったく頭が下がる思いであったと同時に、この業務からは一日も早く開放しなければならないと思った。

また生徒の住所が変わったとき、学校本体のデータベースに住所変更を変更しても、学生証のデータは切り替わらない。こちらのデータベースも手作業で変更しなければならなかった。ひとつのシステムとして繋がっていればしなくて良い同じ仕事を2回やらなければならない、ということは、それがいかに簡単な業務であっても精神的に辛い。また簡単な業務であるほど、一方を更新し他方は更新を忘れる、という事故も発生しやすい。

それ以上に学生証の運用上の問題もあった。磁気カードの単価が高いこと、作成に要する作業が膨大になることから、毎年発行することをせず、入学時に作ったものを卒業まで使い続けることにしていた。本校は学年制ではなく、生徒の在籍期間というものが決まっていないので、有効期限を書くことができなかった。そこで退学や卒業をしても、学生証が不当に使われるという危険があった。

まず当面の対策として行ったのは、学生証に有効期限を明示することだった。生徒の在籍期間は決まっていないが、とりあえず入学した時点から3年間を有効期間とし、3年に達するまでに卒業したときは回収する、3年を超えて在籍するときは、4年目に再発行する、ということにした。しかし途中退学した生徒の学生証を回収しきれない場合の問題は残る。また写真が入学したときのままであるということも問題であった。15歳から18歳までの生徒の容姿の変化は大きい。3年という期限は長すぎるのだ。やはり学生証は毎年発行するべきである。

なぜ本校の学生証が磁気カードだったかといえば、校内に磁気カードリーダーを備えたいわゆるキヨスク端末があり、学生証の磁気カードを使って出欠状況や修得単位をシステムから照会できるようになっていたからだ。しかし学生証＝磁気カードである必要はない。そこで次の年には、端末を利用するカードは「生徒情報カード」という名称に変え、カードには学籍番号だけを書き、学生証は別に切り離すことにした。学生証は他の多くの学校がやっているように、紙のカードに住所や氏名を印刷し、写真を糊で貼って手作業で作ることにした。生徒証の管轄を生徒部にまかせ、実際の作業は担任が分担してやることにした。耐久性をもたせるためにラミネートの機械を購入し、作った学生証をラミネートすることにした。これで学生証は毎年新しく撮った写真で作り直すことができ、磁気カードは在学中ずっと使い続けるものにすることができた。

最後に残った問題は、住所管理である。学生証の管轄を生徒部にしたために、担任は生徒の住所変更があったとき、システム管理課と生徒部の両方に住所変更届を出さなければならなくなった。住所データが別々に管理されている問題は依然解決されていない。これを解決するためには、住所データはシステムで一括管理し、システムに生徒証発行機能を組み込まなければならない。これはシステム全体の再構築時に実現しようと計画した。

今年完成した新支援システムでは、生徒の住所変更があったとき、担任が住所データを更新することにした。このようなデータ更新は、担任が行うのが最も正確で早くできる方法だ。この一元化された生徒データをもとにSQL Serverに生徒証用のビューを作成し、SQL Serverに接続するアクセスプロジェクトを作成し、生徒部が管理していた生徒証のアクセスファイルから生徒証のレポートをコピーしてデータ接続をセットした。この作業は約30分。実に簡単に生徒証発行機能を組み込むことができた。このような機能を作る場合、最も時間がかかる作業は出力イメージのレイアウトを作成することだ。カード型の出力レポートを作るために、縦横全体の大きさ、文字の配置、フォントの大きさ、そして何よりもアクセスは罫線の調整に時間がかかる。また一枚の用紙に複数枚配置する設定も必要だ。表と裏の位置を合せることも苦労する。

思えば赴任してから学生証の問題をここまで整理するのに5年かかった。なぜもっとよく最初から考えておかなかったのか、と愚痴っても仕方ない。しかし実際に始ってしまった運用を、途中から変えるにはエネルギーが必要だった。問題があっても見えないふりをしたり、仕方ないで済ましてしまう同僚が多かった。問題点がわかっていても具体的な解決方法が見出せないこともある。業務にシステムが深くかかわっている場合には、業務改善の方向性を見出すのはITセクションの仕事でもあるのだ。そこで問題点と解決策を文章化し、きちんと会議で指摘して全体のものとしながら改善をすすめていった。運用を変えると仕事が増える部課があるので、露骨な抵抗にもあった。だからといって業務を丸抱えすると自滅する。少しずつ前に進みながら、ようやく解決した。

感無量だ。

教科書購入票の出力にあたって、問題があった。ある教科書が昨年度の採用教科書と同じであるのに、異なる教科書として登録してあり、昨年度に購入した教科書を重複して買うことになっていたのだ。このことは、ある生徒の申し出から明らかになった。

以前書いたように、本校は完全に単位制で生徒によって使用教科書が全く違う。また受講登録しても欠席時間オーバーで未履修となり、次年度に再び同じ講座を受講する生徒が少なからずいる。そのために、年度初めの教科書販売では、個々の生徒の受講登録データに加えて、昨年度までに購入済みの教科書データを重ね合わせて購入票を作る必要がある。そのデータに一部間違いがあったのだ。

在校生が昨年度までに購入した教科書データは、旧のシステムに入っている。そのデータを取り出して新システムに移したのだが、このとき、旧システムで管理していたコードを変換したのだ。

高等学校の教科書というものは、文部科学省の検定を受けたものであり、教科書会社のコードと教科書のコードの2つで管理している。しかし旧システムでは、採用した教科書を一連の通し番号で管理していた。本校の発足当時は、その管理方法が合理的だと判断されたのだ。ところが数年前から、文部科学省の行う教科書需要数の調査が電子化され、データで提出するように求められるようになり、同時にすべての教科書を一意のコードに決めるということが行われた。文部科学省が決めたコードであるから、これを使わない手はない。そこで新システムでは教科書の管理を、文部科学省の決めるコードで行うこととした。

そのために、旧システムのコードを新システムに移行するとき、文部科学省のコードに置き換える必要が生じたのだ。これが手作業になった。

教科書の名称は単純である。ほとんどの教科書は教科の名前を冠するのだから、そのバリエーションは少ない。余談になるが、英語だけは違う。「All Aboard! English」とか「SUNSHINE English Course」といったように個性的な教科書名が使われる。しかし一般的な教科書名は、その科目名をつけられるので、例えば化学の教科書ならば「化学ⅠB」といった味もそっけもない教科書名となる。しかし教科書も何年かごとに内容を改訂されるので、そのときは「改訂化学ⅠB」とか「新編化学ⅠB」、さらには「新訂化学ⅠB」などと、内容が新しくなったことを何らかの形で教科書名に反映させる工夫がなされている。

ところが、だ。今回、教科書コードの整理を間違った教科書は、教科書名が全く同じであるのにもかかわらず、内容が改訂されていたのだ。それをデータ移行の際に気づかなかった。もちろん、教科書コードを比べると違っているということがわかったはずだが、当然書籍名も変わっているはずだ、という思い込みが災いした。

書籍名称は同じだが、平成19年度から改訂になっていた、ということを見逃したのだ。正直なところ、教科書会社を恨みもした。なぜ全く同じ書籍名なのだ、と。そのために、昨年と同じ教科書を必要とする生徒に、買わなくてよいというデータを与えることができなかった。返本しなければならない。いったい何名の生徒が返本の対象になるのか、を調べた。データベースの教科書購入データをバックアップした後、書籍コードの訂正を行って、さらに教科書購入データを出力し、その差を点検した。すると17名の生徒が対象であることがわかった。人数的にはそれほど多くなかったので、やや、ほっとした。

しかし、その後、こんどは別の教科書で、改訂されているので昨年度の教科書は使えず、同じ講座を受講しても新たに教科書を購入しなおさなければならないケースがあることが判明した。これも教科書名が全く同じケースだった。こちらは返本ではなく追加購入になるので、問題の影響は小さかったといえるが、余計な手間を必要としたことには変わりない。

つくづくデータの移行は難しいと実感した。そして長期間使える「持久力のある」コード体系、データ移行にも耐えうる「意味のある」コード体系を考えることの大切さも身にしみた。