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

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

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

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

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

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

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

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

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

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

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

アクセスのデータベースウィンドウ
話をわかりやすくするため、かなり強引な見方になりますが、Excelの機能などを分割するとAccessのオブジェクトになります

テーブル

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

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

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

ちなみにこの表は「セルA1から始まる箱型の表」を指し、いわゆる「Excel方眼紙的な表」は含まないことにご注意ください。

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

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

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

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

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

データの種類が保証されているということは、たとえばある列(カラム)に「日付」を定義することで、その列には「日付(のデータ)が入力されている」ことは保証されているという意味です。
しかし、定義されているとはいえ、「入力された値が正しいかどうか」までは判定できません。
たとえば、「日付」を定義した列に、ある人の誕生日を1日間違えて入力することもできます。
仮にNG扱いにするならば、テーブルの定義とは別のチェック機能が必要です。

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

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

クエリ

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

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

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

クエリの本体は「SQL」です。SQLとはテーブルなどを操作するときの言語ですが、AccessではSQLを直接触らないよい代わりにクエリが用意されています。
なお、Accessでもクエリ画面ではなく、SQL自体を作ることもできます。
クエリはSQLでも記述できる
古い私の記憶では、Accessでは、SQLに触れずにクエリで対処できる仕組みを作ったことでデータベースをとても身近にしたと評価されていたと。。

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

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

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

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

上記の合計値の表だけを見ると、Excel作業でも「日付をキーにして、SUMIFを入れておけば修正不要じゃない?」と見えてしまいますが、ちょっと違いますのでご注意です。
ここで言いたい点は、「新しい日付の売上が行として追加」されるイメージです。
もし、予め追加される日付がわかっていれば、SUMIFでも対応できます。が、そうではなく、「いつの日付かわからない売上が追加」されるイメージです。そのためSUMIFで先手を打って準備するというのが実質不可能であることをイメージしてもらうとわかりやすいかもしれません。

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

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

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

フォーム

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

  1. フォームを通じて、データを入力することができる
  2. フォームを通じて、データを(選択した状態で)表示することができる

イメージです。

なお、Excelにもフォームが2種類あります。うち1つは、VBA(プログラム)上で作成するフォームです。こちらは万能ですが、もう一方のフォーム(初期はリボンに非表示)は緩い作りになっています。
以下は、Excelのフォーム(初期はリボンに非表示)です。
Excelのフォーム
Accessのフォームは、ExcelでいうVBAのフォームに相当すると思いますが、Excelほどプログラムをこねくり回さないで作れるなど敷居が低くなっているのも特徴だと思います。
(もちろんAccessのフォームもプログラムで動かせるので、細かい制御も可能です)

レポート

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

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

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

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

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

マクロ

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

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で割と普通に使われているように思います。

  1. 毎月、複数の宛先に請求書を作成(印刷)している
  2. 作成(印刷)のレイアウトはすべて同じ
  3. 変わるのは明細内容と金額

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

ここで挙げている請求書については、Excelシートに請求書のレイアウトを作成し、データや数式などを手動入力するものです。見たままの通りです。
といいますのも、当サイトの別の記事(Excelで関数だけを使って請求書を作成する)にて、Excel請求書をAccessライクにした作り方を紹介しています。
そちらのページの請求書は、当ページで想定している請求書(の作り)とは構成が異なります。仮に別記事からダウンロードしたExcelファイルの「請求書」シートを見ていらっしゃる方は(そこのページの内容と乖離しますので)ご注意ください。

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

たとえば・・

  • 請求明細の一部が前回シートのまま(上書き・消し忘れ)
  • 明細の数が変わり、請求金額のSUMの範囲が足りなくなった
  • 明細の数が変わり、2ページにまたがり、次月以降2ページ仕様を1ページに無理やりまとめたためレイアウトがおかしくなった
  • 前回分のシートに上書きしてしまう

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

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

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

ここでは定型化作業の例として「請求書」を挙げていますが、このような作業(概念・意味合い)が満たされている作業であれば他の作業でもよいという意味です。みなさんの周りの作業も確認してみてください。

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

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

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

仕様がコロコロ変わる作業はExcelのほうが勝手が良い

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

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

なお、レポートを使わずにテーブルとクエリのみで使用する場合は、この限りではないです。集計し出力したところ、「ああでもないこうでもない」とクエリの内容を変えて試すこともあります(そして納得いく形にできるとクエリの結果をExcelに出力して体裁整えて印刷するとかです)。

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

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

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

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

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

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

修正する項目によって影響する範囲が変わるため、オブジェクト単体の修正ではなく、「テーブルとクエリの両方に修正が必要」というケースももちろんあります。
また、修正の影響範囲などは設計の段階である程度決まります。「のりしろ」を考慮した設計にするほど難易度が上がりますが、このあたりは作成者(Accessの場合は「開発者」とも言いますが)の技量にも依存してくる部分になると思います。

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

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

タイトルとURLをコピーしました