ChatGPT( OpenAI 社の生成 AI ツール)の力を借りてアクセス(以降、「Access」)からファイルメーカー(以降、「FileMaker」)への移行についてまとめてみました。
一般的な違いは既にたくさんのサイトで書かれていると思うので、
「 FileMaker 利用者が Access に移行したエンジニア目線で語ってもらう」
という想定にしてみたいと思います。
FileMaker → Access という逆説的な移行の視点で見ることで、移行を実施する前に押さえておきたいことを浮かび上がらせる目論見です。
Index
- 本記事の概要
- FileMaker から Access への移行の現実:最初に感じた壁
- フォームとレポート作成の違い:デザインの制約
- スクリプトとVBAの違い:自動化のハードル
- データ型の管理と制限:自由度の違いを実感
- パフォーマンスの違い:大規模データの処理速度
- まとめ:FileMaker から Access への移行で学んだこと
- 本記事のまとめ
本記事の概要
余談:さて、次の章からが ChatGPT に聞いてみた内容になります。
「FileMaker の使い手が Access に移行してみた」という想定になります。
FileMaker → Access への移行で難しいところや制約・制限などが分かれば、結果的に FileMaker → Access への移行に関しても何かヒントを得られるのではないか。
例えば、移行の実施前に押さえておきたいことが浮かび上がるかもしれない、ということです。
生成された文章は、なるべくそのまま使っていますが、文章的におかしかったり、辻褄が合わないような箇所には一部手を加えています。
(以降、ChatGPT による生成文章まとめ )
FileMaker から Access への移行の現実:最初に感じた壁
私は FileMaker を使い続けてきた中で、その直感的で自由度の高いデザインや操作感に大変満足していました。
しかし、ある日業務上の必要から Access に移行することになり、まず最初に直面したのは、その操作の複雑さでした。
移行を始めた当初は「似たようなものだからすぐに慣れるだろう」と考えていましたが、実際には操作感の大きな違いに戸惑い、特にその「直感的な設計」に対する制限に気づくことになりました。
作業途中での柔軟性の違い
FileMaker では、データベースの構造やリレーションシップを途中からでも柔軟に変更でき、プロトタイプ感覚で作りながら調整していくスタイルがとれました。一方、Access ではテーブル間のリレーションシップをあらかじめしっかり設計し、 SQL などで定義しておく必要があり、「作りながら考える」という進め方がしづらいと感じました。
特に、初期設計段階での構造の完成度が求められるため、途中からの方向転換や変更が難しく、作業効率が下がる場面が多くありました。
FileMaker の「すぐできる」が Access では通用しない
FileMaker では、新しいフィールドやレイアウトを簡単に追加でき、試行錯誤しながら迅速に構築できました。しかし、Access ではそれができず、設計を反復して見直さないといけませんでした。
このプロセスの違いに驚き、移行初期はかなりストレスを感じました。
【ながにぃ考察】
Access では「初期設計段階での構造の完成度が求められる」とありますが、FileMaker も初期段階での構造設計は最低限やっておいた方が良い場合が多いです。なお、制作に入ってしまえば FileMaker の柔軟な変更・調整は発揮しやすいかと思います。
フォームとレポート作成の違い:デザインの制約
FileMaker の魅力の一つは、フォームやレイアウトのデザインの自由度です。
ユーザーインターフェースを直感的に設計できるため、業務に合わせたカスタマイズが容易に行えます。
ところが、Access に移行すると、フォームやレポートのデザインには大きな制約があり、思うようにカスタマイズできないことに気づきました。
フォームのカスタマイズの難しさ
Access ではフォームのデザインが可能ですが、細かいレイアウト調整が必要で、FileMaker のように簡単に変更することはできませんでした。特に、フォームの中に複数のパーツ(テキストボックスやボタンなど)を配置する際に、視覚的にバランスを取ることが難しく、調整に時間がかかりました。
このような制約が、ユーザーインターフェースのカスタマイズを大きく遅らせてしまいました。
レポート作成の制限と手間
FileMaker では、レイアウトモードで視覚的に項目を配置でき、見た目の調整や条件付き表示なども比較的簡単に対応できました。一方、ccess ではレポート作成においてウィザードやテンプレートが用意されているものの、複雑なデータ構造や条件付きの集計が絡む場合は VBA やクエリとの連携が必要になる場面も多く、単に「見た目を整える」以上に技術的な調整が求められる印象を受けました。。
特に、デザインの自由度やレイアウトの細かさに関しては、FileMakerの方が柔軟性が高く、業務に合わせた見た目の最適化がしやすかったと感じます。
【ながにぃ考察】
FileMaker の場合はパワーポイントのような感覚で画面を調整できる簡易さに留まらず、Web サイトのようなリッチな画面に仕上げることもできます。今回は Access と比較していますが、他のデータベースツールと比較しても FileMaker の画面優位性は高いと思います。
スクリプトとVBAの違い:自動化のハードル
FileMaker では、独自のスクリプト機能を使って処理を日本語に近い感覚で組み立てられるため、非エンジニアでも比較的短期間で業務の自動化を実現しやすい環境が整っています。
一方で、Access に移行すると、より本格的な自動化には VBA(Visual Basic for Applications)の活用が求められ、プログラム的な思考や文法の理解が必要になり多くの学習時間を費やしました。
簡単な自動化が VBA では難解
FileMaker のスクリプトは、非常にシンプルで分かりやすいため、特にプログラミングの知識がない私でも簡単に自動化できました。 しかし、Access の VBA は構文が複雑で、最初は理解するのに時間がかかり、すぐに必要な処理が実行できない場面が多々ありました。特に、VBA ではエラー処理やトランザクション管理* を明示的に記述する必要があり、処理の安全性を保つには細かな制御が求められる点に苦労しました。
一方で、FileMaker ではそうした高度な制御は意識せずに済むため、使いやすさの面では大きな違いを感じました。
*トランザクション管理・・・データベース用語。複数の処理をひとまとまりにして、全て成功したときのみ確定させる仕組み
VBA コードの長さと複雑さ
Access では、FileMaker のスクリプトに比べてコーディングが長くなりがちです。例えば、単純なデータ更新や条件分岐を行うだけで、かなり長いコードを書かなくてはならないことに驚きました。
このような細かい処理を繰り返すたびに、VBA コードを管理するのが煩雑であり、結果として作業効率が低下してしまいました。
【ながにぃ考察】
VBA のコーディングは専門的な技術や知識の習得が不可欠です。記述のルールも規制が多いので思った通りの動きになるまでトライ&エラーによる多くの時間がかかると思います。
データ型の管理と制限:自由度の違いを実感
FileMaker では、データ型の扱いが比較的柔軟で、ユーザーが意識しなくても自動で型変換が行われる場面が多く、日常的な運用がスムーズに進みました。
一方、Access では各フィールドのデータ型が厳密に定義されており、予期しない型のデータが混在するとエラーが発生しやすく、取り扱いに慎重さが求められます。
データ型変換に必要な手間
FileMaker では、日付や数値などの型をまたぐ演算や変換がシームレスに行え、ユーザーが意識しなくても正しく処理されることが多くありました。しかし Access では、型変換が明示的に必要であり、 クエリ や VBA で関数を使って処理しなければならないケースが増えます。
特に、数値と文字列を混在して扱う処理や、日付形式の整合を取る処理などで時間がかかり、作業効率に影響しました。
不整合データを扱う際の問題点
FileMaker では、入力時のデータチェックやスクリプトでの補正が容易で、ある程度不整合なデータも柔軟に処理できました。一方 Access では、データ型が厳密であるため、少しでも合わないデータが存在するとインポートや更新時にエラーが発生しやすくなります。
そのため、事前にデータクレンジングを行ったり、エラー処理のためのロジックを追加したりと、設計・運用時に一層の注意が必要になります。
【ながにぃ考察】
「データクレンジング」というのはまさに「データ洗浄」。特殊記号や改行が誤動作を引き起こしたり、半角の必要がある文字列が全角になっていたり、予期しないデータが入っている場合には Access は確かに弱いのかもしれません。(最近の Access は分かりませんが)
パフォーマンスの違い:大規模データの処理速度
FileMaker は、少量から中規模のデータ処理において非常に高速で安定しており、ユーザーが意識せずとも高いパフォーマンスを発揮します。
これは、インデックスやキャッシュといった最適化機能が自動で管理されているためで、特別な設定をしなくてもスムーズな操作が可能です。
一方 Access では、大量のデータを扱う際にパフォーマンスの低下が顕著になり、処理の高速化のために手動で最適化を行う必要が出てきました。
クエリの最適化とパフォーマンス低下
Access では、特に複数のテーブルを結合するような複雑なクエリ(条件に応じてデータを抽出・加工するための処理命令)を実行すると、パフォーマンスが著しく低下することがあります。この場合、インデックスの追加やクエリの再構成といった最適化作業が必要になりますが、それらはすべて手動で行う必要があり、想像以上に手間がかかりました。
ファイルサイズが数百MBを超えるような状況では、検索やレポート生成に数十秒以上かかるケースもあり、運用面での課題を強く感じるようになりました。
データの取り込み速度の違い
FileMaker では、大量の CSV ファイルや他システムからのデータ取り込みがスムーズで、インポート中にフリーズしたり動作が遅くなったりすることはほとんどありませんでした。それに対し、Access ではデータのインポート時にパフォーマンスの落ち込みが見られ、特に10万件を超えるデータを一括で読み込む場合は、途中で停止したり処理に数分以上かかることもありました。
このような特性から、定期的なデータ更新やバックアップの運用を考える際には、Access のパフォーマンス特性を事前に理解し、工夫した設計が求められると感じました。
【ながにぃ考察】
FileMaker であっても、10万件を超えるような大規模データではある程度のパフォーマンス低下は避けられません。とはいえ、FileMaker ではスクリプトやレイアウトの調整など、視覚的かつ柔軟な手法で最適化が可能ではあります。
まとめ:FileMaker から Access への移行で学んだこと
FileMaker から Access への移行は、予想以上に多くの課題を含んでいました。
FileMaker の柔軟性、直感性、デザインの自由度、そして自動化機能に慣れていた私は、Access の堅牢さや制限に直面し、最初はその違いに戸惑いました。
しかし、最終的にはそれぞれのツールの強みを理解し、どちらが最適かを見極めることができました。
移行をスムーズに進めるためには、両者の違いを理解し、Access の仕様に合った最適な設計と管理を行うことが重要であることを学びました。
今後も、FileMaker と Access のどちらが適しているかを見極め、プロジェクトに最適なツールを選ぶ重要性を再確認しました。
【ながにぃ考察】
Access は費用面では優位性が高いけれど、イチから複雑なデータベースを構築するのは多くのハードルがあります。FileMaker は柔軟で取り組みやすい反面、費用の部分では Access に劣ることもあります。どちらが良い悪いではなく、それぞれの特徴を捉えて最適な選択をするのが大事ですね。
本記事のまとめ
Access から FileMaker への移行で大きく戸惑うのは次の2点です。・画面構造の違い
・リレーションの違い
これは弊社が移行のサポートした経験から導き出されたものです。
ということは、逆に言えばこの2点さえ克服(理解)すれば、その後の開発はスムーズに進むことが期待できます。
Access も FileMaker も同じリレーショナルデータベースですしね!
対面によるサポートならマンツーマンで早い習得も見込めます。
メッセージツールによる質問数無制限のきき放題サポートではマイペースで理解を進められます。
今日も良い一日を♪
AccessとFileMakerの比較:メリット・デメリット一覧
基本的な違い
AccessはMicrosoftのリレーショナルデータベースで、ExcelやSQL Serverと相性が良いのが特徴。一方、FileMakerはClaris(Apple傘下)のノーコード/ローコードツールで、直感的なUIとマルチプラットフォーム対応が強み。
メリット・デメリット比較表
項目 | Microsoft Access | Claris FileMaker |
---|---|---|
操作性 | リレーショナルデータベースの概念を理解する必要があり、初心者には難しい | 直感的なGUIでドラッグ&ドロップ操作が可能 |
データベース設計 | 正規化を前提とした設計が必要 | 柔軟なテーブル設計が可能(非正規化でも動作しやすい) |
クエリ・データ検索 | SQLを使用できるため、高度なデータ操作が可能 | SQL不要で簡単にデータを検索・集計できる |
フォーム作成 | デザインの自由度が低く、カスタマイズに制限がある | 直感的なレイアウト作成が可能で、自由度が高い |
スクリプト・自動化 | VBAが必要で、習得に時間がかかる | FileMaker独自のスクリプト機能で簡単に自動化可能 |
Microsoft製品との連携 | Excel、Outlook、SharePoint、Power BIと強力に連携 | 直接的な連携は弱いが、APIや外部ツールで対応可能 |
マルチユーザー対応 | 10~20人程度の同時接続が限界 | FileMaker Serverを使用すれば100人以上でも安定稼働 |
クラウド対応 | 基本的にローカル環境向け(クラウド運用にはPowerAppsやAzureが必要) | FileMaker Cloudでクラウド運用が可能 |
モバイル対応 | PC向け(Access単体ではモバイル未対応) | iPad/iPhone用のFileMaker Goがあり、モバイルでも快適に動作 |
データベースの容量制限 | 1ファイル2GBまで | ほぼ無制限(サーバー側の制約による) |
拡張性・外部DB連携 | SQL Server、MySQLなどと連携可能 | ODBC/JDBCを使えば外部DBと接続可能 |
初期導入のハードル | Microsoft 365 BusinessやAccess単体で利用可能 | FileMaker Proのライセンス購入が必要 |
コスト | Access単体なら安価(月額1,400円程度)、本格運用にはSQL Serverが必要 | FileMaker Proは買い切りorサブスク(月額2,500円~)、FileMaker Serverの導入でコスト増 |
カスタマイズ性 | 制限が多く、デザイン面の自由度は低い | UI/UXを自由にデザインできる |
初心者向け | データベースの基礎知識がないと難しい | 直感的に作成可能で初心者でも扱いやすい |
まとめ:どちらを選ぶべき?
Accessは Microsoft製品との連携が強く、リレーショナルデータベースとしてSQLを活用できる点が魅力。ただし、デザインの柔軟性が低く、VBAの学習が必要になる場面が多い。FileMakerは 直感的な操作でアプリを作成でき、特にモバイル対応が優れている。ただし、Microsoft製品との直接連携が弱く、ライセンスコストがやや高め。
こんな人にはAccessがおすすめ
✔ Microsoft製品と強く連携したい✔ リレーショナルデータベースの設計が得意
✔ SQLを活用したデータ分析をしたい
こんな人にはFileMakerがおすすめ
✔ 直感的にデータベースを作りたい✔ モバイルやクラウドでの運用を考えている
✔ プログラミングなしで業務システムを構築したい
https://quality-start.in/2020/01/filemaker%E3%81%A8access%E3%81%AF%E4%BD%95%E3%81%8C%E3%81%A9%E3%81%86%E9%81%95%E3%81%86%E3%81%AE%E3%81%8B/ FileMakerとAccessは何がどう違うのか 中小企業が自社で使うための業務システムをゼロからシステム開発会社に依頼して開発するケースは多くないと思います。コスト面や的確な発注が出せるかどうかも難しいからです。 そうはいっても、自分たちでやれるところまでやりたいとお考えのケースは多いと思います。システムを自分たちで作ろうとする際に、何の開発ツールやサービスを使わないのは難しい。いくつかある選択肢の中で、歴史もあってどの会社でも使われている頻度が高いのが「FileMaker」か「Microsoft Access(以下 Access)」です。 この2つのどちらかを選ばねばならない場合、「スクリプト開発が出来るならFileMaker、そうでないならAccess。ただ、Accessは以下の制約を理解して使ってくれ」になります。当社がそう考える根拠について、ご案内します。 目次 Accessでは不特定多数のユーザーが利用するアプリケーションが極めて作りにくい 忘れてはいけないバックアップとリストア Windows Updateの影響をまれに受けてしまい、ファイルが破損することがある FileMakerはスクリプトの習熟に時間がかかる 当社はkintoneをプッシュしています Accessでは不特定多数のユーザーが利用するアプリケーションが極めて作りにくい 常時3人以上がネットワーク共有の上に同時に使う前提なら、Accessはリスクが高いです。理由は以下のとおりです。 最大ファイル容量が2GBしかない リンクテーブルなどを使えば分割はできるが、遅くなることがある 難しいことをやろうとするとVBAでクエリを投げるしかなく、ハードルが高くなる クライアントの設定が面倒 バックアップ / リストアの仕組みがない Accessはmdbという拡張子のファイルでデータを保存しますが、最大ファイル容量が2GBと決まっています。上限がこれです。Microsoftとしては、本格的な業務アプリケーションを作るのであればAzureのようなクラウドサービスやSQL Serverを使って欲しいというメッセージでしょう。この上限が緩和されることは極めて考えにくいです。 Accessはデータベースの分割が可能で、フォームをデザインしたmdbファイルと、データを保存するだけのmdbファイルの2つに分けることができます。リンクテーブルと言って、mdbファイルではなく外部サーバにあるデータベースに接続し、データを読み書きすることも可能です。 それならそれで良いじゃんという話なのですが、リンクテーブルという仕組みは「サーバーサイドのデータをクライアントに取り込んで、クライアント側でデータ操作の処理を行う」仕組みなので、転送するデータの容量やクライアント・マシンのスペックにパフォーマンスが左右されてしまいます。なので、リンクテーブルも万能ではありません。 リンクテーブルを使わずに外部のデータベースに対して直接データ操作を依頼する「SQLパススルー」という仕組みもありますが、ほとんどプログラミングと同じになります。コードを書けば何でも出来ますが、コードを書くことが目的ではありません。 自分たちで作ろうとする=プログラミングを頑張ってやる、ではないでしょう。本末転倒です。 Accessを複数人で共有する場合は、共有するクライアントマシンにはODBCという外部接続設定が必要になる場合があります。Webアプリケーションみたいに、ブラウザを開いてアドレスを入れるだけ、というわけにもいかないのも面倒です。 忘れてはいけないバックアップとリストア Accessにはバックアップを行う仕組みが存在しません。「データベースファイルをコピーして、名前を付けて保存する」以外の方法がありません。それを毎日のように行うのは、結構、いや相当だるいです。リンクテーブルを使って複数のMDBが存在するなら、それら全てが対象になります。リストアはバックアップから復帰する仕組みのことです。Accessの場合は、ファイルを戻すだけ。とても原始的です。 FileMakerは、FileMakerServerを買うことで自動でバックアップを取ることが出来ます。5分おきにバックアップを取得する機能を使えば、ダウンした5分前の状態に戻ることが可能です。スナップショットと一般的に言われる機能です。アプリは再インストールすればOKですが、データは再インストールすることは出来ないので、適切にバックアップを行う運用が必要です。 Windows Updateの影響をまれに受けてしまい、ファイルが破損することがある これは最近あった例ですが、Windows Updateを適用したことで、MDBファイルが開けなくなったという不具合が発生しました。Office365版Accessおよび、Access2019での『クエリ’’は破損しています』を回避する方法にその内容が書かれています。 この不具合はMicrosoftがアップデートのプログラムを提供したことで収まりましたが、1日?2日のタイムラグがありました。こういう突発的なエラーが起こりえます。 FileMakerはスクリプトの習熟に時間がかかる FileMakerは「スクリプト」と呼ばれる様々なプログラムが用意されていますが、Excelの関数のように直感的ではなく、マニュアルを見たら明日から使いこなせるようなものでもありません。これを使いこなすには、メンター(先生)のサポートが絶対に必要です。プログラミング歴10年を超える私でも、いきなり使えるようにはなりませんでした。癖が強いのです。 普通のプログラムのように「def xxx(self)..」みたいな英語の羅列ではありませんが、これらのスクリプトを駆使しないとAccessを超えるアプリケーションを作るのは難しいです。アプリケーションの作成が出来る幅は最も広いですが、覚えなくてはならないこと、FileMakerの開発手法への理解など、本格的な学習が必要です。 また、わかりやすい弱点は価格面です。FileMakerはサーバも含めると年間10万円ほどかかります。毎年です。Office365にはAccessがあり、年間12,000円ぐらいなので、Accessのほうが安いです。FileMakerは使うスキルが有れば本格的なアプリケーションを作れますが、一朝一夕にはいきません。 当社はkintoneをプッシュしています 手軽さはAccessに軍配がありますが「行きはよいよい帰りは怖い」です。当社は非プログラマへの受け皿として機能しつつ、不特定多数のユーザーが安全に利用でき、最もバランスが良いkintoneプラットフォームをまずは活用する、使い倒すことが良いと考えています。 FileMakerやAccessを頭から否定するわけではないですが、継続的なメンテナンス、IT担当者の退職リスク、データ保護の観点など、不特定多数の人が使っても安定稼働するアプリケーションを作るコストを鑑みると、まずはkintoneを使いこなせるようになるのが最もコスパの良い選択肢だと思っています。
Blogger Comment
Facebook Comment