ピボットテーブルが広まらない理由02（すごいプロの方でもこんな程度の認識です）
関連記事
●ピボットテーブルの使い方やできること01 ～「できること」編 ～ ビジネスデータ管理（コスト減等も）を2～100倍効率化するツールその2
●ピボットテーブルの使い方やできること01 ～「できること」編 ～ ビジネスデータ管理（コスト減等も）を2～100倍効率化するツールその2
●★★★★★★★★★★★★ 超重要！！★★★ Excelでのビジネス定型集計の「真の基礎」
●「Microsoft Query」 で私たち素人のエンドユーザーでもできること いろいろ
●Excel2000で30分で作るバーコードPOSレジのコア部分（定型集計効率化サンプル）ダウンロード
◆ 「ピボットテーブルを使ってはいけない」と書かれている市販書籍をどう考えたらい？？
◆ ビジネスデータ管理においては、「ピボットテーブルやMicrosoft Query」は
「VBAプログラミングよりもはるかに重要な機能」なのに
何故かあまり広まっておらず、「データ管理のムリ・ムダ・ムラ」が
Excel2000の時代からほぼ減っていない理由
（むしろ増えている場合もあるかも？）
(01)マイクロソフトさん自らの愚かな誤認と姿勢。
(02)Excelのレジェンドさんやプロの方々の愚かな誤認と姿勢。
(03)上記２つの理由からの大小 一般のパソコン教室さんの誤認と姿勢。
(04)特にピボットは上記３つの理由からの表のレイアウトがしにくいとか、
自由にならないと誤解されているから。集計が難しいとの誤解も。
(05)上記4つの理由から、「ただの反復練習不足」の状況になってしまいました。
※「ピボットテーブルやMicrosoft Query」は中小様や零細様、個人事業主様、
学生さん、にとっては、VBAプログラミングよりもはるかに重要な機能です。
日本の企業の数は中小・零細・個人事業様が8割以上？と聞き及びますので、
そこに広まっていないというのは、
「日本のデータ管理教育やExcel教育は完全に失敗している」
ということを意味していると思います。
※前置き01：個人攻撃みたいになってしまってやっぱり気持ちのいいものではない（し、自分自身、大した人間ではない）と思いましたので、2017/06/06 書籍の実名を消しました。ただ、ピボットテーブルのことを「ちょっとした便利な機能」としてしか認識していないのは間違いだと思いますので、そのほかの部分は消してありません。以降は、書名を公開していたものと想像して、お読みください。
ただし、狭い視野で「ピボットを使ってはいけない」、と何の但し書きもなく書いている、例えば『「教科書」や「プロ技」「すごい」を銘打った市販Excel関連書籍を書いている自分の仕事範囲でしかものを考えない視野の狭いノータリンでバカな低能著者ども（ただの関数バカ・VBAバカ・専門バカ） 』に足りない視点を表現している優れた大人な考え方のWebページの「良い事例」を先にご紹介しておきます。
Excel ピボットテーブルは「表形式」でさらに使いやすくなる
特にお若い方々は、↑こういう書き方のできる、「人格の」優れた方からExcelの基礎やデータ管理の基礎を習いましょう。「専門バカども」や僕のような人間 に習うと、いつか自分が痛い目を見てしまいます。どうかお気を付けください。
※たまたま見つけた面白そうなWebページ
『ピボットおじさんのパソコン教室』
※前置き02：「あわせてお読みください」
ピボットテーブルは慣れないと使いづらく感じるかもしれないですけど、でもビジネス定型集計においてだけは、「VBAや関数だけで全部やる」よりも10倍以上の効率になるのは誰もが異論の無いところですので、有料でもかまいませんから、もっとプロの方々が 使いやすくなる技 等々をもっと 解説してほしいです。とくに子供さん（小中高）や学生さんたちに色々と教えてあげてほしいです。是非 それを望みます。
◆ ビジネスデータ管理においては、「ピボットテーブルやMicrosoft Query」は
「VBAプログラミングよりもはるかに重要な機能」なのに
何故かあまり広まっておらず、「データ管理のムリ・ムダ・ムラ」が
Excel2000の時代からほぼ減っていない理由
（むしろ増えている場合もあるかも？）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以下、本文です。
まず先に謝っておきます。
あまりこういうマイナスな発言の投稿はしてはいけないと思うのですが、ピボットテーブルについて、これ以上誤った認識が増えるといけないので、特に、零細様や個人事業主さま、お子様、学生さん達、新社会人の方々、等々が誤解するといけませんので、あえて、書いてしまいました。
本当にごめんなさい。
では、お話させていただきます。
先日、ちょっと危ないなあ・・・ということを書いている書籍に出会いました。
この本の ××× ページですが、
（2017/06/06 書籍の実名を消しました。）
「いつまでもピボットテーブルのままではいけない」
と書いてある本です。
いい本だと思って購入したら、終わりのほうでそう書いてあったのを発見してしまい・・・。
かなりガックリ来てしまいました。
「××× ××× ×××」という本です。
Amazonでも、もちろん大きな書店でも販売しています。
いや、全般的にはすごくいい内容の本なんですが、その一文だけは許せませんでした。
僕自身、Excelはそう詳しくはないので勉強になる基本操作がいっぱい書いてあって、すごく参考になりましたし、新入社員の方やExcelでの集計に時間がかかってしまうような方には是非購入していただきたい一冊だと思います。
でも、この「いつまでもピボットテーブルのままではいけない」という一文だけは悲しかったです。（そのあとに「関数で再現できないかを検討しましょう」と書いてあります。）
意図はわかるのですが、この本の構成上、この書き方だと（その他の説明が足りなさ過ぎて）非常に誤解を受けやすいと思いました。特に関数やピボットに慣れてない方は間違った方向に誤解しやすいと思います。
ピボットについて詳しい説明をしてないのに（特に、GETPIVOTDATA 関数のことも説明せずに）ピボットテーブルを下に見ているような誤解を与え、さも、ピボットテーブルよりも関数利用（例えば複雑な関数利用）のほうが上位であるかのごとく・・・のニュアンス・・・を醸し出してしまっています。
本当に残念な・・・この短いセンテンス・・・。
『こういうすごい人が、こういう風に書くから、ピボットが今後も過小評価され続けて・・・過小評価が止まらずに、零細様や個人事業主様に「単なる”ちょっとした”便利な集計機能」と認識されるだけに終わってしまい、メンテしにくい無駄な関数やVBAプログラムコードが増えるんだよなあ・・・。』とか、『「すごい人達」は、もうちょっと「ご自分の影響力は本当にすごいんだよ？」、ということをちゃんと意識してほしい・・・』などと思いました。
例えば 事務のお仕事（計算作業が多い場合）をラクにしたり、例えば「仮説と検証」を風土化したりするためには、まずExcelのMicrosoft Queryとピボットテーブル、Wordのフィールド機能、これらをもっともっと解説して、「それでは間にあわない・ダメ」なシーンではじめて、「関数やVBAを使う」、というやり方のほうがいいように思うのです。
ExcelやWordのプロの方々がもっともっと、Microsoft Queryとピボットテーブル、Wordのフィールド機能、Excel・Word・Outlook等々との連携、のことを詳しく伝えて、そういう風な使い方を伝えていく義務があると思います。
でないと・・・、そういう「データ管理」の教育を 中高生のころからしていかないと、「形式的に無駄に書類を作る」ということが減っていかない状況になってしまいそうな気がします。
『「無駄に書類を作る」ということが減っていかない状況』、というのは実際に自分の周囲にもあります。
「全員がピボットの操作ができて 各々がピボットでささっと集計してしまえば、いちいち、書類なんか作る必要ない」というシーンも決して少なくないと感じます。
「みんなピボットの使い方くらい覚えてくれよ。そうすれば自分ですぐに集計結果出せるから、こんな書類作る必要ないんだから・・・」みたいな・・・
ピボットテーブルで 無駄な書類を作るコスト（時間・金額）を年間どれだけカットできるでしょうか？
もしカットできる時間が 仮に年間に1人20時間（20人時）あったとすれば、20名の社員さんで400人時です。これを例えば時給1500円で換算しても400人時×1500円=600,000 です。年間60万円が浮きます。これは別のお仕事の予算に回せますし、浮いた時間も「人間にしかできない、より利益の生まれやすいお仕事」に回せるかもしれません。
「たかが60万」と感じるか、「60万も！」と感じるかは会社様によって違うのかもしれませんけど・・・。この場合だと 5年で300万浮く計算になりますね。その分、社員さんのボーナスにしてあげてもいいかもしれません。
この本は、「使わないともったいないピボットテーブルの集計機能」という見出しも使ってくれて、ピボットを紹介してくださっているのに、この一文、この段落が本当に悲しいなと感じました。
そこを読むまでは、「ぜひ、ピボットを活用してください」といった内容だったので「おおおお、いいぞ！」と思って読み進めていったら、最後の最後にコレ・・・
この一文・・・
「まず誤解されるよなあ」と感じました。
著者の方は会計士さんだから、零細企業様や個人事業様の気持ちや、IT予算が少ないことや持てないことや、コストのことや、零細企業様や個人事業様にとって本当に必要なExcelの機能のことが分からないのかなあ？と誤解をさせます。
逆に、会計士さんだからこそ、分かってほしいし、分かってなきゃいけない、僕たち零細の味方になってほしい、と思うのですが・・・。とそういう誤解もさせます。
こういうすごい人でも、「ピボットテーブルに対して」は、「こんな程度の認識」です。
ピボットテーブルが広まらないわけですよね。
当然、Microsoft Query なんて広まるわけがありません。
Wordのフィールド機能が深く解説されるわけもありません。
何も広めないもんですから、無駄な関数利用やセルリンク、を大量生産させてしまいます。
ひいては、大量の無駄なVBAプログラミングをも大量生産させてしまいます。
無駄なそれらは大量発生させればさせるほど、会社の資源を食いつぶしていきます。
作る人の時間、時給、人件費。電気代、PC占有。
もちろん、ピボットは、「まさにリアルタイムな数字の移り変わりを見たい」というようなときは使えないですし、また、加算は問題ないのですが平均などを出すとにたまに意図しない集計結果（計算間違いなど）が出ることもあります。
そしてピボットテーブルよりも関数を使うほうがすっきりシンプルになる場合も当然あるとおもいます。
でも、だからといって関数ばかりに頼りすぎるとそれはそれで、入力値のミスの発見もしにくいし、関数の合わせ技になったりすると、ファイルを別の場所に格納しただけでエラーになったり、その他、面倒なことがいっぱいです。
また、基本、関数はメンテの面でも面倒になることもあります。
例えば関数のことを「よく知る人・慣れた人」にしか、「ユーザーがどう入力ミスしたか」が「ほぼ」わかりません。
例えば ３つ以上の関数の合わせ技なんてものが使われてしまっていると、エラーが出たときや結果がおかしい時に何がどういけないのかなんて本当に関数に慣れた人じゃないと発見できません。ユーザーの入力値ミスなのか操作ミスなのか数式設定ミスなのか？特定するのが面倒です。
それを発見するだけでも一苦労です。
実際、僕は関数のことをあまり知らないので、他人の作った3重、4重の構造の関数ですごく苦労した経験があります。（結局、関数の引数の設定ミスでした。関数がわからないと本当に苦労しますね。VBAのほうがまだわかりやすいです。）
「関数を知らないユーザーさん」が数式を簡単に破壊してしまうことも多いですし。
（これは当然であり、無理もないことです。）
セルにロックをいちいちかけないといけないのも面倒くさいです。
（ロックをかけること自体は簡単ですが、例えばロックをかける範囲をミスして”ロックをかけ忘れた”ときに、例えば関数を知らないユーザーさんが数式をぐちゃぐちゃにしてしまった後の直し・・・が面倒なのです。もちろんユーザーさんに罪はありません。ロックし忘れたりミスした自分が悪いので・・・。）
また、「こんなんじゃあ、（無理に数式バーだけで複数の関数を多用して片付けるようとするよりも）VBAで自作関数作って、それ使ったほうがメンテがラクじゃないか？」とも思うときも結構あります。
ピボットだと「間違い」は「間違い」として「表に集計されて現れてこさせる」ということも可能なので、入力ミスの発見もしやすいです。数式も最初からほとんどないですし、チェックすべき箇所が少なくてすみます。
また、ピボットをそれほど知らない人でも、ある程度の操作を教えれば、間違いが比較的発見しやすいです。関数のように1文字違ったらダメみたいなところも少ないですし…。
もちろん、ピボットだって万能じゃありません。
どの機能にもメリット・デメリットはあります。
結局のところ、各場面で目的を達成しやすいように、かつ、ユーザーの入力ミスも少なくなるように、また、メンテ的にラクになるように、各機能をコーディネイトする必要があると思います。
それは正解があるわけじゃなくて、業種ごと、職種ごと、シーンごと、目的ごと、等々で変化していくものです。各機能のコーディネイトにおいての「必要とされるバランス」が、です。
決して、安易に「いつまでもピボットテーブルのままではいけない」というふうにざっくりと、でも、半ば決めつけのように言い切ってしまっていいものではありません。
でも、こんな「スゴ腕」の人がこんな一文を書いてしまったら、経営者様たちのように「忙しい方々」が「ピボットよりも関数のほうが大切」、「複雑な関数が組めるほうが偉いんだ」、「関数のほうが何でも早く片付くんだ」、「ピボットテーブルは関数で処理する前の段階でしか使えない、単なるちょっとした便利な集計機能でしかない」と盲目的に信じてしまうじゃないですか。
もちろん、著者の方にはそういう意図はまったく無いとおもいますけど・・・。
でもこの内容だと、まずほとんどの人が そういう「とても愚かな勘違い」をしてしまいます。ビジネス定型集計に関してだけは、関数盲信は危険です。そもそも論として、ビジネス定型集計には最初から複雑な関数なんてあまり必要ないのですから。シンプルな関数はもちろん必要ですけど、「複雑高度な関数」はそれほど必要じゃありません。VBAプログラミングにしてもまったく同様です。VBA盲信は危険です。
Excelはもともと業種別分野別に必要とされる機能が違うわけですから、会計士様ならばそこを踏まえて細かく発言してほしいと思います。
特に、中高生、学生、新入社員の皆さんへ。
皆さんは絶対にこの本のこの一文だけは、理解してはいけません。
この一文は、発言としても絶対にマネしないようにしてください。
著者の方は「スゴ技」を熟知していて「スゴ技」を自由自在にお使いになれるので言ってもいいのかもしれませんが、また、ピボットの機能を深く掘り下げなくても済むのかもしれませんけど、私たちのようなExcelに精通していない普通の人間がこの一文を口から出してしまったら もうそれは、「自分はExcelの本質を理解していないただのバカです」と自分で自慢しているようなものです。
僕自身、いまだにExcel音痴なので、ピボットの勉強中です。
ピボットをVBAで自動的に動かしたり、
ピボットキャッシュのSQL文をVBAプログラミングで自動変更したり、
AccessのクエリのSQLを自動で書き換えて、ピボットソースとしてVBAで自動反映・データ更新させたり・・・。
特定の集計データを、GETPIVOTDATA関数でイレギュラーな場所、イレギュラーなレイアウトの表の中に表示させたり・・・。
それですごく集計の時間短縮になるので、本当に勉強中、かつ、便利に使わせて頂いています。
ただ、この本は、その一文が非常に「悲しい」とはいえ、その一文以外の内容は実に素晴らしく、僕なんかには普段気づきもしなかった基本テクニックが詰まっています。
（僕はそれくらいのExcel音痴です。だからピボットテーブルとMicrosoft QUery を「ほんとうに有り難きもの」、と感じています。）
そういう本なので、ご購入をおすすめします。
頭がいい方々の話はよく、「じゃあ、その複雑で高度な関数やVBAプログラミングってヤツを勉強すればいいだけじゃん。複雑っていったって 言うほどでもないよね。ちらっと見た感じ・・・。」的な理屈になってしまい、身も蓋もなくなってしまうことがあります。
でもそのような、勉強をする時間も習いに行くお金もないユーザーも大勢いらっしゃいます。
また、複雑で高度な関数やVBAを書きまくるといっても、「 Excelを ” 紙と電卓の延長として使う使い方 ” しか知らない人」がそれらを書きまくったら、どんなに頭のいい人が書きまくったところで、膨大な量の「無駄な関数とVBAコード」が増えるだけです。
だからといって、関数やVBAプログラミングを勉強しないでいいわけではなく、関数やVBAも使えればもちろん良いと思います。
本来は関数やVBAは本当に役に立つ強力で偉大なものですから。
ただ、経営者の方が一般的に知りたがる数字を出したいとき・・・、つまり、ビジネス定型集計に限ってだけは、またそれを「コスト（時間的・金額的両方）の面、コスパの面からみた場合に限ってだけは、ピボットテーブルは関数やVBAプログラミングよりも重要で必ず先にマスターしなければならないものです。
前述しましたように、ピボットテーブル（とMicrosoft Query）では間に合わないシーンでのみ、関数やVBAプログラミングを使うほうがいいと思います。
関数やVBAの前に、ピボットテーブル（ついでにMicrosoft Queryも）を覚えて利用頻度を増やしていけば、少しずつでも無駄な関数やVBAを減ら方向にもっていくことができます。
ピボットのソース表や結果にほどよく関数を使ったりするだけで目的が達成できたり、ピボットテーブル自体やグラフなどをVBAで動かして自動化して更に効率アップできたり、等々、色々とメリットがありますので、そういう両者の使い方をしたほうがいいです。
ごめんなさい。
書いているうちにアツくなってしまいました・・・。
僕のいけないところです。
この本は本当にいい本ですからぜひ、購入してください。
僕も買いました。
いい本だなと思って買ったのに（実際役にも立っていますが）、ピボットに対してや小さな会社や個人事業主に対しての配慮がなかったもんですから、つい、アツくなってしまいました。
大変申し訳ございません。
でも、冒頭にも書きましたが、「はあああ、こんなすごい人でもピボットに対しては こんな程度の認識か・・・」というのは本当にそう思ったし、心の底からガックリ来ました。
以前、「● 採用時に「Excelが本当に使える人」かを30秒で判断する方法」
https://euc-access-excel-db.com/tips/ct07_se/ct070201_get_pc_hard/excel_best_brains
というのを書いたとき、これはシステム業者に対しても効果あるかもと書いたんですが、やっぱりなあ、システム業者さんだけじゃないかもなあ、と感じてしまいました。
なので、この本は零細様がご利用しようと思ったら、ピボットの項の×××ページの下段、「いつまでもピボットテーブルのままではいけない」という項だけは飛ばして読んでください。
もしくは、例えばですが、次のように読み変えてください。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
『・・・ミスが起こったりします。
ミスが起こったら、別の手を考えましょう。
代わりに「シンプルな関数」で実現できるのならそれでもいいですし、「GETPIVOTDATA関数」で解決できる場合もあるかもしれません。
それでもダメなら、VBAプログラミングで「ミスの多発する部分」をある程度自動化したり、ユーザーに入力値などをチェックさせるようにしたりしましょう。ただし、多用は禁物です。
どれも大切な機能です。必要に応じて、ピボットテーブル、「GETPIVOTDATA関数」、関数、VBA、Microsoft Queryをうまくバランスさせましょう。
メンテが困難にならない程度に、また、できるだけミスが発生しないように。
なお、各機能のバランスのさせかたは業種、職種、業務内容によって多種多様です。
もし必要なら、自分だけで悩まずに、プロに聞くのも手です。
また、無理にミックスさせてバランスさせなくてもいいです。
ピボットで繰り返し作業をしているうちに「これは適度な関数利用のほうが早いし確実」と判明すれば、ピボットじゃなくて関数利用に切り替えれたりすればOKです。』
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
繰り返しますが、あまりこういうマイナスな発言の投稿はしてはいけないと思うのですが、ピボットテーブルについて、これ以上誤った認識が増えるといけないので、特に、零細様や個人事業主さま、お子様、学生さん達、新社会人の方々、等々が誤解するといけませんので、あえて、書いてしまいました。
本当にごめんなさい。
＝＝＝＝＝＝＝＝＝＝
※2019/02/16 追記（某サイトにある書籍のレビューとして書き込んだ文章です。）
「特定の機能を否定する文章を売り物に書くこと」はプロにあるまじき愚行
Execelは本当にすごいソフトだと思いますが・・・、とりあえず、Excelの機能は強いて大きく分けると２つくらいのくくりに分けることができます。例えば、100%というわけではないですが、でもおおむね、以降に挙げた(a)～(i)のような感じに分けることができると思います。（後半の(d)以降は多くの人が教えてもらっていません。バージョン2000のExcelでもできるんですけど・・・。）
＝＝＝＝＝＝＝＝＝＝
★(01-1)「Excelを紙と電卓の延長として使う方法しか知らない人が良く使う機能」
★(01-2)「本書のサンプルのような”全体を把握するための”クロス集計表を作る業務しかしたことがない人が良く使う機能」
(a)関数（特に集計関数）、多段化させた関数利用
(b)一般集計機能
(c)セルアドレスベースのVBA操作、グラフのVBA操作
※ほんとうはもっとあると思いますけど、省略しました。
＝＝＝＝＝＝＝＝＝＝
★(02-1)「Excelを真にコンピュータとして使う方法しか知らない人が良く使う機能」
★(02-2)「細部の”原因や理由を推測する・マイニング・ストーリー探し等々をするための”クロス集計表を作る業務しかしたことがない人が良く使う機能」
★(02-3)「本書のサンプルのような表の中で、”本当に注意すべき数字がどこか？” をより詳細に説明するための資料を作るための機能」
(d)Microsoft Query（QueryTableオブジェクト ＝ SQL）とSQLでのリレーション
（SQL＝ある意味データ管理の基礎・世界標準で「Excelの基礎」とは違います。
＝ソフトを選びません。＝複式簿記と同じくらい有名＝「集計関数」も含んでいます。）
(e)ピボットテーブル
(f)Microsoft Query（SQL）とリレーションとピボットを自在に動かすVBA・グラフのVBA操作
(g)AccessやWordとのCOMオートメーション連携などのVBA操作
(h)Wordのフィールド機能との連携
(i)ADO、DAO、にて、他のxls、xlsm、xlsxの内容を「閉じたまま」、UpdateメソッドやSQLで書き換え
(j)セルアドレスベースのVBA操作ではなく、列名／SQL／ADO／DAOベースのVBA操作
※こちらも、もっとあるかと思いますけど、省略。
＝＝＝＝＝＝＝＝＝＝
このとき、「(a)～(j)の全部の機能が必要で、全部の機能が役に立ちます」が、本書では「ピボットテーブル」をなぜかやたらと敵視？否定しています。
機能は、業種・職種・シーン、によって、どのようにコーディネイトするかは逐一、変わってきます。
本書は、ピボットテーブルをやたらと否定しますが、本書は、そもそも(01-1)や(01-2)のようなことをするため、そのような機能を使うためだけに書かれている本です。
ピボットは必要ありません。
「もともとピボットが必要ないビジネスシーン」の本なのに、あえて”使ってはいけない”と嫌味を書いています。
そもそも、(01-1)や(01-2)のような業務しかしたことがない人は、「ピボットテーブルのちゃんとした使い方」を理解できていません。（私自身もいまだに勉強中です）
ピボットテーブルを贔屓するわけではないですが、ピボットテーブルに限らず、「特定の機能を否定する文章をお金を取る商材に書きこむこと」は、プロのすることとは言えません。
「関数ばっかり使う表しか作ったことがない人」「もともとそういう仕事しかない人」は「たいてい」、「ピボットを否定する」んですよね。
「お決まりのパターン」です。
はいはい、っていう。
しかも書き方が無条件だから、毛嫌いしてるように映ります。ご本人様的にはそうじゃなくても。
でも、プロでコンサルとかがそういう姿勢が多いのですよね。
多分、「俺はこんなに関数が使いこなせるんだ」って自慢でもしたいんでしょうね。
Excelを紙と電卓の延長としてだけしか使えない方法ばかり教えておいて、そんなんじゃあ関数なんて別に大した意味ないのに。
それにしても、関数もピボットも、もともと使う場面・シーンが大きく異なるのになんで頭ごなしに否定するんですかね？ほんとう、ニセモノのプロというか、そもそもそんな考え方じゃあ、プロじゃないですよね。
プロにも本物とニセモノが居ますから。
プロにも本物の方向を向いている人と、ニセモノの方向を向いている人がいますから。
プロかどうか、なんて、ピンキリだから、そもそも、基準にもなんにもならないですよね。
顧客が多けりゃプロかもしれませんが、ホンモノか？というとそうでもない。
顧客を皆・誤解させていたら？
ほんとう、「何が ”教科書” だよ。」っていう感じで少しあきれ笑いが出てきます。
実際、そんなものを信じると、ドツボにはまります。
100歩譲って否定してもいいですけど、でも、否定したいなら、もっと「シーンを限定する文章」も、「前提」としてちゃんと読者の皆様にご説明することが必要です。
Excelに無駄な機能はほとんどないので・・・。
（足らない機能やバージョンによっては腐った仕様の機能はあると思いますけど、でもそれでも便利に使えます。）
内容は役立つ情報も多いので、よいかと思いますが、「この本が ”ちゃんと考えて書かれている” わけではなく、”著者のお仕事・業務・職種の中ではこれぐらいしか使わないだけ” "好き嫌いで書かれているだけ"」という「非常に視野が狭い」側面もあることを、読者はあらかじめ知っておいてから読む必要があると思います。
（といいますか、この人、本当にコンサルやってるのでしょうか？まともなコンサルならもっとちゃんと正しい方向へ導くように大所高所から書くと思いますけど・・・。煽って騙してるだけのような・・・。）
でないと、特定の機能を「つかえないんだ・無駄な機能なんだ」と誤解して、かえって、特定のシーンでコスパを著しく下げる状況になりかねません。（例えば重複を探すにしても、そのあとにどんな処理をするかで、関数を使うかExcelの標準機能を使うか、ピボットで重複を探すか、使い分けなければなりません。誤るとどの場合もコスパを落とします。それぞれに良さがあります。）
「特定の機能を否定する文章」は、本書に限らず、どのExcel本・PC本でも信用してはいけないと思います。
そこだけ注意して読めば、本書はとても役に立つと思います。
ただ、プロにあるまじき文章を公共に、しかも「有料で・かつ・真実であるかのように」ばらまいて「平然とし」、Excelを良く知らない読者を騙した罪は大きいので、1点とさせていただきました。（本当は0点つけたいですけど）
そして、「1日で即戦力になれる」というのも吐き気がするくらいの騙しなので、その意味でも1点とさせていただきました。（もちろん、役に立つことがたくさん書いてはありますが、「1日で即戦力になれる」というのはかなりなウソだと思います。）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
★ 2冊目（ピボットとは違い、VBAの話ですが、ついでに。）
本書は、「絆創膏を貼るだけの無駄なVBAコードばかりが増える」ことを推奨する典型的な書籍、です。
それが、いいか、悪いかは、別として、とにかく、オブジェクトのことも何もわからない、「絆創膏を貼るだけの無駄なVBAコード」ばかりを、どんどんどんどん量産させる、それを推奨する、メンテナンスや効率化なんてこれっぽっちも考えない、「とりあえず、目の前のめんどくさい作業がすぐに終わりさえすればいい」ことを満たすだけ、の、そういう「絆創膏プログラミング」の方法を推奨する典型的な本です。
P296・297に、「プロシージャの中身・プロシージャに出てくる各要素」のマインドマップみたいなものがあって、それを見ると「なぜ本書が絆創膏を貼るだけのような無駄なプログラミングを推奨しているか」の理由がはっきりとわかります。著者が、VBA自体を正しく理解していないことがマインドマップにすべて表現されているからです。このマインドマップは、「切った貼ったコピペしたのプログラムばっかりを書いてきました」、という証拠の「刹那的・場当たり的な複雑怪奇な枝」になっており、「まったく、単純化・整理がなされていません」。VBAやオブジェクト、VBAのヘルプ、オブジェクトブラウザ、自作関数、クラスモジュール、ローカルウィンドウ、SQL、ADO、DAO、COM、などをちゃんと（というかある程度でも）理解していたら、このような複雑怪奇な枝葉の形には絶対になりません。もっと「ExcelVBAのヘルプベース」のもう少しシンプルな枝葉の形にはるはずです。少なくともオブジェクトやメソッド・プロパティ・ステートメントがあっちゃこっちゃ散らばるようなわけのわからない枝葉にはなりません。おまけに、最も重要な基礎の一つである「オブジェクトの階層構造や上下自由往来機能」のことと「オブジェクト式」のこと、イベントや列挙と定数といったことなどの記述がまったく・一切ありません。（ただ、このようなマインドマップを作ることは非常に有益です。私も偶然同じ、「プログラムの最小単位であるプロシージャを構成する要素」という視点で、でも全く違う内容ですが作っていますが、作ると理解が深まります。何かを1冊読むごとに、必要に応じて書き足したりしています。作り変えなくてすむように、ちゃんと整理してから作り始めたので作り変えになることはありません。）
でも、それが善か悪か？と問われると、初心者のうちはそれで全く問題ないし、著者のいうレベルの「すごい改善」は達成できるわけですから、また、本書にも書いてあるように「プログラマになりたいわけじゃないんだから」ということからすると、とりあえず、善、ということになるのだと思います。
（著者は、絆創膏プログラミングでもいいのでプログラミングになじんだほうがいいと説いているので、その意味では著者の目的はこのような絆創膏な状況でも、達成できているといえますから、著者的にはOKなのだと思いますし、読んでるほうもそれは理解できます。）
ただ、この本で、悪の部分は例えば以下のようなことです。
(01)本当に「ただの絆創膏貼るだけ」の「無駄なコードばかりの」メンテしにくいプログラミングしか身に付かない。
「マクロの記録」で生成されたコードを少し汎用的にしたレベル・意味合いのコードしか書けない。
（それでも著者の言うレベルの、「すごい改善」、になるからいいのですが。
もちろん、マクロの記録は、オブジェクト調査だけでなく、実務にもちゃんと
活かせる方法があり、大変有益ですが。）
(02)だから中級に上がることは不可能。初級のまま永遠に初級で終わる。
(03)メンテナンス性に優れたプログラムコードはこの本を頼りにしていては死んでも書けない(って、私も書けないですけど。)
(04)どこかでシステム外注したくなったときに、かえって混乱を呼ぶコードしか書けない
また、現状のデータを渡した時にとんでもなくネックになる データ形式の xlsm、xlsx、xlsの量産をし続ける。
(05)よって、書けば書くほど、どんどんと「スパゲッティ状態」になって苦しくなってくる
(06)ユーザーフォームの使い方も無駄な使い方をしているので、誤解する人が増える
(07)セルとシートの操作しかできない
(08)グラフ、QueryTableオブジェクト、ピボットのVBA操作などこれっぽっちもできない
(09)「マクロの記録機能」をオブジェクト調査だけでなく、実務に活かす技術は身に付かない。
(10)ExcelVBAのことが分かったとか、自分は中級、といった誤解をし、つまらぬ自信過剰に陥る恐れがある。
(11)近い将来に必ず限界がきて、でも、「他のワンランク上の本が ”初心者用の本であるにもかかわらず” 全然読めない」状況に陥る。
(12)他の初心者本と同様、クラスモジュールのことは理解できないし、また、どのモジュールにどのように作ったプロシージャを、どこからどのようにCallできるかもわからないので、1回作ったプロシージャの再利用ができず、効率が悪い
(13)他の初心者本と同様、値やオブジェクトを返さない自作関数、値やオブジェクトを返す自作関数を作れないので、効率が悪い。値やオブジェクトを返す自作関数を作ってみなければ、ヘルプもオブジェクトブラウザも読めない。
(14)他の初心者本と同様、SQL、QueryTableオブジェクト、ADO、DAO、ODBC、などを使った、別のxls、xlsx、xlsm、を「閉じたまま」書き換えたりができないので、効率が悪くなるケースが出てくる
(15)他の初心者本と同様、COMオートメーションができず、効率が悪くなるケースが出てくる。
(16)他の初心者本と同様、QueryTableオブジェクト（Microsoft Query＝SQL）とピボットをVBAで操作できないので、効率が悪くなるケースが出てくる。
(17)他の初心者本と同様、エラーを自力で解決できないし、Q&Aサイトで質問したところで、回答をくれた方の回答の意味が理解できない。
ついでに書くと、本書では驚愕することに、「For Each文」の事例が「１っつも」書かれておらず、
・For Each文がコレクションに対してだけでなく配列に対しても使えること
・For Each文がコレクションだけでなくセル範囲（Range(セルアドレス）やSelection）
つまり、「セルの一括処理」にも使えること
セルの一括処理の対象としては、
Range("A1:G1"） とか、
Range("A1:G" & カウンタ変数) とか、
Range("A" & カウンタ変数 & ":G" & カウンタ変数) といった指定だけでなく、
Range(名前の定義にてセル範囲に付けた「名前」）や
Worksheet.UsedRange プロパティ（現在使われているセル全部）も もちろん使えます。
・よって、セル操作では Cells プロパティを使わなくても、「横方向のループ処理」としても一応使えることにもなる、ということ
・・・等々の「基本中の基本」がまったく書いてありません。
そんなの、セルアドレスベースのループだけじゃないんだから、絆創膏プログラムにしたって、絶対に教えないといけない項目だと思いますけど・・・。
そのほか・・・、
・Rangeプロパティは縦のループに使いやすい
・Rangeプロパティは「A1:G10」のような指定ができる
・Cellsプロパティは縦はもちろん、横方向もループしやすい
・でもループで一括セル処理をするなら、基本、For Each でやって、特殊な場合のみRangeプロパティやCellsプロパティを使うのも手かも？
・いずれも親オブジェクトがRangeに変わると意味が変わる（相対的なアドレスの意味に変わったりとか）
・Worksheet.UsedRange プロパティのことすら。
・・・などの基本も書いてありません。
これらも、「絆創膏プログラム」であっても最低限必要な項目です。
パソコン操作のスタートはどんなソフトでもまずは「選択から」です。（選択とクリックが同時になることも多いですが）
Excelの場合は「セルの選択」。
つまり、ExcelVBAであれば、RangeプロパティやCellsプロパティ、Rangeオブジェクトを返す何か、です。そのことすらきちんと書いてありません。
「オブジェクトの取得」が「オブジェクトの選択と同じような意味」であること、や、「オブジェクト式を書くということであること、そしてそれは階層構造を省略するとエラーになることもあり、また、省略すると現在アクティブじゃないシートに対する裏方での操作ができない」といったことも書かれていません。
それに、どうやってエラー解決するんでしょうかね？エラールーチンのことも書いてないし。
ぶっちゃけ、終わりのほうのユーザーフォームの話なんて そんなのどうでもいいから（ユーザーフォームはしっかり設計しないと時間の無駄とメンテの敵だから別の専用の本で教えるべき）全部カットして、そのぶん、RangeオブジェクトとFor Each文の詳細説明にあてればよかったのにと思ってしまいます。
これ、言っちゃ悪いですけど、著者だけじゃなく、編集の人もちょっと・・・と思ってしまいます。
少なくとも、編集の人も、まったくVBAを理解できてませんよね。
編集の人がVBAをまったく理解できていないため、著者の「使命感や国益に貢献したいという想い」からくる内容に何のアドバイスもできていません。そういう内容じゃないですよね？この本・・・。
「まずは ”とっかかり” になれればそれでいいんだ」ということだったとしても・・・。
というわけで、本書だけでは、「セルやシートの選択」すらもままならないので、『永遠に初級のまますぐに限界が来る』『メンテしにくい可読性の低いコードしか書けない』『(11)近い将来に必ず限界がきて、でも、「他のワンランク上の本が ”初心者用の本であるにもかかわらず” 全然読めない」状況に陥る。』と書いた理由がお分かりになるのではないでしょうか？
こんないい加減な内容で、「たった1秒で仕事が片づく」というタイトルも、どうなの？と思ってしまいます。
まあ、はじめてVBAに触れた人は当然、そうはなって、びっくらこくんでしょうけど・・・。
本書の最初と終わりで、「プログラミングができる人が増えること」が、著者ご自身の「使命であり、国益につながる」とも説いておられ、それには異存はありませんが、であるなら、もっともっと、「但し書きを増やして」「この本はあくまでも、時間と経費がない人のための ”とりあえず” ばかりを集めたイレギュラー作法の絆創膏プログラミングの本ですよ。これが正しいとは誤解しないでください。あくまで、とっかり、としてご利用ください。」、ということを但し書きとして何度も何度も随所で説明しないといけません。でなければ、初心者の方が誤解をし、国益にはならないし、それに、「たった1秒で仕事が片づく」というタイトルが「国益とはほど遠い安直なふざけたタイトル」となりかねません。
なので、そういう危険性もあることを前提として読むなら、他の初級本とともに、結構役に立つ本だと思います。
（一度つまづいた人が疑問に思うところが、ある程度解消されるような書き方がしてある箇所もありますし、基本、大変にわかりやすくは書いてありますので。おお!こんな方法が！ということも書いてあって大変に勉強になります。ただ、但し書きが少なすぎて、初心者を「誤った道に放り込む」危険性はありますが・・・。）
ただ、この本だけを読むと、「VBAそのもの」を「誤解する」と思いますので、特に初心者の方は、「まじめに多少なりとも高効率性・メンテナンス性をもったコードを書きたい」なら、せめて、終わりのほうの(01)～(03)に挙げたような本も読まれるとよいと思います。
少なくとも本書は「教科書」ではありません。
これを「教科書」として、じゃあ現場で使えるかというと、「絆創膏プログラミング」としてだけしか使えず、やっぱりすぐに限界がきたり、現場の混乱を招くと思います。
もっと、いうと「プログラミングしてしまったがため」の「 ” 新たなデータ管理のムリムダムラ ” 」を『生みかねない』ともいえるかもしれません。
その一例として、P315の「Variant型」の変数の説明で、「型を使い分けようとすることでハードルが上がるならそんなものまったく必要ない」と説いています。Variant型の変数はたしかに便利ですけど、ただ、「あえて型を細かく指定して、おかしな値が入ったときはあえてエラーが出るようにしたい。Variant型の変数はユーザーがセルにどんな間違った値を入れても代入時にはエラーを出さないし、型も稀に意図しない型に勝手に内部変換して余計なエラー・あるいは・エラーのない質の悪いおかしな挙動・を引き寄せてしまうことがあるから。」といった注意は書いてありません。
有名なのは、Inputboxでユーザーから入力された値は「それが数字であっても文字列型データとしてプログラムに返ってくることになります。結果それが、Variant型の変数に代入されると数値型のデータではなく文字列型データとして変数内部で自動変換されるので、”計算ができない数字” が代入された、という扱いになります。」ということなどです。
つまり、Variant型変数を使う場合は、例えば関数で返ってきたものがどんな型のデータなのか？を常に意識しなければならないといえばそうです。そんなシーンは少ないかもしれませんが、結局は型の勉強を最初からやっていれば「そんなトラブルにはもともと出会わない」です。それに明確に型を指定していれば、代入時やその後の処理でエラーになるから「なんで？」となり、そこでひとつ自然に勉強ができます。
「なんで？」となったときにヘルプ読めば、Inputboxのヘルプの1行目どころか、1語目から「文字列型 (String) の値を返します。」と書いてあるから、「あ！数値に変えてあげればいいのね！？」とすぐにわかります。
Variant型だとエラーにすらならないので、Step実行だけのチェックじゃあ「ちゃんと300って入っているし・・・」、なんて感じで気づけない初心者が多いと思います。周囲に分かる人が居なければ、下手すると数日悩みます。
「文字列型 (String) の値を返します。」の意味すらわからない・・・とか。
といいますか、「型のことすら覚えらえれないくらい理解度・やる気の低い生徒・型のことを初心者にわかりやすく説明できない先生」「関数の戻り値の重要さを教えない授業」って、いったんなんなん？それってそんな本が「教科書」「授業」と呼べる？
一事が万事、こういう姿勢で教えてくれちゃうことになるの？→たいていそうなります。
これがどういうことか、わからない人はいないと思いますけど、著者はそれでも「そんなもの（型指定なんて）まったく必要ない。全部・いつでもVariant型でOK！」と説いています。
ハードルがあがるとかじゃなくて、エラーを未然に防ぐ、という考え方がないのが悲しいです。
そのほか例えば、「LongではなくあえてIntegerを使うことでプログラムの規模感を表現する・規模感が分かる・もちろんユーザー目線に立った不都合回避にも役立つ」という考え方もありません。
「他のユーザーなんかしったこっちゃねえ。俺だけが使うんだから」ということなら「教科書」を名乗らないでほしいです。
たのみますから。
迷惑だし、国益になりませんから・・・。
「ハードルが高い低いじゃなくて、初心者だろうが何だろうが、プログラマになるわけじゃなかろうが、TPOごとに・シーンごとに・やるべきことがある。やっておかねばならないことがある。やるべきことをやらないでおいて、あなたは本当にそれでいいのか？という問いもある。」ということを知っておかないと「自分の作ったプログラムを ” 過信 ” して、とんでもない事故に巻き込まれる（賠償問題とか・降格とか）」といった可能性もないではありません。
この手の本の怖いところは「自分を過信する確率が上がりやすい」ことや「この手の本こそ本物だと超絶マズイ勘違いをする」などです。（でも本書は、ぜんぜん「本物」ではないです。）
そんなときこの本が責任をとってくれるかというと、「責任など取るわけがない。」です。
だから「型なんていらない」ということを「安易に」言うのは、「ある意味、犯罪」でもあります。
少なくとも「プロのとる姿勢」ではありませんし、「国益を考える人のすることではありません」。
この感想文で一番言いたいのはここです。
本書はすごく便利だけど、ホンモノではありません。
もちろん、「教科書」レベルでもありません。
なので、妄信はダメです。
信じすぎるとあとで必ず痛い目を見ます。
ということです。
※特に本書は初心者の方にとっては「おお！！！」という役立ち情報があるので、なおさら、マジで、「この手の本こそ本物だと超絶マズイ勘違いをする」不運なことになりやすいと思います。私もExcelVBAは初心者なので思わずユーザーフォームの列の指定のところでは「おおお！！！なるほど！そんな手があったか！考えてるなあ～！！」と思ってしまいました。もちろん、ADOとか使った方が列を挿入・入替えしても名前の定義の再設定もいらない上に・列名ベースでプログラムが書けるし、SQLも使えて、かつ、閉じた別のExcelファイルにも書き込めるので多分もっとラクではありますが・・・。でも、「おおお！！！」と思ってしまいました。「このレベル・規模ならシートをフォーム替わり・フォーム状にするかな・・・」と思いつつ、でも正直「おお！！すごい！！」と思ってしまいました。なるほど、もしかしてこれをクラスモジュールでオブジェクト化できたらもっと便利になるのかな？・・・みたいな・・・。でも私はADOとかSQLのほうが便利だから当面はしないですけど・・・。もっというとフォーム使うならもうAccess使ったほうがはやい・・・。こんなフォーム（というかコレの3倍以上の機能のものが）、ノンプログラミングで30秒～1分で自動で作れてしまうので・・・（Excelシート状のビューと通常フォームのビューに即座に切り替えられるフォームが）。この程度のフォーム作るのにいちいちVBAなんか使いたくないです。めんどくさい。
ただ、やっぱり、結構な面白いテクニックが詰まっているので、本書のことを初心者の方は、「この手の本こそ本物だと超絶マズイ勘違いをする」だろうなあぁ～、と強く感じました。※
話が逸れてすみません。
そもそも「型なんていらない！全部・いつでもVariant型でOK！」と言いたいなら、せめて、前述のInputboxの例のことを言うとか、関数の戻り値の勉強をさせてから、とか、「ステップ実行+ローカルウィンドウ」を使った、「Variant型の型が内部で本当に正しく自動変換されているのかどうか？ユーザーのセル入力値がめちゃめちゃなせいで代入時に意図しない型に自動変換されてしまっていないか？のチェック方法」くらいは教えてあげないといけません。が、本書にはその説明は1語たりともありません。
もちろん、詳細説明は紙面が足りないのでできないでしょうから、なら、そのことに関する補足の説明・サマリーを「まずちゃんと書いて」、そのうえで自分のWebページの直リンクのアドレスくらい書いておかないと、そのようなことを当然のごとく知っている人たちからすると、本当に「いい迷惑」「絶対に一緒に仕事したくない」「そんなことも知らないのか？」「今までおまえ何やってたんだ？」と本書を読んだ人が責められてしまいます。
なのに、もちろん、「補足の説明を書いた自分のWebページの直リンクのアドレス」も書いてありません。
私なら「そんなものいらない」とは間違っても書きません。
「最初のうちは理解しづらいかもしれないので、現時点ではあえてここでは詳しくは説明しませんが、型を明示的に宣言することは基本です。絶対にどこかでやったほうがいいです。理由や詳細を知りたい人はこちらのWebページを。どんな習い事でも基本をないがしろにする人はいつまでたってもまったく成長しないですけど、逆に、基本を掘り下げる人はあるときビッグバンが来て爆発的に伸びます。もちろん皆さんはプログラマになるわけじゃないとは思いますが、でも、どんなことでもお仕事のことじゃなくても、本物のプロほど、レジェンドになってからでも、延々と基礎を磨いています。というか、基礎のレベルが尋常じゃないほど高すぎて、基礎の8割だけでメシが食えちゃっています。」と説明します。
基本をおさえず、「手っ取り早く結果だけがほしい」「ずっとそれでOK」だなんて、結局はいつも・・・・
「このエラーどうしたらいいの？」
「このWebページの意味って何？」
「Q&Aサイトに質問したけど意味わかんない！」
となるだけです。（プログラマじゃない人で、「やってるうちに自然にわかってくる人」なんていうのはほんのひとにぎりです。これを読んでいるあなたは多分、そうじゃありません。私もそうだし。）
「誰でもできる」というようなことも書いてありますが、それも大きなウソ、です。
真実とは違います。現実はそんなに甘くありません。
「レッスン料払えるだけのお金と時間とやる気がある人」「独学するならそれを上回る熱量のある人」「コツコツ地道に続けられる人」「しか」、「基本的には」、自力でVBAで色々作れるようにはなりません。
自力でのエラー解決なんて夢のまた夢。
「誰でもできる ”可能性はある” けど、結局は本人の ”熱量” 次第。誰でもできるってわけじゃない。」っていうのが「真実」なのに、「誰でもできる」という「嘘」を平気でつく。誰でも「始める」、ことはできますけど・・・・。
そして、VBAは「中級以上に上がらなければ、何の効果も出ないもの」です。
普通、「VBAの中級」というと、前述の(01)から(17)までを「全部解決・クリアできる人」を言います。
（私はグラフが動かせないので初級です。）
それまでに挫折すれば、かけた時間とお金が全部無駄になります。
これは、「そのVBA、頼むから個人だけで人知れずひっそりと使ってくださいね？」、「頼むから本書のVBAの内容で他人のデータまで操作しないでくださいね？社内共用のデータなんて死んでも触らないでね？」、「少なくとも私のデータは頼むからこのVBAで触らないでくださいね？」というレベルの話・・・・、というかそういう感じの本の内容・・・・です。
私なら、この本「だけ」を読んだ人には、「もちろんこの本もとっても有益だけど、但し書きが少なすぎてバカな勘違いもしやすいから、頼むからこの本と、この本と、この本も絶対に一語一句、理解しておいてね。わからないところは全部僕に聞いて。」と、追加で他の本を数冊渡します。
本書のような「絆創膏プログラミング」としてしか使えず、「ソースのExcelファイルのデータの持ち方も考えない非効率データを量産させる方法を得意げに教える本」、「プログラミングしてしまったがために新たなデータ管理のムリムダムラと現場の混乱を生みかねない本」を「教科書」と言っていいのかどうか？というところだと思います。
少なくとも「教科書」と呼べるようなスタンダードなものではありません。
（もちろん、著者の独自性はあっても全然OKですけど、まとめ方が悪いと、やはり「教科書」と書かれてしまうと現場としては「いい迷惑」です。『ヘルプもオブジェクトブラウザも使えず・オブジェクトに何が含まれているかさえきちんと理解できていない・オブジェクトを返す自作関数すら作れない・この本がスタンダードだと勘違いする初心者』が激増してしまうから・・・。あくまでも本書は、とっかかりのためだけ、の「イレギュラー作法・筆者の趣味作法・筆者の好きな作法の絆創膏プログラミング本」、であり、「教科書」ではありません。）
ここ数年で発売された「教科書」と銘打った本は、多くがコンサルの自己満本、そのコンサルの勝手なルールの強要、コンサル以外の他の業種・職種・シーンを全く考えてない、という側面が強いと思います。
そんな本を本当に「教科書」と呼んでいいのかどうか？
出版社や編集者はいったい何をしているのか？
「即戦力がほしい」という求人と同じ。
自社内であきらめずにコツコツ時間をかけて人材を育て上げる視点がない。
即戦力になる人はもちろん すごいしほしいけど、それ一辺倒ではいつか大コケします。
「両方」の視点がないと・・・。
「自社内でコツコツ時間をかけて人材を育て上げる視点がない。」とは、
自社内であきらめずにコツコツ時間をかけて人材を育て上げる能力・ノウハウ・「理念・理想・倫理観・人生観」、が自社にない、ということを意味すると思います。
「そんな悠長なこと言ってるヒマあるか！」という考えに凝り固まり、即戦力の人ばかり求めれば、結果、「他人の幸せを願うことでしか、自分が幸せになることはできない。それを考える余裕を作れないほど詰め込みすぎればいずれ風船ははじけ飛ぶ。」という基本から大きく外れます。
本書を読んだ後、あるいは、読む前に、以下の(01)～(03)のような本（特に02と03）は絶対に読んでおかないと、本書だけでは、「悪いVBAのまま」それに終始することになると思います。（ちなみにですが、ExcelVBAのレジェンドさんたちの初心者本は、初心者の方はあまり読まないほうが無難です。初心者目線で書かれておらず理解できにくいですから・・・。）
そして「(11)必ず限界がきて、でも、「他のワンランク上の本が全然読めない」状況に陥る。」ということになると思います。十分にお気を付けください。
特に初心者の方と自称中級者の方・・・。
(01)超初心者のころのメイン01（セルとシートの操作中心。一般変数の扱いすらなしの「超」初心者用）
図解! Excel VBAのツボとコツがゼッタイにわかる本 “超"入門編 単行本 – 2018/3/28
立山秀利 (著)
「超」初心者用ですが、でも、、初心者の方が陥りやすいエラーへの対処、初心者がおこなうべき考え方、などがよくまとまっています。
(02)超初心者のころのメイン02（一般変数＝絵文字ベース生データの操作と、セル・シート操作中心）
スラスラ読める Excel VBA ふりがなプログラミング
(ふりがなプログラミングシリーズ) 単行本（ソフトカバー） – 2018/9/21
リブロワークス (著)
こちらも、初心者の陥りやすいエラーへの対処、初心者がおこなうべき考え方、などがよくまとまっています。
本書よりも、「もっと詳しい」VBAコードの「訳し方」が載っています。
また、本書には書かれていない、For Each文がコレクションだけでなく配列にも使えることが書いてあります。
ちゃんと「一般変数（文字ベース変数や生データ）の操作とオブジェクト変数（オブジェクト）の操作に分けられて説明されている」し、初心者本としてはいろんな点から「隠れた名著」、です。
(03)本当の意味での真の基礎本・「教科書」（一般変数＝絵文字ベース生データの操作と、セル・シート操作中心）
いちばんやさしいExcelVBAの教本
人気講師が教える実務に役立つマクロの始め方
(「いちばんやさしい教本」シリーズ)
伊藤潔人 (著)
初心者の方には、8章以降がちょっと難しいですが、こういう「真の意味でちゃんとした先生」に習わないと、結局、VBAを誤解したまま進むことになると思います。本書には書いてないけど「必須」の「ローカルウィンドウの使い方・その他」、など、VBAを誤解しないように進むための考え方が（初心者の方とっては）豊富に書いてあります。
この本でわからないところがあったら、必ずわかる人に聞くといいです。
基本、この本を読んで理解できない箇所が一か所でもあれば、「ExcelVBAを正しく理解できていない」、ということになります。つまりこの本は「指標」になります。他の初心者本は、そういう使い方ができません。
RangeとCellsのループの違いのことや、ステップアップするために次の段階ですべきことが書いてあります。
この先生は、どのレジェンドさんよりも「ちゃんとして」ます。
ヘルプやオブジェクトブラウザをいいかげんに済まさない先生、初心者に対してだからこそそこから逃げない先生は、どのレジェンドさん達をも差し置いて、私が知っている中では今のところこの先生だけです。知らない人ですけど。
私は、ExcelVBAのレジェンドさんたちはある意味、ExcelVBA教育を間違ったと思っています。
少なくとも、「ヘルプとオブジェクトブラウザを初心者でもわかるように説明すること」からは、レジェンドさんたちは今でも逃げまくっています。そして「経験させないから育たない」ということを全くわかっていません。
彼らのせいで、5~10年分くらいは、「データ管理の基礎」と「それをサポートするVBA」の学習を後退させたのではないか？とすら思っています。
だから20年前の自著と同じ教え方しかしてなくて進歩がありません。
ある意味あぐらかいているとも言えるかもしれません。
私はExcelよりも先にAccessVBAなどを20年前から初めて、一応30台規模の零細様のRDBシステムもどきの面倒を13年ほど見させていただいています。なのにAccessもろくに扱えませんが、ただまあ、でも今ようやくExcelVBAを勉強し始めました。なので、ExcelVBAは超ド素人です。
が、「ExcelVBAのレジェンドさん達がVBA教え方を間違った・そして今も間違ったまま全然変わってない」というのは「習う側」としての率直な感想です。
(04)そして以下の最強のリファレンス本。
Excel VBA逆引き辞典パーフェクト 第3版 単行本（ソフトカバー） – 2016/7/15
田中 亨 (著)
↑かなり便利です。Web検索するよりも早くて便利かも？
やれることだけでなく、やれないことなどもたくさん書いてあり、実務において大変に便利です。
でも本書を読むだけでは、使いこなせないでしょう。例えば(01)～(03)も読まないと理解できないと思います。
(05)ExcelVBA 実戦のための技術
沢内 晴彦 (著)
「自称」ではなく、「真の中級」に上がりたい人は絶対に買ったほうがよい本です。クラスモジュールや自作イベント自作のオブジェクトなどについてもわかりやすく書かれていますし、オブジェクトや関数などの深いところのお話もあって、他の書籍ではまず得られない「的を得たTips」がかなりそろっています。「中級者の色んな迷いをかなり消し去って上級者へのきっかけを間違いなくつくってくれる本」です。Web情報探す前にこちら読んだほうが早いです。
数ある中級者本の中では他の追随を許さぬ程、圧倒的にわかりやすく役に立つ本です。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
関連記事
◆ 「ピボットテーブルを使ってはいけない」と書かれている市販書籍をどう考えたらい？？
◆ ビジネスデータ管理においては、「ピボットテーブルやMicrosoft Query」は
「VBAプログラミングよりもはるかに重要な機能」なのに
何故かあまり広まっておらず、「データ管理のムリ・ムダ・ムラ」が
Excel2000の時代からほぼ減っていない理由
（むしろ増えている場合もあるかも？）
(01)マイクロソフトさんの誤認と姿勢。
(02)Excelのレジェンドさんやプロの方々の誤認と姿勢。
(03)上記２つの理由からの大小 一般のパソコン教室さんの誤認と姿勢。
(04)特にピボットは上記３つの理由からの表のレイアウトがしにくいとか、
自由にならないと誤解されているから。集計が難しいとの誤解も。
(05)上記4つの理由から、ただの反復練習不足の状況になってしまいました。
※「ピボットテーブルやMicrosoft Query」は中小様や零細様、個人事業主様、
学生さん、にとっては、VBAプログラミングよりもはるかに重要な機能です。
日本の企業の数は中小・零細・個人事業様が8割以上？と聞き及びますので、
そこに広まっていないというのは、
「日本のデータ管理教育やExcel教育は完全に失敗している」
ということを意味していると思います。
