Access

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

ホチキス先生 — 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: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