こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
今回は、MicrosoftAccessで開発をしていた私が、なぜFileMakerプラットフォームを用いた開発を手掛けるようになったのか、そしてなぜAccessでの開発を完全に離れて、FileMakerのみで開発するようになったのかの背景について解説したいと思います。
以前はよく「FileMakerとAccessどちらがいいですか？」という質問を受けることがございましたが、ここ最近はほとんど無くなりました。
Googleのキーワードプランナーやトレンド分析で調べてみても、両者の比較についてネットで検索されることは随分と減ってきているようです。
※Googleトレンドでの調査結果
※Googleキーワードプランナーの調査結果
以前は非常に情報の少なかったFileMakerプラットフォームですが、現在は様々なメディアで取り上げられるようになり、情報がかなり充実してきました。
そして何よりも、FileMakerGoの登場がFileMakerプラットフォームのポジショニングを確立した感があります。
そのことも、両者を直接比較する必要がなくなってきた一つの要因かもしれませんね。
一方、内製化支援の仕事をしていると、「どちらがいいの？」というよりも「何が違うの？」とご質問をいただくことがあります。
このご質問をいただくのは、SIerやソフトウェア開発会社で技術者をしている方ではなく、システムの社内開発・内製化を考えている事業担当者や事業部門の方が中心です。
今回は、FileMakerとMicrosoftAccess双方の開発プラットフォームを、概ね同じぐらいやってきた私の経験をもとに、両者の違いを解説し、なぜ結果的にFileMakerプラットフォーム１本に絞るようになったのかについて書いてみたいと思います。
1.MicrosoftAccessでの開発経験
まずは、私自身のMicrosoftAccessでの開発経験を振り返ってみたいと思います。もし、すぐにFileMakerとAccessの比較について知りたい方は、項番３へお進みください。
また、この項でお話しているAccessの経験は、概ねAccess95からAccess2003までの経験です。
それ以降、Accessは2007・2010・2013・2016とバージョンアップを重ねていますが、これらのバージョンはほぼ触ったことがございません。それを前提にお読みいただけると助かります。
1-1.元の出発点はメインフレーム+COBOL
私は約10年程、MicrosoftAccessやVisualBasic、時にはDelphiやJavaといった開発プラットフォームでソフトウェアを開発していました。
さらに自らのキャリアを遡ると、その出発点はメインフレーム＋COBOLで、その後はdBASEIIIやdbXLなどを使ってPC系のビジネスアプリケーション開発を手がけました。
Accessの勉強に関しては、当時VisualBasicマガジンという専門雑誌が月刊誌として発売されており、また参考図書も初級者向けから上級者向けまでかなり豊富にございましたので、それらの本を参考書として独学で学びました。
Accessでのアプリケーション開発は、自分自身でプログラミングすることもあり、そしてより大規模なプロジェクトになった場合は、アウトソーシングするようなプロジェクトもありました。
自身で開発したアプリケーションは、ざっと数えても恐らく10以上のアプリケーションになると思います。
当時、私がAccessで開発したアプリケーションを、VisualBasicでの開発が得意な有名ソフトウェア開発ベンダーのプログラマに見せた時に「随分勉強されていますね。かなりしっかりとした作りです。」と評価をいただいたので、Accessでのプログラミング技術も、それなりのレベルにあったのはないかと思います。
また、アウトソーシングするような規模のレベルになると、フロントエンドのみをAccessで開発し、バックエンドはMicrosoftSQLServerや、時にはMySQLのRDBMSエンジンを配置して開発するようなアーキテクチャで構成していました。
1-2.社内SEの私はAccessには非常に助けられた
その当時、Accessがありがたかったのは、デベロッパーライセンスを購入すれば、ランタイムプログラムの配布が無制限にできたこと。
次に、ネットワーク上でデータベースを共有する場合、ワークグループレベルの規模であればSQLServerの機能限定版であるMSDEやSQL Server Expressが使えたこと。
そしてより大規模な利用が想定される場合はSQLServerへ比較的容易にスケールアップできたことです。
また、私はキャリアのほぼすべてを社内SEとして歩んできたので、社内のちょっとしたツールの開発や、SQLServerで構築された基幹系のシステムから、RAWデータを引っ張ってくるのにも、Accessは非常に重宝しました。
さらに、AccessVBAをマスターしてしまえば、それをExcelVBAやWindowsScriptingHost（WSH）等のVB系言語と組み合わせて、より高度なソリューションを開発することも可能でした。
Excelはほぼ社内全てのマシンにインストールされているものですし、WSHはWindowsOS標準の機能なので、ランタイム等の配布も必要ありません。
社内SEという限られた時間で開発をしなければならない私には、このVB系の言語をひとつマスターすれば、社内の細々とした開発に活かせるという点から非常に助けられました。
1-3.Accessで苦労したこと
一方、Accessで苦労したのはデータ共有、そしてmdbファイルのもろさです。
基本的にmdbファイルはローカルディスク上で使うものであり、ネットワーク上で共有するには大きなリスクがありました。Microsoft自身もそれは認めており、mdbファイルをファイルサーバ上で共有して利用しないようなインフォメーションが出されていたと記憶しています。
それでもやはり、SQL Server ExpressやSQLServer用のサーバを用意するのはお金も時間も、そして、ただAccessのみを使って開発・運用することを考えると、相当の技術力も必要となります。
特にお金の件に関しては、現在のようにクラウド上でWindowsServerが動かせるような時代では無かったこともあり、SQL Server ExpressやMSDEのサーバを建てるにもオンプレミスの専用サーバが必要でした。
当然安価なサーバでも数十万レベルの費用がかかります。
結果、「まずはシステム化の結果が出るまで…」と、半ば神頼みのようにファイルサーバでmdbフィアルを共有して運用したことがあるのですが、パフォーマンスは出ない、mdbファイルは頻繁に破損するといった事態が発生し、すぐにこの構成での運用を諦めた経験があります。
そこで、この事実を上層部に説明し、予算を獲得した上でバックエンドのRDBMSをMSDEやSQL Server Expressに置き換えるわけですが、ここでも問題が発生します。
特に、不測の事態に備えたバックアップ・リストアに関しては、単にmdbファイルを別ドライブにコピーすればOKといった簡易的な運用では無くなりますので、いくらSQL Server ExpressやMSDEといえども、SQLServerのバックアップ・リストア知識が必要になります。
これは、非専門家にとってはかなり高いハードルとなりますし、社内のITにまつわる様々な業務を兼任しながら仕事をしている社内SEの私にも非常にハードルの高いものでした。
結果、少なくとも10名以上で使うようなアプリケーションを、Access+SQLServerで社内SEひとりが、兼任しながら開発・運用するのは不可能との結論に達し、ある程度の規模のシステムになることが想定される場合は、全てアウトソーシングで開発するようになりました。
2.FileMakerで開発するようになったきっかけ
数十名規模での利用を想定したシステムのAccessでの自社開発がムリと判断した頃、その当時勤務していたサービス業の事業会社で、一部のユーザがFileMakerを使って、ある部門の業務システムを作っていました。
その当時勤務していた会社は、これから上場を目指す、もしくは上場直後のベンチャー企業でしたので、IT統制といった観点から、このような情シス部門から見えない「野良アプリ」は非常に目障りな存在でした。
これらのアプリケーションが動かなくなった、もしくはこのアプリが原因で情報が漏洩したとなると、責任は全て情報システム部門になすりつけられます。
しかも、その当時、私自身のFileMakerのイメージといえば、Accessとは比べ物にならない程のロースペックで、実業務には使いものにならない…という印象を抱いていました。
なので将来的には、社内から全てのFileMakerライセンスを無くし、別の開発プラットフォームで統一しようと考えていました。
2-1.最初はFileMakerを否定していた
この頃、社内稟議でFileMakerProのライセンス購入の申請が回ってきた時には、ほぼすべて却下していた記憶があります。今考えればなんてひどいことをしていたのだろうと思います…
しかし、情報システム部門の立場だと、どうしてもそうせざるを得ない背景もあります。
特に自分たちにサポートできないようなアプリケーションが導入され、それがトラブったら全てこちらに問い合わせが来るような構図は決して健全ではありません。
また、このような情報システム部門から見えないアプリケーションは、今で言うところの「シャドーIT」になります。
情報システム部門が中身を把握していないソフトウェアで業務が運用され、例えばそこからアウトプットされた請求書に誤りがあって会社の運営に具体的な損害が出た場合等、情報システム部門も「管理不行き届き」ということで、責任の一部を負わされる可能性があります。
こういったことを考慮すると、「情報システム部門のわからないものは導入させない」という思考が働いて当たり前です。
結果、情報システム部門としてはどうしても硬直的になってしまいます。
2-2.Delphi+Oracleのプロジェクトを失敗…
そんなある時、このFileMakerを使って動かしていたある事業部門の基幹システムを、Delphi＋Oracleで再開発することになりました。
そして開発は、数年来の付き合いのある非常に優秀な、そして信頼できるソフトウェア開発会社さんに依頼しました。
しかし、残念ながらこのプロジェクトは失敗に終わりました。
この時のエンドユーザさんの要求をまとめると、「新たにFileMakerそのものを作って欲しい」というレベルの要求でした。
例えばFileMakerでは、CTRL+Fのショートカットで検索モードに入り、自分の好きな条件で、如何様な条件でも検索を実行することができます。
しかし一般的に、我々プログラマがソフトウェア開発する場合は、まず最初に「どのような検索パターンがあるか？」「どのような検索要件があるか？」を洗い出し、それを検索機能として実装します。
このような「一般論」をお話した上で、エンドユーザさんにヒヤリングしても「どんな条件でも検索できるようにして欲しい」「FileMakerではどんな条件でも検索できる。」「なぜ高い金を払ってシステムを開発するのに、今よりも不便になるのか？」
…といった、エンドユーザさんからの目線では至極まともな、しかしプログラマサイドからすると至極理不尽な要求が次々につきつけられます。
それ以外にも、お客様に必要な情報は全て画面上に表示して欲しい。フォントサイズは小さくなるが、拡大ボタンを押せばその部分だけを拡大できるような機能を実装して欲しいという要求がありました。
FileMakerには、レイアウトの左下にウインドウを拡大・縮小できる拡大ボタンが標準で実装されています。今で言うところのピンチイン・ピンチアウトの機能が標準で実装されているのです。
その機能を便利に使っていたエンドユーザさんは、当然新システムにも同等の機能実装を求めてきます。
私達は「タブに分割するわけには行きませんか？」と提案しますが、「タブボタンをクリックするのが面倒くさい。」「全部の情報を画面上に並べて、必要なところは拡大できるようにして欲しい」。
そして最後には「なぜ高い金を払ってシステムを開発するのに、今よりも不便になるのか？」という決めゼリフをつきつけられていました。
また、ビジネス要求に関しても、非常に複雑で変化の激しいものでした。
特にこちらの会社様は、事業そのものが成長段階にありました。なので、ビジネス環境も刻々と変化し、それに合わせて機能要求も次々に変化（進化）していきました。
当時はウォーターフォール手法で開発をしていたこもあり、この目まぐるしく変わる要求の変化についていくことができませんでした。
結果、完成したソフトウェアは、当初予算の２倍近くの費用がかかり、実現したかったことの半分も実現できない、典型的な失敗プロジェクトに終わりました…
2-3.プロが失敗した開発をエンドユーザが完遂
この状況をみた同事業部門の長の方が、その当時のFileMakerの最新バージョンである8.5で、私がアウトソーサーに作らせた数千万円のDelphi+Oracleのシステムよりも、高性能なものをたったの３ヶ月程度で開発してしまったのです。
これには衝撃を受けました。
もちろん、内部的には洗練されていませんし、ユーザインタフェースに関しても「本当にこれで使いやすいのだろうか…」と、一般的なソフトウェアエンジニアリングのセオリーからは全く想像がつかないようなものでした。
しかし、そちらのシステムが現場に入った後のほうが、業務ははかどるようになりました。
何よりエンドユーザからの受けが非常に良く、結果的に「教育コスト」といった面からも非常に優れたソリューションになりました。
そしてまもなく、Delphi+Oracleで開発された「失敗アプリ」は破棄され、エンドユーザがFileMakerVer8.5で開発したカスタムアプリケーションが本稼働を開始しました。
この本稼動を受けて、よりこのカスタムアプリケーションの機能を充実させるために、やや高度なプログラミング技術を要する機能を実装することになりました。
私は、Delphi+Oracleのプロジェクトを失敗させたせめてもの罪滅ぼしのために、そちらの機能実装をサポートさせていただきました。
この時はじめて、FileMakerを本格的に触りました。
2-4.FileMakerの学習に没頭する
結果、「なるほど。このような仕組みになっていたのか。基本はRDBMSと同じだ。これをソフトウェアエンジニアリングの知識があるプログラマがうまく使えば、より高度なソリューションを短期間で作れるかも…」と気づきました。
その後、運良く幾つかの小規模なFileMakerソリューションを開発する機会に恵まれ、本格的にFileMakerの世界に没頭していきました。
また、この頃はFileMakerプラットフォーム自体が劇的に進化している途中でもありました。（※最近のFileMakerプラットフォームは、この頃にもまして劇的に進化しています。）
Ver8.5でWebビューアが実装され、Ver9で条件付き書式やESS（外部SQLデータソース接続）が実装され、Ver10では待望のスクリプトトリガが実装されました。
そしてVer11では、ついにiOSアプリへの対応が可能になります。
このようなFileMakerプラットフォームの進化もあって、対応できるアプリケーションの幅が一気に広がりました。
一方この当時は、FileMakerに関する本格的な開発テクニック情報を得ることは非常に困難でした。
結果、英語圏にその情報を求め、FileMakerMagazineを購読し、こちらで本格的なFileMakerソリューションの開発手法を学びました。
このFileMakerMagazineは、FileMakerプラットフォームの著名な技術者であるMatt Petrowsky氏が、月に１〜２本のペースで、30〜60分のビデオチュートリアルで開発テクニックを解説してくれます。
もちろん英語なので、すべてを完全に理解できるわけではありません。しかし、サンプルファイルも同時に提供されるので、このファイルを解析することでビデオで解説されている開発テクニックをより深く学ぶことができました。
結果、Accessでは到底開発することはできないような規模のソリューションを、自らの手で開発できるようになりました。
その後、こちらの事例にあるような比較的規模の大きなプロジェクトに参画する機会にも恵まれました。
このプロジェクトを通して、FileMakerプラットフォームの優位性と自分自身の技術力に対して、確固たる自信が持てるようになりました。
3.FileMakerとAccessの比較
さて、ここまで私の個人的なMicrosoftAccessとFileMakerプラットフォームでの開発経験を振り返ってきました。
この経験を踏まえて、FileMakerとAccessの比較を行い、なぜAccess開発者だった私がFileMakerに完全移行したのかを７つの理由に分けて解説したいと思います。
また、この解説は、先にも申し上げた通りAccessに関しては2003までの個人的な経験から書いています。
その後Accessは、2007・2010・2013とバージョンアップを重ねていますが、それらのバージョンはほとんど触っていません。
なのでもしかしたら、ここに書かれていることが最新バージョンでは誤っているかもしれません。
これを前提にお読みいただけるようお願いいたします。
3-1.コーディング量が圧倒的に少ない
Accessで本格的なソリューションを開発する場合と比較して、FileMakerプラットフォームでの開発は、コーディング量が圧倒的に少ないです。
Accessで本格的なソリューションを開発するとなると、まずVBAでコーディングすることになります。
一方FileMakerでは、「スクリプト」と呼ばれる、あらかじめ用意された命令セットを組み合わせながらビジネスロジックを組み立てていきます。これは、Accessで言うところの「マクロ」に近いイメージです。
また、FileMakerのスクリプトはタイピングが必須ではないというだけで、ロジックを組み上げるという意味では、プログラミングとなんらかわりはありません。
ただタイピングによるコード記述ではないので、「コーディング」と表現するには抵抗を示すプログラマさんもいるでしょう。
FileMakerのスクリプトは、コーディングというよりも、どちらかと言うと、子ども向けのプログラミング学習環境である「Scratch」に近い感覚です。
※本記事投稿時点の最新バージョンの14では、マウスによるドラッグ＆ドロップでのプログラミング以外に、タイピングによるスクリプトの記述も可能になりました。
このようなプログラミングのスタイルなので、当然ですがそれ程たくさんのコードを書かなくてもソリューションを開発することが可能です。
また、SQLを記述すること無くデータベースのハンドリングが可能なこともコーディング量を少なくしている一つの要因です。
もちろんAccess+VBAもSQLを記述すること無くデータベースをハンドリングすることは可能です。
しかし、ちょっと複雑な条件でレコードセットを取得したい、クエリのレスポンスを上げたいという場合には、どうしてもSQLの記述が必要になります。
このSQLの記述が、プログラムの可読性・保守性を下げます。
一方、FileMakerでは、リレーションシップグラフとスクリプトの組合せでレコードセットを獲得します。
※FileMakerでは、一般的にレコードセットではなくFindSetと表現されることが多いようです。
また、計算フィールドや集計フィールドといったFileMakerの特徴的なスキーマの仕組みも、コーディング量を圧倒的に少なくするひとつの要因です。
この計算フィールドや集計フィールドは、経験のあるプログラマ程、「奇抜」に見えると思います。
しかし、その動作原理がわかってしまえば、これほど便利なものはありません。
さらに、Accessプログラマからはネガティブにとらえられてしまう、コントロールとデータのバインドを外すことができないことも、コーディング量の少なさに貢献しています。
これ以外にもコーディング量を少なくしている要因は様々ありますが、個人的な経験からAccessとFileMakerで同じようなソリューションを開発する場合のコーディング量は、単純比較でも半分から３分の１程度。場合によっては５分の１程度で済むと思います。
もちろんこれは、私自身の個人的な経験から感じられる「肌感覚」のようなもので、定量的な分析結果ではありません。
しかし、このコーディング量の少なさは、私自身がAccessからFileMakerへ乗り換えるに至った大きな一要因であります。
3-2.日本語でプログラミングできる
FileMakerのスクリプトは、こちらにある通りプログラムはほぼすべて日本語で表現されます。実はこれが「FileMakerが稚拙に見えてしまう」一つの要因かもしれません。
しかし、この日本語でプログラミングできるということは、我々日本人にとって非常にありがたいことです。
何よりプログラムの可読性が高いので、生産性・保守性が格段にあがります。
私は基本的に、よほどの理由がない限りテーブル名・フィールド名・スクリプト名・レイアウト名等、FileMakerのオブジェクトのほとんどを日本語で記述するようにしています。
理由はたったひとつで、そのほうが可読性が高いからです。
可読性が高いということは、それだけ開発スピードも上がりますし、バグも減りますし、後々のメンテナンスも非常にやりやすいです。
私自身、過去にTOEICを受験した時のスコアは600点台でしたので、英語に対してものアレルギーはさほど無いと思っています。
今でも、FileMakerをはじめとする様々な技術情報は、日本語圏よりも英語圏からたくさん取得していますし、必要があれば、Amazonで洋書を購入して読むことがあります。
それでもやはり、日本語圏で生まれ育った人間なので、日本語で記述されたプログラムのほうが読みやすいです。
いくら我々日本人が背伸びをしても、英語圏で生まれ育ったプログラマと同等レベルで、アルファベットで記述されたコードに対して臨場感を得ることは難しいでしょう。
FileMakerの良さのひとつは、小さくはじめて大きく育てられることですが、このアプローチにおいて、スクリプトの可読性の高さは非常に大きなアドバンテージになります。
どうしても英語でプログラミングしたい方は、OSを英語で起動する良いでしょう。スクリプトもユーザインタフェースも全て英語になります。
3-3.サーバ運用がラク
FileMakerプラットフォームには、FileMakerServerという優れたサーバサイドアプリケーションがあります。
このFileMakerServerは、FileMakerProAdvancedで開発したソリューションを、サーバで安全にホストするためのサーバアプリケーションです。
Accessで開発したソリューションをネットワーク上で共有する場合、mdbファイルそのものをファイルサーバにデプロイして共有する運用は推奨されません。
パフォーマンスは悪いですし、何よりデータベースの破損リスクが極めて高くなります。
その点、FileMakerでは、fmp12ファイルをそのままFileMakerServerにホストすれば、それだけで安全にネットワーク上での共有が可能になります。
応答性能に関しても、Accessのソリューションをファイルサーバにホストした時と比較すると雲泥の差です。
特にFileMakerServerの12以降では、サーバ・クライアント間の通信が最適化されたこともあってより高速になり、LTE接続でもストレス無く利用できるレベルになりました。
FileMakerServerの操作はAdminConsoleと呼ばれるグラフィカルなユーザインタフェースを介して行うことが可能です。
シェルスクリプトやコマンドプロンプトで、CUIベースの制御をする必要がありません。これは、タイピングコマンドによる操作に慣れていない開発者にとってはありがたい機能です。（※一部CUIのみでしか対応できないコマンド有）
また、私がAccess+SQLServerからFileMakerへスイッチしてありがたかったのが、バックアップ・リストアの仕組みが極めて簡単だということでした。
FileMakerServerには、GUI操作のみで簡単に設定が可能なオンラインバックアップの機能が実装されています。
このオンラインバックアップを実行して、バックアップされるファイルは全てfmp12形式のファイルです。
そしてリストアするには、このfmp12ファイルをファイルシステムレベルで既定のフォルダにコピーするだけ。
たったこれだけでリストアが完了します。
これはSQLServerをバックエンドDBにした場合とは、比較にならないほど簡単です。
また、FileMakerのVer14には、ソリューションの可用性を高める仕組みとして、これまでのオンラインバックアップ以外に、「プログレッシブバックアップ」と「スタンバイサーバ」という２つの機能が実装されました。
※プログレッシブバックアップはVer12から搭載。
プログレッシブバックアップは、より一般的な表現をすると「増分バックアップ」という表現になるでしょう。
これは、前回バックアップした時以降の変更分だけが保存される仕組みです。
例えばプログレッシブバックアップを5分おきに取得していたとします。
そのサーバで何らかの障害が発生して、データベースをリストアしなければならない事態が発生した場合、夜間に実行するオンラインバックアップでは、前日の業務終了後の状態まで戻らなければなりません。
しかし、５分おきにプログレッシブバックアップを取得しておけば、最悪ダウンした５分前に戻ることが可能なのです。
スタンバイサーバーは、メインサーバーとの同期状態を保った二重化のためのサーバーです。
ハードウェア障害、またはネットワーク障害が発生したときには、スタンバイサーバーがメインサーバーに代わってオンラインになります。（サーバ管理者のコマンド実行による切り替えが必要/コールドスタンバイ方式）
このような機能が標準で装備されているので、よりミッションクリティカルなシステムの運用にも十分に耐えうることができます。
これと同じことをAccess+SQLServerで実現しようとすると、相当のスキルと費用が必要になるでしょう。
3-5.クライアントへの展開がラク
Accessでソリューションを開発した場合、プログラムファイルとAccessランタイムをクライアントマシンに配布することが必要です。
特にプログラムが格納されたmdbファイルをクライアントに配布するとなると、クライアント間のバージョン差異が発生しないように細心の注意が必要となります。また、常に最新のプログラムをクライアントに配布するための仕組みも別途で構築しなければなりません。
一般的にはログインスクリプト等を使って、ファイルサーバの所定の場所にアップロードされている最新バージョンのmdbファイルをクライアントに配布することになりますが、当然これらの機能を作りこむ必要が出てきます。
また、各クライアントマシンにはODBC接続設定が必要となります。
さらにバックエンドDBがSQLServer以外のRDBMS…
例えばMySQLやPostgreSQL等を使用する場合、各クライアントマシンにODBCドライバのインストールも必要となります。
もちろんこの部分は自動設定のプログラムを開発することも可能ですが、当然その機能は別途作りこむことになります。
また、クライアントの台数が数十台・数百台となれば、この手間も大変なものになるでしょう。
一方、FileMakerでは、プログラムもデータも全てFileMakerServerにホストさせることができます。
構造的にはWebアプリケーションと同じです。
FileMakerServerをWeb+DBサーバ、クライアント側のFileMakerProやFileMakerGoを専用ブラウザと見立てればより理解が容易かと思います。
なのでクライアント側にはFileMakerPro、もしくはiPhone/iPadがクライアントデバイスであれば、FileMakerGoさえインストールされてれば、それだけで最新のソリューションにアクセスすることができます。
Accessアプリケーションのように、わざわざクライアントにプログラムファイルを配布する必要はありません。
また、FileMakerVer13から実装された「FileMakerWebDirect」を使えば、ブラウザからFileMakerServerにホストされたソリューションにアクセスすることができます。
こういったクライアントへの展開という視点からも、Access+SQLServerでの運用を想定した場合と比較して格段にFileMakerのほうがラクなことがご理解いただけると思います。
3-6.iOSへの対応（ワンソース・マルチデバイス）
FileMakerプラットフォームは、Ver11からiOSへの対応が可能になりました。
デスクトップアプリケーションを作る場合とほぼ変わらない手間で、iPhone/iPadへのアプリケーション展開が可能です。
これはAccessと比較して大きなアドバンテージです。
もし、あなたがAccessでの開発経験が豊富なプログラマで、これまでに開発してきたソリューションが、iPadやiPhoneのようなスマートデバイスで動くことを想像してみてください。
全く異なるレベルや、これまで対応できなかったクライアントの要求に応えることができるはずです。
今、ビジネスアプリケーションの主役は、PCではなくスマートデバイスです。
このスマートデバイスへの対応ができない開発プラットフォームは、近い将来淘汰されてしまうでしょう。
もちろん完全になくなることはないと思いますが、需要としては相当すくなるなるに違いありません。
3-7.Webサービスとの連携が容易
FileMakerプラットフォームは、Ver8.5から実装されたWebビューアを窓口に、WebAPIをコールすることが可能です。
例えばAmazonや楽天等が公開しているAPIをコールして、ネット上で提供されている様々な情報を取得することができます。
これは、巨大な企業内システムにおいても効果を発揮します。
例えば、基幹システムがデータ連携のためのREST-APIを用意していれば、そのAPIを経由して基幹システムのデータをアップデートすることも可能ですし、逆に基幹システムからデータを取得することも可能です。
FileMakerプラットフォームは特殊で、他の一般的な開発プラットフォームとの親和性が悪いと思われがちですが、Webサービスを通して、あらゆるアプリケーションとの連携を実現することが可能です。
まとめ
この記事では、私の個人的なAccessとFileMaker双方の開発経験から、両者の比較について解説させていただきました。
恐らく、Google検索で、FileMakerとAccessの比較に関する情報を求められている方は、SIerやソフトウェア開発会社にいるプログラマ・SEではなく、自社システムを社内開発したい…つまり内製化を考えている事業部門の御担当者か、社内SEの方になるでしょう。
なぜなら、ソフトウェアの開発を請け負うプログラマ・SEほど、FileMakerプラットフォームを敬遠する傾向があるからです。
これには２つの理由があります。
まずひとつ目は、最初から「FileMakerプラットフォーム=エンドユーザ向けのオモチャ」とラベリングしてしまい、実際に自分の手で検証をしない傾向にあることです。
FileMakerは、FileMakerジャパンのマーケティング戦略から「カジュアルデータベース」というキャッチフレーズで売りだされています。
これは、FileMakerがとっつきやすいという意味では素晴らしいキャッチフレーズなのですが、ITプロフェッショナルからすると「カジュアルなデータベースでミッションクリティカルなソリューションはつくれない」という十分な言い訳になります。
ふたつめの理由として、FileMakerプラットフォームの開発効率が極めて高いことによる開発工数減少のリスクです。
ソフトウェア開発ベンダーは、プロジェクトが大規模で人手がかかればかかるほど、売上が大きくなるというビジネスモデルです。これを「人月積算型ビジネス」と呼びます。
この人月積算型ビジネスは、うがった見方をすれば、非効率に人手をかければかけるほど、売上が大きくなるというビジネスでもあります。
また、能力の低いプログラマでも、数を集めて人海戦術で開発すれば、潤沢なキャッシュを得ることができるビジネスモデルでもあります。
そのようなビジネスモデルなので、極めて開発効率のよいFileMakerが魅力的に映るはずがありません。
開発効率が高くなり、より少ない人数、より短い期間でプロジェクトが終わってしまうようでは、彼らの売上は縮小してしまいます。
受託開発を生業としているソフトウェア開発ベンダーはこのようなビジネスモデルなので、FileMakerプラットフォームに感心を持つ理由がないのです。
一方、事業会社側で自社開発・内製化したい企業の立場に経つと、全く別のニーズがあります。
事業会社側は、できるだけ手間と時間をかけること無く、ビジネスに対して有益なソリューションを素早く開発したいはずですし、ビジネスの成長やビジネス環境の変化に合わせて柔軟にソフトウェアを進化させていきたいはずです。
なので、そもそもソフトウェアの受託開発会社が開発プラットフォームに求めるニーズと、事業会社で自社開発・内製化したい企業のニーズとは、根本的に異なるのです。
このような視点をもって、両アプリケーションを眺めてみると、また違った評価が得られるのではないかと思います。
最後までお読みいただきありがとうございました。
この記事を読まれた方には、こちらの記事もおすすめです。
