Accessの概要(使い方)を「Excel目線で説明」する

Accessは、Excelのように「シート」上で何でもできるわけではない

いきなりですが、AccessにはExcelでいう「シート」がありません。

Excelでは、「シート」という非常に便利な台紙があります。
私達は、ここに数値や文字を入力したり、図形を貼り付けたり、計算式を入れたりできます。それは、直感的でとても便利ですよね。

しかし、Accessではこのようなシートが無いのですね。存在しません。

AccessでExcelのような作業ができないのは、「それはExcelの役割だから」とも言えますが(笑)、Accessを使うとき、そもそもそのシートが存在しないこと(シートが存在しない理由)を考えることもAccessを理解する上でのヒントにも思います。

AccessとExcelは互いに似たような機能も持っており、非常に親和性が高くなっています。
「AccessとExcelは親戚関係」と言われる所以かもしれません。
しかし、こういう点があるが故に余計に悩める部分が出てきてしまうこともあると思います。

「Accessは初心者、でもExcelは経験者」という方はかなりいらっしゃると思います。
当ページの内容として、この点から見たときのAccessの概要、使い方をExcel目線で説明したいと思います。
ただし、厳密ベースで言うと、Excel目線の説明上、誇張している箇所や足りてない箇所もあります。実際にお試しになるときには、ご注意下さい。

テーブル、クエリなどAccessのオブジェクトとExcel機能を対比させてみる

Excelは表計算ソフトです。そしてAccessはデータベースソフトです。似ている部分もありますが大きく違う部分もたくさんあります。

そのAccessソフト(ファイル)を起動したことのある方はご存知だと思いますが、AccessにはAccess固有の「オブジェクト」があります。

話をわかりやすくするため、かなり強引な見方になりますが、Excelの機能などを分割するとAccessのオブジェクトになります。

テーブル

テーブルは一見すると「Excelのシート」ですね。しかし、それはあくまで見た目だけです。

テーブルをシートという意味で使ってしまうと、それはテーブルではなく別物になってしまいます。
(後述していますが、シート自体は「レポート」オブジェクトに近いと思います)

Accessのテーブルは、Excelのシートそのものではなく、そのシートの中にある「表」に該当します。

Excelユーザならば、誰でも作れるシンプルな「縦長や横長の表」、それをAccessで作成したものがテーブルです。

ただしExcelとの違いの一つとして、テーブルの列(カラム・フィールドとも言います)には、定義が必要です。

Excelではセルには通常、文字、数字、数式など自由に入力することができます。
しかしAccessのテーブルは、テーブル自体を作成するタイミングで、どの列にどのようなデータの種類を入力するのかを最初に「定義」しなければなりません。

たとえば、「日付」を定義した列には名前を入れられません。仮に入力しようとしてもAccessに怒られてしまいます。

これはExcelと真逆なイメージですね。しかし、定義することでデータの種類が保証されていることになります。
この「保証されている」ということこそがAccessで作業をする上での土台、あるいは前提になっています。

また、テーブルで大事な点として、データの内容などにもよりますが、通常はテーブルは複数で構成されていることがほとんどです。
たとえば、Accessで「請求書」を作るとき、最終的には1つの請求書にデータが埋まりますが、そのデータの出所であるテーブルは、1つではなく複数のテーブルから読み込まれているなどです。

この構造は、「Accessだから」というよりも、データベースという仕組み上から成るものです。
私自身は、こうすることでデータのメンテンスの効率がよくなることが理由の一つだと感じています。

クエリ

クエリはテーブルの表を加工できる表のようなイメージです。
なお、クエリには表加工の元となるテーブルが必ず必要になります。

クエリはExcelでいうところの関数に近いイメージですが局所的です。関数の中でも別のシートから値を表示できるVLOOKUP関数やINDEX関数、MATCH関数に該当します。
ただし、関数自体がクエリではなく、たとえば、「VLOOKUP関数で他のシートや表から値を設定、表示した状態」がクエリに近いと思います。
もっとも、クエリもいろいろな使い方ができるので、1つの表で単純な「SUM関数で横計を出す」、「MID関数で文字を抽出する」などもクエリに近い形だと思います。

クエリ目線で見れば、クエリとは「表と表をつなげる」、「表と表、あるいは1つの表の中の列同士で計算、加工などする」、そして表示する機能です。

クエリの本体は「SQL」です。SQLとはテーブルなどを操作するときの言語ですが、AccessではSQLを直接触らないよい代わりにクエリが用意されています。
なお、Accessでもクエリ画面ではなく、SQL自体を作ることもできます。

古い私の記憶では、Accessでは、SQLに触れずにクエリで対処できる仕組みを作ったことでデータベースをとても身近にしたと評価されていたと。。

ちなみに上部のSUM関数の部分で、意図的に「横計」と書いている点にもご注意下さい。縦計をクエリでやろうとするとクエリ本体のSQLを直接触ることになります。また、SUMはクエリ上ではExcelのそれとは趣の異なる意味にもなりますが話が複雑になるためここでは触れません。

なお、Excel同様にAccessにも「関数」があります。両者で同じ関数もあれば、一方だけ存在するものもあります。
このAccessの関数は、フォームやレポートでも使用できますが、クエリ上でもよく使います。テーブルのときに説明したように、元となるテーブルの列は、「データの種類が保証されている」ため、Excelのようにしばしば意図しない種類のデータの入力がないことも使いやすい理由になっていると思います。

最後に、クエリの重要な機能として「仮想的な表」が挙げられます。
クエリを実行すると「クエリで作成した表が表示」されます。しかしこれは実態がない仮想的な表(結果)です。

これはExcelと比較するとわかりやすいかもしれません。
たとえば、Excelで以下のような表を作るとします。

これは、Excelでは1回の手順では作れませんが、作ることはできますよね。
しかし元のデータが増えたとき、減ったとき、あるいは値が変わったとき、Excelでは「その都度、手修正」しなければなりません。
強いて半自動的に行うならば、シートの表を選択して作成する「ピボットテーブル」になります。しかし、ピボットテーブルでも元の表の範囲が変わると、その都度、範囲の設定をし直す作業が発生してしまいます。

しかしAccessの場合、クエリで一回作ってしまえば、後はクエリを実行するだけで常に「その時点(テーブルに格納されている値)の結果」が表示されます。

データの件数、データの内容が未来永劫変わらないならば、クエリのメリットは少ないでしょう。
しかし、データの件数や内容が日々変わるような表の場合、クエリの恩恵が得られると思いますし、そのためにクエリが存在すると言っても過言ではないと思います。

なお、クエリには上記のように「加工して表示のみ」のクエリをAccessでは「選択クエリ」と呼びます。
しかしAccessには、選択クエリだけでなく、加工した値をそのまま「テーブルにして作成するクエリ」などいわゆる「アクションクエリ」と言われるものもあります。
Accessを使って、より踏み込んだ仕組みを作るならば、このあたりのクエリも理解する必要がありますが、本ページでは選択クエリのみを使う想定で説明をしています。

フォーム

テーブルには表の元となる「データ」を入力(格納)します。
しかし通常は、直接テーブルを開いて入力することはなく、何らかの画面を通じて入力することがほとんどです。
それがフォームですね。あるいはデータの検索にも使用することができます。

イメージです。

なお、Excelにもフォームが2種類あります。うち1つは、VBA(プログラム)上で作成するフォームです。こちらは万能ですが、もう一方のフォーム(初期はリボンに非表示)は緩い作りになっています。
以下は、Excelのフォーム(初期はリボンに非表示)です。

Accessのフォームは、ExcelでいうVBAのフォームに相当すると思いますが、Excelほどプログラムをこねくり回さないで作れるなど敷居が低くなっているのも特徴だと思います。
(もちろんAccessのフォームもプログラムで動かせるので、細かい制御も可能です)

レポート

レポートは、Excelでいうところの「シート自身」、「印刷プレビュー」のイメージです。
シート上でセルを広げたり、結合したりすることをAccessで実現するならばレポートになります。

「では、100行分のデータがあるとき、すべてセルの枠線を作成するのか？」

このような疑問を持つ方もいらっしゃるかもしれません・・しかし大丈夫です。
レポート(やフォーム)では、このような「くり返し」に対応できる機能があるからです。1行分だけ作成すれば、あとは自動的に行数分セルの枠線ができる仕組みになっていますので。

レポートは、Excelのシートを使ったレイアウトよりも詳細に作成できます。
いわゆる「Excel方眼紙」のようなレイアウトもレポートで対応できます。

また、レポートでは、レイアウトを作成するだけではありません。そのレイアウトのどこに(どのように)テーブルやクエリの「データを表示」するのかを決めます(そして、運用時にはそれを表示することができます)。

これらは、フォームでも同様にできますが、印刷前提ならレポートだと思います。

マクロ

Excelにもマクロ(の記録、VBA)と言われる機能があります。しかし、Accessのマクロは別物と思っておいたほうがよいと思います。少なくともExcelのマクロとはイメージが異なります。
Accessのマクロのほうがむしろわかりやすいのではないかと思います。

なお、VBAについてはExcelのVBAと同じです。ただし、文法構造は同じですが、扱う対象が異なります。そのため、Excel VBAができても、Access VBAでは、それなりに覚えなければならない箇所も出てきます。(たとえば、Accessにはブックやシートという概念がないですし、表の行と列も違う呼称で意味合いも変わります。従いまして、プログラム上の扱い方も異なりますですね)

Accessでは「組み立て」から始まり、そして「入力(運用)する」という順序がある

AccessにはAccessの作り方、進め方があります。
上記のオブジェクトの説明を見て気づいた方もいらっしゃるかもしれませんが、AccessではExcelと比べるとそれなりに手間が発生します。

Excelでは、シートさえあれば、データや関数などを入力しつつ、罫線を引いたり、セルの幅を調整したりできます。
要は、「入力と見た目(レイアウト)」を同時進行で進めることができますよね。

しかし、Accessではまず「仕組み」から作り始めるのが一般的に思います。
この仕組みという部分は、いわゆる「設計」や「構築」と言われる箇所になると思います。もう少し格好良く？いえば、「システム設計」、「システム化」です。

そしてその仕組みができて、その後にデータを入力していくという流れです(そして入力がそのまま「運用」へとつながっていく流れになると思います)。

ちなみに、この「入力」という作業は、フォーム経由で、あるいはテーブルを開いて手入力することもあるでしょうし、他のファイルを丸ごとインポートすることもあると思います。

もっとも、その仕組みを作る際には、実際にデータがないとイメージしづらい箇所も当然出てきますから、厳密に切り分けられるわけではない点にもご注意です。

このようにExcelでは、同時進行できることが、Accessではできない、あるいはやりづらい仕組みになっています。

それは、Accessでは「組み立て」から始まり、そして「入力(運用)する」という順序があるからです。
言い換えると、Accessのソフト自体が「システム化する作業(システム自体を作り込む作業)」と「運用する作業」に分けて使うことが前提になっている構造だからとも言えます。
平たくいうならば、Accessは、「ガチガチの仕組みを作る」のに適しています。

Accessに適した業務とは

Accessのメリットを語る上で、よく出る内容に「大量のデータに対応できる」がまず挙げられると思います。
これはこれで事実ですね。Excelには1つのシートに約100万行あります。ただし、Excelでは末端の行どころか(列数や数式の数などにもよりますが)、数万件で画面が濁った白い画面になって(固まって)しまい、アップアップしてしまう(しばらくすると使える状態になる)ケースも割とあります。

しかし、Accessでは、少なくとも「Excel以上の頑張り」は見せてくれます。
従いましてデータ件数が多いとき、「Accessを使うことでパフォーマンスの改善が図れること」の理由で使用する選択もありだと思います。

このようにExcelよりも大量のデータ件数に処理対応できるということは異論がないのですが、Accessに適した業務として私が別に提示したいことは、「定型化された業務」です。しかも(ほぼ)完全に定型化された業務です。

別の言い方をすると「システム化された」、あるいは「システム化可能」な業務です。

たとえば、イメージしやすい作業として「請求書の発行」作業などがあります。

請求書の作業というのは、私の経験上では、Excelで割と普通に使われているように思います。

実際、この作業をどのようにExcel化しているかというと、とてもシンプルです。
「前回作成した請求書シートをコピーし、今回分として使う」作業ですね。
そして、その今回分のシートに、今回請求する明細や金額を「上書き入力」して印刷で完了です。

しかし、Excelでの作成では、シンプルにもかかわらず、いろいろな「困った状況になったシート」を私は見てきました。

たとえば・・

Accessでは、上記のような問題は構造的に発生しづらいように、そして解決できる仕組みを持っています。

極端な言い方かもしれませんが、Excelのシートは利用者のさじ加減ひとつで自在に変えることができます。
しかも、残念なことに誰かがシート上の「何か」を変えても、第三者が見たときにそれに気づけないでミスに繋がることも割とよくあります。
もちろん、Excelでもシートの保護、入力規則など縛りをかけることもできますが、Access以上に限界があります。
このような定型化された業務では、その緩さは事故のもとになりかねません。

定型化(システム化)できる業務では、むしろガチガチであるほうが良いケースが多々あります。
従いましてAccessに適した業務というのは、このような仕様が固まった定型化・システム化できる業務ということになります。

すでにお話しましたが、Accessでは、それぞれのオブジェクトを使用して「設計」しなければなりません。
しかし、一度作り込んでしまえば、後のメンテナンスはAccessのほうが容易になるケースも多いと思います。
Accessの「オブジェクト」はそれぞれオブジェクト同士が依存する部分がはっきりしているため、作業の切り分けが簡単でメンテンナスが容易になるのですね。

あるいは、作業の担当者が変わりやすい状況の場合、Accessでこのようなシステム化が実現できていれば、引き継ぎや作業の説明は機械的ですみます。比較すると、Excelよりもスムーズにできるだろうという部分で、これもメリットに思います。

逆の見方をすれば、Excelのようにすべてを同時に進めていくような使い方には適していません。

従いまして、例外や想定外が多く発生するような作業では、Excelのほうが勝手がよいという部分もあります。

なお、Accessだからといって、上記の困った状況を自動的に解決する機能があるわけではありません。
それは、前項でお話した「設計」部分で考慮した作りにしなければなりません。
むしろ「今月はお客様の要望レイアウトで印刷して」など、いわゆる例外ケースが多発する場合では、ガチガチであるが故に「融通が利かない」という負の面も出てきます。
さらにExcelに詳しい方が担当するならば、Excelでうまく対処できる可能性もあります。

そのため、こういう部分も考慮した上で、Access化する必要があるのかも検討になると思います。

「Excelは何でもできるシート」という考えで使っているならばAccessでは180度変える

これまでお話してきているようにExcelでの使い方で、「入力とレイアウト作業を同時に進めて考えていく」と、Access導入のハードルが高く感じてしまうケースもあると思います。
というのも、Accessは「データを入力、格納」、「データを加工」、「データを表示」と分けて考える前提になっているからです。

たとえば、先ほどの請求書の画像を見て分かるように、Excelでは「請求書シート」なるものを作成し、そこにデータを入力していけば出来上がります。合計など一部のセルでは関数を使っています。

Excelのシート上では、かんたんに言えば、セルの幅を調整し、請求先の宛名、住所、請求金額のデータなどを入力していけばできあがりますよね。

一方、Accessではそのようにはできません。厳密に言えばできますが、そのような作りにすると効率的な管理が難しくなるため、通常は「分けて」管理します。そして、それがオブジェクトになります。オブジェクトは役割が明確ですので。

そのため、Excelで同時進行的な使い方や、Accessのテーブルの表の構造とは違う表をメインに作っているExcelユーザの方は、Accessでは目線を大きく変えたほうが理解が早まるのではないかと思います。

Excelは、みなさんがご存知の通り、ある意味何でもできる最強ソフトでもあります。
つまり、ExcelにもAccessと代替できる機能もあるわけです。最終的にはどの辺に重きを置くかという点も大事になります。
従いまして、本ページの内容なども参考にして決めていただくとよいと思います。