● AccessとExcelの違い。（Excel代替ソフトも含む。一番大きな違いは「SQL」が「ありとあらゆる」「細かい」ところで使えるところ。）
※まだ書きかけです。すみません。
※間違ってたらすみません。
※メモ書きなので、自分でも意味不明な箇所も多いです。ごめんなさい。
★ 「プログラム」作成上の両者の大きな違い
ビジネスの現場では、「プログラム」というものを、例えば・・・・
(01)個人レベルの「 ”クロス集計表やルールが無いレイアウトの表” に対してだけ使う・かつ・他人には使わせない・かつ・自分が早く帰りたいだけの目的に使う」もの
(02)グラフなどの見える化機能の自動化や細かいシュミレーションプログラム
(03)他の人も使うシステムめいたもの
(04)データベースシステムとしての、データベースエンジン部分
（データの大量蓄積部分、表の紐つけ、複雑な条件でのデータ抽出や基本集計等々）
(05)データベースシステムのなかでの、インターフェイス部分や帳票印刷部分
・・・・といった感じで、主に分けることができると思います。
（この分け方ではちゃんとした基準はありませんが）
Excelが得意とするのは、(01)と(02)と(05)で、(03)と(04)については作れないことはないですが、とてつもなく非効率ですし、件数が増えるとまともに動かない可能性もあります。また、作れないではないものの、Accessなどと比べると少なくとも10倍以上は「非効率」でコストもかかります。実際、(03)と(04)を作ろうと思うとかなり面倒くさく、「Excelって本当にこういう処理には向かない。時間のムダ。」ということに改めて気づくだけ、です。もちろん作り変えもAccessの10倍は面倒くさいです。
Accessが得意とするのは、(03)と(04)と(05)の半分くらいで、(01)と(02)と(05)の残りは作れないことすらあります。作れたとしても、とてつもなく非効率ですし「Accessって本当にイレギュラーなことができないし、進化しないなあ。面倒くさ！時間のムダ！」と気づくだけです。
Excelの少なくとも10倍以上は「非効率」で、Excelの足元にはまるで及びません。
★ データ管理上の両者のもっとも大きな違い
Accessでは、ありとあらゆるところで「SQL」が「使える」、あるいは、
「SQLが使いやすくなっている」、というところがExcelとは最も大きく異なります。
※また、Accessの側では、
「データを大量に貯める・共有する」
「入力フォームの活用（ExcelやVB6よりも50倍効率的）」
「Excelで使うデータの中間集計や中間抽出」
「連続帳票印刷・作成」
「グラフにする前までの見える化」
を中心に行い、
Excelの側では、
「そこからより細かい集計や加工・グラフ化・帳票作成」
「より細かい見える化」
「シュミレーション」
「ビジュアル的なインターフェイス作成」
などを行う・・・、というかたちで
「両者は２つで１つ。兄弟姉妹。」という感じで「セットで使う」のが一番コスパがいいです。（＝ぞれぞれのソフトの得意分野を分担し合う。COMオートメーションなどで。）
どちらか片方で「全てをやる」と考えることほど「愚か」なことはないと思います。
（すべてのケースで、とはいいませんが・・・。小さな会社や部署なら、Accessが1、2台に入っているだけでも結構違います。Accessの数万をケチって、Excelでの無駄な「プログラム作成の人件費」をかけることほど愚かなことはありません。AccessランタイムがあればAccessが無いPCでも定型的な入力フォームくらいは使えます。）
※「Access」を「SQL Server（express）」とか「MySQL」と読み替えても、「用途」の部分としては、入力フォームや連続帳票機能以外は、おおむね同じことが言えると思います。
※「SQL」とは？→→「 " Excel " の基礎」ではなく「 " データ管理 " の、言わば " 世界標準の基礎 " 」です。（こちらもご参考に。）
「複式簿記」と同じくらい有名なデータ管理の基礎で、「Excelに依存しない」といった特徴を持っています。Excel以外のいろんなソフトで使えるようになっています。たしかGoogleスプレッドシートでも使えたような・・・。
というわけで、基本的に「SQL」は、・・・
・Google、アサヒビール、等々の大企業の「社内システムや部署内システム」、
・「世界中のWebカート」
・「世界中のブログ（Wordpressやブログ企業のブログなど）の中核」
・「弥生や奉行シリーズなどのビジネスソフトの中核」
・「システム屋さんに発注して作り・導入するほとんどの中規模システム」
などに使われています。
一般的なプログラミングと違って集計やリストアップのみに特化されており、基本「ループ処理」をする必要がないので、例えば、「そこそこ複雑な条件でのデータ抽出・集計」なら、ExcelのVBAや関数を使うよりも「10倍簡単で10倍コスパがいい」です。し、比べるわけではないですが、実際、ExcelVBAやExcel関数なんか知っているより、SQLが得意な人の方がお給料が高いしお仕事も速く見つかる傾向にあるので、少しうらやましいです。
もちろんExcelでも使えます。
★ 「データが大量ならAccess」という使い方ももちろん間違いではないですけど、「どちらか一方で全部処理」「Accessを使ったらExcelは使わない」「Excelを使うならAccessは使わない」というのは大変・愚かしい考え方です。
基本、「データの量だとか高速性だとか、たった１つか２つのことを基準に」「Accessか？Excelか？を分けてしまう」という短絡思考は、あまり良い結果を生まない傾向にあると思います。（もちろんケースや規模にもよりますので絶対ではないですが）
データが多かろうが少なかろうが、SQL中心で効率的に、「複雑な条件で」、「短時間・短期間のうちに頻繁に」、「集計・リストアップ・テーブルデータの書き換え」をしたい・無駄なVBAや多段関数を少しでも減らしたい、データの一括処理が多い、複数のクライアント（瞬間3台以下くらいまで）でデータ共有や同時書き込みをしたい、なら、私は、「その部分だけ」は、ExcelよりはAccessを使います。
そのほうが面倒がないからコスパがいいので。
そもそも複数のクライアントからサーバ上の共有テーブル（＝共有表）に同時アクセスしてレコード（行のデータ）の書き換えをしたいのにExcelは使いません。Excelにも一応共有機能はありますし、Accessも完全じゃありませんが、でも、一応Accessの共有機能はExcelのそれよりは便利ですから・・・。
（その他の、グラフ、クロス集計表操作・管理、イレギュラーな表操作、シュミレーション、帳票の一部、等々はExcelを使います。）
データが多かろうが少なかろうが、「ビジネスデータの蓄積」と、あと、「クロス集計表等のためのソース表作成・リストアップ・中間集計」、といったビジネス定型処理で、コスパ良く・無駄なプログラムを書きたくない・無駄な多段関数を少しでも減らしたい、なら、こちらも「その部分だけ」は、Accessです。
（同じくグラフ、クロス集計表操作・管理、イレギュラーな表操作、シュミレーション、帳票の一部、等々はExcelです。）
また、「事務系の定型入力フォーム」を作るとき、Excelの不便なユーザーフォームで「無駄に ” 作り変えや作り足しがしにくい不便なフォーム ” を作る」くらいなら、最初からAccessでテーブルやフォームは作ってしまって、あとはExcelとCOMオートメーションで連携させます。
そのほうがデータ管理のコスパが10倍は良くなると思います。（Excelにはない「サブフォーム」も使えますし。）
逆に、ドラッグ操作中心のフォームやビジュアル中心のフォームを作りたいときは、シートをフォームに見立ててExcelでやるほうがAccessを使うよりは 多分、はるかにマシです。Excelシートは、フォームの代用としてはイベントが少ないのが難点ですが、でも、それでも「ドラッグを多用したビジュアル度の高いインターフェイスを作りたい場合」は、AccessフォームよりはExcelシートをフォーム代わりに使うほうが、「はるかにマシ」だと思います。
（そんなレベルでAccessをとどまらせているマイクロソフトの方針はおかしいのですが・・・。）
縦罫線の無い帳票を作るのもAccessのほうが早いとは思います。
（顧客別の連続印刷などは縦罫線が必要なことが多いので微妙・・・です。Accessは縦罫線のある帳票作成が苦手なので。やれるけど、横罫線の縦方向の位置決めの微調整に時間がかかる。Excelでヘッダフッタのついた帳票を連続印刷するプログラムを作る面倒くささと、Accessの横罫線の位置の微調整をする面倒くささとどっちがマシか？の選択になることが多いとは思います。もちろんそれだけではないのでなんとも言えませんが。縦罫線の問題さえある程度解決できれば、Accessのほうが連続印刷はラクだとは思いますけど・・・・。）
AccessとExcel、それぞれに得意・不得意があるので、お互いがそこを埋め合う使い方で連携させるのが一番コスパがいいです。
「どっちかでぜんぶやる」というのは、かなり効率・コスパが悪くなります。
エラそうに言ってしまって大変申し訳ないのですが、「AccessやExcelのソフトウェア代金をケチってみすみす、というか、わざわざ 全体的なコスパが悪くなる方法を取る」のは、大変愚かしいことだと思っています。
（これは、Excel代替ソフトも含めて。もちろんGoogleスプレッドシートなどにしかできない共有機能などもありますから、それはそこだけGoogleスプレッドシートを使えばいいと思います。Googleスプレッドシートなら一応、レイアウトにこだわらなければExcelともデータのやり取りがしやすいわけですから・・・。※もし「ExcelとGoogleスプレッドシートなどの連携」までもが、もし必要なら、例えば「UWSCのような無料マクロ自動化ソフト」やコマンドプロンプトやPowerShellなどを使って自動連携させれば、多少なりとも自動化・省力化できるとも思いますし。）
※ただし、『 そんな頻繁に複雑な条件でSQLなんか使わないし、とりあえずデータためとくだけ。同時アクセスもしないし・・・。入力フォームなんて要らんしね。 シートに普通にリスト表を入力して、その分だけレコード全部、サーバのExcelファイルに（誰もアクセスしてないときに）一発追加で送ったりゃーそんでいい。』、ということなら、当然、「Excelだけで全部対応する」という場合もあると思います。
Excelはバージョン2000の時代からすでに、MicrosoftQuery（＝簡易SQL機能）やピボットテーブルがなんとかある程度「使える」レベルになったので、ミニリレーショナルデータベース的なものも組めます（※事例：『 Excel2000で、POSレジ中核を30分で作る 』）。
ですのでデータをためるだけでたまにリレーション（SQLなど）で集計やリストアップしたいだけならそれでも十分かと思います。（一応、MicrosoftQueryは2013以降のリレーションシップ機能よりも便利な面もあります。クラウド対応ではないし、そのような不便な面もあるかもしれませんけど・・。でもかなり使えます。）
★ そもそもAccessとExcelとの違いはどんなところ？
平たく言うと、Accessは・・・
「小規模システム（一部の事務系のみ・セキュ捨て）の作成効率・コスパ」と
「大量データの高速処理・蓄積・条件抽出の作業効率・コスパ」が
Excelよりも圧倒的によく、反面、細かい計算やドラッグ処理、ピボット処理、
グラフ処理、きれいな作表、などがあきれるほど（多少はできるんですけど、
でも、使い物にならないくらい）
苦手なところです。特にバージョン2000はそうです。
（他のバージョンはちょっとわかりませんけど・・・。
でも多分大して進歩してないと思います。）
Excelはちょうど「その逆」な雰囲気です。
（Excelのダメなとこは、Accessのダメダメなとこほどじゃないかもですが・・・。）
主な項目として挙げると次項の通りです。
★ ExcelとAccessの違いの主な項目（主にAccess側から見た場合です。）
・Accessは「データ管理」のいわば世界標準でもある「SQL」が、
ありとあらゆるところで使える、あるいは、使いやすくなっています。
逆に言うと、「SQL」を「必ず使う」ことが「前提」のソフトです。
また、Accessはもとから「SQL」の理屈にもとづいて・・・、
＝『SQLをベースに』、そのソフトウェア自体のすべての
仕組み・機能が、設計・かたちづくられています。
一方、Excelはそこまで「SQL」に依存（？）していません。
（なのでAccessではVBAのほかに、SQLの勉強も余計に要ります。
SQLは、難易度的には、「私たち素人がよく使う部分に関してだけ」は、
中高生でも理解できるので、その範囲ならVBAよりは難しくはないと
思いますが、超初心者の方にとってみたら、そこそこ「負担」です。
なお、「SQL」はExcelでは、「Microsoft Query」という機能で学べます。
Ver.2003以前は「新しいデータベースクエリ」というメニューです。）
・Accessはフォーム（各種画面）作成、レポート（帳票）作成、
VBAプログラミング、データ操作、「細かいリスト設定」、
ありとあらゆるところで「SQL」が「使える」。
（Excelは「あらゆるところ」とまでは行かないので、それが、
システム構築の効率を少なくとも10倍は非効率にします）
・Accessは「動的な表」を中心に管理することが得意なソフト・・・
（「データ管理の世界標準」の仕組み＝自動集計、に基づくことが多い）
一方、Excelは「静的な表」を中心に管理することが得意なソフト・・・
（「データ管理の世界標準」の仕組み＝自動集計＝はほぼ無視した、
イレギュラーな集計作業やシュミレーションが多い。
だから多段的な関数やVBAの多用が必要。）
・・・と言えるかもしれません。
・Accessは事務の定型処理や大量データ処理・データ共有・一括処理が得意、
Excelはそれ以外の細かい計算や細かい作表、シュミレーションなどが得意。
・Accessは、クエリ（仮想表）をソースにした連結フォームが作成でき、
しかも、クエリ経由からも、テーブルの生データを直接書き換えられる。
つまり、クエリ（＝SQL結果）をソースにした連結フォームからも、
クエリ（＝SQL結果）単体からも、テーブルの生データを直接書き換えられる。
これはほんとうに大きいです。
Excelではこれができないので定型事務フォームの効率がメッチャ悪いです。
といいますか、Excelだけではなく、多分、他の多くのデータベースソフト
できないことが多いと思います。
Accessが他のデータベースソフトよりも優れている点とすれば、
唯一、これだけかもしれません。
定型的な事務系フォームに限っては、他のソフトの数倍は工数を減らせます。
Excelでは「Microsoft Query」にて SQLが扱えるものの、
でも、それで絞り込んでシートに表示された結果表は、
そのセルの値を変更してもソースの表のほうのセルは書き換えされません。
他のデータベースソフトでも同様です。
が、Accessのクエリの場合はSQLで絞り込んで表示した結果表のセルの値を
書き換えると、リンク先のテーブルの生データも書き換えられます。
もちろん、事故を防ぐために書き換えできないようにもできます。
そしてそれを連結フォームにすることで
（もちろんやってもOKな状況の時だけですが）、
次項の「フォーム作成の作業効率がExcelの50倍以上」
ということにも大きく貢献します。
・フォーム作成の作業効率がExcelの50倍以上（事務的なものの一部に限りますが）
（例えば、システム構築の時間コスト・金額コストの削減も同じです。）
例えばExcel2003の「フォーム機能」的な感じ（2007以降は設定が必要）で、
Accessでは、次のようなフォームが、（テーブルの定義が完了していれば）
「30秒」ほどで自動作成できます。
（30秒で以下の機能を全部組み込めます。）
- -『 表＝テーブル（またはクエリ）』と『フォーム』を
完全連動（連結・リンク）させることができるので、次のレコードや
、（特にカード形式の画面の場合に）次の入力画面に移動したい時に、
レコード移動のためのプログラムが「何も要らない」です。
（もちろん、リンクさせなくもできます。）
- -『 表＝テーブル（またはクエリ）』と『フォーム』を
完全連動（連結・リンク）させることができるので、フォームの
入力欄に値を入れると、そこから直で、ソースの表（モト表）のほうに、
ダイレクト・かつ・自動で値が入っていきます。ある意味セル単位で。
また「更新ボタン押下」も不要で。
（Excelの「フォーム機能」と同じように、フォームのテキストボックス
と、モト表のセルが、トンネルで繋がっているかのように入力でき
ます。）
そのため、フォームにいったんすべての値を入力して、それから、
「何らかのボタンを押して表のほうに転記する」、といったような
プログラムは、基本的には不要です。
ただ、5人以上が常時・同じレコードに同時書き込みするような場合は、
そこまで頑丈にはAccessはできてないので、あえてリンクさせない
形もとれます。（非連結フォームなどと呼んだりしてます。）
その場合は、「ボタンを押して表のほうに転記する」といった形に
なります。SQLでもやれるし、DAO・ADOでもやれるし、通常のVBA
でもやれて、また、Excelよりも色んな方法がやりやすいです。
- -他人も使うシステムめいたもののフォームをつくるとき、セルロック、
シート保護、VBA実行中にシート保護にまつわる設定変更や
コード追加、といった面倒くさい処理が必要ない。
- -Excelのデータシート状の画面と、カード形式・その他のフォーム状の
画面の行き来がワンタッチでいつでも切り替えれるので入力や
値のチェック等々がラクです。
（メニュー・ツールバーでの切り替えや1行VBAでの行き来です。）
Excelのデータシート状の画面では、Excelのウィンドウの固定に似た、
「列の固定」などもできます。
列に色をつけたりとか、表示する罫線を変えたりとかも。
各セル（各テキストボックス）に設定したドロップダウンリストは、
もちろん、フォーム状の画面に切り替えたときも引き継がれます。
- -セル移動も「Enterキー押下で」、Excel状の時は基本右方向。
右端まで行けば「Enterキー押下で」次は勝手に次行の先頭へ。
フォーム状のビュー（カード形式等々）の場合なら縦方向や右方向。
順番的に最後のセル入力してEnterすれば、勝手に次ページへ。もちろん
次ページへの移動もノンプログラミングです。
また、「セルとセルの間をEnterやTABでどう移動するか」をユーザーの
好きなように指定できます。
（30秒でできるのは、初期値で、上から順番、左から右へ順番。）
- -どこかのセル（列、テキストボックス）の値を入力することで、自動的に
入力されるようなセル（列）は、飛ばしてしまい、入力が必要なセル
（列）だけを移動することも可能です。
飛ばすのはプロパティ設定するだけです。1列あたり3秒くらいで
設定できます。（点滅カーソルが飛び飛びに進んでくれます。）
- -「できるだけ変なデータが入らないように値をチェックする」ための、
イベントや仕組みがExcelの5倍以上は用意されていて、しかも
設定や機能の組み込みがExcelの5～10倍はラクちん。
- -フォームフィルタといって、フォームの画面をそのままフィルタの
画面にすることができます。And、Or、複数条件、色々設定可能です。
頻繁に使いそうなものはクエリとしても保存できます。
- -入力チェックのコマンドボタンやイベントプロシージャをいくらでも
作り足せます。Excel状のデータシートでは、ある列をコマンドボタン
代わりにもできるし、入力時にEnterしたときにイベントプロシージャ
で入力チェックや転記等々、いろいろとできます。
Excelはシートをフォーム代わりにするほうが便利だと思うんですが、
ただ、その場合、Changeイベント？とその他少しくらいしか無いっぽい
やりづらいですが、Accessの場合はその20倍（テキトー）くらい、
イベントが用意されています。
それとExcelはAccessで簡単に（数秒か数分で）できることを、
クラスモジュールで自作オブジェクトを作らないとできないことも
多そうだし・・・。
Excelは、「定型入力フォームの作成」だけは、ほんと、
めんどくさいです。
（定型的かつドラッグを多用しない事務系のみのフォームに限りますが。）
- -セルまたはテキストボックスの右クリックでも簡単にフィルタができます。
OrやAndが使えます。また、セルの入力値の・・・、
先頭数文字をドラッグで、前方一致
中ごろの好きな個所数文字をドラッグで、部分一致
最後の数文字のみをドラッグで、後方一致
・・・のフィルタができます。
「非選択」といって、「選んだもの」「以外」のフィルタもできます。
全部、右クリックで。
- -フォームのソースとなるデータを「テーブル直」ではなく、
「テーブルの ”まんま” をソースにしたクエリ」にすることで、
列単位の数式利用（計算）が容易となるので、
「縦方向の数式のオートフィル」もほとんど要らないようにできます。
もちろん、数式では、Excelのワークシート関数に似た関数も使えます。
（セル＝テキストボックスのプロパティでも設定できる場合もありますが。）
※以上のような「入力とヒント探しをしやすくした」フォームが、
何にもしなくても、「30秒で」、ウィザードで、「ポコッと」
できてしまうので超ラクです。
もちろん、多くの場合がさらに作りこむので、その分の時間はもっと
（プラスで）かかりますが・・・
でもその、「30秒でできるやつ」と同等の機能をExcelで作ろうと思うと、
速い人でも数週間、場合によっては数か月かかる場合もあるので、
僕は、Excelで事務の定番的なフォームを作ることに限ってだけは、基本、
「しません」。（それ以外は、もちろん、Excelに頼る場面も多いのですが。）
テーブルではなく、「テーブルをソースにしたクエリ」をモトにフォームを作る
ことで、「数式のオートフィル」もほとんど要らないようにできますし。
正直、Excelのユーザーフォーム使うくらいなら、最初からAccess使います。
（もちろん、例外もあるでしょうが、いまだ遭遇したことはありません。）
だからいつも、AccessとExcelのそれぞれの得意な部分を連携させて使ってます。
ついでに言いますと、話が逸れてすみませんが、
まずはデータに騙されないように、前述のような機能でデータの「傾向や何か」を
つかむことのほうが先決で、それをやらないただのExcelでの「きれいな作表」
なんてほとんど意味がない無駄作業だと思っています・・・。
あと、特に、罫線や色が無いと数字が読めない、カンマだけで数字が読めない
「上の方」に対しては、下っ端の人間としては現場で無駄作業が増えるので
やはり困ってしまいます。（働き方改革のジャマです。）
なんとかカンマと値のスキマだけで罫線も色もなく、数字が読めるように
なって頂きたいです。
できないならご自分で定規でもご用意してほしいですね。蛍光ペンとか。
定規と蛍光ペンを手に「チェックするぞ！」ってやったほうが数字見るの、
楽しくありませんか？
それをしないから、社内で「きれいな作表」という無駄作業が増えます。
会議で眠たくなったりとか・・・。
「きれいで無駄な作表」は、「立派な作表」とも呼ぶかもしれません。
くだらない色付けのせいでインク代ももったいないような気もします。
チリも積もって・・・。
（もちろん、重要なプレゼンなどは別です。）
正直、社内だけでなく、社外でもそうなったらいいのにと思います。
いい加減、Excelの機能満載で作る「きれいな作表」、どの会社様もやめません？
コンサルを喜ばすだけで、あまり意味がないことありませんか？
ExcelやAccess、パソコン、ごときに人間様がふりまわされるの、
もうよくないですか？
働き方改革は、もしかしたらExcelを半分捨てると大幅に改善されるかも？
・・・というケースも、もしかしたらあるかもしれません。
- -あと、30秒以内ではないですが、Accessでは
フォームの中に、さらにフォームが複数作れるのでそれも便利です。
「サブフォーム」と呼んでいます。
あるデータに紐ついた内容をその埋め込みフォームに表示できます。
埋め込んでリンク設定するのも1～10分くらいでできます。
それも、Excelで作るフォームの2～20倍以上は、効率化を図れます。
サブフォームも、もちろん、連結（＝リンクON）も非連結
（＝リンクOFF）も両方いけます。
・定型帳票、定番帳票の作成の作業効率がExcelの20倍以上
（縦罫線の要らないもの・凝ってない罫線のものに限りますが）
印刷中のイベントもあるので、印刷しながらいろいろ細工ができます。
・インデックスなどの機能が付いているので大量のデータを
Excelよりも高速に扱えます。
・Accessはクライアントサーバ「もどき」なシステムを作って、複数ユーザー
での同時書き込みが、特に機能の制約が無くできます。
Excelでも2000から「ブックの共有」機能でできますが、
一応使えない機能が出てきます。（困らない機能だとは思いますが）
※Accessのmdbファイルが破損する・しない、やファイルサーバに
データ専用のmdbを置いた時の処理速度が遅くなるという問題は
バージョン2000や97の頃からのセオリー１とセオリー２を守れば、
大抵は回避できます。
これを守れば、Excelよりも共有時の破損は少ないかもしれません。
ただしその場合、ユーザー別セキュリティを捨てないといけません。
そこを押さえれば、同時書き込み機能や画面の作り込みは、
AccessのほうがExcelよりもがラクといえばラクなのかもしれません。
（僕自身、Excelの共有機能はデータ量と速度と破損確率の問題で、
怖くてまだ使ったことがないのですが…。でももしかしたら、
「使ってみたらすごく良かった！」ということもあるかもしれないですね(^^)）
・部署をまたいだ、情報共有がやりやすい（かもしれない）。
組織の規模があまりに大きいと向きませんが、
パソコンが30台以下くらいの零細様なら、すべての部署をまたいだ、
全ての事務的データの一元管理、情報共有、検索・条件抽出・加工・等々
について、Accessのほうが、Excelよりもやりやすいと思います。
データの量、ファイルの破損、処理速度、問い合わせ（集計や抽出検索）
などやりやすさ、等々の面などでExcelと比較して。
・AccessはSQLServerExpressやMSDEなどと接続できるADPファイルで
画面やプログラムを作ると、ストアドプロシージャが一応、使えます。
※もしかしたら最新のExcelでは、SQLServerなどにつないで
ストアドプロシージャが使えるのかもしれません。僕が知らないだけで…。
なお、ADPファイルを使うと、ユーザー別セキュリティが一応
そこそこ高度なものがつくれるそうです。
（※「ストアドプロシージャ」・・・
集計作業をサーバパソコンのCPUにやらせて
クライアントパソコンはその結果の表を受け取るだけ、という仕組みです。
mdbの場合はサーバの全データをいったんクライアント側に読み込んでから
クライアント側のCPUで集計するのですが、ストアドプロシージャを使うと
それを全部サーバ側がやってくれるので、そのため「集計が速い」
「ネットワークの負荷が軽くなる」などとされています。
なお、mdbの場合は、パススルークエリという機能で、
ストアドプロシージャと似たようなことができるようです。）
・一応Accessは「レプリケーション」ができる。
（※「レプリケーション」・・・データ（mdbファイル）のクローンを構築し
そのデータ内容を自動的に同期させ、どのクローンにアクセスしても
同じ集計・抽出の結果が得られるため、パワー・・・というか負荷の分散が
できる・・・みたいな機能です。でも僕は怖くて使ったことありません。）
・差異ではないけど「OWC」にて、htmlに埋め込んだExcelのピボットと同じように
ブラウザ上で扱える（ASPベース？）のWebフォームが作れる。
Access2000ではそれを「データアクセスページ」と呼んでいます。
簡単な入力、検索、編集、削除等々ができます。
サブフォーム的な動きもするので結構便利かもしれません。
IIS上（Webサーバ上）で動くので、イントラネットに使えるかもです。
ブラウザ経由であり、常時接続ではない（連結フォームではない）・かつ・
NetBIOS（SMB）経由ではなくHTTP経由なので、同時アクセス可能数が
50とか100とか、（疑似連結的に）メッチャ増えたように見えます。
「OWC」ではピボットをWebページに埋め込んで集計操作ができます。
「OWC」はExcel、Accesなどで使えるOfficeのツールです。
ただし、最新のIISで動くかはわかりません。
※Excelのピボットは、htmlに埋め込んで使えます。
Webページ上にてフィールドをドラッグで入れ替えて、
色んな切り口で集計し直せます。
（標準機能ではできませんが、Office2000に付属の
「OWC」を使うと、Excel2000でもできます。）
・同じく差異ではないですけど、Excelもたぶん同じだと思いますが、
IIS上（Webサーバ上）で動かすなら、データアクセスページじゃなくても、
PHPやVBScriptでもやれたような気がします。mdbへの接続。
ADOかDAOの併用などで。
最新のIISやPHP、VBS、ASP、でやれるかはわかりませんが・・・。
・「Personal.xls(xlsb）＝個人用マクロブック」は無いけど同じことはできる
mdbファイル自体を自由に複数、VBE画面にて「参照設定」できます。
参照設定したmdbは、ExcelのPersonal.xls(xlsb)の場合のように、
その中のフォームやプログラムを、自由に呼び出せます。
また、特別な場所のmdbでなくても自由に複数のmdbを参照設定できます。
そのmdbの中に共通部品や共通プログラムを入れておけば、
フォームやプログラムの再利用がよりラクになります。
つまり、Excelで言う「Personal.xls」のような外部のmdbを、
『何個でも同時に参照して、それぞれから同時に共用プログラムや
共用フォームなど呼び出せる・・・』という感じのことができます。
また、Excelはxlsやxlsx・xlsmなどを参照設定すると
参照設定先のファイルも開いてしまいますので非表示にしたり
しないといけません。面倒くさいです。しかも、非表示に
しても、閉じるときにアプリケーションウィンドウが残るので
さらにそれも面倒くさいです。
が、Accessではそのようなことは起こらないのでmdbに参照設置
するだけで終わるのでラクちんです。
また、Accessで参照設定したmdbファイルは、標準モジュールに書いた
プロシージャを、参照元のmdbから普通に「Call」できます。
Excelの「個人用マクロブック」のようにエラーにはなりません。
その点も便利です。
※Excelの「個人用マクロブック」に書いた標準モジュールの
プロシージャは、「Call プロシージャ名」では呼び出せません。
（「マクロ」として、クイックツールバー等からは呼び出せますが）
Application.Run で呼び出さないといけないし、引数があるものは
正常に呼び出せないっぽいです。
また、引数のあるプロシージャをCallしたかったら、アドイン化が
必要らしいです。
Accessではそんなことしなくても参照設定さえすれば、
（そのmdbが道連れに表示されることなく）読み込まれるし、
プロシージャも「Call プロシージャ名」で簡単に呼び出せますので
ラクちんです。
・Excelの得意なピボットやグラフ、細かい計算、はかなり苦手。
（例えば Ver2000のAccessだと、ものすごい容量肥大を簡単に起こし、
使い物にならないです。それらはExcelに任せるほうが絶対にいいです。
きれいで細やかな作表、細かいシュミレーションもかなり苦手。）
・ドラッグや図・図形を多用したシステムがExcelの100倍は作りにくい。
（例えば、ガントチャートやグループウェアの予定管理機能。）
・エンドユーザーに対し、デザイン的な見せ方や使わせ方はほとんどできない。
※なのでExcelの得意はExcelにまかせて、Accessの得意はAccessにまかせて、
両者を「DAOやADO」、「COMオートメーション」を使って自動化連携させるのが
一番効率・コスパがいいです。あくまでもユーザー別セキュリティは捨てて。
※補足01
ExcelとAccessは本来は使用目的は違うのですが、でも「現実」として「実際にできること」としては、かなり似ています。（世間一般に言われる以上に。）
AccessもExcelも両方とも、「バージョンが2000であったとしても」、フィルタも、クエリ（SQL）もクエリのネストもでき、リレーションも、ピボットもグラフも扱えます。フォーム（入力等の画面）の作成や帳票の作成・印刷だってできます。DAOやADOだって使えます。
僕はド素人としてAccess（というかmdbファイル）ばかりいじってきたのですが（なのでExcel音痴です。まあ、結局Accessもなんですけど。ADPファイルわかんないですし。）、特に、Excelはすぐれていて、ほんとうにびっくりさせられました。
例えばExcel2000の場合は、「Microsoft Query」でどこまでできるのか表面的なことを見てきただけですが、それを見ると、まったくAccess（mdb）と変わんないことができる・・・、別にAccess要らないじゃん・・・、と驚きました。
特に「沢山のマシンで共有しないなら、かつ、データ量が片手万件以下」の場合なら、Excelで十分、SQLなどを使ってAccessと同じことができてしまいます。
本サイトでもご紹介してるのですが、このようなこともできてしまいます。
『Excel2000で30分で作るバーコードPOSレジのコア部分（定型集計効率化サンプル）ダウンロード』
『Excel＋Wordで、明細付きの顧客別差込み印刷をする方法。（顧客別連続切換明細印刷・基本VBAゼロ）』
もちろん、「問題の数値化」、「仮説と検証」、「選択と集中」、「PDCAサイクル回し」、などに利用できる表も作成できます。両方とも。（「Excel・Accessのそれぞれが得意なTPO・利用シーン」は業種や職種、あとはまさにTPOによって変化していきますが）
では何が違うのかというと、「それぞれの得意分野」が違います。
そしてそれぞれの得意と苦手が、うまいぐあいに、凸と凹で補えるようになっています。
Access(mdbファイル）の得意は大きくは以下のようなことです。
・データ管理のいわば世界標準でもある「SQL」がありとあらゆるところで使える、
あるいは、使いやすくなっている。
「SQL」を必ず使うことが前提のソフト。（なのでSQLの勉強も少しだけ要ります）
・データを大量に蓄積
・大量データから「Excelの十数倍は高速に」複雑な条件で問い合わせ（抽出）
・フォームや帳票をExcelやVB6などの50倍効率よく作成可能。
（事務系入力フォーム限定ですけど。前述のとおりです。）
・機能制限のない「データのLAN共有」
・ピボットテーブルのソースに使う表の作成
（複数枚の動的な表を紐付けし合った上での複数条件での抽出）
・一部の帳票をExcelやVB6などの20倍は効率よく作成
（主に凝った罫線・縦罫線・規則性の無い罫線・等々、が必要の無いもの）
・複数の外部のmdbを同時に参照して、共用プログラムや共用フォームを呼び出す
・ブラウザ経由でIIS上でASPやPHP、VBSなどでADOやDAO等を使ってデータ操作する
反面、Accessでも一応できるけど、でも「苦手」あるいは「かなり苦手」なことは以下のようなことです。
・きれいで細やかな作表（色や図、罫線がとりどりの作表）
・細かい計算（シュミレーション等々も含む）
・一部の帳票の作成（主に凝った罫線・縦罫線・規則性の無い罫線・の必要なもの）
（※苦手というか「Excelよりは難しい・面倒」という感じ、かも？）
・細かいシュミレーション、大まかいシュミレーション
・ガントチャートやグループウェアなど、ドラッグを高度に多用した処理
（あきれるほど、ドラッグを利用可能なフォームを作成できません。
なぜ、ここを改善していかないのか不思議でなりません。）
・ピボットテーブル処理
（例えばAccess2000の場合だと、とんでもない容量肥大を簡単に起こします。
とてもじゃないですが使えません。他のVerでもmdbなら同じかも？）
・グラフ処理
（同上。Access2000だと、とんでもない容量肥大を簡単に起こします。
とてもじゃないですが使えません。他のVerでもmdbなら同じかも？）
・白紙の（手書き記入用の）帳票・申請書などの作成
・「文章」の作成。（特に、色や形などデザイン的に多彩な文字を使った文章の作成も。）
・地図やワードアートなどの「図」系のオブジェクトの作成
・画像やシェイプ（ベジェ的な線等々）を作る、動かす。
・ドラッグを使ってそれらを動かす。
・その他ドラッグ操作可能な画面の作成。
反面、Excelの苦手と得意はまさにこれの反対です。
なので、Excelの得意はExcelにまかせて、Accessの得意はAccessにまかせて、両者を「COMオートメーション」で自動化連携させるのが、一番効率・コスパがいいです。
また、ExcelもAccessも両方とも、ユーザー別の高度なセキュリティは「やれない」に等しいので、セキュリティは捨てます。（簡単なもの以外は）
逆に、ユーザー別セキュリティを捨てないと、高いコスパを得られません。
また、それぞれの「苦手」を「無理に」やろうとすると、お互いにコスパが100倍は悪くなります。
それを理解できないと、なんでもExcelでやろうとしてしまいます。もしくは、なんでもAccessでやろうとしてしまいます。
それが一番「愚か」です。
そこはとても注意が必要です。
Microsofot Officeは、Word、Outlook、パワポの含めて、「DAOやADO」、「COMオートメーション」を使って、得意なソフトに得意をまかせる、ということが一番のコスパアップとなります。
そんなところです。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
※ 補足02：『「Excelの真の基礎」も考え方は同じ。』
当サイトで言っています「Excelの真の基礎」も、前述のお話と似ています。
例えば集計作業全体をおこなうことを考えた場合に、
前述の「Access」の部分（…A）は、
・「Microsoft Query と ピボットテーブル」を多用する。
・「Excelを真のコンピュータとして使う使い方」。
としていて、
また、「Excel」の部分（…B）については、
・「ワークシート関数やVBA等々、これまでよく利用・説明がなされてきた機能」を多用する。
・「Excelを紙と電卓の延長として使う使い方」。
としています。
いずれにしましても、「Excelの真の基礎」の場合も、この（A）と（B）の２つの使い方は、それぞれに「得手不得手」、があります。
そして、その得意・不得意は、前述のAccessとExcelの場合とかなり似ています。
なので「Excelの真の基礎」でも、お互いに得意・不得意を補いあって、凸と凹で集計作業全体をカバーする、という考え方をしています。
※補足03：Excelはデータ管理の基礎をぶっ壊したソフトなのかも？
AccessとExcelの違いを仕組みなどから見てみると・・・
・Accessは「動的な表」を中心に管理することが得意なソフト
（「データ管理の世界標準」の仕組み＝自動集計、に基づくことが多い）
・Excelは「静的な表」を中心に管理することが得意なソフト
（「データ管理の世界標準」の仕組み＝自動集計＝はほぼ無視したイレギュラーな集計作業やシュミレーションが多い。だから多段的な関数やVBAの多用が必要。）
・・・と言えるかもしれません。
とすると、Excelは、いわば、
・「データ管理の世界標準の仕組み＝自動集計」をぶっ壊したソフト
・SQLやピボットなどの自動集計機能では不可能な集計やシュミレーションなどをVBAや多段関数で細かくやれるようにしたソフト
といえなくもないかもしれません。
SQLという自動集計・リストアップ機能自体は、理論自体は40年くらい前、ソフトへの実装が30年くらい前からあったそうですので・・・（つまりExcelのほうがあと・・・。でも理解し間違えているかも。専門家の方にお聞きください。）
ただ、いずれにしましても、Excel2007以降から「テーブル機能」や「リレーションシップ機能」などが追加されてきているところを見ると、「データ管理の世界標準の仕組み＝自動集計」も無視できなくなってきた・・・という側面も多少あるのかもしれません。
何にしても、「※補足02」の（A）と（B）２つの「使い方」の「両方が必要」なことは明白で、「お互い片方同士で終わってしまったら結局は効率が悪い」ということは間違いは無いと思います。
当サイトの「Excelの真の基礎」では、「テーブル機能」や「リレーションシップ機能」を、「Microsoft Query」で処理することをお話させて頂いています。
「テーブル機能」や「リレーションシップ機能」は使えるバージョンにばらつきがありますが、「Microsoft Query」はExcel2000以降、すべてのバージョンで使えるからです。
※補足04：Excelの代替ソフトについて
Excelの代替ソフトについても「※補足03」のように「データ管理の基礎をぶっ壊したソフトなのかも？」ということが言えると思います。
Excelの代替ソフトとは、有料無料のすべての「表計算ソフト」と呼ばれるソフトです。
有料のものは
・ロータス123、
・三四郎（JUST SYSTEM：販売終了・生産も終了）、
・Calc（同上：法人のみ・単品無しでJUSTOfficeに含まれる：1ライセンス2万円前後くらいから）
などがあり、無料のものは
・Apache OpenOfficeのCalc、
・OpenOffice.orgのCalc、
・LibreOfficeのCalc、
・Google Spreadsheets
などがあります。
これらについても、
・もしデータベースソフトが付随する場合なら、それは「動的な表」を中心に管理することが得意なソフト・・・
（「データ管理の世界標準」の仕組み＝自動集計、に基づくことが多い）
・代替の表計算ソフト自体は「静的な表」を中心に管理することが得意なソフト・・・・
動的な表を扱うのはもとから苦手・・・。
（「データ管理の世界標準」の仕組み＝自動集計＝はほぼ無視したイレギュラーな集計作業やシュミレーションが多い。だから多段的な関数やVBAの多用が必要。）
・・・と言えて、かつ、
代替の表計算ソフトは、いわば、
・「データ管理の世界標準の仕組み＝自動集計」をぶっ壊したソフト
・SQLやピボットなどの自動集計では不可能な集計やシュミレーションなどをVBAや多段関数で細かくやれるようにしたソフト
・・・とも言える、ということになります。
ただ、これらのソフトで、ExcelのMicrosft Queryのような「SQLによるデータ操作が可能な機能」が組み込まれていないものは、「事務的ビジネス定型集計・定型リストアップ」の効率化・コスパアップは望めないのが現状だと思います。
この場合のコスパアップとは、『ライセンス料金の話だけでなく、自動化プログラムを自社内で作成する人件費やそれを引き継いでいくための教育費用、引継ぎ方、など、もろもろの管理費と実際の集計や売上貢献・利益貢献等々ができるバランス（対費用効果）等々も考えてのこと』です。
LibreOfficeなどのOpenOffice系のソフトには、たしかBASEと呼ばれるAccessと同じ位置づけのSQLが扱えるソフトがついていますので、もしかしたら効率化が図れるかもしれません。（テストしてないので図れないかもしれません。すみません。）
ロータス123、三四郎、にはたしかSQLが扱える機能が無かったと思いますので、部分的に自社に合った「便利な機能」を「つまみ食い」するほうが、効率がアップできる気がします。
Google Spreadsheets、には「Fusion Tables」というのがあって、それでSQLが扱えたと思います。（こちらもテストしてないのでよくわかっていません。すみません。ただ、こちらの書籍やWeb情報が増えたら一番Excel＋Microsft Queryの代替になりえるかもしれないですね。）
なお、無料の代替ソフトは、Exel＋Microsoft Query （あるいは、それらプラス、DAO、ADO、QueryTableオブジェクト、ピボットテーブル）の効率レベルを凌駕できるほどの効率化ができる気がしないので、「100％静的な表しか扱わない」という現場以外は、効率化は難しいと思います。（特に今は、Office365で5台で月1000円とかですから・・・Excel＋Microsft Query 以外のソフトも全部ついてますし・・・。）
ただ、逆に言うと、『 Exel＋Microsoft Query （あるいは、それらプラス、DAO、ADO、QueryTableオブジェクト、ピボットテーブル）の部分は、そんなんExcelでやる必要ある？その部分はもう自社システムやクラウドのBIシステムがあるから、ExcelはBtoCのお客様だけへの「きれいな作表」だけにしか使わないので、ピボットも何もいらない。 』、ということのほうが現実的には多いかもしれません。ですので、もしそうなら、逆に、Excelなんてやめて、代替ソフトにしたほうがいいかもしれません。
なお、そういう現場なら、すでにできあがったシステムが速いと思いますので、速度も求められないでしょうから、Google Spreadsheets がとっても良いと思います。
あと、もしかしたらそういう現場はもともと表計算ソフトが要らない現場だったりする可能性も無きにしもあらずかもしれません。なので色々再考するのも良いと思います。
Excelの代替ソフトについて・コスパ等については、以下の記事もご参考にしてみてください。
・ 「Excel代替ソフト」の「データ管理のムリ・無駄・ムラ」についてはどう考えたらよいでしょう？代替の無料の表計算ソフトは本当にお得でしょうか？
https://euc-access-excel-db.com/tips/ct09_biz-pctec/demerit_of_excel-compati-soft01
