FileMakerとAccessの比較
この記事では、私の個人的なAccessとFileMaker双方の開発経験から、両者の比較について解説させていただきました。
恐らく、Google検索で、FileMakerとAccessの比較に関する情報を求められている方は、SIerやソフトウェア開発会社にいるプログラマ・SEではなく、自社システムを社内開発したい…つまり内製化を考えている事業部門の御担当者か、社内SEの方になるでしょう。
なぜなら、ソフトウェアの開発を請け負うプログラマ・SEほど、FileMakerプラットフォームを敬遠する傾向があるからです。
これには２つの理由があります。
まずひとつ目は、最初から「FileMakerプラットフォーム=エンドユーザ向けのオモチャ」とラベリングしてしまい、実際に自分の手で検証をしない傾向にあることです。
FileMakerは、FileMakerジャパンのマーケティング戦略から「カジュアルデータベース」というキャッチフレーズで売りだされています。
これは、FileMakerがとっつきやすいという意味では素晴らしいキャッチフレーズなのですが、ITプロフェッショナルからすると「カジュアルなデータベースでミッションクリティカルなソリューションはつくれない」という十分な言い訳になります。
ふたつめの理由として、FileMakerプラットフォームの開発効率が極めて高いことによる開発工数減少のリスクです。
ソフトウェア開発ベンダーは、プロジェクトが大規模で人手がかかればかかるほど、売上が大きくなるというビジネスモデルです。これを「人月積算型ビジネス」と呼びます。
この人月積算型ビジネスは、うがった見方をすれば、非効率に人手をかければかけるほど、売上が大きくなるというビジネスでもあります。
また、能力の低いプログラマでも、数を集めて人海戦術で開発すれば、潤沢なキャッシュを得ることができるビジネスモデルでもあります。
そのようなビジネスモデルなので、極めて開発効率のよいFileMakerが魅力的に映るはずがありません。
開発効率が高くなり、より少ない人数、より短い期間でプロジェクトが終わってしまうようでは、彼らの売上は縮小してしまいます。
受託開発を生業としているソフトウェア開発ベンダーはこのようなビジネスモデルなので、FileMakerプラットフォームに感心を持つ理由がないのです。
一方、事業会社側で自社開発・内製化したい企業の立場に経つと、全く別のニーズがあります。
事業会社側は、できるだけ手間と時間をかけること無く、ビジネスに対して有益なソリューションを素早く開発したいはずですし、ビジネスの成長やビジネス環境の変化に合わせて柔軟にソフトウェアを進化させていきたいはずです。
なので、そもそもソフトウェアの受託開発会社が開発プラットフォームに求めるニーズと、事業会社で自社開発・内製化したい企業のニーズとは、根本的に異なるのです。
このような視点をもって、両アプリケーションを眺めてみると、また違った評価が得られるのではないかと思います。
安Office365の販売者
あなた様のおっしゃる通りです。私は2018年6月にヤフオクでOffice365を購入し全く問題なく使えていました。PC5台インストールも問題ありません。OneDrive も問題なく5TB使えています。つい最近、OneDriveを開いたら以下の警告表示が出るようになりました。「このOffice365は認証されていません。2019年10月1日にアカウントは停止されます。」対処として正規のOffice365アカウントを購入するよう促されます。
私の推測ですが、これはマイクロソフト社の陰謀と思われます。ヤフオクでマイクロソフトが違法をあえて否定しないのは、最近台頭してきているキングソフト（現在WPSオフィス）など「office互換ソフト」の存在です。3000円程度の価格で正規に購入できます。互換性は100％ではありませんが個人使用では全く問題ありません。むしろマイクロソフトより使いやすいです。互換ソフトはマイクロソフトにとっては大変脅威です。これを潰すには、正規品の価格は下げずに、マイクロソフトはヤフオクを巧みに利用して、正規品と同じ激安Office365をばらまいています。利用者は誰でもこれを買いますよね。販売しているのは、マイクロソフトの手下（中国？）かな？激安office365は、1年位でやがて使えなくなり、正規品を購入させようという狙いがあると思われます。思惑通りにいくかは疑問です。それにしても、最近の互換Officeは素晴らしいです。中古パソコンでは、多くの場合、互換ソフトが入っていますが、個人使用の場合は全く問題ありません。3000円位の価格は適正です。正規品の3万円は高すぎます。企業や団体では、高くても正規品を必ず購入すると思われます。それとOffice365はサブスクリプション版のみです。激安365は、サブスクリプション版では、ありませんが、1年で使えなくなります。購入者は永続使用ができると思っていますがそうではありません。これはマイクロソフトのずる賢い策略と思われます。ヤフオクの激安365は、今でも堂々と沢山売られ買われています。何の規制もなくこんなものが堂々と売ることができるヤフオクも問題ですね。盗難品が何の規制、チェックももなくヤフオクで売ることができるのと同じです。激安Office365の販売者の正体はいったい誰でしょうか？ ひょっとしたらマイクロソフトかもしれません。マイクロソフトが違法性を否定しない理由がこれで理解できますね。
身近なデータベース Microsoft Access をマジメにエンジニアが使ってみた
Microsoft Access の使い方を工夫すれば強力なデータベースメンテナンスツールとなる
昨今、様々なデータ活用が進み、それに伴い様々なツールやサービス、ハードウェアが毎日のように生まれては消えていきます。そんなカンブリア紀並みに進化激しい時代、20年以上前から殆ど変わらぬ姿を保っている奇跡的なデータベースがあります。今回はガラデービーこと Microsoft Access について、マジメにデータベースエンジニアがイケている使い方を探してみました。(たぶん、一般的な使い方と違うと思います)
そもそも Microsoft Access って何よ？
Microsoft Access(以下、Access) は簡易的な開発が行えるデータベースアプリです。単品で購入することも可能ですが、Microsoft Office のある一定上のグレードを購入すると付いてきます。リリースされたのが1992年と古く、Windowsの普及共に2000年初めぐらいまでは使われてきました。しかし、取り扱うデータ量が増えたことで ORACLE や SQL Server などの専用のデータベースへのシフトが進み、今では細々と命を繋いでアプリと言えるかもしれません。
データベース ＋ 開発環境 ＋ 実行環境 が1つに纏まっている
Accessが「データベース」ではなく、「データベース ＋ アプリ」であることが最大の特徴です。Accessファイルの中には一般的なデータベースのテーブルやビューの代わりになるクエリなどが存在します。そして、フォームと言われるボタンやテキストボックスを配置して、テーブル更新などができる入力画面機能を開発・実行できることがメリットです。フォームに張り付けるボタンには初めから操作(アクション)を割り振ることができ、これらを使うことでプログラムを全く書かずにテーブル内のデータ検索、データ追加・変更・削除を行うことができます。
また、ExcelやCSVファイルなどのインポート/エクスポート処理が簡単に行えるため、非エンジニアでも簡単なデータベースシステムが作れるため、今でも中小企業では自社で開発・運用しているところはあるらしいです。
また、20年前から殆ど変わっていないシンプルな開発画面はノスタルジーさえ感じられ、昔からのWindowsアプリ開発者は抵抗なく開発を進められると思います。(私もその一人でした)
VBAマクロっていいよね
上記のように基本的な機能はノンプログラミングで実装可能です。そして、更に複雑な処理を実装したい場合はVBAマクロによって実現することが可能です。
VBAもAccess本体と同様に20年前から全く変わっていません。VBAは最近のプログラミング言語のような処理速度や自由度はありませんが、自然言語に近いプログラミング言語のため、比較的に習得のハードルが低いことが特徴です。また、VBAマクロはExcelなどでも使われているため、事例や技術者も多く、インターネットで検索すれば参考になる情報は沢山あります。
でもデータベースには色々と問題が。。。
20年前から殆ど変わっていないAccessですが、軽微な機能拡張が行われ外部へのインターフェースが増えたり、ウィザード機能でマクロを作れたりするようになりました。昔は10万件程度のテーブルの検索にちょっとした時間が掛かっていましたが、最新の Microsoft Access 2016 では一瞬で処理が終わります。「おっ！ なかなか使えるな！」っと思っていましたが、やっぱり以下のような昔からのデータベースとしての残念なところも変わっていませんでした。
- テーブル結合を3つ以上できない(副問合せ風にすると回避可能)
- SQL命令の副問合せなどで複雑な事をすると「クエリが複雑すぎます」とエラーダイアログが出る
- 普通のSQL関数と命令が違う(CASE命令の代わりにSWITCH命令があるとか)
- テーブル更新をやっていくとAccessファイルが肥大化する(テーブル削除してもファイルサイズが減らない)
- テーブル更新処理の途中でコケるとAccessファイルが破損する
他にも色々と残念なところがありますが、書いているとキリがないのでこの辺にします。しかし、Accessファイルが壊れやすいというのはデータベースとして致命的です。これの回避策として「データベースの最適化/修復」という機能がAccessに付いていますが、100%修復でいる保証はありません。私もこのブログを書く前に1回壊して、痛い目を見ています。
データベース部分を外部データベースにすれば可能性が広がる
この様にAccessはちょっとした機能開発はクイックに行えるが、データベース機能には欠点があるという事はご理解いただけたと思います。そこでAccessのデータベース部分を外部データベースに置き換えて、Accessのデータベースとしての機能を補完する方法を取ります。
方法は簡単です。以下のようにAccessからODBC接続で外部データベースのテーブルにデータリンクするだけです。これによって、仮にAccessファイルが壊れてもデータベースのデータは救えます。(データリン
クのためSQL命令の残念なところは継承されています)
この仕組みの導入個所としてはマスタメンテナンス機能としてAccessをツールとして使えます。AccessのテーブルのユーザーインターフェースはExcelのような表形式になっており、セルの中の値を変更することによって、データベースのテーブルの値を変更することができます。内部ではSQL命令によってテーブル変更が行われるため、大量データを持ったテーブル更新には不向きですが、部署マスタや社員マスタなど1,000行程度のマスタテーブルの更新なら問題なく行えます。また、ちょっとした機能を作りたい場合は、Accessのフォームを使うことで比較的短時間で実装可能だと思います。
Microsoft Access によって本流以外の隙間を埋める事ができる
一般的なシステム開発には、それなりの時間と費用、そして技術者が必要とされます。確かに利用頻度の多い機能やミスの許されないような機能ではきちんとした設計・開発を行う必要はあります。しかし、月に1回程度の使用頻度の機能や基幹系ではない社内向けの機能では、そこまで大掛かりな開発は費用対効果に合っていないと思います。この様なちょっとした機能開発では、クイックに作れて、比較的に誰でもカスタマイズが可能なAccessのようなツール系のアプリ開発環境でも十分だと思います。
システムを構築ではなく、ちょっとした要望を実現するための選択肢として Microsoft Access のような枯れた技術を選択肢として考えてみては如何でしょうか？
身近なデータベース Microsoft Access をマジメにエンジニアが使ってみた
Microsoft Access の使い方を工夫すれば強力なデータベースメンテナンスツールとなる
昨今、様々なデータ活用が進み、それに伴い様々なツールやサービス、ハードウェアが毎日のように生まれては消えていきます。そんなカンブリア紀並みに進化激しい時代、20年以上前から殆ど変わらぬ姿を保っている奇跡的なデータベースがあります。今回はガラデービーこと Microsoft Access について、マジメにデータベースエンジニアがイケている使い方を探してみました。(たぶん、一般的な使い方と違うと思います)
そもそも Microsoft Access って何よ？
Microsoft Access(以下、Access) は簡易的な開発が行えるデータベースアプリです。単品で購入することも可能ですが、Microsoft Office のある一定上のグレードを購入すると付いてきます。リリースされたのが1992年と古く、Windowsの普及共に2000年初めぐらいまでは使われてきました。しかし、取り扱うデータ量が増えたことで ORACLE や SQL Server などの専用のデータベースへのシフトが進み、今では細々と命を繋いでアプリと言えるかもしれません。
データベース ＋ 開発環境 ＋ 実行環境 が1つに纏まっている
Accessが「データベース」ではなく、「データベース ＋ アプリ」であることが最大の特徴です。Accessファイルの中には一般的なデータベースのテーブルやビューの代わりになるクエリなどが存在します。そして、フォームと言われるボタンやテキストボックスを配置して、テーブル更新などができる入力画面機能を開発・実行できることがメリットです。フォームに張り付けるボタンには初めから操作(アクション)を割り振ることができ、これらを使うことでプログラムを全く書かずにテーブル内のデータ検索、データ追加・変更・削除を行うことができます。
また、ExcelやCSVファイルなどのインポート/エクスポート処理が簡単に行えるため、非エンジニアでも簡単なデータベースシステムが作れるため、今でも中小企業では自社で開発・運用しているところはあるらしいです。
また、20年前から殆ど変わっていないシンプルな開発画面はノスタルジーさえ感じられ、昔からのWindowsアプリ開発者は抵抗なく開発を進められると思います。(私もその一人でした)
VBAマクロっていいよね
上記のように基本的な機能はノンプログラミングで実装可能です。そして、更に複雑な処理を実装したい場合はVBAマクロによって実現することが可能です。
VBAもAccess本体と同様に20年前から全く変わっていません。VBAは最近のプログラミング言語のような処理速度や自由度はありませんが、自然言語に近いプログラミング言語のため、比較的に習得のハードルが低いことが特徴です。また、VBAマクロはExcelなどでも使われているため、事例や技術者も多く、インターネットで検索すれば参考になる情報は沢山あります。
でもデータベースには色々と問題が。。。
20年前から殆ど変わっていないAccessですが、軽微な機能拡張が行われ外部へのインターフェースが増えたり、ウィザード機能でマクロを作れたりするようになりました。昔は10万件程度のテーブルの検索にちょっとした時間が掛かっていましたが、最新の Microsoft Access 2016 では一瞬で処理が終わります。「おっ！ なかなか使えるな！」っと思っていましたが、やっぱり以下のような昔からのデータベースとしての残念なところも変わっていませんでした。
- テーブル結合を3つ以上できない(副問合せ風にすると回避可能)
- SQL命令の副問合せなどで複雑な事をすると「クエリが複雑すぎます」とエラーダイアログが出る
- 普通のSQL関数と命令が違う(CASE命令の代わりにSWITCH命令があるとか)
- テーブル更新をやっていくとAccessファイルが肥大化する(テーブル削除してもファイルサイズが減らない)
- テーブル更新処理の途中でコケるとAccessファイルが破損する
他にも色々と残念なところがありますが、書いているとキリがないのでこの辺にします。しかし、Accessファイルが壊れやすいというのはデータベースとして致命的です。これの回避策として「データベースの最適化/修復」という機能がAccessに付いていますが、100%修復でいる保証はありません。私もこのブログを書く前に1回壊して、痛い目を見ています。
データベース部分を外部データベースにすれば可能性が広がる
この様にAccessはちょっとした機能開発はクイックに行えるが、データベース機能には欠点があるという事はご理解いただけたと思います。そこでAccessのデータベース部分を外部データベースに置き換えて、Accessのデータベースとしての機能を補完する方法を取ります。
方法は簡単です。以下のようにAccessからODBC接続で外部データベースのテーブルにデータリンクするだけです。これによって、仮にAccessファイルが壊れてもデータベースのデータは救えます。(データリン
クのためSQL命令の残念なところは継承されています)
この仕組みの導入個所としてはマスタメンテナンス機能としてAccessをツールとして使えます。AccessのテーブルのユーザーインターフェースはExcelのような表形式になっており、セルの中の値を変更することによって、データベースのテーブルの値を変更することができます。内部ではSQL命令によってテーブル変更が行われるため、大量データを持ったテーブル更新には不向きですが、部署マスタや社員マスタなど1,000行程度のマスタテーブルの更新なら問題なく行えます。また、ちょっとした機能を作りたい場合は、Accessのフォームを使うことで比較的短時間で実装可能だと思います。
Microsoft Access によって本流以外の隙間を埋める事ができる
一般的なシステム開発には、それなりの時間と費用、そして技術者が必要とされます。確かに利用頻度の多い機能やミスの許されないような機能ではきちんとした設計・開発を行う必要はあります。しかし、月に1回程度の使用頻度の機能や基幹系ではない社内向けの機能では、そこまで大掛かりな開発は費用対効果に合っていないと思います。この様なちょっとした機能開発では、クイックに作れて、比較的に誰でもカスタマイズが可能なAccessのようなツール系のアプリ開発環境でも十分だと思います。
システムを構築ではなく、ちょっとした要望を実現するための選択肢として Microsoft Access のような枯れた技術を選択肢として考えてみては如何でしょうか？
