★★★ Access2000VBA・Excel2000VBA独学~「Excelが発売されて20年も経ってるのに」、「ExcelVBAを教える教室やサイトが当時の100倍以上も激増しているのに」、なぜ未だに初心者が自力でエラー解決ができないのか? → → → 理由はExcelVBAを教えるレジェンドさん達の教え方が下手くそだったから・誠意がないから・本当のことを教えてくれないから。ピントがズレてるから。~
  
※まだ書きかけです。すみません。
※間違ってたらすみません。
※メモ書きなので、自分でも意味不明な箇所も多いです。ごめんなさい。
  
  
「Excelが ”発売されて” 20年以上も経っているのに」、
「ExcelVBAを教える教室やサイトが発売当時の100倍以上も激増しているのに」、
なぜ、いまだに・・・
「ExcelVBAの初心者が自力でエラーが解決できない」、とか、
「いつまでたっても初級の、しかも「 ” 下 ” か ” 中 ” にもいかないレベルのまま」で、「中級」なんて「難しすぎて」「ぜんぜん上がれない」とか
「Q&Aサイトで質問しても、回答者の言っている意味が理解できない」とか、
「有料で習っても全然回収できない」とか、
・・・そういうことが起こっているのでしょうか?

本来なら(もう20年も経っているわけなのですから)、ExcelVBAの初心者教室は、
「変数、オブジェクト式、オブジェクト変数、SQLやそれを使ってのリレーション、ピボット、なんて、そんなのWebでタダで独学できてて、初級教室で習う前から知っててあたりまえ」で、
「シュミレーションやガントチャートやグラフをVBAでバンバン動かして、ちゃちなBIシステムならそんなものいらない」
「こういう仕事やマーケティング、PDCA、仮説と検証、問題点の数値化、の内容の時はこういう機能の使い方で、もしSQLやグラフやピボットをVBAで自動的に動かす使うならこう」
・・・というようなことが「 ”当たり前に” 教えられている状況」になってないといけません。

また、
『MicrosoftQueryとQueryTableオブジェクトの専門書が何冊も刊行されている』
『MicrosoftQuery(QueryTableオブジェクト)+ピボットの合わせ技の本が何冊も刊行されている』
『ピボットとGetPivot関数をExcelVBAで自動的に動かすための本が何冊も刊行されている。』
『SQLをExcelVBAで扱うための本が何冊も刊行されている。』
『SQLをADO・DAO・ExcelVBAで扱うための本が何冊も刊行されている。』
『ADO・DAOをExcelVBAで扱うための本が何冊も刊行されている。』
『Wordへの差し込み印刷・Wordのフィールドとの連携の本が何冊も刊行されている』
『クラスモジュールの使い方、自作オブジェクトの作り方とビジネスへの応用といったテーマの本が何冊も刊行されている。』
『こういう仕事やマーケティング、PDCA、仮説と検証、問題点の数値化、の内容の時はこういう機能の使い方で、もしSQLやグラフやピボットをVBAで自動的に動かす使うならこう、といった、そういう本が何冊も刊行されている』
『グラフとマーケティングなどをからめた本が何冊も刊行されている』
『オートメーションやIE操作の本が何冊も刊行されている』
『VBAヘルプなんか、どんな初心者も ”読めてあたりまえ” 』
『VBAヘルプとオブジェクトブラウザ、デバッグの解説本が何冊も刊行されている』
『そしてそれらの本が売れてて全然減らない』
という状況になってないといけません。

Excelが発売されて「20年以上」もあったんですから。

しかし現実には、
そんな状況は今後も一切来る気配もなく、なぜいまだに、
『シートとセルを操作する本しか無い、と言っても過言ではない』とか、
『 ”Excelデータベース”、と題された本に、SQLという単語やSELECTという単語が微塵も出てこない。ニセのデータベース本が98%くらい。そういう単語が出てても、MySQLやSQLServerを扱う本しかない。Excelファイルに接続する事例が満載の専門書(たとえばこちらのような内容の真のExcelデータベースの本)など1冊もない。』とか、
「ExcelVBAの初心者が自力でエラーが解決できない」、とか、
「いつまでたっても初級の、しかも「 ” 下 ” か ” 中 ” にもいかないレベルのまま」で、「中級」なんて「難しすぎて」「ぜんぜん上がれない」とか
「Q&Aサイトで質問しても、回答者の言っている意味が理解できない」とか、
「有料で習っても全然回収できない」
「変数がわかりません」
「オブジェクトブラウザがわかりません」
「ヘルプが読めません」とか、
そんな状況のままなのでしょうか?

その原因は・・・、

僕もVBA初心者なので、今いろいろ勉強中の、その立場から感じることを正直に、

でも、誤解を恐れながら言いますと・・・

「ExcelVBAを教えるレジェンドさん達の教え方が下手くそだったから・誠意がないから・本当のことを教えてくれないから。ピントがズレてるから。」

それがもっとも大きな原因なのではないかと、最近、強く、思います。

例えば、「Book1のSheet2(Sheet1ではなく)のA1セルの値を取得したい」という時、色んな書き方ができると思いますが、例えばこれ以降で、 青い太字 で挙げたような書き方ができます。

でも、レジェンドさん達からは、シートやブックを指定するしない(つまり「省略する・しない」で)、意味がまったく変わってくることを、「最初に」「おおまかにでも」「全体的な概要を」「まったくもって」教えてもらえてません。(特に彼らの著書で。)
教えてもらえても、ほんの一部かあるいはとぎれとぎれかつ「抜けの多い」情報しか教えてくれません。(体系的ではないのです。)

たとえば、初心者のみなさんや、初心者レベルのまま・今少し挫折中のみなさんは、以降に描いたようなこと、すべて把握していますか?(僕は一応ExcelVBAの初心者ですが、がんばってヘルプ読んだり・本・Web記事を読んだりして、自分なりに、以下のようにまとめてみました。みなさんも是非・少しずつTipsを集めてまとめてみてください。)
  
  
  
  
Application.Workbooks("Book1").Worksheets("Sheet2").Range("A1").Value
(=Application.Workbooks.Item("Book1").Worksheets.Item("Sheet2").Range("A1").Value)

(まだ「1回目の保存」を完了していない、「Book1」というブックのSheet2のA1セルの値)
※「1回目の保存」の前のExcelファイルには拡張子が付きません。ウィンドウのタイトルバーで、「1回目の保存」の前とあとの表示文言がどう変化するか、確認してみてください。
オブジェクトの階層構造をほぼ省略していないので、本来なら良い書き方になるはずが、でも保存前のときの書き方なので、ほとんど使えない書き方です。
僕もちょっとしたテストや調べものしたいときで、ファイル保存までをする必要も無い、というときくらいしか使いません。

ちなみにですが、「階層構造をほぼ省略していない」と書いてしまいましたが、「Application.」の前に本当は「Excel.」というものが省略されています。
(「Excel.」よりも上の階層は存在しません。「Excel.」が一番上です。)

「Excel.」は「ライブラリ」と呼ばれるもので、オブジェクトブラウザの一番上のドロップダウンリストに出てくるものです。このドロップダウンリストに出てくるものは、(VBAProject以外は)基本、「参照設定=事前バインディング」というものがなされています。「Excel」のほかに「VBA」「Office」などがありますが、それらは全部、それぞれ「Excel」と独立したオブジェクトの階層構造を保有しています。そして、「Excel.」と同じく、各オブジェクト構造の中の「一番上の階層」です。
(なお、「Excel」や「Office」「VBA」などのそれぞれの実体は、EXEやDLLなどの ”ファイル” です。オブジェクトブラウザでそれらをドロップダウンで選べば、下のほうの説明ペインに出てきます。それぞれのファイルの中に、それぞれの階層構造が組み込まれている・・・みたいなイメージです。それが「ライブラリ」です。下図も参照してみてください。)
※オブジェクト変数に代入できるっぽので、「ライブラリ」とは言うものの、「オブジェクトの一種」のような気もします。


「Excel.」は複数のファイルを同時に扱うときによく使います。
が、ただ、そのときは(おすすめはしませんが)省略してもエラーにはなりません。でも「Excel.」が省略されている、ということは必ず覚えておく必要があります。「参照設定」がなされている場合・かつ・「他のファイル」がWordのファイルの場合、「Excel.」と同じように「Word.」を使いますので。
僕は複数のファイルを同時に扱う場合は、「Word.」や「Excel.」はプログラムの冒頭部分だけですが、必ず書くようにしています。そのほうが可読性がよくなって、メンテもラクなので・・・。(ExcelVBA初心者ですから特に。)
  
  
※「Item」について
Itemプロパティ(あるいはメソッド)は、「コレクション(=コレクションオブジェクト)」なら、「基本的に、どのコレクションも保持・保有・内包」しているプロパティ(あるいはメソッド)です。
逆に言ったら、単一オブジェクトはItemプロパティ(あるいはメソッド)を保持していませんので、そういうものは「単一オブジェクト」、となります。
なお、「Item」には、「Itemプロパティだけでなく、「Itemメソッド」もあります(例えば、「PivotTables.Item メソッド」など。)
深いところは意味が違うようですが、似た動作をします。
つまり、コレクションから単一のオブジェクトを返してくれます。
そのため、オブジェクトブラウザにて、「Item」で、完全一致で検索すると、出てくるオブジェクト(=クラス)は、すべて、コレクションです。
コレクションの一覧を見たかったら、オブジェクトブラウザで「Item」で検索すればOK、ということになります。「Itemプロパティ」や「Itemメソッド」を保持したコレクションオブジェクトたちが、ずら~っと並びます。

なお、Worksheet(ワークシート)のコレクションは「WorkSheets」、WorkBook(ブック)のコレクションは「Workbooks」と、大抵コレクションは「s」のついた複数形がほとんどです。稀に、単純に「s」がつかず、「・・is」が「es」になったり「・・・y」が「ies」になっているものもあります。

ちなみにですが、「Range」オブジェクトは「Item」プロパティを持っていますので、「複数のセルを保有するコレクションオブジェクト」と言ってもいいのかもしれません。(厳密には違うかもですが、そう考えるほうが色んな場面・Rangeの動きなどを見ても納得できます。)
その証拠(?)に、Rangeオブジェクトに対しては「For Each」文が使えます。
「For Each」文は配列かコレクションオブジェクトに対してしか使えないので。
「Cells」はコレクションじゃないので私たち初心者にとっては紛らわしいのですが・・・。
「セル」のコレクションが「Range」で、
「Range」(セル範囲)のコレクションが「Ranges」(セル範囲たち)・・・という感じになっています。

あと、「Item」はプロパティもメソッドも、基本、その記述を省略できます。
つまり、
正式には「WorkSheets.Item("Sheet1")」であっても、
実際には「WorkSheets("Sheet1")」と書いても同じ、
ということです。
僕も省略して書きます。
ただし、省略するとエラーになるような場合もあるかもしれないので、エラーになったらエラーの原因をつぶすために、一時的にItemを書いたりすることもあります。

最後に、Itemプロパティも、それ以外のプロパティもそうですが、引数を指定できるプロパティは、メソッドと同じように、名前付き引数としても指定できるようです。

Range("A1:C3").Item(1,1).Value

Range("A1:C3").Item(RowIndex:=1,ColumnIndex:=1).Value
とも書けます。

Activesheet.PivotTables.Item(1).name

Activesheet.PivotTables.Item(index:=1).name
とも書けます。
  
  
  
  
Application.Workbooks("Book1.xlsx").Worksheets("Sheet2").Range("A1").Value
(=Application.Workbooks.Item("Book1.xlsx").Worksheets.Item("Sheet2").Range("A1").Value

(1回目の保存を完了した「Book1.xlsx」というブックのSheet2のA1セルの値)

※「Item」については前項参照してください。

前項と同様、「一番先頭」に、「Excel.」と書くのを省略してます。
長ったらしい書き方ですけど「オブジェクトの階層構造」をほぼ省略していないので、例えば、

・Excelファイル(=ブック)が1つだけ開かれている場合や、
・反面、ブックが複数開かれている場合、
・そのほか、操作したいブックやシートがアクティブじゃない場合、

・・・等々、いろんなシーン・ケースを考えた場合、どのシーン・ケースでも、最もエラーや挙動不審・誤作動の「出にくい」書き方です。(「出ない」ではなく「出にくい」です。基本、シートやブックの名前が変わってしまうとダメですし。変えてしまった場合はちゃんとエラーか挙動不審・誤作動になります。それをできるだけ回避するには、「ブックの保護」の機能で、シートのタブでの名前変更や順序入れ替えなどを禁止すればOKかもしれません。未確認です。すみません。)

この書き方は、長ったらしくて面倒な書き方ですけど、
でもこれこそが、Excelに限らず、「VBA」でのオブジェクト式やコードの書き方の「基礎」「原則」です。
つまり、「オブジェクトの階層構造を省略しない」という書き方が、Excelに限らず「VBAのオブジェクト操作における原則・本当の基礎・スタート地点」、なのです。
(そして、もし短く書きたかったら「オブジェクト変数」を使います。)

基本、VBAのオブジェクト操作は、「オブジェクトの階層構造ありき」なのです。

ヘルプもオブジェクトブラウザも、各種命令も、全部、その前提で、そのルールの上に成り立っています。

つまり、それを意識しないと、ヘルプもオブジェクトブラウザも扱えず、エラーの自力解決なんて夢のまた夢です。

ヘルプなどはその前提ですべて書かれているので、階層構造を理解していない人は絶対に意味がわかりません。(ついでに言うと、値やオブジェクトを返す自作関数のことを理解できていない人もヘルプとオブジェクトブラウザは絶対に理解できません。)

「たかが階層構造」、ではないのです。

「階層構造こそすべて」と言ってもいいくらい、階層構造は重要です。
オブジェクト(オブジェクト式)のオブジェクト変数への代入後にもついてまわります。
(なのにそう教えてくれる講師が少なすぎます。)

「オブジェクトの階層構造を省略しない書き方」の、その「意味・意義」を理解しようとせず、ここをテキトーに済ませてスルーする人は、いつまでたっても、どれだけセミナーでお金を払っても、ExcelVBAが上達しません。

他の書き方は、この書き方を「省略」したり、(他の単語を使って)少し変形させた書き方となっています。

でも『 省略や変形を増やせば増やすほど意味が変わってしまい、エラーや誤作動も出やすくなる 』ということは、”最初にまとめては教えない・わざと小出しに教えてわざと困惑させたりあえて分かりにくくさせる” のがレジェンドさん達のやり方です。
大変無礼で申し訳ございませんが、「わざと根本を教えずに枝葉のことばかり教えて、わざと困惑させて、わざとわかりにくくさせて、で、ご自分の有料サービスに誘導しているのでは?」と勘繰りたくさえなるほどです。
今では恐らくほとんどの教室がそんなダメな教え方に右に倣えのバカ講師ばっかりで、教育レベルが大変に低いと推測できます。
多分かなり高い確率で「当たり」です。
その証拠に、Q&AサイトのVBAに関する質問が20年前から一向にレベルアップしていないですし、独学でVBAに挫折する人の数も多分減っていませんし、何より、『VBA初心者向けの書籍の内容が全然進歩していません。』
あんな内容では、『本を読んですぐにある程度のことがわかる・VBAが扱える』人は非常にすくないし、エラーの自力解決・・・というよりも、「そもそも解決のための情報の探し方がわからない」という初心者が増えるだけです。
そして事実、「現実に、そうなっています」。
そういう挫折者・独学者が多すぎます。
その理由は、バカ講師たちが、「何よりも重要な階層構造のこと」や「変数のこと」や「値やオブジェクトを返す関数」のことを、ぜんぜん、教えないからです。
「日本の未来」「子供たちやお若い方々の未来」「国益」などこれっぽっちも考えず、「レベルの低い内容でお金を取ってラクして儲けようとしている」のではないか?とこれも勘繰りたくなってしまいます。
こんなことでは、これからも、ExcelVBAの教育は、お先真っ暗だなあと思います。
ExcelVBAの教育どころか、バカ講師たちは、「データ管理の基礎」も教えないので、そちらもお先真っ暗で、日本の「各現場単位でのデータ管理の状況」は本当に暗澹たるものだと思います。

そもそも、「省略」とは「意味がわかっている人」がやることが「省略」であって、「意味がわかってない人」がやるのは「単なる手抜き・いい迷惑」、「頼むから俺には近づくな」」、「頼むから会社のみんなの共有データには近づくな」です。
意味もわからず「省略」あるいは変形をすれば、「バグやエラーの温床」にもなります。
そして「エラーが多い」ことは、「挫折」の原因、「中級へ上がれない」原因にもなります。
(つまり、初心者が、「エラーが多くて挫折が多い」のは、全部、レジェンドさんたちやバカ講師さんたちが「テキトー」にしか教えないから。それが原因のすべて。)

なのに「そんな風になってしまう方法」=後述する「 Range("A1").Value という書き方」ばかりを、「あえて」「最初から」教えて、「 ” 省略や変形のデメリット ” の但し書きもしない」方法が、レジェンドさん達やバカ講師たちの教え方です。

そしてそれを何の疑いもなく、「そのほうが最初はいいから」「レジェンドさんたちがそう言うんだからとりあえずそれでいいでしょ?」という理由・決めつけだけで、あるいは、テキトーで都合のいい理由を口実にして、自分の「頭」で「生徒さんのこと」を考えようとせず、ただ右に倣えでマネするだけの、もちろん但し書きなんかするわけもなく、「思考停止したバカで質の低い講師たち」がどんどん増えています。

20年もあれば、Webで検索した時に「オブジェクト式の書き方やその省略とエラーの関係」とか「Variant型の変数とエラーの関係」とか、「ヘルプの読み方」とか、そういうサイトやWebページがGoogleのトップページにヒットしないといけないのに、出てきたためしがありません。
「オブジェクト式の書き方とエラーの関係」「よくあるエラーの一覧・どこをチェックすべきか?何を学ばないと解決できないか?」の一覧や本なんて、20年もあれば、だれか作れただろうから、作っとけばいいのに・・・、と思ってしまいます。
もしかしてバカなのかしら?少なくともまとも教える気は無いんだろうなあー。
と、大変無礼とはわかってはいますが、でも、「習う側」としては正直な感想です。

初心者には、「最初は意味がわからなくてもいいので、でも、今は詳しくはやらないけど概要だけ言っておくから絶対忘れないで!と前置きしながら、重要度やナメないこと、難しくなくてもメッチャ簡単でもないこと、でもメッチャ簡単ではないからこそ私たちが導くから安心してとか、目標・どこまで理解しないといけないか?、真実」など、を与えるべきです。

「プログラマになるわけじゃないんだから」という理由で「変数なんか全部Variant型でいいじゃん(でもローカルウィンドウも何も教えない))」というようなテキトーな絆創膏プログラミングを教える、「教科書」を名乗るような書籍とかもありますが、そんな腐った本が出るようになってしまったからこそ、「最初からの詳しい説明」や但し書きは必要だと思います。
長ったらしい書き方で面倒だからこそ逆に、そこで『 オブジェクト変数やオブジェクトのこと・オブジェクト変数を使って短く書くこと 』等々をしっかりと教えればいいのに、それもしません。
オブジェクト変数への代入の場合、一般的な変数の場合の「生データ(ほぼリテラル値)」に相当するものは「オブジェクト式」だ、ということすら教えません。
そしてオブジェクト式をそのまま(変数に代入せずに生のまま)使う方法ばっかり教えます。
オブジェクト変数への代入の重要性も教えないもんだから、オブジェクトを返す自作関数なんて全く作れずに、そのため、ヘルプも読めずにオブジェクトブラウザも扱えません。「初級」の「下か中」の位置にずーっと居たままです。「初級の上」の位置にも上がれません。
エラーが出ないようにする方法なんて最初に言って欲しい、とあとから思わされます。

この書き方は、ある意味「絶対的な」書き方・・・という感じです。(それに対して、基本、あまり使わないほうが良い「ActiveSheet」や「ActiveCell」などを使った「相対的な感じの書き方」もあります。)
なお、「.Value」よりも前の「オブジェクト式」を短く書くには「オブジェクト変数」を使い、それに代入します。
(「With」を使うこともできますが、僕は、「With」にまだ慣れてなくて、コードが汚く見えて読みにくくなるため、滅多に使いません。)
(※「オブジェクト変数を使う」というのは一応「原則」です。例えばAccessなどではオブジェクト変数を使うことで原因不明のエラーになる、などのトラブルを僕自身・経験したことがありますが、そのような場合はもちろん原因が判明するまではオブジェクト変数を使いません。Withも、使って全然OKです。ただ、そいうとき以外は原則は守ったほうがエラーや誤作動は間違いなく減ります。)

なお、シートやセルの操作ではなく、ユーザーフォームやその部品(「コントロール」と呼びます)の場合は、Excelとは独立したオブジェクトの階層構造となりますが、こちらでもおおむね同じことが言えると思います。
もちろん、ユーザーフォームにはセルはありませんが、セルを『ユーザーフォームやその部品(=コントロール)』と見立てれば、やはりここでも、階層構造を省略しない書き方が基本で、短く書きたいなら省略やWithを使うよりもオブジェクト変数を使うことが原則です。
ADOやDAOと呼ばれる便利な機能たちも、Excelと独立したオブジェクトの階層構造を持っていますが、考え方・原則は同じです。

ちなみにですが、「Value」プロパティも(例えば2010の場合は)本当は「RangeValueDataType」という「引数」を持っていて、「Value」だけだと「省略した書き方」です(Range.Valueプロパティの2010のヘルプページに書いてあります)。省略によりどんな不都合が起こるか僕にはわかりません。
(※引数がある・ないは、バージョンによっても違うようです。バージョン2000の「Value」プロパティには引数は無いみたいです。ヘルプにも書いてありませんでしたし、ローカルウィンドウにもValueとValue2がちゃんと表示されます。)

なのでこの「書き方」は、「もっともエラーや挙動不審・誤作動が」、「出ない」ではなくて、「出にくいもののひとつ」、とお伝えさせて頂きました。

更にちなみにでですが、「引数」を持っているプロパティは、その値は「ローカルウィンドウ」には表示(リストアップ)されないそうです。
なので、「Value」もリストアップされません。
「value2」は引数を持ってないので表示されます。
(※ここでは2010を想定しています。前述のとおり、バージョン2000では引数を持たないらしく、「Value」もリストアップされます。2003や2007もどのようになるか、テストしてませんのでご自分でもチェックしてみてください。)
  
  
  
  
Workbooks("Book1.xlsx").Worksheets("Sheet2").Range("A1").Value
(=Workbooks.Item("Book1.xlsx").Worksheets.Item("Sheet2").Range("A1").Value)

(1回目の保存を完了した「Book1.xlsx」というブックのSheet2のA1セルの値)
前項の書き方の「Application.」だけを省略した書き方です。
こちらも長ったらしい書き方ですけど、かなりエラーの出にくい書き方です。
「Application.」だけは省略しても、「どの想定シーン・ケースでもまずエラーにならない」ので。
ExcelファイルやWordファイルを同時に複数扱うようなときは「Application.」自体や「Excel.Application.」「Word.Application.」自体をオブジェクト変数に代入してしまうことが多いですが、その場合は、その『 ××××.Application が代入されたオブジェクト変数 』を省略すると、ちゃんとエラーになることが多いですから逆に省略できません。
以降同上。

僕は、この書き方を一番使います。
特に本番では。
  
  
  
  
Worksheets("Sheet2").Range("A1").Value
(=ActiveWorkBook.Worksheets("Sheet2").Range("A1").Value
 =ActiveWorkBook.Worksheets.Item("sheet2").Range("A1").Value)

(アクティブなブックのSheet2のA1セルの値。)
この書き方は、ちょいちょいエラーや挙動不審・誤作動が出ます。
例えばブックが2つ以上同時に開いていた場合は、目的のブックのA1セルの値じゃないこともあります。例えば「Book1」のほかに「Book2」も開いていた場合、もし「Book2」のほうがアクティブだと、間違ってそちらのブックのSheet2のA1セルの値を取得してしまいます。
なので(転記の処理を自動化をしたい等々で)、複数のブックを開いていたときなどに、むやみにこの書き方を使うと、ちょいちょいエラーや挙動不審・誤作動が出ます。ご注意ください。
1つのファイルだけを処理する場合はもちろんこれでもいいですが、大抵はあとになって 作り変えや作り足しの要望が出て、「2つめ以降の他のExcelファイルも同時に開く処理を追加する」ということも多いので、そのような時をあらかじめ想定して、できるだけ「Workbooks(××××).」は省略しないほうが無難です。
短く書きたかったら、オブジェクト変数を使います。

なお、この書き方は、後述する「Workbooks(1).Worksheets("Sheet2").Range("A1").Value」
(=Workbooks.Item(1).Worksheets.Item("sheet2").Range("A1").Value)
というような「Workbooks(1).・・・」という書き方と違って、Personal.xlsb(or xls)つまり、「個人用マクロブック」が自動生成されてしまったとしても、「ActiveWorkBook.Worksheets("Sheet2").」と書いたり、「Worksheets("Sheet2").」とBookの部分を省略して書いても、エラーにはならないことはならないです。

ブックが1つだけしか開いていない場合、「ActiveWorkBookの使用やBookの指定の省略」をしたときは、「今開いているブックを指定した」と自動的にみなされるからです。
つまり、「個人用マクロブック=Personal.xlsb(or xls)」の存在は基本、無視されるようです。
しかし、それはあくまでも、ブックが1つしか開いていない場合だけです。
2つ以上のブックを同時に開いたときは、エラーになりやすいので僕はあまり使いません。

なお、複数のブックのうち、どれが「1回目の保存が完了しているか」はこの場合は無関係です。
  
  
  
  
Range("A1").Value
(=ActiveWorkBook.ActiveSheet.Range("A1").Value)

(アクティブなブックのアクティブなシートの、A1セルの値。)
この書き方は、ここまで書いてきた中ではもっともエラーや挙動不審・誤作動が出やすいです。
前項の書き方と同様、ブックが2つ以上同時に開いていた場合は目的のブックのA1セルの値じゃないことも多いです。例えば「Book1のSheet2のA1セルの値を取得したい」という場合、基本、「目的のブック」の「Sheet2」までも、が、アクティブになってないと正しい値が取得できません。つまり、もし目的のブックがアクティブだったとしても、「Sheet2」ではなくて「Sheet1のほうがアクティブだった場合」は、間違って「Sheet1」のA1セルの値を取得してしまい「Sheet2」のA1セルの値は取得できません。
その際、もし「Sheet1」のA1セルの値が空白だったら、そのせいで何らかのプログラムがエラーになる場合もあります。
結局のところ、いろんなシーン・ケースを想定した場合、ここまで書いてきた中ではもっともエラーや挙動不審・誤作動が出やすい書き方です。
なぜそうなるかは、実際にたくさんプログラムを書いたり、テストを繰り返すとわかります(失敗してほしくないので、ここでは使用をおススメしていませんが)。
テスト方法は先生や先輩に聞けば教えてくれます。
僕の場合はこの書き方は、
「テスト用」
「値や構造を調べたい時だけ」
「Webに載せるサンプル作成」
「自分しか使わない他人は絶対に使わないすぐ捨てるプログラム」のときに使うことが多い書き方です。
「お仕事としての本番」では使うことは基本、あまりありません。
特に「他人も使うプログラム」の時は使用頻度が落ちます。ほとんど使わないかも・・・。
なお、この書き方の場合も、複数のブックのうち「どれが1回目の保存が完了しているか」は無関係です。
  
  
  
  
Application.Workbooks(1).Worksheets(2).Range("A1").Value
 =Workbooks(1).Worksheets(2).Range("A1").Value
 =Workbooks.Item(1).Worksheets.Item(2).Range("A1").Value

(1つめのブックの左から2つめのシートのA1セルの値)

この書き方は、ブックやシートを、「Nameプロパティの値(俗名)」ではなく、「インデックス番号」で指定していくやりかたです。

基本、まず使いません。

この方法は、どのブックやシートが(1)になったり、(2)になったりするかわからないので、エラーや誤作動が多いから、です。(特に作り変えや作り足しをしたとき)

オブジェクトの階層構造をほぼ省略していないので、本来なら良い書き方になるはずですが、そのようなエラー・不都合が多いので、実務ではほとんど使えない書き方です。

何らかのテストをするときや「どうしてもやむを得ない時」くらいしか使いません。

例えば、「新規作成」として開いたブックは、もし「個人用マクロブック=Personal.xlsb(or xls)」が生成されていなければ「Workbooks(1).」という書き方で特定できます。
が、しかし、個人用マクロブックが、「マクロの記録」機能を使って自動生成されたり、手動で設置された瞬間から、次回以降は、「新規作成」したブックは「Workbooks(1).」ではなく「Workbooks(2).」になってしまいます。
次回以降は「新規作成したExcelファイルは、” 必ずWorkbooks(2)になる ” 」のです。

もちろん、「新規ファイル」だけなく、既存のファイルも同じで、個人用マクロブックが無ければ、一番最初に開いたブックは「Workbooks(1)」で、そのままの状態で追加で2番目に開いたBookは「Workbooks(2)」となります。
個人用マクロブックがあれば、一番最初に開いたブックは「Workbooks(2)」で、そのままの状態で追加で2番目に開いたBookは「Workbooks(3)」となります。
ただ、既存のファイルでも逆の順序で開けば、「Workbooks(2)」や「Workbooks(3)」はその内容が入れ替わってもしまいます。(だからブックの指定自体が、仕組みを良くわかっていなければメチャクチャになってしまいます。)

シートについても、例えば「Sheet2」をドラッグで一番左に入れ替えてしまうと、「Worksheets(2)」ではなくなります。
「Worksheets(1)」と書き換えないといけなくなってしまいます。
ドラッグで入れ替えた瞬間から「Worksheets(2)」は他のシートになってしまいます。
そのことを知らないとエラーだらけになります。

だから、使いません。

どうしても使いたい場合は、シートを動かしたりリネームしたりができないように「ブックの保護」をかけるなどをします。(もちろん、それでは、「Workbooks(×××).」のほうの問題は何も解決できませんが。)

あるいは、「ブックの保護をかけたくない」という場合は、「1つだけのファイルしか絶対に開かない」、という「ケース限定」での処置であれば、その場合に限っては、例えば代わりに次項の「VBAProject.Sheet2.Range("A1").Value」や「Sheet2.Range("A1").Value」を使ってもOKです。
(※もちろん、一番長い書き方をしてブック保護するかタブを非表示にするほうがより安全です。)

あ、今思い出しましたけど、そのような利用シーン以外の利用シーンもあるにはありますね・・・。

それは例えば、「データ管理の世界標準の基礎(複式簿記と同じくらい有名)」を知らない人・使えない人が、「データを大量のフォルダごと(取引先ごととか)に分割して保管してしまっているような場合や、同じフォーマットの請求書のシート(でもシート名はぐっちゃぐちゃとか)を作ってしまっている場合とか、そういった場合に、それらのデータを一気にループ処理でまとめあげたりするときにはよく使ったりするかもしれません。
ただ、VBA講師たちは、そういう「無駄なデータ管理の手法にまったく無頓着」な人も多いので、「取引先データの場合は、そもそもフォルダごとに取引先ごとに分ける行為 自体が、原則としては ” 無駄・かつ・超非効率データ管理手法 ” です。 だからできるだけやめましょうね?」と教えてもらえないのです。
書籍を出している人も出していない人もそういうことを教えない講師たちばっかりで、その責任は重いです。
正直、彼らが、「日本のデータ管理」を軽く10年は遅らせたと思います。

だから「僕ら習う側」が知らなくても仕方なく、基本、講師たちの怠慢です。

だから無駄なVBAや無駄な関数が増える。
「数十もの取引先のフォルダのや売り上げのフォルダのデータをまとめるプログラム」だなんて、「データ管理の基礎(SQLやMicrosoftQueryやピボットなど)」からしっかり教えていれば、もともとフォルダごとに分ける必要なんてないわけですから、もともと書く必要のない無駄なプログラムなのです。(ExcelVBA講師たちがテキトーなことしか言ってないので、僕もテキトーなことを言っています。)

僕は「データ管理の世界標準の基礎(複式簿記と同じくらい有名)」を守っているので、そいういう無駄なデータ管理の方法は モトからしなくなりましたからそういう無駄なVBAは使わずにいられるのでその意味ではまだラクです。

なお、前述しましたが、「ActiveWorkbookの使用やBookの指定の省略」をした場合は、「個人用マクロブック=Personal.xlsb(or xls)」の存在は無視されるようですので、前述したような個人用マクロブックがらみのエラーは出ません。

といって、「ActiveWorkbookの使用やBookの指定の省略」自体も、「2つ以上のブックを同時に開いたりして行う処理(例えば転記処理)」ではエラーが出やすいのでおススメはしません。

あと、この書き方の場合も、複数のブックのうち「どれが1回目の保存が完了しているか」は無関係です。

※ちなみにですが、データをお取引先ごとに分けたり・売り上げを月ごとにシートごとにわけたりすること自体は、大変残念ながら、『ダメなデータ管理、データ管理の基礎を無視したやり方』なのですが、そういったことさえ、講師の人たちは教えてくれません。(VBAがあるからとたかをくくって、無駄なことと教えないのです。教えれば「本来空く必要のないVBA」自体の無駄を減らせるのに。)

さらに悪いことに、一部の「教科書」を名乗るVBA関連の愚かな市販書籍には、そんな無駄を自慢げに「すごいだろ」とばかりに教えている本もありますのでご注意ください。

僕は、データ管理の基礎を守らないとあとで面倒くさいことになるから、もとから取引先ごとのフォルダなんて作らないし、データを月ごとにシートに分けたりとかそういう無駄なこともしていないので、なのでそもそも、そういう無駄な処理(たくさんのデータをWorkbooks(1)とかWorkSheets(2)とかを書いてまとめる・転記するような処理)をすることはありません。
みなさんも、取引先のフォルダをわける、とか、売上を月ごとにシートに分ける、というようなことは「本来はデータ管理の基礎を無視した無駄な処置」と、どうか・ぜひ、お知りになっていただき、「リレーショナルデータベース」の基礎を、Excelにて、MicrosoftQueryやこちらのサイト、などで学んでみてください。
業種や職種にもよりますが、無駄なVBAや関数が激減することも少なくないです。

そして、ほとんどのダメ講師たちに「もっとExcelでやれるSQLの話とかリレーショナルデータベースの基礎を教えろ!そしてそれをVBA操作する方法を教えろ!」と言ってやってください。
  
  
  
  
ActiveWorkBook.Worksheets(2).Range("A1").Value
(=ActiveWorkBook.Worksheets.Item(2).Range("A1").Value)
ActiveWorkBook.ActiveSheet.Range("A1").Value

(アクティブなブックやシートのA1セルの値)
これまでの流れからもお分かりになると思いますし、少し前にも書きましたので繰り返しになってしまいますが再度、書かせていただきます。

この書き方も、ブック名やシートを、「Nameプロパティの値(俗名)」で決め打ちしてないので、作り変えや作り足ししたときにエラーになりやすいので、「やむを得ない場合、か、それじゃないとダメという特殊な時」以外は使いません。

「今のこの瞬間での ” ActiveWorkBookやActivesheet ” が何なのか?どのブックやシートなのか?」を判断・分岐させて、それによって色々と動きを変えていくようなプログラムを動かしたい場合とかは使います。
(逆に、そのような判断で、動きを止めたいとか。)

なお、この書き方の場合も、複数のブックのうち「どれが1回目の保存が完了しているか」は無関係です。
  
  
  
  
VBAProject.Sheet2.Range("A1").Value
(=Sheet2.Range("A1").Value)

(CodeNameプロパティの値が「 ” Sheet2 ” 」になっているシートの、A1セルの値。)
これも(「相対的」ではなく)「絶対的な感じ」の、書き方です。
また、エラーや不都合がそこそこは少ない書き方です。

ただし、「複数のブックを同時に開いて転記処理をするようなケース」では「使えない」という感じです。(だから「そこそこ少ない」とお伝えしました。エラーが出ないのは1つのブックしか開いてない時だけです。後述します。)

なので、後述しますが、「あくまでも1つのブックしか開かない」かつ、「どうしてもシートをドラッグで動かしたりリネームしたりしたい場合」以外は、基本、使いません。

普通、シートは、「WorkSheets("Sheet2")」「Worksheets.Item("sheet2")」みたいな感じで、シートの「Nameプロパティの値」で特定することが多いのですが、ここでの書き方のように「CodeNameプロパティの値」を「まんま」で使うことでもシートやブックなどを特定できます。(「Worksheet.Sheet2」みたいに書くのではなく)

たとえばシートの場合は、「Sheet2」とだけ「まんま」で書くことで、「WorkSheets("Sheet2")」を意味します。

このとき、「CodeNameプロパティ」は、「コード名」と呼んだりもします。
「CodeNameプロパティ(=コード名)」とは、VBE(=VBAプログラムを書く画面=VisualBasicEditor)の、プロパティウィンドウの「(オブジェクト名)」の欄にて付ける・書き換えることができる「名前」です。
シートのタブで付ける名前が芸名だとすると、コード名は本名、みたいな感じです。
例えば、「Sheet2.Range("A1").Value」と書いた場合は、Sheet2の「シートのタブ側で付けた名前」を「何に変えようとも」、1回書いた「Sheet2.Range("A1").Value」というプログラムの記述を、ずーっと書き換えずに、Sheet2のA1セルの値を取得できます。

また、「WorkSheets(2).Range("A1").Value」「Worksheets.Item("sheet2")..Range("A1").Value」のような書き方をした場合は、「左から2番目のシートのA1セルの値」という意味になりますが、「Sheet2.Range("A1").Value」とコード名で書くと、これも、シートがどの位置に入れ替わろうが、ちゃんとSheet2のA1セルの値を取得できます。
なお、「VBAProject.ThisWorkbook.Sheets("Sheet2").Range("A1").Value」と書くこともできますが、この場合は、シートのタブの名前を変えてしまうとSheet2は操作できなくなります。

あと、例えば前述した『 プロパティウィンドウの「(オブジェクト名)」の欄 』で、「Sheet2」を「SheetTest02」という名前に変更した場合は、タブで付けた名前にかかわらず、「Sheet2」ではなく、「SheetTest02 とか、VBAProject.SheetTest02」と書き換えないといけなくなります。

ちなみにですが、「VBAProject」はオブジェクトブラウザでも、「VBAProject」として、一番上のドロップダウン(ライブラリの選択ドロップダウン)にてカテゴライズされています。
コード名を使った「Sheet2」という書き方でどんなプロパティやメソッドが使えるかも、そこから分かります。(Sheets("Sheet2")という書き方の場合、つまり、Worksheetオブジェクトと比較してみましたら、コード名を使った「Sheet2」という書き方の場合は、プロパティとメソッドはWorksheetオブジェクトと基本・同じらしく、イベントが全部含まれていませんでした。)

なお、ユーザーフォームやその部品(「コントロール」と呼びます)には、CodeNameプロパティは無いっぽく、「Nameプロパティ=CodeNameプロパティ」みたいな感じになっているようです。なので、ユーザーフォームがらみでは意味がない=使えない、ということになりそうです。

なお、この書き方・このシートの操作方法は、「自ファイル」にしかできません。

といいますか、複数のExcelファイルを開いていた時は、「シートやブックの側がアクティブになっている・なっていないにかかわらず」『 ” VBEのプロジェクトエクスプローラの画面の中 ” で現在アクティブになっているファイル(=プロジェクト)のシートとThisWorkbook 』しか扱えないようです。(NewもCreateObjectもできないようなので)
なので、エラーは出にくいといえばそうなんですが、利用シーンが、「一番長い基本の書き方」よりも限定されてしまいます。
今のところ、調べた限りでは、「複数のファイルを同時に開いて転記処理をするようなケース」では「使えない」という感じです。

※:もしかしたらプロの先生なら切り替え方法をご存知かもしれません。
一応当方でも切り替える方法を見つけられはしましたが、かえってエラーや誤作動が増えそうであまり実用的ではありませんでした。
VBEのモジュールのコードペインをコードペインのCaptionをキーにアクティブにすることで、アクティブなVBAProjectを切り替えられるっぽいです。でも事前にそのコードペインが開かれていることが前提です。一度開いたコードペインは、次回のファイルオープン時も自動的に開かれるようです。
でもそんなことを裏方でやるのもエラーが頻出しそうで諦めました。

よって、この「コード名」を使っての書き方は、「1つのファイルを開いている時だけの」「シート操作やThisWorkbook操作」、「限定」、と言えそうです。

※プロジェクト名を、例えば「VBProject」から「PrjTest01」といった感じで書き換えて「参照設定」すれば、参照設定した側からだけ、「PrjTest01.Sheet2.Range・・・」という形でセルを指定できますが、動きがちょっと変なので、トラブルの原因になりそうなのであまりお勧めの方法ではありません。(参照設定するとそのファイルが絶対に開いてしまうし、また、そのファイルを非表示設定にすると閉じるときにめんどくさいし・・・。)
  
  
  
  
Application.ActiveWindow.ActiveCell.Value
=ActiveWindow.ActiveCell.Value
=ActiveCell.Value
=ActiveCell

(アクティブなウィンドウのアクティブなセルの値)

この書き方も、「もっともエラーや誤作動が出やすい書き方のひとつ」です。
「Range("A1").Value」の書き方よりも出るかもしれません。

「Book1のSheet2のA1セルの値を取得したい」という目的からすると、
アクティブなブックがたまたま「Book1(xls、xlsm、xlsx)」で、
かつ、アクティブなウィンドウのアクティブなシートがたまたま「Sheet2」で、
かつ、たまたまA1セルがアクティブセルだった場合に限り、
この書き方が使えます。

あるいは、ユーザーが手動で、「Book1のウインドウ」の「Sheet2」の「A1セル」を完全にクリックしてからか、もしくはVBAで自動的に、それらを明確に「Select」や「Activate」してからなら使えます。

「ケース限定」なので、基本、エラーや挙動不審・誤作動になりやすいです。
ただし、もちろん、この書き方が便利になるケースもあると思います。

なお、この書き方はユーザーフォームには使えません。
ユーザーフォームにはアクティブセルは無いので・・・。

僕の場合はこの書き方も、
「テスト用」
「値や構造を調べたい時だけ」
「Webに載せるサンプル作成」
「自分しか使わない他人は絶対に使わないすぐ捨てるプログラム」のときに使うことが多い書き方です。

「お仕事としての本番」では、
ActiveCell.CurrentRegion をどうしても使いたい時、
ユーザーにアクティブセルを指定させたい時、
ActiveCellを使うことでなんかのエラーや不具合が回避できる場合、
「今この瞬間の ActiveCell がどのセルなのか?」で条件分岐処理をしたい時、
等々以外は、使うことはあまりありません。
(が、こんなケースは僕の場合はほとんどありません。シュミレーションなどの場合は多いのかも?)

なお、ActiveCellプロパティは、「Worksheet」オブジェクトや「Workbook」オブジェクトには属しません。
つまり、階層構造的に、WorksheetやWorkbookの中には含まれていない=組み込まれていません。

なので、
「ActiveSheet.ActiveCell.・・・」とか、
「Worksheets("Sheet1").ActiveCell・・・」
「Workbooks("Book1.xlsx").ActiveWindow.ActiveCell.・・・」
「ActiveWorkbook.ActiveSheet.ActiveCell.・・・」
などと書いても、全部、エラーになります。(僕もよくやります)

例えば、
「オブジェクトが必要です(そんなオブジェクトにActiveCellは属しとらんから、ちゃんとしたオブジェクト持ってこい!)」とか、
「オブジェクトは、このプロパティまたはメソッドをサポートしていません(あなたが書いたオブジェクトの中には、あなたが書いたプロパティやメソッドはもともと含まれていませんよ?ちゃんとオブジェクトのそもそもの決まりを勉強しなおしてそれを守って書いてください。)」
といった感じのエラーになります。

「ActiveCell」を内包している=保持しているオブジェクトは「ActiveWindow」と「Application」しかないので、
「ActiveWindow.ActiveCell.・・・」と書くか
「Application.ActiveCell.・・・」と書くか
「Application.ActiveWindow.ActiveCell.・・・」と書くか、
全部省略して「ActiveCell.・・・」と書くか、
しかありません。
僕なんかExcel初心者なので、まだしょっちゅう「Worksheets(×××).ActiveCell」と書いてエラーになってしまうのですが、それはExcelの階層構造にはもともと存在しない「ルート」となりますので、当然エラーになりますからご注意ください。

なお、『「ActiveCell」を内包している=保持しているオブジェクトは「ActiveWindow」と「Application」しかない』、ということは、オブジェクトブラウザで「ActiveCell」で完全一致で調べれば、わかります。「Worksheet」や「Workbook」は出てきませんから。そこで、「Worksheet.ActiveCell・・・というルートも存在しない」、と判断できます。

「ActiveCell.・・・」と書くのが一番エラーが少ないと言えばそうですが、にしても、ActiveCellを使うと、「しっかりユーザーがセルを選択するか、Selectメソッドなどで明示的に選択しないと誤作動する」ので怖いですから、僕は「やむを得ない場合・特殊な場合」以外はまったく使いません。

  
  

・・・というわけで、「Book1のSheet2(Sheet1ではなく)のA1セルの値を取得したい」という場合、ざっと思いつくだけでも、以上のような、(オブジェクト式というか)コードの書き方がありますが、ほとんどの教室で最初に教えてもらうのは、「Range("A1").Value」という書き方ですよね?

でも、以上を全部お読みになっていかがでしょうか?
(多少間違いがあるかもしれませんが、おおむねこんな感じです。)

使う気します?

「Range("A1").Value」。

初心者の方は『 書き方としては一番簡単だけど、でも「 ” 実務では ” 一番エラーが出やすい」』、って習いました?
(もしくは初心者向けの書籍に 但し書き、そう書いてありました?)

ファイルが一つだけ開いている場合・かつ・目的のシートがアクティブになっている場合だけなら、「Range("A1").Value」というだけでもいいかもしれませんが、それ以外の場合・・・、たとえば・・・
「複数のファイルを開いてそのファイル間で転記処理などをする」場合は、「Range("A1").Value」という書き方だけしか知らないと「転記ミスだらけ、エラーだらけでグッチャグチャになる可能性がある」・・・・、となんとなくでも想像がつきますよね?

だって、「Range("A1").Value」だけでは、「どのブックのどのシートかは決め打ちできないまま」「たまたまアクティブなシートの」A1セルの値を取得するわけになるんですから・・・。(プログラムの実行中にユーザー側で目的のブックやシートをクリックするなんて不可能ですし。)

そして、「複数のファイルを開いてそのファイル間で転記処理などをする」というケースは、VBAが分かってくればくるほど、増えてくるかもしれません。

もう一回、おたずねします。

「Range("A1").Value」、ばっかりを、使う気します?

階層構造のことは深く学ばなくていい、と、そう感じますか?

「いや、だってBookやSheetの名前を書き足せばいいだけだろ?」というご意見もあるでしょう。
そのとき「じゃあなんでBookやSheetの名前を書き足さないといけないの?なんでBook名やSheet名を指定すんの?」という、その質問にすぐさま答えられますか?

例えば「だって、Excelのオブジェクトモデルの全図でそういう階層構造になってるじゃん。見りゃわかるじゃん。その構造の順序 守らないとエラーになるに決まってんじゃん。マイクロソフトがそういう構造にきめちゃったからしょうがないじゃん。Worksheetオブジェクトが一つ上でWorkbookオブジェクトがそのまた一つ上の階層のオブジェクトでしょ? 見なくたってわかるじゃん。上位のオブジェクトなら多くの場合は、TypeName関数とParentプロパティでイミディエイトで調べれば誰でもすぐわかるじゃん。そんなの。」みたいな風に。

そういう風に数秒で答えられないなら、自力でエラー解決などぜんぜんできません。

「だって本にもそう書いてあるから。」とか、「だってそういう決まりだから。普通みんなそうするじゃん。」と、そいういう答え「だけ」で、「みんながそうするからって理由になる?」ということも考えず、『 結局 よく意味もわからずに逃げていたら 』、いつまでたってもこれまた自力のエラー解決できませんし、いつまでたっても初心者の「下の下」の位置のままです。

そういう人は、VBAで他人のファイルを「絶対に」触らないでください。

VBAを使うなら、絶対に自分のファイルだけにしてください。

他人のファイルをVBAで扱いたいなら、基本的には、「何かを知らなくても ” Webを頼らずに ” 、自分で調べられる術を知っている、だいたいの構造をわかっているからそれができる」というスキルが求められるのです。

それができない人は、VBAで他人のファイルを絶対に触らないでください。

「必ず」「シートを指定忘れ、指定ミス、ブックを指定忘れ、指定ミス」などの、「事故を起こして」、「データをメチャクチャにしてしまいます」から・・・。

こちらも もう一回、聞いちゃいます。
バックアップしてない、かつ、みんなの共用のファイル・データでそれやったらどうなります?

あなたの立場は?

そしてこれまでに書いてきたような「VBAのオブジェクト操作の基礎」をないがしろにしてもいいと感じますか?
講師たちに習う必要などない、というお考えのままですか?
「講師たちが隠している、ウソを教えている、ムダを教えている、肝心なことを教えてくれない」と疑うことは一度もしませんか?

そしていつまでたっても、WebのVBAコードのコピペしかできず、Webには書いてない機能を自分で調べて自分で構築していく、なんてことはできないままでしょう。
で、テキトーなWeb情報をコピペして、どんどんどんどん「エラーの温床」を自分で作り、「自分で自分のクビをしてめていく」ことになってしまうのです。

そのほかにも、『 関数バンバン使う系の ” 愚かな・初心者本の著者 ” がよく書く、” ピボットテーブルは要らない ” という愚かな文章を信じてしまい 』、ピボットテーブルはもちろん、SQLやMicrosoft Queryにも全く目がいかず、本来書かなくてもいい無駄な関数と無駄なVBAをどんどん書く羽目になるのです。( 関数バンバン使う系の愚かな著者がよく、但し書きもせずに ” ピボットテーブルは要らない ” というテキトーなウソを書くことが多いので、僕もしかえしに ” 愚かな彼らから見ればテキトーなこと(でも彼らとは違い・真実) ” を書いています。)

こういうことを、たとえば「変数の型」や「オブジェクト変数」「値やオブジェクトを返す自作関数」などについても、「省略」「省略」「省略」で、ぜんぜん「最初に」「一度に」、「最重要な基礎だよ!!」と、教えてくれなかったのがExcelVBAのレジェンドさんたちの教育方法です。
で、それを、自分の頭で考えないで、マネするだけのバカ講師たちが増殖中です。

ExcelVBAが上達するわけがない、と思いませんか?

もちろん、こういった細かいことは、「エラーが出てから学べばいい」という考え方もあります。

もちろんそれでもOKです。

でも、それならそれで『 今は細かいこと言っても混乱してしまうから敢えて言わないけど、必ず一読だけはして。「Range("A1").Value」だけじゃあ、全然対応できないからね。そのつもりでいて。上達したかったらそれ以外の詳しい書き方ももっともっと学ばないとね!概要をある程度把握できて、VBA全体に慣れて来たらまた詳しく学びましょうね!」と自著に書かないといけないはずです。

「エラーが出るまではこれだけ知っていればいいよ。でもエラーが出たらこのようなことは全部確認しないといけないので、そのとき、また少しずつ、詳しく教えるね。挫折しないように頑張って教えるね。だから、絶対に "これさえ知ってればOK" だなんて手抜きしないでね?」と教えなければなりません。

なのに現実には、「これだけ知っていればOK!ねっ!?簡単でしょ?」と「しか」「言わない」、まったく「但し書き」をしない「最低」な教え方をしているのが実情です。

どうでしょうか?
みなさんはエラーがでたとき、上記のこと全部、ちゃんと教えてもらえてます?

そもそも、
『 最初のうちに、わからなくてもいいから、理由・原因はともかく、現象だけでも・よくあるエラーパターンだけでも、ある程度体系的に全体的に、最初に、教わる 』のと、
『 エラーが出たそのときに。そのエラーのことだけテキトーに、エラーが起こるごとにバラバラに教わり、モレもある 』のと、
どっちがいいですか?(僕は前者の方が幸せだと思ってますけど・・・)

難しいから、最初には教えてもらわないほうがいいですか?

都度、教えてもらえばいいですか?

「ここに全部まとめて書いてあるから、最初のうちはわからないかもしれないけど、エラーの度に、何度でも、ここに戻ってきて何度も読み返してみて。必ずわかるようになるから。」という文書は必要ありませんか?

ちなみにですが「Value」プロパティには「引数」すらあります。
(2003以前は無いみたいです。2000にはありませんでした。)
私たちはそれを「省略」して使っていただけだったのです。
ご存じでしたでしょうか?
そのためか、ローカルウィンドウには値が表示されません。
そんなことも最初に教えてくれません。
あるいは、(敢えて教えてくれないなら)それを示唆すらしてくれません。
「無知」による「省略」=エラーや誤作動のもと。です。

僕はVBAはAccessのVBAから入ったのですが、Accessも似たような状況といえばそうですが、でも、

ExcelVBA教育界ほど

「変数の型なんて全部Variant型でいい」とか、

「オブジェクトもしくは階層構造その他省略だらけ」とか、

「オブジェクトの階層構造すら教えない」とか、

そういったメチャクチャ・かつ・いい加減なことは少ない気がします。
  
  
「ExcelVBAの挫折者が20年も経ったのにぜんぜん減らないわけだ。初級コースの内容もいっこうに上がらないわけだ。教え方が悪いもんなあ・・・。エラー解決なんてこんなんじゃ絶対自力じゃムリだよね?」と感じてしまいます。
「特にエラーの出ない誤作動解決なんて、もっとムリかも!」とも感じてしまいます。

「Accessのほうがオブジェクト構造は簡単で整理されているかも」と思うので、最初は「Excelのオブジェクト構造、難しいなあ」と感じてましたけど、学びが進むうちに、「そうではない」ことが分かってきました。

「オブジェクト構造が難しい」のではなくて、「 ”ほとんど” のサイトや本で教え方が下手くそ」「ぶっちゃけ教える気がまるでない」「テキトーすぎる」ということに、ようやく気が付きました。
VBA初心者を、「テキトーすぎる」ようにわざと教えて、混乱させ、有料セミナーに習いにこさせているのでは?と勘繰りたくなるくらいです。
いずれにしても、「最低限の必要なこと・基礎、を ”わざと教えない” からオブジェクト構造を理解できない・しにくい」んだな、と分かってきました。

ついでなのでここで、「ExcelVBAがいつまでたっても上達しない人」の特徴をあげてみたいと思います。(これは、実際に自分でオブジェクトについて調べてみたり、Q&Aサイトでのやりとりを眺めて見たり、僕自身、他人からの質問に少し教えてみたりして、わかってきたことです。
ちなみに僕は以下の項目のことがわかるようになった時点から、急激にWebで調べる回数が1/10以下くらいに減りました。マクロの記録である程度の骨格がわかれば、あとはヘルプに書いてあるからです。まずは都度、オブジェクトブラウザやヘルプでそのプロパティやメソッドや関数がどんな型のデータを返すかなどから調べるほうが、Webや書籍のテキトーな情報に惑わされることも減り、長い目で見れば早いことがわかってきました。最近はマクロ記録もできるだけ使わずに、ヘルプのみで、ということにも少しずつ挑戦しはじめています。どっかで面倒くさくなってやめるでしょうけど。

では、以下、「ExcelVBAがいつまでたっても上達しない人」の特徴です。
(半分は、ちょっと前の僕自身の姿、でもあります。)

・セルのもともとの挙動(少数計算がらみのエラーやバグの誘発の元凶のひとつ)や、関数は参照渡しがデフォになっていて「省略」がなされていること(これもエラー誘発の原因ひとつ)、また、どの関数やプロパティ・メソッドがどんな値やオブジェクトを返してくるのか・その意味などを教えてもらってない。あるいは学ぼうとしない。=集計や計算のことを「どうでもいい」と思っている。
・小数点第1位すらの小数計算でよく計算間違いするのが「正常」なくらい「コンピュータはバカ」だから「もともと信用ならない機械」。そして、AccessフォームやExcel・Word等のユーザーフォームでも、少数計算ミスや値(型)取得ミスがしばしば起こる。ということを教えてもらってない。あるいは学ぼうとしない。=集計や計算のことを「どうでもいい」と思っている。
・だから、変数の型のことを軽く見て真面目に勉強しようとしない。「全部Vaiant型でいい」と言い出す始末。=集計や計算のことを「どうでもいい」と思っている。
・オブジェクトの階層構造のことすら知らない。
・というか、「 ”階層構造の理解” がどれだけ重要か」すら知らない。
・階層構造をしっかりと、省略もせずに「オブジェクト式」として書けない。
・メソッドもプロパティもイベントも、「すべてオブジェクトに内包される」ということを知らない・理解できない。
・なのでオブジェクトには「上位・下位階層への自由往来機能」「上位下位オブジェクトメンバの流用機能」といった感じの機能があることも理解できない。
・オブジェクトに内包されるものも階層構造も自由往来機能もメンバ流用機能も、すべてわからないのでオブジェクト式が自分の意思でまともに書けない。Web情報のコピペしかできない。
・そのため、オブジェクト変数のこともちゃんと理解できない。
・値を返す/オブジェクトを返す関数が自作できない。
・「値を返す/オブジェクトを返す関数」がどれだけ重要かも知らない。
・関数の引数はByRef(参照渡し)が既定とも知らない。それが原因のエラーや誤作動のことも。
・どこからどうプロシージャをCallできるかを知らない。
・以上のことから、オブジェクトブラウザが使えない。存在意義も当然わからない。
・ヘルプも読めない。
・ローカルウィンドウ、TypeName関数、Parentプロパティ、オブジェクトブラウザ、ヘルプなどを使っての、「プロパティやメソッド、関数、などで返ってくる値やオブジェクトの型は何か?」「上位下位のオブジェクト」などの調べ方が全然わかってないし、「それを調べることの重要性」すら理解していない。

どうでしょう?

でも、これ、「全部、レジェンドさん達が、昔から推奨してきた・かつ・今も推奨していること」です。

・セルのもともとの挙動がおかしい(特に小数)→いいよいいよ、あとで。めったにそんなこと起こらないから
・コンピュータが小数計算に弱い→いいよいいよ、Variant型でDouble型に変換してもらえるから大抵は防げるから。(「すべてのケースで防げる」と「言い切らない」。また、Variant型が速度以外に他のエラーやバグを呼び起こすことはあえて言わない。ExcelでもAccessやWordでも「フォーム」や「戻り値次第」では注意が必要なことを隠している。)
・変数の型のこと→いいよいいよ、全部Vaiantで。
・オブジェクト変数の階層構造→→いいよいいよ、難しいから。2000の一覧図すら見せない。
・階層構造をしっかりと省略せずにオブジェクト式として書く→→→いいよいいよ、難しいから。あとで。あとでといいつつ真面目に教えない。(これなんでかな?お金にならないのかな?)
・メソッドもプロパティもイベントもオブジェクトに内包されることを知る。→→→いいよいいよ、難しいから。あとで。あとでといいつつ真面目に教えない。教えたとしても入り口だけでしっかり教えない。(これなんでかな?お金にならないのかな?)
・オブジェクト変数のこともちゃんと理解する。→→いいよいいよ、難しいから。あとで。あとでといいつつ真面目に教えない。
・値を返す・オブジェクトを返す関数の自作→→いいよいいよ、難しいから。
・「値を返す/オブジェクトを返す関数」が、意味的にどれだけ重要かを学ぶ。→→いいよいいよ、あとで。
・ByRef(参照渡し)が既定と知る。→→いいよいいよ、難しいから。
・どこからどうプロシージャをCallできるかを知る。→→いいよいいよ、難しいから。
・オブジェクトブラウザを使う→→いいよいいよ、難しいから。
・ヘルプを読む→→いいよいいよ、難しいから。
・その他→→ぜんぶ、いいよいいよ、難しいから。

こんな教え方をしてきたのが、ExcelVBAのレジェンドさん達です。
今でもそれをやっています。

「→→いいよいいよ、難しいから。」はいいのですが、「でも絶対 ”これだけ知っていれば大丈夫!” なんてことはないからね!コツコツ、1つずつ、慌てずに学んでいきましょう。知らない基礎が1つあると、それだけで100日は後退する、くらいに思っていてください。(ただ、基礎を真面目に地道に積み重ねればあるとき爆発的に伸びます。)」と「何度も何度も」教えないといけないのにそうしません。

「→→いいよいいよ、難しいから。」と「言いっ放しのまま何もしない」のです。
放置。

「初心者にもわかるようにどう説明したらいいのか」という試行錯誤・チャレンジすらなし。
その証拠に「ExcelVBAのデバッグの専門書」なんて見たことないです。

結局のところ、「→→いいよいいよ、難しいから。」じゃなくて、「いいよいいよ、教えるのが面倒くさいから。もう忘れて。」ということなんだと思います。

「難しい」のは初心者の側の話ではなくて、教える側が「教え方」が「難しい」ということで「逃げっぱなし」になってて、何の工夫もしてない、ってことのようにしか見えません。
プロのくせに、難しいことにチャレンジしようとしない。
20年もあったのに。

そして「情けない」ことに、それを真似する他の講師の人が増えています。
特に、初心者本を立ち読みしたり買ってみるとそう思います。

ひどいと、「Webでサンプルを探せばいくらでも出てくるから」なんて言って、前述で挙げたような「肝心な基礎」を教えることをメッチャ手抜きしています。
Amazonに売ってたKidle版?のExcel本にも多いです。

「日本のExcleVBA教育は終わってるなあ」、
「進化するわけがないなあ」、
「なんだ?これ?ひでえ。子供たちの未来は暗いなあ」、
と落胆しました。

あくまでも、僕自身がExcelVBAの初心者で、その立場からの感想ですけど。