業務エンジニアの攻撃は最大の防御ブログ

業務エンジニアのブログ。業務システム大好き。フレームワーク開発も好き。

MicrosoftAccessの活用方法の4パターン

最近、とある理由でAccessの機能や活用事例について色々と調べている

私はリレーショナルデータベースはずっと仕事で使っているが、Accessを実務で使った事はごく僅かだった。

調べているうちに、Accessの使われ方には大きく分けて4つのパターンがある事に気付いたのでここにまとめておく。

1.事務担当者の作業効率向上のため

事務担当者が、作業効率改善のためにAccessにデータを登録して参照するパターンだ。

このパターンでは基本的にAccessだけで作業が完結するので他のソフトウェアとの連携はしない(VBAを通じてExcelとデータ連携をする場合はあるかもしれない)。

私の妻は、医療系の会社に事務員として勤めていた事があった。

その際に、それまで紙ベースで管理されていた情報を、Accessに登録して大幅に作業効率を向上させた事があるそうだ。

今でこそ妻はJavaPythonなどの実務経験もある技術者だが、当時は「ちょっとPCに詳しい事務員」でしかなく、正規化の概念も知らずデータベースが何かもよくわかっていなかった。

感覚としては、Excelの凄い版のような気持ちで使っていたそうだ。

それでも、調べ物するたびにバインダーを数冊取り出して目的の情報を探しあてていた頃からの、業務改善効果はすさまじく、現場では神様扱いだったらしい。

この様に予備知識の殆ど無い状態から、手探りでAccessの使い方を学んで活用し、成果をあげている事務担当者はきっと全国に沢山いる。

本当に凄い事だと思う。

2.簡易な業務システム内製のため

これはMySQLOracleのかわりにAccessを使うパターンだ。

一連の業務フローをシステム化したい場合に、予算の都合で社内のIT担当者が内製するというのは中小企業ではよくあるらしい。

システムベンダーに外注してフルスクラッチで作らせると簡単なシステムであっても云百万・云千万の世界になる。

また、内製しようにも自社に本格的なアプリケーションを作れる要員はいない。

この様な場合に、学習コストの低いAccessであれば比較的手軽に作れるという事で、Accessが採用される。 (FileMakerも似たようなケースで採用される)

同時実行制御を諦める(つまり少数の人がローカルPCで使う事を前提にする)のであればそれでも充分に実用的だ。

ビジネスロジックは、VBAで頑張るか、VBなどの他の言語で自作される。

※ Twitterで上記のようなご意見をいただきました。Anubisさんありがとうございます

このパターンの場合、1.のパターンと比べてテーブルもある程度シビアに設計する事が求められる。

なるべく、綺麗にテーブル設計して、それをもとにクエリやフォームを作りこみ、VBAはなるべくシンプルにするのが移植性・保守性の面で良いように思う。

ただ、「Accessを採用している時点で、ローカルでしか使わないし保守担当者も限られる」という割りきった上で、全てのロジックをVBAで頑張って作りこむという事例もあるようだ(同僚談)。

余談だが、AccessVBではなくRailsなどのWebフレームワークとMySQLなどを使って独学&独力で自社システムを内製する事務員兼社内SEのような凄い人もたまにいる。

ただ、こういう事例は相当なセンスのある担当者に恵まれたケースだと思うので、一般化して語れるのは難しい気がする。

3.クライアント端末のローカルストレージとして

端末のローカルデータを保存するためにAccessが利用されるパターンだ。

Web開発におけるWebStrageAPIやAndroidアプリ開発におけるSQLiteと同じような位置づけだ。

このパターンでは、必要に応じてサーバーサイドのRDBMSにデータが同期される。

サーバーサイドのRDBMSと同期するのであれば、クライアントサイドでもRDBのテーブル形式で保持するのは合理的だと思う。

またmdbファイルに保存するので、データの確認や端末のリプレースも簡単だ。

私が昔かかわったシステムでは、POS端末のデータ保存のためにAccessが利用されていた。

4.フロントエンドの実装フレームワークとして

フォームやレポート機能を使い、データの保持はサーバーサイドで行うパターン。

データの永続化をサーバーサイドのRDBで行うという意味では3と似ているが、 こちらは、Accessのレポート機能やフォーム機能を活用する。

VBAで直接OracleなどのDBサーバーに接続する設計のシステム(二層アーキテクチャ)もあれば、 間にアプリケーションサーバを挟む設計のシステム(三層アーキテクチャ)もある。

エンドユーザーがソースコードに一切触らずに、帳票のレイアウトを変更できるのはかなりの強みだ。

4つのパターンはMECEになっているか分かりません。

もし、他の事例があれば、コメントでもはてブでもツイッターでも良いのでご指摘いただけると嬉しいです。

【参考図書

小さな会社のIT担当者になったら読む本 (初めてでもよくわかる)

小さな会社のIT担当者になったら読む本 (初めてでもよくわかる)