Microsoft Office InfoPath

アドミンティーチャーズ第６回（大阪）勉強会は2011年2月19日開催

ホチキス先生 — Sat, 15 Jan 2011 12:01:00 GMT

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

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

まず、昨年末に満を持して発売された、シャープのメディア情報端末「ガラパゴス 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/

アドミンティーチャーズ第５回（東京）勉強会は2011年2月5日開催

ホチキス先生 — Fri, 14 Jan 2011 23:36:00 GMT

ようやく東京勉強会の計画ができたアドミンティーチャーズだ。テーマは「校務処理にデータベースを活用しよう」とした。コンピュータや校内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/

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 03

ホチキス先生 — Thu, 16 Sep 2010 20:42:00 GMT

データに対してまとまった処理を行うためにSQL Serverにストアドプロシージャを作ります。ではInfoPathからストアドプロシージャを実行する方法があるでしょうか。InfoPathのデータ接続はSQL文を自由に書けるので、ストアドプロシージャの実行も可能なように思えます。データ接続を編集すればいいはずです。まずSQL Serverにストアドプロシージャを作りましょう。

(slide.15 SQL Serverに作ったストアドプロシージャの例)

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

create procedure テストプロシージャ

update テスト set 氏名 = '松本　吉生' where 学年 = 2

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

上のcreate文で生成するストアドプロシージャは、「テスト」テーブルのデータのうち、学年が2年のデータの氏名を全部「松本　吉生」に変更するストアドプロシージャです。InfoPathからこのストアドプロシージャを実行できるようにデータ接続を作りましょう。データ接続ウィザードによってInfoPathで新しいデータ接続を作り、データ接続ウィザードの最終場面で、SQLの編集によってストアドプロシージャを実行するSQL文に書き換えるのです。

(slide.16 データ接続ウィザード1)

(slide.17 データ接続ウィザード2)

(slide.18 データ接続ウィザード3)

(slide.19 データ接続ウィザード4)

(slide.20 データ接続ウィザード5)

上のスライド20のステップでは、とりあえず適当なデータ接続またはテーブルを選んでおきます。

(slide.21 データ接続ウィザード6)

とりあえず仮のデータ接続ができました。では「SQLの編集」ボタンをクリックしてSQL文を書き換えましょう。

(slide.22 データ接続ウィザードの最後でSQLの編集を行う)

「SQLの編集」ボタンをクリックすると、ウィザードで自動的に生成したSQL文が表示されます。これをストアドプロシージャを実行するSQL文に書き換えます。書き換えた後、SQL文に誤りはないか、実行できるか、をチェックするために「SQLステートメントのテスト」ボタンで調べます。

(slide.23 データ接続を書き換えるSQL文)

ここで書き換えるSQL文は上のスライド23のようなものです。ストアドプロシージャを実行するにはexecute文だけでよいのですが、InfoPathのデータ接続はselect文以外のものを書くと、InfoPathがエラーと判断してしまいます。そこでまずset nocount onコマンドを書き、ダミーのselect文を書き、そのうえでexecute文を書くようにするのです。

(slide.24 InfoPathフォームにボタンを作りストアドプロシージャを実行するデータ接続を実行する1)

ストアドプロシージャを実行するexecute文を書いたデータ接続ができたら、フォームにボタンを作ります。ボタンのプロパティで「動作規則」をクリックします。

(slide.25 InfoPathフォームにボタンを作りストアドプロシージャを実行するデータ接続を実行する2)

ボタンのプロパティで「動作」としてexecute文を書いたデータ接続を使用してクエリを送信する、とします。クエリを送信するとデータ接続に書いたexecute文がSQL Serverに渡され、ストアドプロシージャが実行するようになります。

（前の記事）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 02

http://sqljp.com/hotikisu/archive/2010/09/11/27097.aspx

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 02

ホチキス先生 — Sat, 11 Sep 2010 18:43:00 GMT

InfoPathのフォーム作成でデータ接続先をSQL Serverにしたとき、データ接続ウィザードによってデータ接続を作ることができます。

(slide.04 InfoPathのデータ接続ウィザード1)

(slide.05 InfoPathのデータ接続ウィザード2)

(slide.06 InfoPathのデータ接続ウィザード3)

(slide.07 InfoPathのデータ接続ウィザード4)

(slide.08 InfoPathのデータ接続ウィザード5)

上のスライド08のステップでは、とりあえず適当なデータ接続またはテーブルを選んでおきます。

(slide.09 InfoPathのデータ接続ウィザード6)

InfoPathのデータ接続ウィザードを行うと、上のスライド04から09のようにデータ接続を作成することができます。ここで「SQLの編集」ボタンをクリックすると、ウィザードによって生成した接続用のSQL文を編集することができます。「SQLの編集」によって次のスライドのようなSQL文を書きます。

(slide.10 InfoPathのデータ接続ウィザードで「SQLの編集」を行う)

「SQLの編集」では自由にSQL文を書くことができます。しかしInfoPathは、SELECT文以外を書くとエラーになってしまうので、「set nocount on」を実行し、ダミーのセレクト文を書いてから必要なSQL文を書くことにします。書いたSQL文がエラーにならないことを「SQLステートメントのテスト」ボタンをクリックして確かめるとよいでしょう。

(slide.11 InfoPathのデータ接続ウィザードで「SQLの編集」を行い記述したSQL文)

実行したいSQL文の本体はUPDATE文です。ここで使う「テスト」テーブルには、生徒の氏名や年齢などのデータが入っています。この「テスト」テーブルのデータに対して、学年が「1」年の生徒データの氏名を全部「松本吉生」に変更する、というUPDATE文になります。データ接続には以下のように記述します。

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

set nocount on

select 'dummy'

update テスト set 氏名 = '松本吉生' where 学年 = 1

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

このようにして実行したいSQL文をInfoPathの「データ接続」として作成します。ではこれをInfoPathフォームから実行するにはどうすれば良いでしょう。それはInfoPathのフォームで「ボタン」を作り、ボタンの動作に「データ接続を利用してクエリを送信する」とすればよいのです。

(slide.12 InfoPathのフォームでボタンを作り「クエリの送信」を動作に設定する1)

(slide.13 InfoPathのフォームでボタンを作り「クエリの送信」を動作に設定する2)

(slide.14 InfoPathのフォームでボタンを作り「クエリの送信」を動作に設定する3)

このようにしてボタンを作れば、ボタンをクリックすることでクエリが送信され、UPDATE文を実行することができます。

（前の記事）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 01

http://sqljp.com/hotikisu/archive/2010/09/11/27096.aspx

（続き）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 03

http://sqljp.com/hotikisu/archive/2010/09/16/27102.aspx

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 01

ホチキス先生 — Sat, 11 Sep 2010 16:12:00 GMT

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」について、スライドを使いながらふりかえってみる。

(Slide.01 InfoPathはXMLオーサリングソフトなのか)

MicrosoftのOffice製品情報のページには「Microsoft InfoPath 2010 は、ビジネスプロセスの合理化に役立つ、フォーム作成およびデータ収集のためのツールです。」といった説明があります。この説明は少しわかりにくいですが、Wikipediaによると「マイクロソフトが開発・販売しているXMLオーサリングソフトである。」とあり、その他の技術ページでもおおむね「XMLオーサリングソフト」といった記述が見られます。これはInfoPathの基本的な一面をあらわしていますが、それだけではありません。InfoPathはデータ接続を利用してSQL Serverなどのデータベースに接続することができ、データベースサーバーに対するクライアントアプリケーションとして利用できるのです。InfoPathはドロップダウンリストボックスやラジオボタンなどのリッチなコントロールを使い、動作規則や条件付き書式、データの入力規則など豊富な機能を使ってノンコードでデータ入力フォームを作ることができます。つまり、SQL ServerとInfoPathを組み合わせると、クライアントサーバー型のデータベース業務アプリケーションを構築することができるのです。

(slide.02 InfoPathとSQL Serverによるクライアントサーバー型データベースシステム概要)

InfoPathとSQL Serverで構築したクライアントサーバー型データベースアプリケーションはこのような構成になります。データベースはSQL Server、クライアントコンピュータにはInfopath、そしてユーザー管理のためにActive Directoryを使います。データベースの個々のデータを参照したり、登録、修正の業務は、InfoPathを使って行いますが、システム管理にはどうしても「一括操作」といった場面があります。テーブルの全部のデータをある値で更新したい、ある条件のデータに対して特定の更新業務を行いたい、ある基礎データから別のデータを一括で作成したい、といった場面です。このような一括処理はInfoPathだけではできません。そこでSQL Serverが持っている機能を使うことになりますが、SQL Serverの中で動く仕掛けを作ったときに、InfoPathからどのようにコントロールのかを知る必要があります。

(slide.03 SQL Serverでデータを一括して処理する方法)

データを一括して処理する方法には色々ありますが、InfoPathからコントロールできる手法としては、次のようなものが考えられます。まず「データ接続にクエリを書く」方法があります。InfoPathのデータ接続には、直接SQL文を書くことができるのです。次に「ストアドプロシージャ」を使う方法があります。SQL Serverにストアドプロシージャを作り、その実行をInfoPathからコントロールします。また「トリガ」を使う方法もあります。そして「ジョブ」を使う方法があります。

（続き）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 02
http://sqljp.com/hotikisu/archive/2010/09/11/27097.aspx

OBA開発（３）

ホチキス先生 — Thu, 23 Apr 2009 01:32:00 GMT

ビューの変更は、単なるデザイン面の変更だけでなく、データベースの定義そのものの変更も必要とされる場合が多い。足りないデータを追加するには、データベースのフィールドを加えなければならない。単なる更新フィールドで良いと思っていたデータが、実は変更履歴を残しておかなければならないとわかったとき、そのフィールドはテーブルから取り出して別の新しいテーブルを作らなければならない。

ビューや帳票のデザインは、一般ユーザーベースで自由に変更してもらうのが良いが、データベースの変更はシステム担当者でやらなければならない。このとき、クライアントアプリケーションとデータベースの両方が開発対象だとすると、いくつかの手法が考えられる。もし開発者に「一度作ったテーブル構造を変更したくない」という意識が働けば、新しく実現しなければならない要素を、既存のテーブル構造を変更せずに新しいテーブルを追加する、ということで解決したくなる。足りない部分を別のテーブルに実装するのだ。テーブル構造の変更には大きな決意が必要だから、この気持ちは容易に推察することができる。

もちろんVBやC#などを使って開発したウィンドウズアプリケーションを作ると、いくらでも複数のテーブルにデータを送受信できるアプリケーションを作ることができる。だがこれをやりすぎると、ビジネスロジックがデータベース側とクライアント側に分散し、システム全体の仕組みが見通せなくなる。似たようなデータがあちこちのテーブルに散在するデータ構造になってくる。しかもテーブル間のデータ整合性はクライアントアプリケーションに実装されている。データベースを見ただけでは関連性がわからない。クライアントアプリケーションのあちこちを変更していくと、次第にビジネスロジックが複雑化し、あちこちのクライアントアプリケーションに分散し、そのうちに危なくて手を出せなくなってくる。

最もよいのはビジネスロジックをデータベース側に全てまとめて実装することだろう。ストアドプロシージャ、トリガ、ユーザー定義関数などで作ってしまうのである。こうすることでデータベースサーバーさえ見ておけば、全体のロジックが完全に見渡せるシステムになる。データベースとクライアントアプリケーションとのデータのやり取りは、できるだけ単純にしておくのである。

たとえばInfoPathでは、ひとつのフォームに複数のデータ接続を作ることができるが、動的なクエリを行ったりデータの送信ができるのは「メイン接続」と呼ばれるひとつのデータ接続だけである。その他の「セカンダリデータ接続」では単にテーブルやビューのデータを、ごっそりそのまま取得するだけの機能しかない。したがって「セカンダリデータ接続」はあくまでも補助的な使い方しかできない。Excelのデータ連携でも、動的なクエリはできない。だが、このことが逆に「OBA開発」を特徴付けるものでもある。つまりOfficeアプリケーションのデータ接続機能が限定的であるために、Officeアプリケーションとデータベースの接続関係がシンプルに理解できるのである。また限定的な機能しか持たないために、ビジネスロジックはデータベース側に実装せざるを得ない、という開発手法になる。これが結果的に良い開発手法を選択することになっている。

ビジネスロジックはデータベースに実装する。Officeアプリケーションはビューや帳票のデザインに専念する。人間は同時に二つのことを考えることが苦手である。案外こんな単純な人間の特性に、OBA開発のわかりやすさの秘密があるのかもしれない。

OBA開発（２）

ホチキス先生 — Thu, 23 Apr 2009 01:29:00 GMT

OBA開発の利点は何か。まず何といっても、クライアントフォームのデザイン開発が簡単であることだ。利用者にとってビジネスアプリケーションで強い個別の要求が発生するのは、得られるビューのデザインである。そしてデザインの編集に最も手間がかかる。しかしワードやエクセルのデザイン能力は卓越している。単に文字や数字を表示するだけでなく、フォントや文字の大きさ、色を変更するための使いやすい直感的なインターフェースを持ち、グラフや概念図などをウィザードで作ることができる。これらの機能は長年にわたるユーザーインターフェース技術の蓄積によるもので、一朝一夕に完成したものではない。また使う側にも長年利用してきたという経験がある。慣れたメニューやボタン、用語などを新しく学習する必要なく使うことができる。

VBやC#などを使った従来型のウィンドウズフォーム開発では、どんなビューが必要かという点についても、ちゃんと仕様を作ってデザインを定義して開発を始める。いや、むしろ、どんなビューが必要かが仕様の中心であるともいえる。業務アプリケーションは、どんな結果を得たいのかが開発の目的であるはずだからだ。しかしビューの要求というのは仕様を決める段階ではあいまいにされることが多い。なぜなのか。

システム開発で仕様を決める段階では、とにかくビジネスロジックの仕様を決めることが最優先され、個々のビューの定義は「後からでもなんとかなるだろう」ということで後回しにされる。もちろんデータさえ正確に得ることができれば、とりあえず業務ができるには違いない。しかし実際の業務においては、帳票の列がひとつ足りないだけで不便が生じたり、作業が煩雑になったり、その結果、作業の上で勘違いによる間違いがおこったりする。

仕様を決める段階で考えていたことが、実際に業務が始まると様子が違ってきた、ということもおこる。仕事が始まってから「ああ、このビューにはこのデータも必要だった」とか「この帳票はひとつにまとめたほうがよかった」、「この帳票は形式の違う二種類が必要だ」といったことが明らかになっていく。このように、実際の業務が始まらないとベストなビューや帳票の形がわからない、ということを誰もがなんとなく知っているものだから、開発の初期段階で帳票の仕様を決めようという意志が働かないのだ。

これらの現実があるために、きちんと仕様を決めてシステムを開発し、納入したら終わり、という開発手法はうまくいかない、ということが明らかになっている。作った後運用を始めてから細部を再定義しなおす、ということは実際の開発では当たり前である。アジャイルという開発手法が流行する理由もここにある。

「OBA開発」を究極まですすめると、データベースのテーブルやビューの構造、各テーブルやビューへのアクセス権をシステム管理者、開発者が実装し、データベースへの接続方法だけ各業務担当者へ通知する、各業務担当者は、自分の業務の必要に応じてワードやエクセルなど自分の使いやすいオフィスアプリケーション、最も業務にふさわしいオフィスアプリケーションを自由に選択して、自分の欲しいビューや帳票を作る、といったスタイルが可能になる。このことによって人は押し付けられたシステムを利用するだけではなく、自ら思考しながら業務を遂行するワークスタイルになる。考えてみれば今でもそうである。データをエクセルに取り出して各担当者に配布し、各部課で必要なデータを作る、といったことは当たり前に行われている。これが最も現実的なのだ。ただ問題はデータが一元化されていないだけであって、分散されているから情報統制上の問題も起こるのである。

OBA開発（１）

ホチキス先生 — Thu, 23 Apr 2009 01:26:00 GMT

「OBA開発」という言葉がある。略さずに書くと「Office Buisiness Application開発」となる。これはOfficeつまりワードやエクセルなどいわゆるオフィススイートといわれるアプリケーションソフトウエアを使って、業務上で必要なシステムを開発するということだ。

オフィス製品を使ってシステムを開発する、という言葉通りに理解すれば、これまでのイメージでは、マクロを使ってエクセルのアプリケーションを作る、アクセスを使ってデスクトップデータベースアプリケーションを開発する、などを連想するかもしれない。もちろんこれらは立派なビジネスアプリケーションであって、これらの開発に匠と称してもよいほど卓越した技術を持っている人がたくさんいる。素晴らしいアプリケーションが数多く作られ、人の役に立っている。

しかし今日的なビジネスモデルでは、データの一元性、ということが重要になる。つまり、オフィス製品は基本的にデスクトップアプリケーションであるのだが、これをデータベースに接続することで、ワードやエクセルをいわば「入出力インタフェース」として利用するのだ。これが今日的な業務システムに求められる姿であり、「OBA開発」といえば基本的にデータベース＋オフィスアプリケーションの組み合わせでシステムを構築することだ、と言っていい。

この「OBA開発」が広く現実性を持ち始めたのは、マイクロソフトのOffice製品がデータベースとの接続性を充実させてきたからである。Office2000までは、データベースに接続することができるアプリケーションはアクセスだけだった。私の記憶ではOfficeXPからエクセルはデータベースへの接続ができたように思うが、データ接続を手作業で作るなど実際的ではなかった気がする。Office2003からはウィザード形式でデータ接続を作ることができ、SQL Serverにも簡単に接続できるようになった。

しかしワードやエクセルはデータベースからデータを取得して様々なレイアウトで表示する表現力には長けているが、データを入力する能力には欠けている。Office製品の中でデータ入力を担当させるのは、やはりInfoPathということになる。逆にいえば、OBA開発を想定したときに、マイクロソフトはデータ入力に特化したアプリケーションが必要だと考え、InfoPathを開発、発売した、ということもできるだろう。

「OBA開発」については次の書籍が参考になる。

・「OBA開発入門 OfficeとSharePoint Server 2007の連携によるビジネスアプリケーション構築 (マイクロソフト公式解説書)/日経BPソフトプレス」
・「VSTOとSharePoint Server 2007による開発技術 Visual Studio 2008で構築するOBAソリューション (Programmer’s SELECTION) /翔泳社」
・「OBA実践講座 Excel 2007とSharePoint Server 2007によるデータ連携 (マイクロソフト公式解説書) /日経BPソフトプレス」

ちなみに先日、ビッグカメラ新宿西口店でこれらの本を探したが、Officeやサーバーのコーナーにはなく、開発のコーナーにもなかった。店員の人に聞いてみると探してくれたのだが、なんと「セキュリティ」のコーナーにあった。これら以外にもSharePoint関連の本はすべて「セキュリティ」のコーナーにあって、もうちょっと考えて配架して欲しいと思った。

アドミンティーチャーズ第一回勉強会（大阪）を盛大に開催！

ホチキス先生 — Wed, 15 Apr 2009 07:10:00 GMT

2009年4月11日（土）、マイクロソフト関西セミナールームでアドミンティーチャーズ第一回勉強会を開催した。準備の日程が短く、開催アナウンスも遅かったこと、4月はじめという学校がいちばん忙しい時期だったことで、どのくらい聞きに来ていただけるか不安だったが、ほぼ会場は満席に近い状態で、意見交換も活発に行われた。

最初に私から問題提起という位置づけで、私がやっている「教務システムの内製」について話をさせていただいた。技術的なノウハウではなく、本校で教務システムが必要な理由や、内製を決断した理由と経緯、内製によって業務がどのように改善されたか、といった観点で説明をした。今までノウハウ的な話をすることはあったが、まとまった話をするのは今回が初めてであり、私自身も仕事の現状を整理するよい機会になった。

セカンドオフィスは、私が手をつけられなかった「生徒情報端末」を作ってくれた会社だ。セカンドオフィスと一緒に仕事をするようになったのは本当に偶然が重なったからである。たまたま本校の事務職員が名簿の中から選んで電話をし、電話を受けた営業担当者には経験がなかった本校の要求を、たまたま席の隣で聞いていた別の担当者がピンときて本校に一緒に来ていただいた、という経緯だ。セカンドオフィスの提案は、まさに本校の要求にぴったりだった。

セカンドオフィスの提案にハードウエアとして選定されたのがタッチコンピュータシステムズのタッチパネル一体型のPCだった。タッチパネルの検知技術には、静電容量の変化をみるもの、薄膜間の電圧変化をみるもの、超音波を使うもの、光を使うものなどいろいろあり、普及型で安価なものから耐久性に優れているもの、濡れた指でも使えるもの、など用途に応じて選定することなどの説明があった。たいへん興味深い話で、教科「情報」でも取り上げたい内容だった。

Qdabra SoftweraからはSQL ServerデータベースをWebサービス化するシステムの説明とデモがあった。データベースをWebサービスにする一番のメリットは、InfoPathクライアントから複数テーブルの同時接続が可能であることだ。InfoPathを直接SQL Serverに接続すると、動的クエリとデータの送信が可能なのはメイン接続のみであり、接続先のテーブルにも制約がある。これをWebサービスにするとInfoPathからの接続が柔軟に作成できるのだ。実際に目の前でデータ接続を作成する場面を見ると、Webサービスを使うメリットがたいへんよくわかった。

クリエ・イルミネートの溝端さんからは、最近の著書「Excel 2007とSharePoint Server 2007によるデータ連携」に関連する話をいただいた。いうまでもなくExcelはオフィスの中ではたいへんよく使われるアプリケーションソフトであり、マクロを組んで簡単な業務を作りこんだり、データベースの代用として使われることもあるが、本来のExcelの得意分野は「データ分析」である、という視点を明確にしていただいた。その上でExcel 2007にはデータベース接続の機能強化がされており、デモを交えてExcelとデータベースの連携について効果的な手法を説明していただいた。まさに「目から鱗が落ちる」ようなセッションだった。

今回あわただしく日程を決めた第一回アドミンティーチャーズ勉強会（関西）だったが、現役のMicrosoft MVPが3人も登壇するというゴージャスな勉強会であったと、手前味噌ながら喜んでいる。次回はぜひ東京で開催したい。

Microsoft 2009 MVP Global Summitレポート（４）

ホチキス先生 — Wed, 04 Mar 2009 16:55:00 GMT

今日はマイクロソフトで開発中の製品を使ってみる機会があった。ディスカッション中心のセッションは辛いが、実際の製品を目の前にして使うことができるのはとても嬉しいし充実した時間だった。

プロダクトチームの人たちも集まり、製品を使いながらあちこちで具体的なディスカッションが行われていた。小さい部屋でPCの台数も多くなかったので、部屋に入ったときPCは全部使われていてしばらく待っていた。するとSharePointのプロダクトチームの人が近寄ってきて、壁に貼られたチャートを説明しよう、と言ってくれた。しかし残念ながら言葉がわからないことと、SharePointに詳しくないのでお断りし、しばらく世間話につきあってもらった。

とてもゆっくりと優しい言葉で話しかけてくれて「英語が難しいのはよくわかります。私だって日本語はできない」と慰めてくれた。学校の情報システムを作っていることなどを話し、名刺交換をした。

使ってみた製品については書くことができないのだが、当然ながら新しい考え方に基づいて作られていた。触った瞬間、ああ、やっぱりこうなんだ、と思えるようなインタフェースで、実によく考えられていると思った。これはマイクロソフトが常に製品に対してユーザーからのフィードバックを吸収し、積極的に取り入れていることの証明でもある。

ソフトウエアの開発環境は目覚しく進歩し、10年も前なら「可能なことをできるだけやる」という世界だったものが、今はやろうと思えばなんだってできる。だからこそ「何をどう作ればよいか」が重要になっており、そこにはフィードバックが大切になってくる。マイクロソフトがフィードバックを積極的に受け止める理由がここにある。単にリップサービスではないのだ。