FileMaker Proだと何が便利なのか?
特別な専門技術が不要
前述しましたが、ODBCドライバとODBCデータソースのセットアップ以外は、基本的にFileMaker Proの操作のみで、RDBMSをFileMaker Proから外部データソースとして利用することができます。
同じようなことができるソフトウェアにMicrosoft Office Access(以下、Access)がありますが、Accessの場合は、複雑な処理を行うソリューションを作成したい場合に、プログラミングの知識が必要になります。一方、FileMaker Proはデータベースの構築やレイアウトの作成、各種自動処理などを直感的な操作で行うことが可能です。もちろん、FileMaker Proではできないような細かい処理などはAccessの方が優位ではありますが、そこまで必要のないソリューション開発の場合には、FileMaker Proの実力が大いに発揮されるでしょう。
クロスプラットホームなので、WindowsとMacintosh環境のどちらでもOK
FileMaker ProはWindows、MacintoshのどちらのOSでも動作するクロスプラットホームのデータベースですので、クライアントマシンのOSを選びません。従って、企業内や大学などの学内で、これらのOSが混在するような環境であっても問題なくFileMaker Proを利用することが可能です。
なお、共通のRDBMSに、FileMaker ProのESSを利用して接続する場合は、クライアントOSで利用可能なODBCドライバが必要になりますので、事前に調達しておくと良いでしょう。
![Macintosh、Windowsのどちらとも、ODBCというインターフェイスを使用可能なため、OSの違いを気にせず運用が可能 Macintosh、Windowsのどちらとも、ODBCというインターフェイスを使用可能なため、OSの違いを気にせず運用が可能](http://cz-cdn.shoeisha.jp/static/images/article/2599/CZ901_s.gif)
ESSはどのような場面で使用するのか?
企業内の基幹システムのサブシステムとして使用する
一般的に基幹システムと呼ばれる部類のシステムが存在しますが、FileMaker Proの機能だけで基幹システムに取って代わるシステムを構築するのはとても大変なことですし、開発者である筆者もあまりお奨めはしません。しかし、基幹システムのサブシステムとしてのFileMaker Proの利用は大いに推奨します。
企業内の業務に変化があり、基幹システムに機能を追加しなくてはならなくなったという話は、日常茶飯事でよく耳にします。基幹システムに対して機能追加を行う場合、自社開発にしても、開発ベンダーが行うにしても、計画開始から本番稼働までには多くの時間を要します。システム開発の流れとしては、FileMaker Proも要件定義から始まって、設計、開発、単体テスト、組み込み、連携テスト……本番稼働といった一般的な流れになりますが、要件定義以降の作業においてFileMaker Proは短期間で各作業を進めることが可能になります。
例えば、帳票印刷の処理を追加するような場合、一般的なプログラミング手法を用いると、帳票作成ツールを使ったとしても、それなりの開発工数がかかってしまいます。一方、FileMaker Proの場合は、PowerPointやワープロソフトのように画面上で帳票のイメージを作成するだけです。この作業は、ESSを使用してRDBMSに保存されているレコードを検索して帳票にするような場合でも、通常のFileMaker Proにおける帳票設計作業と何ら変わりはありません。
その他の機能の開発に関しても、基本的にはFileMaker Proに初めから用意されている各種機能を組み合わせて処理を作成しますので、一般的なプログラミング手法でシステム開発を行う場合よりも開発時間を短縮することができるところが、FileMaker Proの強みの一つです。
ERPとの連携
ERPの場合も同様で、バックグラウンドで動作しているRDBMSの種類やバージョンにも左右されますが、FileMaker ProのESSが対応しているRDBMSを採用している場合、ERPのサブシステムとしてFileMaker Proを役立てることができます。
一般的にERPの導入を考えた場合、基本的なパッケージで用意されている機能の他に、導入する企業独自の機能が盛り込まれることがあります。通常このような機能追加を行う様な場合、ERPメーカーやERPに詳しいベンダーが機能追加を行うのが一般的です。
しかし、機能追加の費用が思いのほか高額だったり、開発期間が長かったりなど、システムのライフサイクルに対する投資効果や導入効果を考えると機能追加を断念せざるを得なくなるようなケースが存在します。その様な場合にFileMaker Proを使用して、ERPと連携するサブシステムを構築すると次のような効果が期待できます。
- 短期間で開発可能な場合が多い
- エンドユーザー視点で設計から始められる
- 短期間で開発可能なので、開発コストも抑えられることが多い
- 導入後のカスタマイズが容易
もちろん、FileMaker Proの機能で実現可能な範囲でのシステム開発になりますので、FileMaker Proではできないこともあると思います。その様なケースを見極めて、ERPのメーカーや開発ベンダーに依頼する機能追加と、FileMaker Proで可能な機能追加を仕分けする必要があるでしょう。
![ERPに追加する独自機能のうち、FileMaker Proで開発可能な機能を切り出してFileMaker Proで開発する ERPに追加する独自機能のうち、FileMaker Proで開発可能な機能を切り出してFileMaker Proで開発する](http://cz-cdn.shoeisha.jp/static/images/article/2599/CZ905_s.gif)
追加機能の構築にFileMaker Proを使用する場合、FileMaker Proの開発ベンダーの力だけで開発を成功させることは不可能です。FileMaker ProのESSでRDBMSへアクセスするためには、RDBMS側のテーブルの構造を知らなくてはなりません。また、新たなテーブルやビューを作成する必要もあるかも知れません。その様な場合には、ERPメーカーや開発ベンダーの力を借りなくてはなりませんので、データのやりとりをするための手順や依頼ルールをERPとFileMaker Proの開発者双方で、あらかじめ取り決めておくとよいでしょう。
ERPのサブシステムをFileMaker Proで開発した場合のメリットとして挙げている「導入後のカスタマイズが容易」という部分についても、ルールあってのことになりますので、明確なルールを設けずにFileMaker Proによるシステム開発を行ってしまうと、後々のトラブルのタネを残すことになってしまうかもしれませんので注意が必要です。