ホチキス先生の「プログラマーと呼ばれたい」

「究極無比！Windows7のコマンドプロンプトを完全解説！ユーザーからエンジニアまで仕事がすいすい捗る最強リファレンス」と表紙にコメントが書かれているとおり、まさに他に類比なき本である。このようなコンピュータ関係の解説本では、主要なアプリケーション、主要な技術に関して類似の本が何冊も出版されることが一般的だが、この本に関しては最初にして究極の本が出た、という印象である。

Windowsに限らず他のOSでも、今日的な一般用途向けコンピュータはGUIによる操作が行われる。GUIとは「グラフィカル・ユーザー・インターフェース」で画面に表示されるアイコンやメニューをマウスなどのポインティングデバイスで選択しながら操作する方法である。この方法のメリットは、アイコンの絵柄から機能を類推することができ、また文字によって詳細な説明を見ながら操作できるので、覚えることが少なくてすむということである。だから一般ユーザーに支持され普及した。

しかしGUIですべての操作が満足にできるかというとそうではない。およそ世の中のあらゆることがそうだが、いくつかの選択肢があったとき、ある方法が他の方法に比べてすべて勝っている、ということはない。ものごとには利点と欠点が必ずある。GUIの欠点としては、見えているものだけが操作対象になるので、いくつか複数の設定項目が影響する操作では全体が把握しにくいこと、操作が感覚的に陥りやすいのでうっかりクリックミスなどで間違ったときに気が付きにくいこと、そしてコンピュータの設定について必ずしも全ての項目についてGUIが提供されているわけではないことだ。

面白いことに若い人を中心にして、意外にもコマンドによるコンピュータの操作が受け入れられているようだ。コマンドプロンプトでバッチ処理をしている、レジストリの設定を自分でカスタマイズしているなど、「パワーユーザー」と称されるようなユーザーが増えているように感じる。GUIによる操作にあきたらず、コンピュータの性能をフル活用したいという気持ちの表れだろう。そしてもちろん、コマンドプロンプトの恩恵を最大限に活用できるのはシステム管理者である。

Windowsコンピュータシステムにおいて最も効果的に管理する方法はActive Directoryによる管理だ。複数のコンピュータを複数のユーザーが入れ替わり立ち代わり使う環境では、Active Directoryによる管理が必須である。このような環境でまだActive Directoryによる管理をしていないところがあるなら、それはずいぶん損をしている。時間と手間と、そして何よりもセキュリティ上のリスクを背負っていると断言する。ドキュメントなど生成したコンテンツの共有、管理も効果的にできないはずだ。情報の正しい共有、管理ができず、あちこちの部課で似たような文書を作り、さらにそれら相互に矛盾をきたしカオス状態となっているはずだ。

Active Directory管理の基本はそれほど難しくない。基本はユーザー管理、ポリシー管理、セキュリティ管理、リソース管理である。リソース管理の主要なものはファイルサーバーのフォルダ管理とプリンタ共有の管理だろう。これらはある一定までGUIでできる。だがGUIだけでは完璧ではない。それにはレジストリに関する知識と、もうひとつはコマンドに関する知識である。

Active Directoryにはコンピュータの設定を変える機能がグループポリシーとして用意されている。しかし標準的に搭載されたグループポリシーによってコンピュータの全ての設定を変えることはできない。コンピュータの設定を自由に変えたいならばグループポリシーの知識を持ち、自分でグループポリシーテンプレートを作る必要がある。グループポリシーテンプレートを自分で作ることができるようになれば完璧だ。

より詳細な機能設定を行い管理するにはログインスクリプトを使う。ログインスクリプトはActive Directoryで管理でき、特定のユーザー、特定のグループに対してログイン時に特定のスクリプトを実行させることができる。このログインスクリプトはコマンドによる記述を行う。ここでこの「Windows コマンドプロンプトポケットリファレンス」の威力が発揮される。この本を読むと、コンピュータの機能をカスタマイズするとき、どのようなコマンドを使えばいいかがわかる。

コマンドの実行によってレジストリの値を変えることもできる。グループポリシーテンプレートを使うよりもログインスクリプトで実行した方が良い場合もある。この本にはレジストリの値を取得したり変更したりするコマンドについても、もちろん、説明されている。しかも対象OSはWindows 2000からWindows7までと広範囲にわたっている。この本が「究極無比」とうたわれる所以である。

この本の特徴として、序章に「コマンドの基礎知識」、第一章に「Cmd.exeの内部コマンド編」が書かれていることがある。「コマンドの基礎知識」では、コマンドを活用するために前提となる知識が説明されている。コマンドの文法、ファイルシステム、フォルダツリー、パス、ユーザーアカウント制限などについてである。「Cmd.exeの内部構造」ではDIRやCD、MD、COPY、DELなどの内部コマンドの説明がある。これらの知識は長年従事してきたシステム管理者や経験豊富なパワーユーザーにはおおむね理解されていることかもしれないが、これからコマンドの使い方を学ぼうと思う者には必須の知識である。またある程度知っているという者にも改めて知識を確認するという意味で読んでおいた方がいい。この2章で76ページが割かれているが、ここを読むだけでもこの本の値打ちはある。

第6章の「ネットワークコマンド編」もシステム管理者には随喜の章である。とかくネットワーク障害は対策が難しい。いったいどこがどうなってネットワークに不具合がおきているか、なかなかGUIだけではわかりにくい。こんなときコマンドを使ってコンピュータやネットワークの状態を調べることができる。ネットワーク管理者にも必携の書だ。「ネットワークコマンド編」には32のコマンドが解説され、65ページも費やされている。ネットワーク関係のコマンドは豊富なオプションを持つものが多く、そのオプションの解説も詳細でわかりやすい。ネットワーク管理者は中途半端なネットワーク管理の解説本を買うよりも、この本を買った方がいい。

特にこの序章「コマンドの基礎知識」は高等学校の教科「情報」の教員にもお勧めしたい。高等学校の教科「情報」ではGUIとCUIの特徴などを教えなければいけないが、CUIつまりキャラクタベース・ユーザー・インターフェースはコマンドプロンプトのことであり、CUIを授業で扱うときに必ず役に立つ。また実習プランの作成には、この本のリファレンス項目の中から生徒が興味を持ち、効果的な理解につながる課題を選ぶことができるだろう。

一般ユーザーでも自分のコンピュータを縦横無尽に使いこなしたいと思っているパワーユーザーや、コンピュータのトラブルに悩まされており解決したいと思っているユーザー、そして何よりもシステム管理者にとって「Windows コマンドプロンプトポケットリファレンス」は座右の書となるはずだ。またWindows8の開発も進んでいるようなので、筆者にはぜひWindows8も対象に含めた改訂版をタイムリーに出してもらいたい。

学校の情報インフラ管理のうち最も大きな厄介ごとはプリンタの故障であるような気がする。ドメインコントローラーによってActive Directoryのユーザー管理を行い、Webアクセス、ファイルサーバーなどを運用しているが、何らかの障害がおこったとき、他の何らかの方法で回避してもらえるなら、あるいは復帰を待ってもらえるならいい。しかしプリンタの障害だけはなかなか他の方法で回避してもらえず、また今すぐ使いたいと言われることが多い。

Webアクセスの障害はたいてい待ってもらえる。学校の場合はまだリソースを校外に置くケースは少なく、Webを使う場面の多くはWWWの情報検索なので、「Webが使えないと仕事にならない」というケースは、今のところ、まだ、ほとんどない。ファイルサーバーも重要なインフラだ。ファイルサーバーにアクセスできなくなったとき、現在作業中のものをローカルのハードディスクに保存してもらったりUSBなどの外部メモリに退避してもらうことはできる。保存してあるファイルを呼び出すことはできないが、多くの場合は待ってもらえる。またWindows Serverのファイルサービスは安定しており、あまり障害がおこることもない。

プリンタの問題はヒューマンな問題でもある。頑丈に見える業務用のレーザープリンタも内部はデリケートな構造であり、そして多くの人はそのことを意識していない。紙がなくなれば各自で紙を補給するのだが、給紙トレイの扱いはぞんざいで、用紙サイズを決めるレバーはがしゃがしゃしているうちにずれてしまい、そのまま、力任せにプリンタへ差し込まれる。

紙が詰まるのもあたりまえである。

<Fig.1 プリンタに詰まった紙の切れ端が出てきた>

紙が詰まったとき、たいていは印刷をした本人がプリンタを開いて紙を取り出すことになるのだが、いつも慎重に、丁寧に取り除いてくれるとは限らない。紙を取り出す途中で破れ、切れ端がそのまま詰まったままになっていても、自分の印刷さえ出てくれば後は気にしない、という人も、なかには、いる。

給紙がうまくいかず、紙詰まりばかりおこる、というとき、しばらくするとこんな具合に紙の切れ端が出てくることがある。また詰まった紙を引き出すときや、詰まった紙の切れ端が部品を傷つけてしまうこともある。

プリンタからスポンジのようなものがぼろぼろ出てくるようになった。どうやら内部の給紙ローラーを傷つけてしまったようだ。

<Fig.2 レーザープリンタの内部からスポンジの細切れが出てきた>

プリンタの具合が悪いとき、「次の授業で使うプリントを印刷したいのですぐ直してくれ」と言われることがある。「授業で使う」というのは学校にとって最優先事項である。もちろん、プリンタのトラブルは想定内なのでネットワーク上には何台かのプリンタがあり、ローカルUSB接続になっているクライアントPCも職員室に置いてあるのだが、自分がどのネットワークプリンタに印刷キューを出したか意識できない人が多く、そもそもどのプリンタがどの名前かわからない場合もある。USB接続の端末を使うには自分の席から経って職員室端のコーナーに行かなければならず、面倒がられる。

だが、こうなってしまってはおしまいだ。ローラーが破損しているらしい。部品の交換が必要だ。

とにかくプリンタの故障には泣かされる。プリンタサーバーの問題か、ネットワーク経路の問題か、プリンタのネットワーク機能の問題か、トナー切れか、トナー以外の交換部品の消耗か、あるいは給紙など物理的な故障なのか。たいへん障害の原因範囲が広い。そして修理は緊急を要求される。

この際プリンタメーカーにも不満を書いておくと、技術革新もいいのだが、あまりにも部品仕様の変化が激しすぎる。たとえば給紙トレイに不具合がおこることは多いが、同じメーカーであってもほとんどの機種で給紙トレイの流用ができない。本体に取り付け異なるサイズの用紙を装填できる「給紙ユニット」なども、本体並みに高い値段であるにもかかわらず、たいていはその機種専用を買わされる。もちろん、トナーも同じだ。

もうそろそろ給紙ユニットや給紙トレイ、トナーなどデファクトスタンダードが決まらないものか、と思う。メーカーにとっては常に新しく自社メーカーの部品を買わせたいところだと思うが、値段の点だけでなく管理運用の点でも、少しでも共通化をすすめてほしいものだと思う。

いささか大上段に構えたタイトルにしたが、実際におこったことは些細なことである。しかし、今日はあらためてシステムを作ることの難しさを考えさせられた。

今日のテーマはシステム構築における純粋な技術の話ではなく、人の思考や行動といったヒューマンな側面についてである。しかしシステム開発は技術的に完全であればよいものではなく、ヒューマンな要素を十分に考慮しなければならない。また狭い意味でのコンピュータシステムだけを考えるのではなく、データ入力の帳票のあり方、作業の方法なども見直さなければならないケースもある。

私は勤務校でSQL Serverをデータベースにし、InfoPathとAccessを組み合わせた、いわゆる「OBA開発」の手法でクライアントサーバー型の「校務システム」を構築し、運用している。このシステムの基本は、単位制高校である本校の講座編成、時間割、履修登録、出欠、考査点、成績、修得単位など、教務処理を行うものである。それに加えて、通知表などを家庭に発送するための住所管理、職員の勤務時間を集計する従事時間集計、学校評価のアンケート集計など校内の情報管理を一元的に行うものへ発展させている。「OBA開発」の利点は、運用しながらシステムを改良することがやりやすいところだ。

このシステムに今年度から生徒の保健情報も扱うことにした。身長、体重などの健康記録に加えて、内科検診など検査結果も処理できなければならない。これらのデータをどのようにデータベース化するかについては、養護教諭つまり保健の先生と相談しながら設計し、実際のデータに対応できるものにした。このあたりの詳細は、また別にblogにまとめるつもりだ。

さて前置きが長くなったが、このシステムに「結核検診結果」を入力することになった。結核検診について、SQL Serverのテーブル構造は次のようになっている。

＜SQL Serverのテーブル構造＞
学籍番号 char(7)
年度 char(2)
結核検診 char(2)
結核検診詳細 varchar(50)

「結核検診」フィールドはコード管理し、00が「未受診」、01が「異常なし」、02が「異常あり」とし、所見があったときは「結核検診詳細」フィールドに自由記述することとした。

これにデータを入力するためのInfoPathフォームは次のようなものである。

＜Fig.1 結核検診結果を入力するInfoPathフォーム＞

SQL Serverで「結核検診」フィールドのデフォルト値を00にしておき、ボタンで01または02に変更できるようにする。「結核検診詳細」テキストボックスは、「結核検診」フィールドが02でなければグレーアウトし、読み取り専用になるようにしておく。これはInfoPathのテキストボックスのプロパティで「条件付き書式」で設定する。結核検診の結果が「異常あり」でなければ、詳細は入力できないようにしておくのだ。入力間違いを少なくする仕掛けだ。

さて、入力作業をしているところに、ふと、立ち寄って後ろから見ていると、なにかおかしいことに気づいた。次のような入力画面が見えたのだ。

＜Fig.2 目にとまったおかしな入力画面＞

結核検診の結果を入力しているのに、詳細が「脊柱側湾」となっている。入力担当は若い男性教員だ。どうやら養護教諭に頼まれてかわりに入力しているらしい。

「脊柱側湾」って、結核と関係ないんじゃない」「はあ。」「それは内科検診の項目だから、入力フォームを間違っていると思うよ」「はあ。でも結核検診の結果に書いてあるんです。養護教諭の先生がとりあえずそこに入力しておいて、って言ったので」

そこで入力のために使っている検診結果の表を見ると、確かに次のように書かれている。氏名はもちろん仮名である。

＜Fig.3 データ入力に使った結核検診の結果表＞

「結核検診」の記録のはずなのに、結核と関係ない「脊柱側湾」の所見が書かれている。これはおかしいのではないか。そこで養護教諭に事情を問いただした。すると、こういうことである。

結核検診はレントゲンなので、結核の疑いのあるなしだけでなく、脊柱側湾つまり脊柱が曲がっている症状もわかることが多いのだ。そこで慣習として、いわばサービスみたいなものとして、脊柱側湾の症状がレントゲンからわかれば、検査機関が所見に書いてくれるということなのだ。

養護教諭の立場からすると、少しでも多くの症状が早く発見できればよいのだろうが、データ入力上は間違いの原因になる。この生徒は、脊柱側湾であるが、結核の異常はないのである。しかし、上のような入力では、結核検診で異常が発見されたことに集計されてしまう。

何が問題なのか。まず入力に使う結果用紙の様式が問題である。脊柱側湾を結核検診で所見に書くなら、所見の欄を2つに分け、まず結核検診の結果を書き、それとは別にその他の所見を書くべきである。検査結果の用紙を見直したい。

もし検査用紙の見直しができないならば、データ入力において、やはりそのデータに関する、ある程度の知識を持っていること、データがどのように集計されるべきなのかという意味を理解していることが必要である。書式がデータ入力に即していなかったり、記入の仕方があいまいであっても、きちんと判断できる人間が入力するなら問題ない。

今回のケースは些細なこと、また結核検診という、まず全員が異常なしとなるだろう記録であったので、このまま間違い入力をしてしまっても、後で間違いが発見されただろう。しかしこのようなケースが他の例でも起こりうることであり、いかに正しく設計されたシステムであっても、間違ったデータ入力が見過ごされて信頼性のないデータで汚染され、全体として機能しないシステムに陥る危険を垣間見た気がする。

年度末に近づき、多くの学校では一年間のまとめをする時期になったと思う。本校でもこの一年の取り組みのまとめとして、学校評価を行うことになった。

本校の学校評価では、いくつかの大項目の下に、小項目として50弱の項目を目標として設定した。これらの小項目に対して、それぞれ教員が1から4までの評価を与えることにしている。このようなアンケート式のデータ集計は、InfoPathとSQL Serverが最も得意とするところである。しかしテーブル構造や集計については、少し工夫を要するところがある。

InfoPathフォームはSQL Serverのテーブルに対して1対1の対応が得意である。そこでやや強引ではあるが、テーブル構造として次のようなものを作成した。

———————-（ここからテーブル作成SQL）———————-

CREATE TABLE gakkohyoka_t_hyoka (
    [shokuinbango] [char] (6) ,
    [inputtime] [datetime] ,
    [01] [char] (2) ,
    [02] [char] (2) ,
    [03] [char] (2) ,
    [04] [char] (2) ,
    [05] [char] (2) ,
    [06] [char] (2) ,
    [07] [char] (2) ,
    [08] [char] (2) ,
    [09] [char] (2) ,
    [10] [char] (2) ,
    [11] [char] (2) ,
    [12] [char] (2) ,
    [13] [char] (2) ,
    [14] [char] (2) ,
    [15] [char] (2) ,
    [16] [char] (2) ,
    [17] [char] (2) ,
    [18] [char] (2) ,
    [19] [char] (2) ,
    [20] [char] (2) ,
    [21] [char] (2) ,
    [22] [char] (2) ,
    [23] [char] (2) ,
    [24] [char] (2) ,
    [25] [char] (2) ,
    [26] [char] (2) ,
    [27] [char] (2) ,
    [28] [char] (2) ,
    [29] [char] (2) ,
    [30] [char] (2) ,
    [31] [char] (2) ,
    [32] [char] (2) ,
    [33] [char] (2) ,
    [34] [char] (2) ,
    [35] [char] (2) ,
    [36] [char] (2) ,
    [37] [char] (2) ,
    [38] [char] (2) ,
    [39] [char] (2) ,
    [40] [char] (2) ,
    [41] [char] (2) ,
    [42] [char] (2) ,
    [43] [char] (2) ,
    [44] [char] (2) ,
    [45] [char] (2) ,
    [46] [char] (2) ,
    [47] [char] (2) ,
    [48] [char] (2) ,
    [49] [char] (2) ,
    [50] [char] (2) ,
    [hyokaiken] [varchar] (2000) ,
    [unneiiken] [varchar] (2000) 
)

———————-（ここまでテーブル作成SQL）———————-

フィールド[shokuinbango]に職員番号を生成しておき、[inputtime]にInfoPathフォームで入力したときの日付を入れる、フィールド[01]から[50]までにそれぞれの項目の1から4評価をストアし、最後の[hyokaiken]と[unneiiken]には自由記述で文を入力できるようにする。このようなテーブルにすると、InfoPathフォームは作りやすい。

しかし問題は集計の方法だ。これがExcelの表ならば、各列の最後にcountif()文を使って各評価の個数を集計するところだが、SQL Serverではそうはいかない。

そこで、まず、このテーブルの値を正規化するビューを作る。次のようなビューだ。

———————-（ここからビューのSQL）———————-

SELECT                  ’01′ AS 項目, [01] AS 評価, COUNT(01) AS 回答数
FROM                     gakkohyoka_t_hyoka
GROUP BY          [01]
UNION
SELECT                  ’02′ AS 項目, [02] AS 評価, COUNT(02) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_02
GROUP BY          [02]
UNION
SELECT                  ’03′ AS 項目, [03] AS 評価, COUNT(03) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_03
GROUP BY          [03]
UNION
SELECT                  ’04′ AS 項目, [04] AS 評価, COUNT(04) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_04
GROUP BY          [04]
UNION
SELECT                  ’05′ AS 項目, [05] AS 評価, COUNT(05) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_05
GROUP BY          [05]
UNION
SELECT                  ’06′ AS 項目, [06] AS 評価, COUNT(06) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_06
GROUP BY          [06]
UNION
SELECT                  ’07′ AS 項目, [07] AS 評価, COUNT(07) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_07
GROUP BY          [07]
UNION
SELECT                  ’08′ AS 項目, [08] AS 評価, COUNT(08) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_08
GROUP BY          [08]
UNION
SELECT                  ’09′ AS 項目, [09] AS 評価, COUNT(09) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_09
GROUP BY          [09]
UNION
SELECT                  ’10′ AS 項目, [10] AS 評価, COUNT(10) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_10
GROUP BY          [10]
UNION
SELECT                  ’11′ AS 項目, [11] AS 評価, COUNT(11) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_11
GROUP BY          [11]
UNION
SELECT                  ’12′ AS 項目, [12] AS 評価, COUNT(12) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_12
GROUP BY          [12]
UNION
SELECT                  ’13′ AS 項目, [13] AS 評価, COUNT(13) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_13
GROUP BY          [13]
UNION
SELECT                  ’14′ AS 項目, [14] AS 評価, COUNT(14) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_14
GROUP BY          [14]
UNION
SELECT                  ’15′ AS 項目, [15] AS 評価, COUNT(15) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_15
GROUP BY          [15]
UNION
SELECT                  ’16′ AS 項目, [16] AS 評価, COUNT(16) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_16
GROUP BY          [16]
UNION
SELECT                  ’17′ AS 項目, [17] AS 評価, COUNT(17) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_17
GROUP BY          [17]
UNION
SELECT                  ’18′ AS 項目, [18] AS 評価, COUNT(18) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_18
GROUP BY          [18]
UNION
SELECT                  ’19′ AS 項目, [19] AS 評価, COUNT(19) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_19
GROUP BY          [19]
UNION
SELECT                  ’20′ AS 項目, [20] AS 評価, COUNT(20) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_20
GROUP BY          [20]
UNION
SELECT                  ’21′ AS 項目, [21] AS 評価, COUNT(21) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_21
GROUP BY          [21]
UNION
SELECT                  ’22′ AS 項目, [22] AS 評価, COUNT(22) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_22
GROUP BY          [22]
UNION
SELECT                  ’23′ AS 項目, [23] AS 評価, COUNT(23) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_23
GROUP BY          [23]
UNION
SELECT                  ’24′ AS 項目, [24] AS 評価, COUNT(24) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_24
GROUP BY          [24]
UNION
SELECT                  ’25′ AS 項目, [25] AS 評価, COUNT(25) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_25
GROUP BY          [25]
UNION
SELECT                  ’26′ AS 項目, [26] AS 評価, COUNT(26) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_26
GROUP BY          [26]
UNION
SELECT                  ’27′ AS 項目, [27] AS 評価, COUNT(27) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_27
GROUP BY          [27]
UNION
SELECT                  ’28′ AS 項目, [28] AS 評価, COUNT(28) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_28
GROUP BY          [28]
UNION
SELECT                  ’29′ AS 項目, [29] AS 評価, COUNT(29) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_29
GROUP BY          [29]
UNION
SELECT                  ’30′ AS 項目, [30] AS 評価, COUNT(30) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_30
GROUP BY          [30]
UNION
SELECT                  ’31′ AS 項目, [31] AS 評価, COUNT(31) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_31
GROUP BY          [31]
UNION
SELECT                  ’32′ AS 項目, [32] AS 評価, COUNT(32) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_32
GROUP BY          [32]
UNION
SELECT                  ’33′ AS 項目, [33] AS 評価, COUNT(33) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_33
GROUP BY          [33]
UNION
SELECT                  ’34′ AS 項目, [34] AS 評価, COUNT(34) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_34
GROUP BY          [34]
UNION
SELECT                  ’35′ AS 項目, [35] AS 評価, COUNT(35) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_35
GROUP BY          [35]
UNION
SELECT                  ’36′ AS 項目, [36] AS 評価, COUNT(36) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_36
GROUP BY          [36]
UNION
SELECT                  ’37′ AS 項目, [37] AS 評価, COUNT(37) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_37
GROUP BY          [37]
UNION
SELECT                  ’38′ AS 項目, [38] AS 評価, COUNT(38) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_38
GROUP BY          [38]
UNION
SELECT                  ’39′ AS 項目, [39] AS 評価, COUNT(39) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_39
GROUP BY          [39]
UNION
SELECT                  ’40′ AS 項目, [40] AS 評価, COUNT(40) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_40
GROUP BY          [40]
UNION
SELECT                  ’41′ AS 項目, [41] AS 評価, COUNT(41) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_41
GROUP BY          [41]
UNION
SELECT                  ’42′ AS 項目, [42] AS 評価, COUNT(42) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_42
GROUP BY          [42]
UNION
SELECT                  ’43′ AS 項目, [43] AS 評価, COUNT(43) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_43
GROUP BY          [43]
UNION
SELECT                  ’44′ AS 項目, [44] AS 評価, COUNT(44) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_44
GROUP BY          [44]
UNION
SELECT                  ’45′ AS 項目, [45] AS 評価, COUNT(45) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_45
GROUP BY          [45]
UNION
SELECT                  ’46′ AS 項目, [46] AS 評価, COUNT(46) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_46
GROUP BY          [46]
UNION
SELECT                  ’47′ AS 項目, [47] AS 評価, COUNT(47) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_47
GROUP BY          [47]
UNION
SELECT                  ’48′ AS 項目, [48] AS 評価, COUNT(48) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_48
GROUP BY          [48]
UNION
SELECT                  ’49′ AS 項目, [49] AS 評価, COUNT(49) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_49
GROUP BY          [49]
UNION
SELECT                  ’50′ AS 項目, [50] AS 評価, COUNT(50) AS 回答数
FROM                     gakkohyoka_t_hyoka AS gakkohyoka_t_hyoka_50
GROUP BY          [50]

———————-（ここまでビューのSQL）———————-

ひたすら長いSQL文だが、構造は簡単なUNIONクエリの繰り返しなので、機械的に作ることができるはずだ。このSQL文によって、「項目」、「評価」、「回答数」というビューが得られる。結果はSQL Server Management Studioの編集画面を見てもらうと一目瞭然だろう。

＜Fig.1 : UNIONクエリによるデータの途中集計＞

この後はPIVOTによる集計を行う。クエリは以下のとおり。

———————-（ここからPIVOTのSQL）———————-

SELECT 項目
    ,SUM(CASE WHEN 評価 = ‘Ａ’ THEN 回答数 ELSE 0 END) AS 評価Ａ,
    ,SUM(CASE WHEN 評価 = ‘Ｂ’ THEN 回答数 ELSE 0 END) AS 評価Ｂ,
    ,SUM(CASE WHEN 評価 = ‘Ｃ’ THEN 回答数 ELSE 0 END) AS 評価Ｃ,
    ,SUM(CASE WHEN 評価 = ‘Ｄ’ THEN 回答数 ELSE 0 END) AS 評価Ｄ
FROM v_gakkohyoka_shu
GROUP BY 項目

———————-（ここまでPIVOTのSQL）———————-

これもSQL Server Management Studioの編集画面を見てもらうと直感的にわかるだろう。

＜Fig.2 : PIVOT集計のビュー＞

あとはこのビューに対して、画面に表示する単純なInfoPathフォームを作るだけだ。こうしておけば、アンケートの入力が終わった時点で、即集計結果を出すことができる。

SQL ServerのようなデータベースとExcelを単純に比べることは意味がないが、このような集計をするにはExcelは得意であるが、SQL Serverでやろうとすると手間がかかることは間違いない。しかし一度作っておけば、毎年同じ処理をこのテーブルとビューでできるので、省力化できる。項目がいくら増えても、選択肢が増えても、職員数が変わっても、ほとんど変更することなく集計ができる。

東京の勉強会に続いて大阪でも勉強会をする。東京の勉強会のテーマはデータベースにポイントを絞ったが、大阪の勉強会では広く「教育の情報化」をテーマにした。

今回の勉強会は講師陣がスペシャルである。

まず、昨年末に満を持して発売された、シャープのメディア情報端末「ガラパゴス GALAPAGOS」について、シャープの方より技術的な話をうかがう。昨年度はいわば「電子書籍元年」だと言えるが、シャープのガラパゴスは電子書籍はもちろん、メディアサービスと連携し、ビデオや音楽も再生できる端末だ。今後はこのようなPCではない情報端末も普及することが予想され、その活用は学校現場でも求められるだろう。

そして現在兵庫県立須磨東高等学校に勤務される、仲正博先生をお迎えして、長年開発を続けてこられた「IKシステム」についての話をしていただく。IKシステムは仲先生が兵庫県立伊川谷北高等学校に勤務されていた1993年に、学校で統一的に成績処理をするシステムが必要とされて開発され、以降、全日制普通高校の標準的な仕様を確立されて一般公開し、現在数多くの学校で利用されている校務処理システムだ。仲先生からこのIKシステムの歴史や開発の理念などを語っていただく。

そして実際に学校現場で、情報システムの運用管理がどのようになされていて、どんな問題があるのか、うまくいっているコツはなにか、などを、現場の担当者からレポートしていただきディスカッションする。参加者の方も積極的に参加していただければと思う。

私からは東京勉強会と同じ内容の、InfoPathとAccessを使った教務システムの構築デモを演示する。全日制普通高校の成績処理を念頭におき、フルスクラッチで50分の時間でどれだけできるかをお見せする。この勉強会で使うデモは、持ち帰ってご自分でもやってみることができるようにテキスト形式のものを用意するので、勉強会では、だいたいどのような感じで作ることができるのか、を把握していただくことを目標にする。

勉強会は参加費無料、定員40名。場所はマイクロソフト関西支店セミナールームだ。学校の先生だけでなく、教育の情報化に興味のある方なら大歓迎だ。申し込みはアドミンティーチャーズWebサイトから電子メールで受け付けている。

アドミンティーチャーズWeb

http://adminteachers.wordpress.com/

第６回勉強会（大阪）の詳細ページ

http://adminteachers.wordpress.com/2011/01/10/%e7%ac%ac%ef%bc%96%e5%9b%9e%e3%82%a2%e3%83%89%e3%83%9f%e3%83%b3%e3%83%86%e3%82%a3%e3%83%bc%e3%83%81%e3%83%a3%e3%83%bc%e3%82%ba%e5%8b%89%e5%bc%b7%e4%bc%9a%ef%bc%88%e5%a4%a7%e9%98%aa%ef%bc%89%ef%bd%9e/

ようやく東京勉強会の計画ができたアドミンティーチャーズだ。テーマは「校務処理にデータベースを活用しよう」とした。コンピュータや校内LANなど機器としては充実してきた近年だが、必ずしも校務の情報化がすすんだとは言えない。校務の情報化はデータベースの活用が欠かせないが、まだまだ学校でデータベースをうまく活用している事例は少ないと思われる。そこで今回はテーマをデータベースに絞った。

私からは、全日制普通高校を念頭に置いた教務処理システムを、InfoPathとAccessで作成する演示をする。InfoPathもAccessもMicrosoft Officeの製品であり、これらを使ってシステムを開発することを「OBA開発」と言う。実際に作るところを見てもらえばわかるが、InfoPathとAccessによるデータベースシステムを作成するのは実に簡単である。データベースはできればSQL Serverにしたいところだが、データベースをやったことがない人には敷居が高いようなので、Accessデータベースを使うことにした。50分でどこまでできるか、楽しみにして欲しい。

場所は、筑波大学東京キャンパスをお借りすることができた。学校の先生だけでなく、学校の情報化に関心のある方はぜひ参加して欲しい。参加費無料、定員は40名だ。参加受付はアドミンティーチャーズのWebより電子メールで登録することにしている。

アドミンティーチャーズWeb

http://adminteachers.wordpress.com

第５回勉強会（東京）のページ

http://adminteachers.wordpress.com/2010/12/27/%e7%ac%ac%ef%bc%95%e5%9b%9e%e3%82%a2%e3%83%89%e3%83%9f%e3%83%b3%e3%83%86%e3%82%a3%e3%83%bc%e3%83%81%e3%83%a3%e3%83%bc%e3%82%ba%e5%8b%89%e5%bc%b7%e4%bc%9a%ef%bc%88%e6%9d%b1%e4%ba%ac%ef%bc%89%ef%bd%9e/