こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
この記事では、私達が大規模でスケーラブル（拡張しやすい）なFileMakerのソリューションを開発する時に実践している７つの取組みについて解説します。
一般的にFileMakerは、大規模なソリューションやチーム開発は向かないという論調で語られることが多いように感じます。
また、FileMakerで開発されたソリューションは、検索や表示が遅くて規模の大きなシステムには向かないというネガティブな評価もよく耳にします。
しかし、これはFileMakerプラットフォームの正しい評価とは言えません。
もちろん、「大規模」というのは人によってかなり基準が異なると思います。
例えば極端な話ですが、AmazonやYahooのような超大規模なシステムをFileMakerで開発・運用することは不可能でしょう。
しかし、私達は恒常的に数百クライアントが接続するようなソリューションをFileMakerプラットフォームでご提供しています。
また、この数百クライアントが同時接続しているソリューションは単なる経費精算であったり、各種申請業務をサポートするような単純構造のシステムではありません。私達がご提供するソリューションのカバー範囲は購買・物流・在庫・販売・請求・入金管理といった基幹業務を包括的にサポートするような複合的ソリューションです。
このレベルの規模であれば、私達はFileMakerプラットフォームでも十分に対応できると考えています。
しかし、その為には当然ながら、相応の設計や実装技術が必要です。。
この記事では、私達が普段の開発で実践しているスケーラビリティを担保するための技法や戦略を７つの視点から解説したいと思います。
目次
1.DOAに基いたデータモデリングと実装を行う
FileMakerプラットフォームは、基本的にSQLによるデータのハンドリングを行いませんが純粋なリレーショナルデータベースです。なのでデータモデリングに関しては、DOA（DataOrientedApproach：データ中心アプローチ）で提唱されているモデリング技法を使って設計することが望ましいです。
DOAとは、該当のソリューションがカバーするビジネスドメインの構造と流れに着目し、その構造をERモデルに表現することから始まります。ERモデルとは、Entity-Relationship-Modelも略で、ある抽象化された世界観…一般的なビジネスソリューションに例えると、ある抽象化された業務を「エンティティ（実体）」「アトリビュート（属性）」そして「リレーションシップ（関連）」とう３つの構成要素を用いて表現する技法のことです。
※在庫管理システムのER図
ネット上でFileMakerとMicrosoftAccessやその他一般的なRDBMSとの比較をしているサイトでは、FileMakerでソリューション開発をする際には、モデリングや正規化は必要ないという論調をしばしば見かけることがあります。
もちろんそのソリューションが、個人のデスクトップ上で使われる小規模で利用者も限定されているものならそれでも構いません。
しかし、数十人・数百人が同時に利用し、かつテーブルの数も数十・数百規模のソリューションになると、どれだけDOAで提唱されいている技法に基いて忠実に設計・実装されているかが、後々の拡張性や応答性能に大きく影響してきます。
また、DOAで用いられるERモデルは、FileMakerプラットフォームで言うところの「リレーションシップグラフ」では無いところも重要です。
リレーションシップグラフは、一般的なプログラミング言語やRDBMSではSQLやプログラミング言語で記述するデータ操作のためのロジック…つまり人間からコンピュータに対しての「命令（コマンド）」にあたる部分です。
FileMakerソリューションでは、SQLを記述することなくデータ操作をすることが可能ですが、それを可能にしているのがリレーションシップグラフです。結果的にER図と似たような表現方法になっていますが、その存在目的は全く別物なので、注意が必要です。
DOAの弱点は一度モデリングしたデータ構造を変更すると、その影響範囲を特定するのが極めて難しいことです。なので、フィールドの追加やテーブル間のリレーション設計の変更は、一般的なRDBMSとプログラミング言語を使った開発では非常に嫌われる傾向にあります。
一方FileMakerでは、表面的にはデメリットと言われるデータとビジネスロジック（スクリプト・レイアウト）が分離できないため、どのテーブル・どのフィールドが、どのスクリプトやどのレイアウトで、どういった役割で使用されているかを、メカ的に特定することが可能です。
これはFileMakerの開発生産性の高さを担保しているひとつの大きなアドバンテージだと思っています。
私自身、FileMakerプラットフォームでの開発に従事するまでは、AccessやSQL-Serverといった一般的なRDBMSを使った開発をしていました。そしてFileMakerプラットフォームでの開発を始めた時、このデータとビジネスロジックが完全に分離できないことに強いストレスを感じていました。
しかし、今ではこのデータとビジネスロジックを完全に分離できないことが、DOAの欠点である構造変化の困難さを克服するひとつの要因にもなっていることに気がついたのです。
それ以来、データとビジネスロジックが完全に分離できないことをストレスと感じるのではなく、ひとつの特徴でありアドバンテージだと考えるようになりました。
2.データオブジェクトとそれ以外のオブジェクトを格納するファイルを分離する
これは一般的に「分離モデル」と呼ばれる手法です。
データオブジェクトとは、FileMakerで言うところの「物理テーブル」にあたります。FileMakerでは、「テーブル」という言葉を使う時に、具体的にデータが格納されるテーブルと、リレーションシップグラフの中で用いられる仮想的なテーブルの２つがあります。
私達は、前者を「ベーステーブル」と呼び、後者を「テーブルオカレンス」と呼ぶようにしています。そしてここで言う「データオブジェクト」とは、ベーステーブルの事を指します。
つまり、物理的なデータが格納されているテーブルと、それ以外のオブジェクト…例えばスクリプト・カスタム関数・レイアウトと言った、データのコントロールやユーザインタフェースにあたるオブジェクトを格納したファイルを分離して管理する方法を「分離モデル」と呼びます。
この分離モデルを採用する利点は、スキーマ…つまり、テーブル構造に変更が無く、レイアウトやスクリプト・カスタム関数といったオブジェクトにのみ変更が必要な場合に、ファイルの差し替えだけで、アップデート作業が完了する点です。
もし、分離モデルを採用しない場合、単純にレイアウトが増えた、スクリプトに修正が発生した、でもテーブルスキーマに変更は無いといった場合でも、変更を加えたファイルのクローンを作成し、商用環境で動いているファイルから、最新データのインポートを行う必要があります。
このインポート作業に関しては、データ件数が少なければ良いのですが、数百万件・数千万件のデータが対象となると、インポート処理にかかる時間も膨大になります。結果、システムを停止しなければならない時間が長くなってしまい、業務に影響が出ることが懸念されます。
FileMakerの良さは、小さくはじめて大きく育てるアプローチが容易な点です。しかし、システムに追加機能や修正機能が実装されるたびに、長時間システムが使えない状況が発生することは避けるべきです。
そして、それを避けるためのひとつの方法論が、分離モデルなのです。
3.リソース・イベント・サマリー系でファイルを分割する。
データオブジェクトとそれ以外のオブジェクトが格納されたファイルを分割すると同時に、データオブジェクトファイルも格納されるデータの性質によって分割することが有益なことがあります。
データベース管理システムでは、格納されるデータの性質毎に、大きく３つに分類されます。それが「リソース系」「イベント系」「サマリー系」の３つです。
3-1.リソース系
リソース系とは、一般的に「マスターデータ」と表現されます。比較的更新頻度が少なく、実際に存在するモノやサービスメニューを管理するエンティティ（実体）という事ができます。
例えば一般的な販売管理システムだと、「商品マスタ」「顧客マスタ」「社員マスタ」「店舗マスタ」などといった基本情報がリソース系に分類されます。
このリソース系は、レコードの更新頻度は低いものの、常に多くのレイアウトやスクリプトから参照されるデータになるので、常にFileMakerServerのメモリ上に展開されていて欲しい情報になります。
また、様々な場所から参照されるデータなので、物理ファイルのフラグメンテーションも発生してほしくありません。データの追加や変更が激しいイベント系のファイルと一緒に保存してしまうと、このフラグメンテーションの発生が懸念されます。
また、リソース系ファイルは、イベント系ファイルと比較すると、たった１件のレコード変更で、でシステム全体に大きな影響を与えてしまう特徴もあります。例えば、ある商品マスタレコードの単価を変更した、もしくは課税設定を変更しただけで、イベント系ファイルのトランザクション全体に影響が出ます。
そういった観点から、リソース系ファイルの更新権限は、特定のユーザにしか与えないようなアクセス権設定を施すことが一般的です。FileMakerプラットフォームでは、ファイル毎にアクセス権設定が容易にできるので、この特性を活かし、職務分掌的な側面から、イベント系とリソース系を分割することが推奨されます。
3-2.イベント系
イベント系とは、時間の経過にともなってビジネス活動の中で、随時発生する情報が恒常的に増加するエンティティの事を著します。
一般的にイベント系ファイルに分類される情報は、動詞で表現されることが多いのが特徴です。
例えば、受注・移動・売上・請求・入金等は全て能動的な動詞表現が可能です。これらの単語を動詞で表現すると、「受注する」「移動する」「売上計上する」「請求する」「入金する」となります。
このように動詞表現される単語は、イベント系のエンティティとして分類される候補になります。
イベント系に属するデータの特徴は、更新頻度が極めて高いことです。ということは、物理ファイルレベルでのフラグメンテーションが発生することが予測されますし、不慮の事故が発生した場合のデータ破損リスクも、リソース系ファイルと比較すると相対的に高い傾向にあります。
この物理ファイルのパフォーマンス低下や破損リスクを分散するためにも、イベント系データを格納するファイルと、リソース系データを格納するフファイルは分離することが望ましいと考えます。
また、同じイベント系ファイルでも、先ほどのリソース系ファイルにあったように、職務分掌によって分割することも推奨されます。例えば受注データと売掛金の管理データは、その管理目的や主管部署が異なります。前者は営業部門になりますし、後者は一般的に経理部門がデータ管理の主管部門となるでしょう。
こういったデータ管理の目的や主管部門が異なるデータも、ファイル分割のひとつの目安となります。
3-3.サマリー系
リソース系とイベント系のデータを連結した状態…つまり「非正規化」した状態で集計した結果がサマリー系のエンティティです。
例えば、日別・店舗別の売上集計や、棚卸終了時点での商品別在庫集計等がそれにあたります。
サマリーデータはイベント系データの集計結果なので、イベントファイルをオンデマンドで集計すればこれらの情報を修得することは可能です。しかし、集計対象のイベント系レコード件数が数百万件・数千万件という単位になると、そのたびに集計するのは非常に時間がかかります。また、その影響でサーバ・ネットワークに対する負荷も非常に高くなるので、ソリューション全体の応答性能低下にも直結する懸念事項です。
なので、一般的には集計結果を格納する専用のファイルを設けて、夜間バッチや定期実行されるサーバサイドスクリプト等で、リソース系・イベント系を参照しながら、集計結果をサマリー系テーブルに格納するという方法を取ります。
また、サマリーした売上の結果を、仕訳データとして会計システムに連携するような場合、その連携データを履歴として保存しておくテーブルも、サマリー系に分類されます。特に基幹系システムへの連携履歴は、会計監査上の証跡となるので、別ファイルにセキュアな状態で補完しておくことが望ましいでしょう。
4.命名規約・コーディング規約を決める。
FileMakerで部門横断的な複数の業務を包括的にサポートする大規模なソリューションを構築する場合、チームでの開発が必須となります。そしてこの時に重要なのが、命名規約やコーディング規約、そして禁止事項といったルールを決めておくことです。
例えばテーブル名・フィールド名・レイアウト名・スクリプト名・テーブルオカレンス名・変数名・カスタム関数名などは、ひとりで開発するときでも、命名規約を設けておくと何かと便利ですし、複数人で開発する時には、このルールが無いと大きな混乱をきたします。
また、コーディング規約に関しては、スクリプト引数やリザルトの返し方、LOOPロジックのブレイクポイントの書き方、許容されるIFやLOOPのネストの深さ等をあらかじめ決めておくのも有効な手段です。
また、禁止事項としては、グローバル変数をスクリプト内にハードコーディングしない。やむを得ずグローバル変数を使用する場合は、カスタム関数を経由して参照・更新するなどといったルールが考えられます。
そして重要な事は、この取り決められたルールが守られていることを担保する人間系の仕組みです。
残念ながらFileMakerにはリファクタリングをメカ的にサポートする機能がありません。なので、ルールが守られていることを確認するには、昔ながらの「コードレビュー」という方法しかありません。しかし、このコードレビューを行うことで、潜在的なバグの検知や、熟練した技術者から、未成熟な技術者への技術伝承も可能です。
ぜひ、チーム開発を行うときには、このような開発ルールを制定し、そしてそれが確実に守られるように、コードレビューを行うようにしましょう。
コードレビューは、ルール遵守の監視だけではなく、品質の向上や技術伝承といった副次的な効果も期待することができる素晴らしいアクティビティです。
5.共通ライブラリを用いて一貫性のある構造を保つ
カスタム関数や汎用的なスクリプトは、それらをライブラリ化してチームで共有すると、より早く、そしてより一貫性のあるソリューションを開発することができます。
汎用的なライブラリの格納対象となるオブジェクトの条件は、特定のテーブルオカレンス・テーブルオカレンスグループに依存していないことです。この状態を「コンテキストフリー」と呼びます。このコンテキストフリーな汎用的に使える関数やスクリプトを、たくさん「部品」として持っておくと、開発効率が上がり、またバグの内在率も極めて低くなります。
私達は、この汎用ライブラリの管理にClipManagerというFileMakerプラットフォーム専用の開発サポートツールを使っています。
ClipManagerとは、FileMakerのスクリプトやレイアウト、カスタム関数、テーブル定義等といったオブジェクトを、ファイルシステムレベルのXMLファイルで保存・管理することができる大変優れたライブラリ管理ツールです。
また、保存されたXMLデータを直接編集することも可能なので、ある特定のプレフィックス文字を持ったテーブルオカレンス名を一括して変更するといった操作も可能です。これは、エディタとしての機能があまり充実していないスクリプトワークスペースやレイアウトエディタの機能を補完する素晴らしい機能です。
6.BaseElementsを使ってで内部構造を常にシンプルに保つ
FileMakerプラットフォームでは、レイアウトの追加や修正、スクリプトの追加・修正が容易にできることが非常に素晴らしいのですが、時にそれがデメリットとして働くこともあります。
特に、これらのオブジェクトを簡単に追加できることが災いして、使っていないテーブル・フィールド・テーブルオカレンス・スクリプト・レイアウト・カスタム関数が、残骸のように溜まっていくことがあります。
これら未使用のオブジェクトを定期的に取り除いて、ソリューションの内部構造を常にクリーンに、そしてシンプルに保っておくことは、ソリューションの保守性を担保する上で極めて重要です。
しかし、あるオブジェクトを削除しようとした時に、本当にそのオブジェクトを削除しても良いものかどうか、判断に迷うことがあります。使っていないと思っていたフィールドが、自分の全く知らない別のファイルに格納されているスクリプトから参照されていた、使っていないと思っていたスクリプトが、実は別のファイルのスクリプトから呼び出されていたということは、多くのFileMaker開発者が経験したことのある失敗エピソードではないでしょうか。
このような時に便利なのがBaseElements（ベース・エレメンツ）です。BaseElementsはFileMakerソリューションの内部構造をメカ的に解析してくれるサードパーティー製の開発サポートツールで、各オブジェクト間の参照状態を、物理ファイルをまたいで解析してくれます。よって、先に上げたような別ファイルに格納されているレイアウトやスクリプトから、削除を検討しているオブジェクトが参照されているか否かも、メカ的に把握することが可能です。
このようにBaseElementsは、内部構造をシンプルに保つ時にも役立ちますが、機能の追加・修正を実施するときの影響範囲を調べるときにも非常に効果を発揮します。
ぜひ、FileMakerの開発者として手元に揃えておきたい開発補助ツールです。
7.スケールアウト可能な環境にFileMakerServerをインストールする
スケールアウトとは、必要に応じてサーバリソースを拡張できる事を著します。
より直接的な表現をすると、私達はFileMakerServerを全てクラウド上で運用しています。
クラウド環境であれば、開発当初、及びリリース当初のユーザ数が限定された状態では、少ないリソースでサーバを動かすことができます。そして徐々に機能が拡張され、カバーできる業務の範囲も広がり、それにしたがってユーザ数も増加したら、その増加状況に応じて、サーバリソース…つまりCPUコアやメモリを追加するという手法を取ります。
また、１台のサーバでの運用が厳しくなってくると、２台のサーバを並列して動かすこともあります。
例えば１号機で販売管理系の機能を動かし、２号機で物流管理系の機能を動かすといった運用をします。この時、先に書いたようなファイル分割をしておくことが後々効果を発揮します。
FileMakerプラットフォームでは、１つのデータベースファイルを複数台のサーバに分散して保存することはできません。しかし、ファイルが分離していれば、複数サーバに書くファイルを分散して配置し、それらを相互参照させることでひとつのソリューションとして運用することが可能です。
従来のようなオンプレミスサーバであれば、最初の段階から最大利用時を想定したサーバの購入が必要なので、ソリューションの成熟度が未熟な初期段階ではある意味過剰投資になります。
また、最大利用時を想定していたとしても、その予想が外れることもあります。つまり、必要以上に重厚なリソースを搭載したサーバを購入してしまい、ソリューションが完成した後も、そのリソースを十分に使い切っていないといったことはよくあります。これは明らかに過剰投資であり、ムダなお金の使い方です。
こういったムダを排除するためにも、クラウド上でスケールアウトを前提としたサーバ運用は、「小さくはじめて、大きく育てる」アプローチに欠かせない戦略です。
まとめ
この記事では、私達がスケーラブル（拡張しやすい）なFileMakerのソリューションを開発する時に実践している７つの取組みについて解説しました。
一般的にFileMakerは、大規模なソリューション開発やチームによる開発は向かないという論調で語られることが多いように感じます。
この「大規模」というのは人によってかなり基準が異なると思いますが、私達は恒常的に数百クライアントが常時接続するようなソリューションをFileMakerプラットフォームでご提供しています。このソリューションは、テーブル数も大小含めて100以上、レイアウトも数百レイアウトに昇ります。そしてカバーする業務範囲も購買・物流・在庫・販売・請求・入金管理といった基幹業務を包括的にサポートしています。
もちろん、それぞれのシステムは連携して動きますので、内部的な構造は中小企業向けのERPパッケージとさほど変わらないような設計になっています。
それでもエンドユーザ様からは、応答性能に関する苦情も無く、システム自体も非常に安定して動いています。
但し、この規模のソリューションを開発するためには、この記事で解説したようなことは最低限実施しなければなりません。
翻って、これら一般的な開発プラットフォームでも実施されている事を行えば、FileMakerプラットフォームでも常時数百クライアントが接続し、基幹業務全体を包括してサポートするような複雑なソリューションでも十分に対応可能だということです。
最後までお読みいただきありがとうございました。
この記事にご興味を持たれた方には、こちらの記事もおすすめです。
