こんにちは。
株式会社ライジングサン・システムコンサルティングの岩佐です。
この記事では、Microsoft Access（以下MS-Access）で開発されたレガシー（古い）アプリケーションから、FileMakerプラットフォームへのマイグレーション（乗り換え）をご検討されている企業様を対象に、FileMakerプラットフォームの潜在能力についてお伝えしたいと思います。
この記事を書こうと思った動機は、この数ヶ月で、MS-Accessを基幹業務に使用されている企業様からのお問い合わせが急に増加したことです。
実は私自身2000年ごろから2005年ごろまで社内SEとして、MS-Accessを使って相当数のビジネスアプリケーションを開発してきました。
MS-Accessの魅力は、何と言ってもその手軽さです。
MicrosoftOfficeのDeveloper版をたったの数万円で購入すれば、本格的なソフトウェア開発環境が構築できました。
そして無料のランタイムモジュールを配布すれば、作成したソフトウェアを簡単に社内に配布が可能でした。
更には開発ノウハウに関する情報が豊富だったこともその魅力のひとつでした。
私は当時、社内SEという孤独な存在でした。しかし、技術情報が豊富で開発技術をマスターするのが比較的容易だったこともあり、MS-Accessで相当数の社内システムを内製で開発してきました。
しかしながら、特に中堅・中小企業のビジネス現場の最前線で長年親しみ続けられたMS-Accessが、現在かなり困難な状況にあるようです。
特にAccess2013よりADP（Access Data Projects）形式のソリューションがサポートされなくなったことで、MS-Accessで開発されたアプリケーションのレガシー化を一気にすすめてしまったようです。
さらには、今年2017年の10月にはADPをサポートする最後のバージョンであるAccess2010のサポートが終了したようですね…
そのこともお問い合わせ増加の一因なのではないかと思っております。
目次
ADP形式のソリューションとは？
多くのMS-Access技術者にはおなじみのADPですが、まずはこの技術について少しおさらいをしておきたいと思います。
ADPとは、Access Data Projects の略で、ずばりフロントエンドをMS-Accessで、バックエンドにはSQLServerを使用する専用の開発基盤です。
この形式はAccess2000で登場し、Access2010までサポートされていました。
MDB・MDEのソリューションと異なり、ADP形式で開発されたソリューションは、アプリケーション内に、テーブルやクエリを保持しません。すべてSQLServer、（もしくはMSDE/SQLServerExpressEdition）上にストアされた各オブジェクトにリクエストを投げるのみです。
それまでのMDB/MDE形式によるアプリケーションは、処理の多くをクライアントサイドで処理するため、当時の貧弱なクライアントPCの性能に引っ張られて、応答性能に問題を抱えるアプリケーションが多々ありました。
しかし、ADP形式のアプリケーションであれば、データベースサーバ上で可能な処理は、全てサーバリソースを使って処理を実行できます。サーバサイドで多くの処理を実行できることは、それまでの貧弱だったAccessアプリケーションに次のようなメリットをもたらしました。
- サーバマシンは一般的にハードウェア的に高性能なので、その恩恵を享受することができる。
- 多くの処理がサーバサイドで実行されることで、ネットワーク上に無駄なパケットが流れない。
- 複数の利用者でデータを共有しても、データベースが破損しない。
特に３の問題は、Access開発者・ユーザを常に悩ませてきた問題でした。ですので、ADPの誕生は、当時のAccess開発者、さらにはVisualBasicを始めとするMicrosoft製品でビジネスアプリケーションを開発していた技術者にはとても好意的に受け容れられました。
このように、当時MDB/MDEベースのソフトウェアが抱えていた問題を解決することができ、更には機能限定版ではあるものの、SQLServerを無料で入手できるようになったことから、このADP形式で実装されたソフトウェアは、特に中小規模のビジネスアプリケーション開発に大量に採用されるようになりました。
しかしながら、ADP形式のファイルがAccess2013でサポートされなくなったことで、この大量に生み出されたアプリケーション達の行き場が一気になくなってしまったようなのです。
マイグレーション先となる代替プラットフォームが無い？
お問い合わせをいただくMS-Accessをご利用中の企業様の共通の悩みは、このレガシー化したAccessアプリケーションのマイグレーション基盤を何にすればよいかわからない、もしくは代替となるプラットフォームが無いという問題です。
翻って、ADP形式、もしくはMDB/MDE形式で開発されたアプリケーションは、利用開始から10年以上経過しているものが多くを占めています。当然、当時とはビジネス環境そのものが大きく変化をしているので、ビジネスの現状のソフトウェアが提供する機能そのものに大きな乖離が発生しているケースがほとんどです。
ですので、このAccessレガシーの問題を逆にチャンスと捉えて、現在のビジネス環境にあったソフトウェアを再構築したいという強いニーズをお持ちの企業様が極めて多いことも印象的です。
しかし、このシステム刷新にあたって「開発プラットフォームを何にするか？」が大きな課題となってきます。
そして、弊社にお問い合わせいただく企業様は、様々な調査をされた結果、FileMakerプラットフォームを、新たな社内システムの開発基盤としてご検討されています。
Accessレガシーのマイグレーション・プラットフォームとしてのFileMakerプロダクトの可能性
しかしながら、これまでMicrosoft製品を使い続けてきた企業や開発者にとって、FileMakerプラットフォームはとても「異質」なものに感じるようです。
実際、私自身もはじめてFileMakerを知ったときには「あぁ、あのカード型の…」ぐらいの印象で、まさか企業内の基幹系システムを開発できるようなポテンシャルは持っていないと思っていました。
しかしその後、様々なご縁から、FileMakerプラットフォームを用いた開発を行うようになり、現在では数百クライアントが常時接続するような基幹業務に利用するソリューションを開発させて頂く機会に恵まれました。
このような経験からFileMakerプラットフォームは、Accessレガシーのマイグレーション基盤として、必要十分なスペックを兼ね備えていると自信をもって断言できます。
さて、ここからはAccessレガシーからFileMakerプラットフォームへの移行を検討されている企業様からいただく代表的なご質問にお答えする形で、FileMakerプラットフォームの魅力をご紹介したいと思います。
よくあるご質問１：WindowsOSでもOKですか？
もちろんWindowsでも問題なく動きます。
そして弊社のお客様は100%Windowsユーザの企業様です。
現在、最新バージョンのFileMakerバージョン16がサポートしているWindowsのバージョンは次のとおりです。
| オペレーティングシステム | |
| Windows 10 Pro Edition | 32 ビットおよび 64 ビット |
| Windows 10 Enterprise Edition | Anniversary Update |
| Windows 8.1 Standard Edition | 更新プログラム KB2919355 および KB2999226 |
| Windows 8.1 Pro Edition | |
| Windows 7 SP1 Professional Edition | 更新プログラム KB2999226 |
| Windows 7 SP1 Ultimate Edition |
※近い将来、32bitOSはサポートされなくなることが正式にアナウンスされているのでご注意ください。
このように、現在企業内で使われているWindowsのバージョンはほぼ全て網羅されています。
ですので、安心してWindowsで利用するアプリケーションを開発・運用いただくことができます。
よくあるご質問２：ではなぜMacで開発しているのですか？
多くのFileMaker開発者がMacで開発している理由は、iOSで稼働するソリューションを開発しているからです。
この後ご説明しますが、FileMakerプラットフォームは、１ソースマルチデバイスの開発環境です。つまり、デスクトップ用に開発したアプリケーションを、レイアウトの大きさやフォントの大きさなどを調整することにより、そのままiPhoneやiPad等のiOSデバイスで動かすことができます。
この時に問題になってくるのが、フォントの問題です。
Windows環境には、iOSデバイスで使用可能なヒラギノ系のフォントがインストールされていません。
ですので、iOS用のレイアウトをデザインするときも、メイリオ等のフォントを使ってデザインせざるを得ないのですが…
このWindowsOSで開発したソリューションをiOSデバイスに持っていくと、デザイン時のフォントはiOSデバイスにはインストールされていないので、デザインが著しく壊れてしまうのです。
一方、MacOSには、iOSと同じフォントが標準でインストールされています。
ですので、Mac上でレイアウトのデザインをしたソフトウェアを、iOSで動かしてもデザインが壊れないのです。
レイアウトの調整というのは、想像以上に時間と手間がかかるものです。
このレイアウトデザインの効率化がひとつ目の理由です。
よくあるご質問３：これまで習得してきた技術は無駄にならないですか？
ずばり、無駄になることはありません。
もちろん、Microsoft製品ではないので、VisualBasic互換の言語で開発することはできませんし、FileMakerプラットフォームがもつ独自の仕様に起因した開発ノウハウはあります。
ですので、Accessの開発で培った全ての技術をそのままFileMakerプラットフォームでの開発で活かせるわけではありません。
しかし、データベース設計やビジネスロジックの構築に関する技術力はまったく無駄になることはありません。
3-1.データベース設計の要点はFileMakerもAccessも変わらない
特に、データベースの設計技法については、そのまま活かすことができます。
多くのAccess開発者は、ADP形式のソフトウェアでも、MDB/MDE形式のソフトウェアでも、データベース設計の手法は、DOA（DataOriantedApproch）を採用してきたはずです。
そしてFileMakerプラットフォームで開発するソフトウェアも、このDOAの手法に則って設計することが極めて重要になります。
FileMakerプラットフォームは、もともとカード型から出発しているので、未だにその印象をお持ちの方もいらっしゃいますが、それはもう10数年以上も前の姿です。
現在のFileMakerプラットフォームは、リレーショナルデータベースで、データベースの設計技法はDOAに則って進めることが極めて重要です。ですので、データベース設計に必要なスキルは、Accessで培ったものをそのまま活かすことができます。
3-2.ビジネスロジックの記述には注意が必要
一方、ビジネスロジックの記述については、論理レベルのスキルについてはポータブルとなるものの、やはりFileMaker独特の仕様を理解して記述することが求められます。
ここでAccess技術者が犯しがちなのが、Access時代のやり方をそのままFileMakerでやってしまうことです。
特に、「SQLを使わずにどうやってRDBMSを操作するのか」「リレーションシップグラフとクエリ（もしくはView）は何が違うのか？」「データとフォーム（レイアウト）はどうやって分離するのか？」と言った部分は、Accessで開発していた技術者がハマりやすい部分です。
このあたりをしっかりと理解しないまま、やみくもに開発を始めてしまうと、「FileMakerは遅い」「開発効率が良いって聞いたけど全然効率よくない」といった誤った評価につながります。
よくあるご質問４：バックエンドのDBは必要ですか？FileMakerServerってなんですか？
これも非常によくいただくご質問ですね。
ADPやMDB/MDEでの開発に慣れ親しんできた技術者さんだと、常識的にバックエンドにはSQLServerやOracle、MySQL、PostgreSQL等のRDBMSを据えて、フロントエンドのみをFileMakerで…という印象をお持ちの技術者がいらっしゃいます。
これは多くの場合、誤ったシステム構成となります。
確かにFileMakerプラットフォームには、ESS（External SQL Source）という機能が標準装備されています。
これはまさにフロントエンドをFileMakerで、バックエンドをRDBMSでというシステム構成を実現できるテクノロジーです。
しかし、このESSの主な目的は「他システム連携」であり、より高性能なデータベースエンジンを求めるためのものではありません。
4-1.バックエンドのRDBMSを別に用意する必要はない
FileMakerプラットフォームは、単独でも極めて高速なデータベースエンジンを保有しています。なので、この高性能なエンジンを正しく使えば、一般的なRDBMSをバックエンドに据える必要はまったくありません。
むしろ、そのようなアーキテクチャを採用することで、かえってFileMakerがもつポテンシャルを発揮させることができず、スローで使いづらく、何よりFileMakerの強みである変化への柔軟性を欠いたひどいいシステムになってしまう危険性があります。
では開発したソリューションを、数十名、数百名で使いたいときはどうすればよいのでしょうか？
そこでFileMakerServerの登場です。
批判を恐れずに表現すれば、FileMakerServerは、FileMaker形式のファイル（拡張子がfmp12のファイル）をホストする専用のWebサーバのようなものです。
そしてFileMakerPro（FileMakerクライアント）は、このホストされたfmp12ファイルを各ローカルマシンからアクセスするための専用ブラウザだと思ってください。
ですので、FileMakerで開発されたソリューションは、Webアプリケーションと同じように、全てサーバサイドにデプロイ（配置）することになります。
この結果、ビジネスロジックもデータストアも、サーバサイドに置くことになるので、セキュリティという観点からも、ソフトウェアバージョンの一貫性管理という観点からも、理想的な運用環境を実現することができます。
クライアントに配布する必要が有るのは、専用ブラウザという位置づけとなるFileMakerPro、そしてそのiOS版であるFileMakerGoのみです。これらFileMakerクライアントの配布は、ActiveDirectoryのグループポリシーを使ったり、MDMを活用したりすることで集中管理をすることも可能なので、社内のシステム管理者としては管理がラクになるはずです。
FileMakerServerは、もちろんWindowsServerにインストールすることが可能です。現在、最新バージョンのFileMakerServer 16がサポートするWindowsServerのバージョンは以下のとおりです。
| オペレーティングシステム | |
| Windows Server 2016 Standard Edition | デスクトップエクスペリエンスをインストール済み |
| Windows Server 2012 R2 Standard Edition | 更新プログラム KB 2919355 をインストール済み |
| Windows Server 2008 R2 SP1 Standard Edition
および Enterprise Edition |
この通り、現在企業内で使われているWindowsServerのバージョンはほぼ全て網羅していると思います。
さらにFileMakerServerはこの数年で飛躍的な進化を遂げました。現在のVer16では、公式に500接続までをサポートしています。（※非公式にはそれ以上の接続も可能です。）
当然、数百クライアント接続が発生するアプリケーションだと、ハードウェアのスペックや、ネットワーク設計、そして何よりDB設計やアルゴリズムの設計が適切になされていることが極めて重要です。
例えばOracleやSQLServerで開発するアプリケーションでも、これだけのクライアントが接続するアプリケーションだと、様々な工夫やノウハウ、そしてDBAによる定期的なメンテナンスが必要となりますよね。
それと同じで、FileMakerプラットフォームにおける大規模ソリューションの開発と運用も、適切なDB設計、ハード・ネットワーク設計、検索アルゴリズムの最適化、そして定期的なメンテナンス等が重要になってきます。
よくあるご質問５：結局FileMakerってどのレベルのシステムまでカバーできるんですか？
これは少し難しいご質問です。なぜなら「どれぐらい」が、機能の数を想定しているのか、接続ユーザ数を想定しているのか、データ量なのかがわからないからです。
ですので幾つかの要素に分解していきながら、この「どれぐらい」に答えてみたいと思います。
5-1.機能の数と質について
機能をどの粒度で捉えるかで答えは変わるのですが、理論的には一般的な中堅・中小企業で多く活用されているパッケージシステムレベルのものであれば、まったく問題なく対応することが可能です。もう少しストレートに表現すると、これまでAccessで実現していたレベルの機能はまったく問題なく実現することができます。
ただし質については、少し注意が必要です。
例えばAccessで開発されたソリューションでよく利用されているサブフォームに該当するコントロールはFileMakerには存在しません。似たような機能を果たすコントロールに「ポータル」と呼ばれるものがあるのですが、厳密にはAccessのサブフォーム機能を代替するものではありません。
では、Accessソリューションで用いられるサブフォームが担っていた要求機能に対応できないかと言えばそうでもないです。先に上げたポータルコントロールをうまく活用することで、サブフォームが担っていた要求機能を別の形で実現することが可能です。
大切なことは、FileMakerプラットフォームで用意されているシンプルなコントロールを柔軟な発想で最大限活用することです。
5-2.ActiveX系には注意が必要
また、古いAccessで多用しているActiveX系のコントロールも注意が必要です。これらのコントロールやクラスライブラリで実現していた機能は、別のテクノロジーを用いて実現する必要があります。
例えば、ツリービューやデータグリッドコントロール等、業務システムでよく用いられるコントロールに関しては、操作性をそのまま移行するとなるとJavaScript/jQuery等で記述されたUIコントロールで実現するなどの代替策が必要となります。
同じActiveX系と言っていいのか迷いますが、古いAccessで使われているもうひとつの代表的なクラスライブラリとして、WindowsScriptingHostがあります。WSHの中でも、ファイルシステムオブジェクトなどは、Accessから直接OSのファイルシステムにアプローチできるライブラリなので、特に他システム連携やRAWデータの出力時には、定番となるライブラリです。
しかし、FileMakerプラットフォームには、FileMaker単体でOSのファイルシステムにアプローチする手段が極めて限られています。少し複雑なことをしようとすると、標準機能だけではすぐに限界を迎えます。
このような場合、幾つかの方法があるのですが、最もぽピュラーな方法はプラグインを使うことです。FileMakerには、FileMakerの機能を拡張するためのプラグイン・インタフェースが用意されています。プラグインはC++で記述する必要があるのですが、自分でプラグインが開発できるようになれば、極論するとC++で実現できることはなんでも実現できることになります。
5-3.ツリービューやデータグリッド等も注意が必要
ビジネスアプリケーションでよく利用されるコントロールとして、ツリービューやデータグリッドがあります。
実は、これらのコントロールもFileMakerには標準装備がされていません。
解決策はいくつかあるのですが、昨今ではこの部分をJavaScript(jQuery)を使って解決することが増えてきました。
ツリービューやデータグリッドは、業務系のWebアプリケーションでかなり多用されるものです。そして、これらのコントロールは、オープンソースで様々なものがフリー、もしくは有償でも極めて安価な金額で入手可能です。
ただし多くの場合、無償で公開されているリッチなUIコントロールは海外製になるので、英語のドキュメントを読みこなす英語力と、JavaScriptのコーディング技術が必要になります。
しかし、このハードルを超えれば、極めてリッチなユーザインタフェースを実現することが可能です。
これら以外にも、ドラッグ＆ドロップ操作やフォーマット入力（ComplexInput）など、「機能の質としてのどこまで」については注意すべき点があるのですが、現在では概ねJavaScriptをうまく使うことで解決可能です。
5-4.ユーザ数・データ量については多くの場合心配なし
接続ユーザ数と、データの大きさの許容範囲については、適切なDB設計・アーキテクチャ設計が前提となりますが、常時数百名のユーザが接続するビジネスアプリケーションでもまったく問題なく対応することができます。
現在、FileMakerServerの接続クライアント数は、オフィシャルに500接続まで保証されていますし、非公式にはそれ以上の接続が発生するようなアプリケーションの構築も可能です。
詳しくは、FileMakerServer16の技術仕様をご確認ください。（https://www.filemaker.com/jp/products/filemaker-server/server-16-specifications.html）
弊社クライアント様での実例的にも、データ量が年間数十GB/数百GBレベルで増加するようなアプリケーションでを数年に渡って運用しています。
以下、データベースファイルの限界値の代表的な項目について、列挙しておきます。（FileMakerオフィシャルサイトのナレッジベースより引用）
■ファイルサイズ：
ディスクスペースによってのみ制限されます。ハードディスクおよび OS の API 能力に応じて、最大 8 TB（テラバイト）です。
■同時に開くことができるファイル／ウインドウの数：
Mac OS：最大 125 ファイル／ウインドウまでにすることを推奨します。
Windows：最大 125 ファイル／ウインドウまでにすることを推奨します。
※FileMakerにおけるウインドウの数は、DAOのWorkspraceクラスと同じような概念を持っていると思っていただいてOKです。
■レコードごとのフィールド／列の数
ファイルの耐用期間全体で 2 億 5,600 万
■ファイルごとのテーブルの数：
100 万
■テーブルごとのレコードの数：
ファイルの耐用期間全体で 6 京 4,000 兆
■レイアウトオブジェクトの数：
レイアウトごとに最大 32,768 オブジェクト
■ファイル毎のスクリプトの数：
ディスクスペースによって制限されます。
■カスタム関数の再帰限界
総計 50,000 再帰呼び出し
この通り、多くのビジネス・アプリケーション開発において、このスペック値が問題となってくることはまず無いでしょう。結論として、「どれぐらい」という規模を問われるご質問については、多くの場合「心配する必要はほとんど無い」というのが答えになります。
まとめ
この記事では、弊社がMS-AccessからFileMakerプラットフォームへ乗り換えを検討されている企業様からよくいただくご質問にお答えする形で、Accessレガシーのマイグレーション先としてのFileMakerプラットフォームの可能性とその魅力についてお伝えしてきました。
弊社のオフィシャルブログでは、MS-Accessに関する記事を幾つか公開させていただいております。こちらは弊社ブログの中でも最も人気の記事となっておりますので、ぜひチェックしてみてください。
FileMakerプラットフォームは、一般的に流布している印象よりも、遥かに高性能です。
事業規模的にも、年商数百億円レベル企業様の基幹系業務システムを、FileMakerプラットフォームだけで構築できるだけのポテンシャルを秘めています。（もちろんこれは、全てのシステムをFileMakerで開発することを推奨するものではありません。）
恐らく、MS-Accessを基幹業務システムとして使用している企業の事業規模は数十億から数百億が中心となるでしょう。この規模のシステムであれば、いくつかの制限はつきますがほぼ問題なくカバーすることができるでしょう。
恐らく乗り換えの障壁となってくるのは、「基幹系業務システムを開発するための具体的なノウハウ」と「ライセンス費用」に関する問題だと思います。
特にライセンス費用の問題については、バックエンドのRDBMSにMySQLやPostgreSQL等のオープンソースのデータベースを使う、もしくはMSDE（SQLServerExpressEdition）などで開発・運用してきた企業にとっていままだ必要の無かったコストが新たに発生することになります。ですので、社内で稟議起案する時にはしっかりとした理論武装が必要となります。
この理論武装法については、また別の記事にてお伝えさせていただきたいと思います。
もし、ここでお答えしたご質問以外にも、「こんなことを聞きたい！」「FileMakerのこの部分がなぞ…」等ございましたら、お気軽にお問い合わせください。（内容によっては即答できないものや、より詳細なヒヤリングが必要なケースも出てきますので事前のご了承をお願い致します。）
