現場担当者が作れる在庫管理システム
さて、今回のような研修テキストの在庫管理システムは誰に作ってもらいましょうか？ 時間に余裕があれば、システム部が作るのがベストでしょう。しかし、現実は「このくらいの管理であれば、Excelでやってよ」となってしまうケースも多々あるのではないでしょうか。そうすると、話はまた元に戻ってしまい、エンドユーザーはデータをExcelで管理し、ファイルサーバーに置いて、データの関連性も整合性も同時実行性もない状態で、ただ単純にデータが増え続けることになります。
また、全社システム／部門システムという利用形態で、例えば全社システムはOracleで構築し、部門システムはSQL Serverで構築しているという話なども聞くようになりました。
アプリケーション開発をOracleについてはJavaで、SQL Serverについては.NETで行っているのでしょう。どちらもVisual Basicというケースもあるかもしれません。また、SQL ServerをフロントにしてOracleデータベースを利用するという方法もあります。しかし、SQL Serverがどんなにユーザーインターフェイスに優れていると言っても、エンドユーザーには敷居が高い印象があります。
いずれにしろ、すべてを一つのソフトウェアや方法に統一することは、メリットだけでなくデメリットもあると思いますし、OracelやSQL Serverを使った開発はプロのスキルが必要とされるでしょう。その意味では、全社システムはOracleが担当し、部門システムおよび開発ツールは現場担当者がFileMakerで行うという発想も悪くはないと思います。もちろん、全社システムにはSQL Serverを用いても構いません。
専門知識が不要で、直感的に扱えるデータベース
なぜ、フロントエンドツールにFileMakerを使うことにこだわるのか？ それは、（語弊があるかもしれませんが）純粋なリレーショナルデータベースではないからです。良くも悪くも、直感的なデータ操作が行えるよう工夫されています。
「リレーショナルではない」と断言すると、FileMaker社の方やFileMakerを愛してやまない方に、嫌な顔をされるかもしれません。しかし、初めからずっとリレーショナルデータベースで仕事をしてきた私からすれば、やはりFileMakerは完全なリレーショナルデータベースと少し違う気がします。でも、そこが良いんです。
今回の、テキスト在庫管理のテーブルを改めて見てください。入出庫を管理しているテーブルに、主キー列がありません。リレーショナルデータベース屋さんは、主キーの無いテーブルを作らないでしょう。
一方、ユーザーが使用していたExcelを見てください。在庫管理するユーザーにとって、このテーブルに主キーは無用です。もちろん、リレーショナルデータベースだって、主キー宣言を強要するわけではないので、主キーを宣言しないテーブルの作成は可能ですが、あくまでもこれは一例で、リレーショナルデータベースの概念を必要としないデータは現場にいくらでもあるということを伝えたかっただけです。それでもデータであることに変わりはありませんし、蓄積されたデータをもとに情報を得て、仕事に活かしているのです。
だからこそ、カチカチにリレーショナルデータベース設計をしなくても、構築、開発できるFileMakerを現場のデータ管理に使ってみるのは面白いのでは、と思った次第です。
次回予告
現在、OracleやSQL ServerのデータベースのサイズはPB（ペタバイト）、EB（エクサバイト）という単位を上限とすることができます。つまり、データベースベンダーはそれだけたくさんのデータや情報がユーザーによって管理、運用されていると考えています。そういった意味で、最近はそれらの莫大なデータをより仕事に活かせるように「BI」（ビジネスインテリジェンス）をアピールしています。
次回は、FileMakerをOracleやSQL ServerのBIツールとして活用できないかを考えてみるとともに、データを手元（FileMaker）に持ってくるケースとOracle上に置いたまま活用するケースの両方を考えて見たいと思います。
