Accessを学ぶ難しさ

 メインのブログとして「もう一度学ぶMS-Access」というサイトをやっております。
 Accessの操作法やTipsをちびちびと書いていますが、私自身が仕事でAccessを使う機会は、最近はほとんどありません。このたびの異動により多少増えそうですが、この年になるとそんな作業に没頭しているわけにもいきません。このようなメインブログをやっているのもデータベースとAccessが好きだからであって、いわば撮影に行かないカメラ機材オタクみたいなものです。本記事のタイトルも最初は「Accessを教える難しさ」にしようと思いましたが、別に教えてないので「学ぶ」としました;-o-)

 とはいえ、まがりなりにもAccessに触れてきて思うのは、その利用方法が幅広く一様ではないということです。メインブログを開設する際には、データベースの利用のあり方として「対象業務の全体像を把握し、データ項目を整理したうえでテーブルを設計し、その上にUIを構築していく」という流れを想定し、それに沿った記事を掲げています(いまだにたいして進んでませんが)。
 しかし実際にAccessが活用されている状況の多くは、上記の想定とは異なるものです。だいたいメインの外注システムがあって、それでうまく処理できない部分をAccessで補うという利用形態が多いからです。実際に使用されているAccessのファイルの中身を覗いてみると、インポートしたであろう英数名のテーブルとインポートエラーテーブル、インポートテーブルを手直しした和名テーブル、依存関係がよくわからない選択クエリやアクションクエリが大量にあって詳しくは作成者にお聞きください、といったものが多いのです。基本的にレコードの追加や更新は行われず、よって正規化もリレーションシップも考慮されず、利用者の多くが「Accesss≒クエリ発生器」と捉えているような状況がしばしば見られるのであります。
 そのような状況を否定するつもりもありませんが、その結果として「Accessができます」という人間にも、「まず業務分析ありき」「正規化面白い~^o^)」「とにかくSQLで考えたい」みたいなタイプと「取り込み~データ抽出が得意です」「万事VBAで解決」といったタイプに分かれることとなります(相当デタラメな分類ですが)。


 このように「Accessができる」という人もそれぞれで、ある意味タコツボ化しているぐらいですから、Accessができることのすべてを学習するというのは容易ではなく相当の時間と能力を要します。そんなに隅々まで理解している人は世界にもほとんどいないだろうと思います。そんな中で漠然と「Accessを覚えたい」と考えるのは、「パソコンを覚えたい」と言っているのと同様に、ちょっと無謀なのではないかとさえ思えます。
 ですので、Accessを学習しようとする方は、まず一度、長期的な視点に立って考えることが必要です。自ら業務を設計してビジネスルールを定義し、その中でAccessを利用しようとしているのか、それともそうした根幹の部分は誰かから与えられるものとして自らはデータの処理に特化してAccessを利用しようとしているのか。そこを判断したうえで、Accessのどの部分の機能を学習していかなければならないのかを決めていく必要があると思います。あまり難しく考えるのもいけませんが、参考まで_ _)