大規模開発への対応
連載の第3回/第4回/第5回で、FileMaker Proによるプログラミングの基礎を機能ごとに紹介してきました。実際のソリューションでは、これら基本的な部分の組み合わせと積み重ねが、無数のアイデアや発想へとつながっていきます。そういったアイデアの数々は、また機会と場所を改めてお話したいと思いますが、今回はこれまでと少し立ち位置を変え、「大規模開発」について触れることにします。
大規模開発の分類
「ソリューション」は、シンプルな「機能」を組み合わせた「システム」の集合体です。その集合体が大きくなれば「大規模開発」になっていくわけですが、まずはその形態を大きく3つに分けてみます。
- 「利用者数が多い」という意味での大規模
- 「データ量が多い」という意味での大規模
- 「連携範囲が広い」という意味での大規模(他システムとの連携も含む)
いわゆる「大規模システム」には、これらの要素をすべて内包していることが多いとは思いますが、これらの視点からFileMakerの開発における留意点についてを話します。
利用者数が多いシステム
FileMakerにおけるデータ操作の簡易さと、それによる危険性
利用者が増加するということは、多くのデータに多くの人が触れるようになるということです。そこで重要になってくるのが「データの安全性」です。安全性の対象には、データの漏えい以外に、改ざんや消去による紛失なども含まれます。
FileMakerを一つのツールとしてとらえたとき、その操作性の良さから、データの集約、整理、内容の正規化、書き出しなどの作業が容易です。転じて便利な反面、構築するシステムの制御がおろそかになると、ふとした操作で先述のようなトラブルが発生しまう危険性をはらんでいます。システムの規模や性質にもより、これらの制御をどこまで行うかを見極めることも重要です。
制御の手法
FileMakerで、さまざまなアクセス規制を行う基本は「アカウントとアクセス権」による管理です。システム起動時に認証するアカウントに対して、テーブル/レイアウト(画面)/フィールド(項目)の表示/編集を制限することが可能です。
また、FileMaker Pro Advancedを利用すると、画面上部に表示されるメニュー構成(ファイル、編集、表示など)をカスタマイズし、それぞれの画面上で不要なメニューを非表示にできます。不用意な操作や不正な操作を防ぐのに有効です(「カスタムメニュー」の作成には、FileMaker Pro Advancedが必要です)。
さらに、「誰が、いつ、どのデータに対して、何をしたか」を管理できればよいですが、FileMakerの標準機能には、いわゆるトランザクション管理がありません(それぞれのレコードに最終更新者や最終更新日時を記録することは可能です)。
これを実装するには、別途その仕組みを組み込む必要があります。場合によって手法は変わりますが、一例を挙げると次のようなものがあります。
- データ編集の際、対象となるレコードを編集するのではなく、複製したレコードに対し行い、元レコードには「無効」フラグを立てる。
- データ削除に関しても、データを実際に削除するわけではなく、「無効」フラグを立て「削除扱い」のデータとする。
このようにすることで、「誰が、いつ、どのデータに対して、何をしたか」が明確になり、紛失したデータをある特定時点まで復旧することも可能になります。
直感的なUIデザイン
もう一点。これは少し視点が異なりますが、利用者の多いシステムで念頭に置くべきことがあります。それは、「感覚的に操作できるユーザーインターフェイスデザイン」です。
利用者が多いと大変なのが、システムの操作方法の落とし込みや、それに対する問い合わせの対応です。これらを事前に踏まえて、ボタンの配置や、必要最小限の情報の配置を考えていくことが重要です。
幸い、FileMakerはそういったレイアウトデザインや配置に関して、開発者に高いスキルを求めてきません。ドラッグ&ドロップによる直感的な操作で行えるため、配置作業に手間がかからず、クリエイティブな思考に注力できます。「センス」の多少はあるかもしれませんが、コツとしては分かりやすい画面構成を心掛けるとよいでしょう。
データ量が多いシステム
FileMakerのC/S環境における特性
この件の予備知識として、C/S(クライアント・サーバ型)環境におけるFileMakerのある便利な特性について触れておきます。
例えば、「郵便番号簿」のマスターにある特定の同一レコードを、2人のユーザーが画面に表示していたとします。この時、一方がデータの一部を変更すると、当然、変更した側の画面は新しい情報に更新されますが、もう一方の画面ではどうなっているでしょうか。
一般的なC/Sシステムでは、[更新]ボタンなどの明示的なアクションにより、再度SELECT文を発行して、最新情報を取得することになると思います。ところがFileMakerでのC/Sシステムでは、そのような明示的な操作を行わなくとも、表示されている画面の情報が最新の内容に変更されます。
簡単に説明すると、データの変更内容を受け取ったFileMaker Serverが、その情報を各クライアントに向けてほぼ即時に配信します。配信対象は、「その情報を画面上に表示している」クライアントです。
「その情報を画面上に表示している」という部分を念頭に置いて、以下の話を読み進めてください。
ネットワーク上でのデータの流れ
さて、扱うデータ量が非常に多くなった場合、考慮する点の一つに「データ取得時の反応速度」があります。
この速度を左右する大きな要因の一つが、ネットワーク上を流れる「データの量」です。呼び出し対象のデータや利用者に比例して増大します。システムの反応速度を保つならば、この「流れるデータ量」が増えないように工夫する必要があります。
先述のように、FileMakerではクライアントが画面で表示している項目が、データ取得の対象となり、常にそこに向けてデータが配信されます(逆に言えば、その項目を対象にしたリクエストが常に投げ続けられています)。従って、表示しているレイアウトの項目数が多ければ多いほど、流通するデータ量も多くなります。
画面構成の簡易さから、特に意識せず無造作に項目を並べていくと、情報が見づらくなるだけでなく、トラフィックに余計な負担をかけることになるので、注意した方が良いでしょう。
ただ、逆に「画面に表示されていない項目はデータが流れてこない」と考えることもできます。さらに言うと、レイアウト上には配置されている項目でも、ウィンドウの表示サイズの外側にある項目は、画面をスクロールして表示されるまでデータが流れません。
これについては、下記の資料を参照してください。
検索を行った後の一覧表示と、その際にネットワーク上を流れたデータをキャプチャしたものです。
図3~4は、検索にヒットした件数が62件で、そのうち51件を画面に表示しています。図5~6は、図3~4と同じ検索を行いますが、ウィンドウの高さを狭め、画面に表示されるレコード件数を少なくしています。両方とも検索結果の件数は同じですが、流れているデータ量が異なることが分かります。
レイアウトに不必要な項目を配置するとトラフィック増加の要因となるため、画面構成をデザインするに当たっては意識したい部分です。
連携範囲が広いシステム
データ連携する手法
企業規模の大きな所になると、既に基幹システムが稼働しておりマスターデータはそこから引く、あるいは複数のシステムがお互いに必要な情報を補完しあうために、FileMakerで開発したシステムのデータとの連携が必要になってくることが多々あります。
FileMaker以外のシステムとデータを連携させる方法はいくつかありますが、代表的なものは次のとおりです。
- A: CSVやXMLデータなどのテキストデータファイルを介し、定期的にインポート/エクスポートする。
- B: 条件が合えば(適用できるドライバがあれば)、ODBCを経由したデータのインポート/エクスポート、あるいはスクリプト「SQLを実行」を使用して、INSERT/UPDATE/DELETEなどを行う。
- C: さらに条件が合えば(動作環境を満たせば)、外部SQLデータソース(ESS)機能を利用し直接データを参照する。
Aは、取り込み側でそのデータを取り込むための処理と、その処理をキックするトリガーが必要となります。その性質上、汎用性はありますが即時性に欠けます。
Bは、ODBCドライバの有無と、動作確認が条件となります。この場合は、データの送信と取得がFileMaker側のアクションで行えるので、例えば[更新]ボタンのスクリプトに「SQL実行」スクリプトをサブスクリプトで連ねておけば、一連の流れで連携がとれるので、リアルタイムに近い処理が行えます。
Cは、適用可能範囲が狭くなりますが、他システムのテーブルを直接参照していることになるので、連携の中では一番、即時性が高いでしょう。
データ連携する際の留意点
まず連携手段にかかわらず注意が必要なのは、「FileMakerにおけるテーブル定義では、桁数という考え方がない(に等しい)」という点です。FileMakerでは、各データタイプごとに保持できる最大データ量の仕様が存在するものの、テーブル定義の際に、各フィールドに桁数を指定することができません。
従って「テキスト」タイプのフィールドには、データサイズを特に意識しなくても良いくらいの文字数が入力できてしまいます。しかし、他システムとの連携を考えるときには、この「桁数」が大きく影響してきます。
そのため、それらの桁数を考慮した別の連携用フィールドを必要としたり、書き出したデータを成型し直したりする必要があります。
また、同様の理由からFileMakerは基本的に「可変長」です。よくホストデータから提供される形式に「固定長」のものがありますが、これらをFileMakerに取り込む時や他システムに提供する時も、この辺りを念頭に置いておく必要があります。
他システムとの連携を行う場合は、それぞれのシステムのデータの持ち方の特性について、相互理解を深める必要があります。データベースという同じ世界の中でも、それぞれで「常識」というものが存在し、それを外すと担当者同士の会話も通じません。ましてや、システム間の連携がさらに困難なことは言うまでもないでしょう。
以上のように、FileMakerはシステム開発のプロセスにおいて、「技術やデジタル」な部分よりも「対話やアナログ」な部分に関わる時間を多く取ることができる、大きな特長があります。
まとめ
冒頭で述べたようにソリューションがシステムの集合体であるとすると、すべてを一貫して同一環境で構築していく懐石やフレンチのフルコースのようなものより、洋食屋のアラカルト的な需要が増えてきていることが最近特に感じられます。
また得てして、そういう方が「ライス大盛り」にするような融通が効き、好まれたりするものです。また、出張シェフとして、フルコースの一品を供し得ることも忘れてはいけません。
これらを意識するために今回は、ちょっとだけ俯瞰したところから話を進めてきました。
まだまだ整理していきたい情報もありますが、また別の機会に場を移して皆さんと一緒に組み上げていきたいと思っています。
さて、次回よりまた少し新たな皿(展開)へと移っていきます。
最後になりましたが、この連載が終わる頃には「(お客様からの)注文の多い料理店」を志す人が少しでも増えていることを切に願って、次回にバトンを渡したいと思います。