★★★ Access2000VBA・Excel2000VBA独学~巷のほとんどのVBA講師がダメ・バカ・教え方が下手くそな理由(人格が低く、自分の頭で考えてないし、お客様の「コスパ」を考えないから、変化への対応ができない。自分の理論を溺愛していてめくらになり、機能の「業種・職種・TPO別」のコーディネイト・そのバランス修正ができない。)~
  
※まだ書きかけです。すみません。
※間違ってたらすみません。
※メモ書きなので、自分でも意味不明な箇所も多いです。ごめんなさい。
  
  
僕はExceVBAの初心者です。

Excelの一般操作もまともにできません。

関数もほとんど使ったことありません。(今のところ使う必要があまりないので)

で、今、ExcelVBAを勉強中です。

そこで、「習う側」として思うのですが・・・

巷の「ExcelVBA講師」は、「結構バカな人が多い」、と思いました。

「知識的にバカ」という意味だけではなく、「人格的にバカ」、という意味合いも半分あります。

「こんな人たちに習っていたら上達は遅いだろうなあ・・・」とよく思います。

理由は以下の一点のみです。

「極端すぎる」。

もう少し付け加えると・・・、

「自分のよく使う方法しか教えない」
「これさえ知っていれば後は知る必要なし」
「作業の目的を明確化していない」
「自分の理論を溺愛しすぎ」
「これ、どうしても知識的なマウントがしたいらしい」

・・・という教え方しかしてないからです。

例えば、以下のサイト。

GoGo エクセルマクロをはじめよう!の公式Webサイト

一理も二理(?)もありますし、とても丁寧で親切で、挫折しないように、という配慮が満載です。
特に「マクロの記録」を活用しまくっているところが非常に良いですね。
はっきりいって、初心者の方はまずはここから初めて、そのあと、「巷の初心者本」を読んでもとっても良いのでは?、と思いました。
「なるほど!」と唸らされもします。
僕も、これから利用させていただきたいと思います。
「とっても価値の高いサイト」の一つであると感じます。

少なくとも、「某超大物ExcelVBAレジェンドさん」の期待外れの腐った「マクロの記録」の関連本よりは100倍良いです。

僕も、「マクロの記録」機能が大好きなので。
「あれを実務に活用できない講師のほうがバカ。実務のコスパを考えないバカ。」と思っています。

かなり冗長なコードが記録されることは確かに事実ですが、でもそれ以上の実務上のメリットが多いのに、「マクロの記録」を馬鹿にするVBA講師が多すぎます。

愚かなVBA講師たちには、「この機能の ” 強み ” を ” 生かす ” 使いかた」という思考回路はなく「俺がいつもよく使う方法がいいにきまってるだろ?」ということばっかりを教えます。
だからQ&Aサイトでもそれをマネするバカが減りません。

ただ、残念なのは、この『GoGo エクセルマクロをはじめよう!の公式Webサイト』も、「極端すぎる」面もあるにはあると思います。

・変数設定なんていらない。
・オブジェクト、プロパティ、なんておぼえなくていい。

などの極端すぎる記述が意外にも目立ちます。

僕はこのサイトを、「ExcelVBAのレジェンドさん」たちやその関連団体のサイトよりははるかに良い、と高く評価しています。
『 プログラマになるわけじゃない人、小さな組織、の ” コスパ ” 』というものがよく考えられているからです。(そういうサイトや書籍はすごく少ないです。VBAでなんでもできると無駄な方法でもなんでもいいから教え、教えっぱなしで、VBAコードの管理費のコストアップについては知らぬ存ぜぬです。そんなやり口の、データの持ち方やSQLなどを教えない・「コスパ」を考えられない「バカ講師」が日本には多すぎます。Excelを使う大きな目的の一つは「集計やリストアップ~複数の条件での」なのにですよ?なのにSQLの「存在」すら教えない。SQLがExcelVBAで扱えることも教えない。ほんとバカ講師ばっかり。高度なSQLを教えなくても、MicrosoftQueryの使い方や簡単なリレーションくらいは教えるべきなのに。それが既存のテクニックやワークシート関数などとの合わせ技に加わるだけでもコスパが全然違うのに。それしないで無駄な関数やVBAばっかり教えてる。しかもヘルプの読み方やオブジェクトブラウザの使い方・オブジェクトモデルの一覧図などの「核心」は教えない。なお、このサイトはSQLを教えないかわりに、ちゃんと、「マクロの記録」のことを利用して「パソコンをやたら使う人」「じゃない人」の「コスパ」をもちゃんと考えてくれています。)

繰り返しになりますが、少なくとも、某VBAレジェンドさんの期待外れの腐った「マクロの記録」の関連本よりは100倍良いです。

でも、それでも、「言い方が極端すぎる」とも思います。

とーってもいいサイトなのに、このサイトの主宰者のような方ですらマウントしたいのかしら・・・?と少し残念になってしまいました。

ちなみにですが、このサイトは、あくまでも、「プログラマなどになるわけではない、一般的な営業や事務の方、あるいはお年寄りのかたがた」、などが、「限られた状況の中で少しVBAを使う」という目的しか達成できません。
主宰者の方は、「高度なマクロが組める」とうたってはいますが、この内容ではさすがにちょっと無理があります。
主宰者の方は、「高度なマクロが組める」ではなく「初心者レベルの内容はほとんどこれでOK」とうたうべきだと思います。

このサイトの内容では、たとえば「SQL」でできるようなことまでが、できるわけではありません。
また、「SQL」でできることが、全部が全部、「高度」というわけではないので、ということは「高度じゃないことも」このサイトの方法では実現できない、ということになります。
ゲームプログラミングもできませんし、ガントチャートもショボいものしか作れません。
グラフやピボットやQueryTableオブジェクトのVBA操作による「そこそこ高度な見える化」もできません。
ゴールドディスク(レッスン全集CD:69,000円)なるものを買えばわかりませんが・・・。でも各テーマのタイトルを見ると、高度な集計やリストアップが簡単には意外とできなさそうな・・・。ただ、「自動集計の基礎(その1) 」というところがあるので、そのへんでリスト形式の表のこととかSQLなどについても触れられているかもしれません。)

「プログラマなどになるわけではない、一般的な営業や事務の方、あるいはお年寄り限定」ともうたっていません。

そのため、逆に「プログラマ」になりたい人がこのサイトを信じすぎると、大変残念ながら「実務で迷惑ばっかりかけるプログラマ」に仕立てあげられてしまいます。
本当にそれでよいのか・・・?
(さすがに、プログラマになりたいひとには、変数やオブジェクトの知識は必要なので。それに、プログラマになりたいひとは「Excelしか使わない」なんて状況も少ないでしょうし。Accessとかも使うでしょうし。たとえば事務系データの「入力フォーム」に、Excelのユーザーフォームでやろうとしてしまい・Accessフォームを検討しないと、コストが10倍から20倍以上、に跳ね上がります。つまり、コスパが10倍~20倍以上悪くなります。僕は50倍は悪くなると思っています。なので、事務系の定番的な入力フォームを作りたいときは、僕は基本・Excelは使いません。小さな組織の定型事務ではAccessとExcelのCOMオートメーションでの連携利用が一番低コスト・高コスパなので。全部を一つのソフトでまかなおうなんてそれバカのすることです。その意味で、Excel以外の他の言語も、もちろん使うでしょうし。)

だから、このサイトのトップページには『 当サイトは、プログラマになりたい人にとっては考え方が偏ってますし、「マイクロソフトは間違った動きをするソフトは作らない」という前提なので、なので、プログラマになりたい人は読まないでください。 』と、ウソ偽りなく、しっかりと謳うべきです。

ほとんどすべての「講師サイト」で、こういう「正直な」但し書きが付いていません。
そのため、そのようなサイトのことを信じすぎると、「簡単に信用すると必ずハマる」「すべての業種・職種・TPOにあてはまるわけじゃないので、必ず、ハマる」ということが起こります。

そしてこのサイトでは、

・コンピュータというものは、そもそもが「場合によっては、基本、小数計算を、小数点第1位の簡単な計算でも間違える」「信用できない機械」だ
・マイクロソフトはよく勝手な「仕様変更」ってやつをする(Excelのバージョン間でも異なる動きをする・変わる)
・小数については、セルが絶対に正しい動きをするわけではない
・VBAとセルの小数計算に関する動きは異なる
・関数やメソッド・プロパティなどの戻り値の型によってはおかしな動きになる
・ユーザーフォームのテキストボックスのデータは、それが「半角の数字」であっても、データ型をきちんと指定しなければ「数値」ではなく「文字列」として扱われる(足し算すると「文字の結合・連結」になってしまう。)

などの「そもそもExcelの動き自体が完璧じゃないから信じ切ったら痛い目を見る」という視点がありません。
「Excelが不完全な故、もっと言えば、講師たちがネタを隠している・あるいはバグを知らないがゆえ・そのための前もっての用心としての変数宣言もある・・・」、ということも「アリなんだ」ということを教えません。

「Excelやマイクロソフトが ” 正しい ” ・ ” 間違った動きはしない ” と信じ切ってしまうような誤った視点」で書かれています。

再度、繰り返しになりますが、だから、このサイトのトップページには『 当サイトは、プログラマになりたい人にとっては考え方が偏ってますし、「マイクロソフトは間違った動きをするソフトは作らない」という前提なので、なので、プログラマになりたい人は読まないでください。 』と、ウソ偽りなく、しっかりと謳うべきです。(とっても、すごく良いサイトだと思うのであえて書かせていただいてしまいました。ご愛読者の方には本当にすみません。)

そもそも、

「Excelを使う目的は何ですか?」

集計ですか?
条件別集計?
条件別リストアップ?
グラフですか?
見える化?
何の見える化?
数字?グラフ?
グラフを作る前の見える化?
シュミレーション?
図形の管理?
写真の管理?
データの共有?
ガントチャート(工程表)や、予定表の作成?
統計?
ゲーム作成?

Excelじゃなくてもいいんじゃない?

そもそも、もし、目的が「集計」「複数の条件での集計」「リストアップ」なのでしたら、「そもそも」「VBAやワークシート関数 ” だけ ” を使うこと自体がバカ」です。
イコール、そもそも 目的が「集計」「複数の条件での集計」「リストアップ」なのに、「VBAやワークシート関数」しか教えない講師は「バカ講師。」です。
SQLを併用することで「集計やリストアップをするための」職場のデータ管理のコスパが「最低10倍はアップする」のに、そしてSQLのほうが「VBAよりも10倍入りやすい」のに(中高生でも取り組めるのに)、なおかつ、SQLとVBAは併用できて、SQLもVBAで自動化できる、実務上何らかの理由でExcelでSQLの使用を実現できなかったとしても(例えば許可されなかったりですとか)、Accessその他のソフトでは利用できるのでその事前勉強にもなって一石二鳥なこと、英語や複式簿記と同じくらいの価値がある、それを「知ってて教えない」のです。
(実際、SQLは、高校でも商業科の情報の授業などで教えられています。)
そして、SQLのほかに、MicrosoftQuery+ピボットテーブルもVBAやワークシート関数と併用すれば(=合わせ技に使えば)、もっと効率が良くなります。
SQLの存在すらも紹介しない講師は「バカ中のバカ」です。
SQLを教えない、ということは、「データのそもそもの持ち方・ある程度効率的な蓄積方法」もしっかり教えてない可能性が結構高いです。
つまり、「データ管理の基礎」のことと日本の職場の「コスパ」のこと、この2つのことをまったく考えていません。
(「データ管理の基礎」とはExcelやVBA等の基礎のことではないです。そんなのなんかじゃなくて、Excelやその他のソフトに依存しない、あくまでも「データ管理」の基礎のことです。)
たとえば、SQLやデータの持ちかたの基本を教えずに、お客様事や取引先ごとにフォルダをたくさん作ってそこにデータを蓄積させるような方法や、シートを月ごとに「クロス集計表」で作ってそこに日々のデータを蓄積させる、といったような超無駄で効率の悪い方法を(わざと?)教えておいて「ぜんぶVBAで解決できますよ」などと騙し、「本来書く必要のない無駄なVBAコードや関数を大量発生させている」のです。
SQLの存在すら教えない講師は、そのような感じで、いつまでたっても、Excelの初心者コースのショボい簡単な内容で儲けようとして、日本の将来、子供さんたちの未来を「まったく」考えていません。

「集計」「複数の条件での集計」「リストアップ」には、SQL(ExcelだとMicrosoftQueryやQueryTableオブジェクト)を使うかそれをVBAと併用するほうが、VBAや関数「だけ」を多用するよりも10倍難易度が低く、10倍、コスパがいいです。

それから(一番多いExcelあるあるの)、「複数の表を紐付けしたい」「データとデータを紐付けしたい」

という場合、

VBA講師たちは何をしているか?

「あの方法はバカだ」「これは使うな」などとののしりあっているのです。

実際には少なくとも・・・、

Excel限定なら(2000以降の全バージョンで)、
「VLOOKUP関数を使う」
「INDEX関数、MATCH関数、COLMUN関数を使う」
「MicrosoftQuery(2003以前は新しいデータベースクエリ)のドラッグを使う」
「MicrosoftQuery(2003以前は新しいデータベースクエリ)のSQLを使う」
「VBA+QueryTableオブジェクトでSQLを使う」
「VBA+ADOでSQLを使う」
「VBA+DAOでSQLを使う」

Excelの2013以降限定なら(2010はアドイン?アドオン?で?)」
「 ” データモデルのダイアグラムビュー ” でのドラッグを使う(PowerPivot、2010用)」
Power Query のマージ機能を使う

それらとVBAや関数の合わせ技

などの方法があり、

Excel限定でなければ
「AccessでSQLを使う」
「Accessのクエリでドラッグを使う」
「MySQLでSQLを使う」
「SQL Server やオラクルでSQLを使う」
「SQL Server やオラクルのビューでドラッグを使う」

・・・などの方法があり、

「それぞれが、それぞれのケースで、いちばん、効率化・コスパアップ」をしてくれます。
「便利さ・得意な部分」の内容がそれぞれに異なります。

「それぞれ」の「良さ」があります。

つまり、「人」と一緒で、「適材適所」があるのです。

つまり、「1つの目的」に対して、「TPOによって、一番 効率化・コスパアップ」をしてくれる方法が「異なり」ます。現実に。

つまり、「1つの目的」に対して、「TPOによって、そのときどきで、” 一番 効率化・コスパアップできる技 ” を変えるべき」であります。

僕は、そういうことを教えてくれるExcelVBA講師はひとりも見たことがありません。
そういう「高所から」俯瞰して説明してくれて、「こういうケースのときは、この方法が良く使われます。こういうメリット・デメリットがあるからです。」と説明してくれる講師は「皆無」ではないかと思います。

少なくとも、市販されている書籍では全滅です。

それぞれのメリット・デメリットを表にして一覧させ、「時間の都合上、全部説明できないから、一応この表読んでもらって、で、わからないところや知りたいところがあったら別授業してるからそっちでね!」などの但し書きもしません。

「俺様がいつもやってる方法でおまえらもやってりゃいいんだよ!」という思想ばっかりを押し付けてきます。

もしかしたら、VBA講師だけでなく、一般操作の講師もそうかもしれません。

特に「Excelの教科書」を名乗る本。サイト。

日本のデータ管理の教育は、お先真っ暗だなあーーーと落胆します。
  
  

結局のところ、「データの紐付けに対してのこと」ひとつをとっても見ても、

Excel限定なら(2000以降の全バージョンで)、
「VLOOKUP関数を使う」
「INDEX関数、MATCH関数、COLMUN関数を使う」
「MicrosoftQuery(2003以前は新しいデータベースクエリ)のドラッグを使う」
「MicrosoftQuery(2003以前は新しいデータベースクエリ)のSQLを使う」
「VBA+QueryTableオブジェクトでSQLを使う」
「VBA+ADOでSQLを使う」
「VBA+DAOでSQLを使う」

Excelの2013以降限定なら(2010はアドイン?アドオン?で?)」
「 ” データモデルのダイアグラムビュー ” でのドラッグを使う(PowerPivot、2010用)」
Power Query のマージ機能を使う

それらとVBAや関数の合わせ技

などの方法があり、

Excel限定でなければ
「AccessでSQLを使う」
「Accessのクエリでドラッグを使う」
「MySQLでSQLを使う」
「SQL Server やオラクルでSQLを使う」
「SQL Server やオラクルのビューでドラッグを使う」

といったことすらも教えない、ということは・・・、

結局は今のVBA講師たちは、「Yo!俺様の得意技見てくれYo!」「Excel操作オンリー」「ワークシート関数だけ・VBAだけの狭い視点」「関数バカ」「専門バカ」という視点に立っているだけで、
・「ソフトの垣根を超えた」
・「ほんとうのデータ管理」
・「エンドユーザーのメリット」
・「機能の適材適所・コーディネイトバランスによるコスパアップ」
という視点にはまったく立ってない、という「証明」になっています。

※(誤解されるといけませんので少し横道に逸れますと)ちなみにですが、僕は「ワークシート関数」様自体はバカにしていません。便利で偉大だと思っています。でも頭がよくないと使えないです。あれは・・・。
その意味では、あれをVBAやSQL・ピボット・MicrosoftQueryなどと「ムリ・無駄なく」合わせ技ができるかたが一番すごいと尊敬しています。そういう人の作る作業手順は、ほんとうにすごいなあ、と尊敬します。
「見事!」というほかありません。こんなにシンプルな関数で・・・よくこの技と組み合わせてこんな複雑な内容を・・・と尊敬します。まさに機能のコーディネイト!素晴らしい機能たちのバランス!ウェイト!
VBA化もしやすいし。作り変え・作り足しのこともちゃんと考えてくれてます。
全体の「今後の可能性」「コスト」「メンテ」に目が行き届いています。
(その良い事例・すばらしい事例→教えてgoo:「エクセルについて」という質問に対する、No.4 のご回答。※このサイトには、関数に関して恐ろしいくらいメッチャ詳しい素晴らしい方がいらっしゃるのですが、その方が反応しましたけど結局「できなかった」らしき処理です。この方はのちに書いた「関数バカ」ではないと思います。自らの修行と楽しみのためにやっているだけみたいな感じの方なので。ただ、一度反応して答えないなんてことが基本、ない人なんです・・・。それをNo4の回答者の方は、シンプルな関数とピボットの見事な「合わせ技」で「誰でもできるレベル」に落とし込んでいます。エクセレント!と言うほかありません。僕ももっと関数の基礎や応用を勉強しなくっちゃ!と痛感させられました。
逆に、全部「ワークシート関数」でやろうとする人は、「すごい!」のは認めますけど、他人のことを考えない迷惑な人、「ワークシート関数バカ」「専門バカ」「全体のコストのことを考えられない人」だと思っています。
そもとも「全部が全部を」「ムリに」ワークシート関数化すると、のちのちに、例えば、「今度はこの条件でこの数字知りたいんだけど」とか「別の角度からこの集計できない?」っていうような関連した要望が出てきたときに、「本来なら」MicrosoftQuery+ピボットを1つ作ればそれ経由での応用が利いて・作り変え作り足しがしやすいのに、全部関数数式を作り直して作業するんです。プラス、「ワークシート関数職人」にしかコントロールできないようなことをします。(つまり、ワークシート関数は、「ほとんど同じ条件」でしか生かされないことがおおく、複雑に条件が変わる処理には、基本的にはあまり向かないです。逆に「まったく同じことをする場合で、数値だけが変わるだけ」の場合は、すごく生き生きと活かせる。当然、VBAやMicrosoftQuery+ピボットよりも便利な利用シーンが確実にあります。)
そして、それを読まされるほうは面倒くさくてかないません。みんながみんな、その関数式の内容がすぐに読めるわけじゃないんです。簡易的なSQLのほうが全然わかりやすいです。
もっと言うと、VBAコードのほうが「ワークシート関数のようにすべてが1行に詰め込まれてしまっている」わけじゃないので、つまり、「複数行に構造化」されているのでわかりやすいです。
(でも、VBAやMicrosoftQuery+ピボットとワークシート関数との併用なら、少しの修正とボタンクリックするだけとか、ちょっと条件変えるだけとかで処理できることも少なくないし、そもそも関数の内容自体もシンプルになる傾向にあります。)
おまけに関数が増えすぎると慣れてないユーザーによる数式設定ミス(引数の設定ミスなど)・数式破壊も増えて業務に支障をきたします(関数バカの人は自分ができるもんだからセルロックの周知徹底をしないので)。また、「すべてがワークシート関数だけで処理されたもの」は「VBA化・変換」がしにくいから「一から考えなおさないといけない」ですし、それらの理由から、「メンテも超やりづらくてしょうがない」ので引継ぎも困難になってしまいます・・・。
「再利用」「機能追加」できるのは「本人だけ」で、その本人が居なくなったあとは「難解すぎて捨てられるだけ」です(VBAは捨てられない傾向にありますが、ALL関数のシートは割と簡単に捨てられる傾向にあると思います)。で、結局、「あらたに ” 多くの人にもわかりやすい別の方法 ” で処理される」ので、「結局のところ、例えば、部署全体としての ” データの再利用 ” にはまったく貢献していない」のです。で、ワークシート関数がそこまで使えることが転職しても有利かというと、世間一般にはそうでもないです。むしろSQLのほうが関数やVBAよりも有利と言えます。そんな風だから、作った本人は得意げなんでしょうけど、メンテコストが増大し、「そんな極端な」方法ばっかりとる人は、「周囲にとっては迷惑でしかない」です。
自分の中だけの仕事・作業ならいざしらず、チームでの仕事においても「なんでもExcelでやっちゃう病」の人と同じです。
そこに気づけないバカな人・「安易にワークシート関数 ” だけ ” での完結」「全部関数でやってしまうほうが偉い」なんてことを推奨するバカ講師が多いです。(Webにも市販書籍にも。特に市販書籍。Excelの市販書籍にはそういうバカ講師が多くてゲンナリします。)
なんでもやりすぎ、はよくないです。
「やりすぎ」が許可されるのは、たとえば、
「社内だけにとどまらない、他社からもひきあいのある一部のエキスパート中のエキスパートだけ」、
「人類のため」
あるいは「年に数回あるかないかのとき」や
「どうしてもワークシート関数以外は使ったらダメ!VBA・SQL・MicrosoftQuery・ピボットは使ったらダメ!という場合」
とかです。
私ら一般人・凡人にとっては、平常時からそればっかりをやるのは、チームワークを乱す元にもなるので、多くの場合は許されませんし、注意が必要です。
  
  
・・・・すみません。また話が逸れてしまいました。戻します。
  
  
ほとんどのVBA講師たちはそういうバカな人間なので、

「そもそも、1つの目的に対してそのような複数の方法があることも提示せず」
「業種・職種・TPO別に各種の方法のメリット・デメリットを説明せず」
「あれはやるな」「これはやるな」「あれをやるやつはバカだ」「騙されるな」

などとののしりあっているのです。

「騙してるのはお前だよ!」

ということを分かっていません。

人格が低すぎます。

例えばこんな感じです。

VLOOKUP関数は使うな!誰も教えてくれないExcel関数の便利な使い方(第1回)

このサイトは、たまたま検索にひっかかっただけで、何のうらみもありませんが、「VBA講師たちは例えばこんな感じのことばっかりしています、という例」です。

そんな人間性の低い・極端な人が、「本当のこと」を教えてくれるでしょうか?

「上手でコスパのよい合わせ技」や、「コスパの良い合わせ技のコーディネイト・バランス・ウェイト」を教えてくれるでしょうか?

GoGo エクセルマクロをはじめよう!の公式Webサイトも、すっごくいいサイトなのに、残念ながら似たような思想の記述が目立ちます。
(あ!僕もか!って、ここは良いサイトではまったくないけど・・・だから信じないでください。)

「Excelの教科書」を名乗るような本の著者は、(僕と同じかそれよりもレベルが低い)そんな「バカ講師」ばっかりです。

いいかげん嫌気がさしてきます。

習う側として。

「ウソやおまえの都合ばっかり教えやがって」「教える気ねえだろ」という想いしか残りません。

「習う側が知りたいのは、こういうケースではこの技を」という、「コスパが良くなる」ための、「TPO別の機能コーディネイト」です。

彼らには、「日本の ” データ管理 ” の状況を10年も20年も遅らせているのは自分らだ・自分らの責任だ」という自覚がありません。

なんでも「ExcelとExcelVBA」「だけ」で解決しようとします。
なんでも「ワークシート関数」「だけ」で解決しようとします。
なんでも「俺様の得意技」「だけ」で解決しようとします。
「TPO別の ” 合わせ技 ” の推奨」「機能たちのコーディネイト」をまったくしません。
「機能たちのTPO別のメリット・デメリット」を語りません。
そして「いろんな人・状況・立場、等々」の「コスパ」を考えません。

ほんまもんの「バカ」ばっかりです。

子供たちの未来のために、ほんとうに、そういうバカな講師たちは速く業界から居なくなってほしいです。

【お手本】:人格の良い人、はこういう書き方ができるひと。Excelに限らず、パソコンはこういう視野の広い人に習うとよい・・・、という事例をご紹介しておきます。
Excel ピボットテーブルは「表形式」でさらに使いやすくなる

このWebページは、高度なことが書いてあるわけではありませんが、しっかりと「ユーザーにはいろんな業種・職種・状況・ご要望の方がいらっしゃる」ということを意識して、かつ、しっかりと「人によっては見づらいと感じる場合があります。」とか「表を見やすいと感じるかそれとも見づらいと感じるかは個人の感性による部分も大きいため、一概にピボットテーブルのどちらの形式が見やすいとはいえない面もありますが、」などと但し書きを書いてくれています。

こういう「書き方」のできる人こそが、「本来・ものを教える資格のある方」だと思います。

そして、こういう回答のできるQ&Aサイトの常連回答者の方も、少ないけどちゃんといます。

そういう方々が、本来は、「教える立場」になるべきだと思います。

すくなくとも『ピボットが必要のないケースで「ピボットを使ってはいけない」とけなし、誤った情報をユーザーに植え付ける 』、
たった1日で即戦力になるExcelの教科書
とか、
会計士が教えるスゴ技Excel(まだこちらのほうがいいですけど)』
といった「腐った本」そして「腐った人間の僕が書いているこのサイト」のことは絶対に信用しすぎてはいけません。(プログラマになりたいわけじゃない、としても必ずいつかドツボにハマります。)

たった1日で即戦力になるExcelの教科書』の著者は、『たった1秒で仕事が片づく Excel自動化の教科書』という本も書いていて、そこで「変数設定なんて全部Variant型でいい」といった意味合いの愚かなことを書いています。(同じく、プログラマになりたいわけじゃない、としても必ずいつかドツボにハマります。)

あと、ExcelVBAのレジェンドさんたち、その方が関係している団体のサイトも、「TPO別の機能たちのメリットデメリット」をあまり語ってないので、また、情報が古いものもありますので要注意です。(必ずいつかドツボにハマります。)
断片的な情報ばっかりで、「こういうデータの持ち方のときはこう。これらを合わせ技でこう使う。なぜならこうだから。でもそもそもデータの持ち方から変えたほうがいい」とか、そういう情報は、ある意味「皆無」に等しいです。
たとえば「バインディングの話」一つとっても、NewやOpen、Addの話まで結び付けたり、
・そもそも、「Newキーワード・Addメソッド・Openメソッド・GetObject関数・CreateObject関数、一応ぜんぶ、事前バインディングでも実行時バインディングでも両方で使えるんだよ?どこでどう使うか(変数宣言の場所やSetなどの場所でどう使うか?)が変わってくるだけで。」
・それに、「GetObject関数は既存のファイルで開いているモノ閉じているモノ両方を扱える」
・「参照設定はExcelのバージョン違いで外れることもあるので、そうなるとその意味では実行時バインディングのほうがいいかも、という話が多いけど。ただ、実行時バインディングでも、Setのコードなどで例えば「Set ×× = New Excel.Application」みたいに参照設定が必要な書き方をしていたら結局 「実行時バインディングでもダメ」だよ?
・あと、実行時バインディングでも参照設定してあればインテリセンス機能は一部では使えるよ?Objact型やVariant型で宣言したオブジェクト変数に対してだけは使えないけど。「実行時バインディングだからといって、インテリセンス機能がすべてにおいてまったく使えない」ということではないよ?もちろん参照設定したライブラリ(DLL、OCX、tlbなど)はオブジェクトブラウザ・ヘルプが使えるようになるし。逆に言うと、事前バインディングしたい場合は参照設定してないとできないので、一応参照設定する前提だから、インテリセンス機能やオブジェクトブラウザなどは、最初から宣言したオブジェクト変数に対しても当然使えるけど。
・また、大量の外部ファイルを扱うなら事前バインディングは多少遅くなる場合があるので、ケースバーケースで、事前と実行時を混合・バランスさせて使えばいい。
・その他のデメリットは・・・云々・・・」とか、「設計はこうするのが世界標準の基本です」とか、「最初はコレ、わからなくてもいいから、でも絶対に必須だから、必要なこと全部(「目標」の意味も込めて)先に書いとくし・言っとく!だから、今はわからなくても、今後も、少しずつ進むたびに何度でもここへ戻ってきて繰り返し読んで!必ずわかるようになるから!」とか・・・、なんて風に「概論」を「最初に一度に」「わかりやすく」「まとめて」書いてくれる講師・説明してくれる講師はほとんど居ません。
っていいますか、見たことない。
「皆無」。
基本、「バインディングの話」はオブジェクト型変数の宣言の話。
どの変数に対してどのタイミングでバインディングがなされるか?という・・・、そんなイメージの話。
やってはいけないかもしれないけど、1つのプロシージャの中で事前バインディングと実行時バインディングを混合させることも一応できる。
オブジェクト型の変数を、「As Object」で総称的・汎用的に宣言するか、それとも「As Workbook、As Worksheet、As Range、」のように明示的なオブジェクトの種類(型)で宣言するか、の違い、だけ。
後者の事前バインディング(Workbook型、Range型、Application型などでの宣言)については参照設定しないとエラーになるけど、前者の実行時バインディング(Object型での宣言)については参照設定するしないはまったく関係のない話。
逆に、もしObject型での宣言をしても、オブジェクトの代入時にCreateObject関数などを使わずに、「 Set ×××× = New Excel.Application 」みたいな書き方をすれば、参照設定をしていなければエラーになります。
逆に、実行時バンディングはたとえば「アプリケーション」を参照設定されていなくても「クラス名」として「Excel.Application」を指定できるのでそれでバインディングができます。アプリケーションのほかにシートのクラス名なども用意されていますし。もちろん参照設定されていても実行時バインディングは使えます。
結局、(事前バインディングでも実行時バインディングでも)セル操作ではなくて新規ファイル作成という目的だけに限れば 「New ××・・・」または「CreateObject関数」+「Add」が使え、既存ファイルオープンという目的だけに限れば「New ××・・・」または「GetObject関数」+「Open」、あるいは参照設定がしてあれば「Open」だけが使えるのに、その話をしない。
セル操作でもObject型のオブジェクト変数を作る場合もあれば、Range型のオブジェクト変数を作る場合もあります。多分それも「事前バインディング・実行時バインディング」の話と関係があるかもしれない。逆に、無関係であるかもしれませんが、でも、もし無関係であるなら、それこそ話として登場させて「混同しないように」という説明があってしかるべきです。
そういう説明もしてくれないのがバカ講師たち。
だから習う側はどう使っていいのか?わからない。
下手に使ってトラブルにならないか心配になる。
集計・リストアップ業務に使うのにSQLの存在のことすらも教えませんしね。
「いろんなこと」の、「設計はこうするのが基本です」とか、「最初はコレ、わからなくてもいいから、でも、何度でもここへ戻ってきて繰り返し読んで!必ずわかるようになるから!逆に、やるなら、この半部異常が分かるようにならないと、モト取れないから!」とか・・・、なんて風に「概論」を「最初に一度に」「わかりやすく」「まとめて」書いてくれる講師・説明してくれる講師はほとんど居ません。
全部、「そのときそのときだけ」の「断片的で視野の狭い内容」ばかり。
「俺様の技・考え」ばかり。
嘆かわしいです。
本当に「教えることの」プロなのか?
Excelが出て「20年も経ってる」のにだよ?
だから、私ら「習う側」が混乱してしまいます。

なので、「なんかしらデメリットはあるんだろうな。それが分かったら作り変えよう。「特にExcelのサイト」は、レジェンド・大御所のサイト・書籍だからって信用しすぎないように注意しよっと。何隠してるかわかんないし。そもそもパソコンやExcelが正常動作する保証も無いしなー。マイクロソフトもしょっちゅう仕様変更ってやつするし。基本、パソコンもExcelも完全には信用できないからなー。最悪の事態も考えながら作ろう。」というスタンスでならすっごく役に立ちますが、「これが本物」と信じると、痛い目をみると思います。
実際、「あ、あそこに書いてあったアレ、ヘルプに書いてあることのまんま写しだ」とか「ローカルウィンドウで動きとか見たら、セルの小数計算ミス(セルの挙動)って、とんでもないやん!」とか「あー、テキトーなこと書いてるなー。」「俺もわかってねーけどこの人もわかってないかもしんない。」ということが、ExcelVBAや関数の勉強が進むうちに、どんどんどんどん出てきます。
特に「Excelデータベース」系の話とか、定型的なビジネスデータ集計やリストアップの部分では、あきれるくらい多いですね。
(すごいなあ、というExcelVBAや関数の情報にももちろん出会えますけど、意外と少ないです。)
もちろん、僕の書いているこのサイトの記事も、テキトーなので信じないでください。

  
  

ところで、そういうバカな人たちが書いているものとは対極にあるサイトの2つめ・・・『 そういう方々が、本来は、「教える立場」になるべきだと思います。』と書きましたが、そのような「しっかりした視点と人間性」を持っている方が書いている代表格的なサイトを挙げておきます。(もちろん、全然知らない会ったこともない無関係の先生です。)

インストラクターのネタ帳