Microsoft Office InfoPath

なぜ外注した教務システムは使い物にならないのか（１）要件定義に失敗する

ホチキス先生 — Fri, 14 Nov 2008 00:58:00 GMT

自分の学校の教務システム、本校では「支援システム」と呼んでいるのだが、これをSQL ServerとInfoPath、AccessなどのOfficeアプリケーションを組み合わせて作り、「なぜ外注した教務システムは使い物にならないのか」について思うところをまとめてみる。これはあくまでも現時点でのまとめなので、今後また考え方は変わるかもしれないが、あくまでも現時点のまとめである。

まず最も大きな理由は「要件定義に失敗する」ということだ。そもそもシステムを外注するためには、どのような業務を実現したいのかという整理が必要である。実現したいシステムが整理されて、それを「要件定義」にまとめられるのだが、そもそも「何をどうまとめていいかわからない」のが原因である。

学校側は自己の要件定義をまとめる力がない。ではシステム業者はどうか。受注する側は、要件定義が少ないほどいい。作りこまなければならない部分が少なくてすむからだ。だから業者側から積極的に要件定義に協力するということはない。契約の上では仕様を満たせばいいわけだが、本当の目的はシステムが業務にあわせて「ちゃんと動くこと」のはずだ。

最近ある雑誌のコラムに「要求定義は発注側、受注側、両方の責任」という記事があるのを目にした。これなど当たり前のことのように思えるが、実際は問題がおきたとき「仕様を満たしている」ことが責任の範囲になるようだ。このような問題は、大企業間のシステム外注でもおきているらしい。

学校の教務システムに慣れた業者は、「要件定義シート」といった雛形を用意しており、学校の要件定義が簡単にまとめられるようにしている。このようなシートを用意することは一見良心的なように思えるが、実は業者が「作ることができる」あるいは「作りたい」システムの雛形を選択肢に与えているにすぎない。このようなシートにチェックして要件定義ができるなら苦労はない。しかし実際は、このような一般化に現れない部分こそ、学校ごとに異なる仕様が必要になる要件なのだ。

一般化に現れない部分はシステム的には部分的な細部的構造であるのだが、実は部分的な細部の要求を満たそうと思えば、データベースの全体構造を変更せざるを得なくなってくる。これについては別途まとめて述べたい。

要件定義に失敗すれば、その要件定義に基づいた仕様も間違いであり、当然開発されたシステムも使い物にならなくなる。本校ではある意味「要件定義を行いながらシステムを開発している」という同時並行でやっている。したがって常に要件定義を見直しながらシステムを構築、更新している訳だ。

なぜこのようなことが可能になったか。それはSQL ServerとInfoPath、Accessなどのオフィスアプリケーションの組み合わせが、直感的でわかりやすいインタフェース、コードをほとんど書く必要がない、などの変化に順応した開発環境を提供してくれるからだ。

TechEd 2008 Yokohamaでライトニング・トークに出る

ホチキス先生 — Wed, 06 Aug 2008 21:38:00 GMT

今年は昨年と少し趣向が変わった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

InfoPathの改ページについて

ホチキス先生 — Sun, 29 Jun 2008 17:24:00 GMT

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の弱いところ。複数ページの印刷処理。

ホチキス先生 — Sun, 29 Jun 2008 17:21:00 GMT

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

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

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

SQL ServerとAccessによるクライアントサーバーシステムの事例はあるのか

ホチキス先生 — Sat, 28 Jun 2008 12:41:00 GMT

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

InfoPath2003とSQL Server2000の組み合わせでバグかもしれない現象に遭遇した。その２

ホチキス先生 — Thu, 26 Jun 2008 11:47:00 GMT

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

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

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

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

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

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

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

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

行 197、位置 3

--^

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

「一部の動作規則を適用できませんでした」というメッセージがおかしい。フォーム上、何も動作規則を設定していないのだが。

以前におこった現象については、以下に記述している。
http://blogs.sqlpassj.org/hotikisu/archive/2007/01/16/20444.aspx

セカンダリデータ接続で必要なデータだけを取得するには（SQL Serverにサブクエリのビューを作る）

ホチキス先生 — Thu, 12 Jun 2008 22:40:00 GMT

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()関数が正しく実行されるのだ。

セカンダリデータ接続で必要なデータだけを取得するには（データ接続にサブクエリーを書く）

ホチキス先生 — Thu, 12 Jun 2008 22:28:00 GMT

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から自分の氏名を取得するには（データ接続にサブクエリーを書く）

ホチキス先生 — Thu, 12 Jun 2008 22:11:00 GMT

以前、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のデータ接続にサブクエリを書くだけでいいのだ。この手法は応用がきくだろう。

あまりにも複雑なビューを作りすぎた自分に責任があるのだが

ホチキス先生 — Fri, 06 Jun 2008 01:00:00 GMT

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

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

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

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

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

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