● 「ピボットテーブルを使ってはいけない」と書かれている市販書籍については、どう考えたらいいのでしょう？？
※この記事は後半ごろに、問題提起のため、Excelユーザーの声として敢えて品のない言葉遣いが出てきます。ご気分を害してしまったら本当に申し訳ございませんが、品の良い言葉だと問題提起にも何もならないと思い、使ってしまいました。本当は良くないことです。本当に申し訳ございません。でもどうかお許しを・・・。
早速ですみませんが・・・・狭い視野で「ピボットを使ってはいけない」、と何の但し書きもなく書いている、例えば『「教科書」や「プロ技」「すごい」を銘打った市販Excel関連書籍を書いているノータリンでバカな低能著者ども（ただの関数バカ・VBAバカ・専門バカ） 』に足りない視点を表現している優れた大人な考え方のWebページの「良い事例」を先にご紹介しておきます。
Excel ピボットテーブルは「表形式」でさらに使いやすくなる
特にお若い方々は、↑こういう書き方のできる、「人格の」優れた方からExcelの基礎やデータ管理の基礎を習いましょう。「専門バカども」や僕のような人間 に習うと、いつか自分が痛い目を見てしまいます。どうかお気を付けください。
あと、「ピボットを使うとモトデータ（ソースとなる表）の行や列が増えたときにいちいちデータ範囲を設定し直さなければならいから使えない」、という意見がありますが、これは間違いです。
昔から・・・、つまり（Excel97はどうかわかりませんが）、最低限2000～2016のほぼ全てのバージョンで、ピボットのソースとなる表において「名前の定義」の機能で
「=OFFSET($A$1,0,0,COUNTA($A:$A),COUNTA($1:$1))」
という式を、シート名に関係なくまんまでコピペすることによって、ソース表の行や列がどれだけ増えようと減ろうとも、いちいちデータ範囲の再設定をする必要はありません。以下の記事もご参考にしてください。
・ピボットテーブルのソースの表を、行も列も可変にして、再設定しなくても済むようにする方法 ２つ（「=OFFSET($A$1,0,0,COUNTA($A:$A),COUNTA($1:$1))」とテーブル機能
https://euc-access-excel-db.com/tips/ct08_exceltruebasic/ct080820_make_table_rule/src01
2007以降なら「テーブル」という機能も用いることができます。
特に、古くて関数ばかりを推奨するExcelのWebページには、このことが抜け落ちているページしか存在しないので盲信しないようにご注意ください。
また、モトのソース表から Microsoft Queryを経由させてそこそこ複雑な条件でデータ（レコード）を絞り込んだシート（表）を作ると、それもピボットのソースにできます。Microsoft Query側でソース表の条件をころころと変えて絞り込み、都度、連動してピボット集計できるのでかなり便利で、無駄なVBAを排除できます。通常の「フィルタ」や「2007以降のテーブル機能（のフィルタ）」ではソース表の絞り込み結果がピボットに連動しないのでできませんが、Microsoft Queryなら連動するのでできるのです。「2007以降のテーブル機能」ではソースの表の列と行の増減には連動してくれますが、フィルタ結果は連動してくれません。
もちろん、そのMicrosoft Queryを経由したシート（表）にも「=OFFSET($A$1,0,0,COUNTA($A:$A),COUNTA($1:$1))」での名前定義ができますので、行や列が増えても減っても、ピボットソースの範囲の設定変更は要りません。また、Microsoft Queryでの絞り込み結果によって行や列が減ったときでも、「空白」項目の集計が出てくることもありません。
この記事は、その前提でお読み下さい。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以下本文
最近よく目にするのが、市販書籍において、「ピボットテーブルを使ってはいけない」という感じで書かれているものです。
このことについてどう考えたら良いでしょうか？
本当に「ピボットテーブルを使ってはいけない」のでしょうか？
そのことについて、皆さんが悩んでしまうといけないので少し書かせていただきました。
例えばPOSレジデータや、他人からもらうデータで次のような明細形式の表をソース表（おお元の表）としてもらうことがあります。
（シートA）ソース表
で、この表を違う形に加工したりまとめたりして、現状把握や原因調査、対策立案などをしたいとします。
このとき上図のソース表をもとに、新たに作成する表として、例えば次のような2つのタイプがあったとします。
（シートB）ピボットテーブルを1シート内に小さく、しかし、数を多めにたくさん使う。
（シートC）1枚の表の中にできるだけ多くの情報を詰め込む。（ピボット不使用）
（シートB）の場合は以下のような感じです。
そして、（シートC）の場合は以下のような感じです。
「ピボットテーブルを使ってはいけない」と声高に叫ばれていたり、「ほどほどに」と書かれている市販書籍は、多くが、（シートC）のような表やこれのもっと大きくなった表を「関数をバンバン使って」作る場合に限っていると思います。（大抵は前後のどこかにそう断り書きがしてあります。もしくは断り書きが無ければそのような文脈のはずです。）
別の言い方をすると、「関数バンバン使う系」の「関数信者」の人しか、「ピボットテーブルを使ってはいけない」とはまず言わない、とも言えます。
（いずれにしましてもケース限定のそう大した話ではないと思いますので、それほど気にしないでください。）
例えば（シートC）のような表がもっと大きくなったとき・・・
例えば地域別に四半期ごとに数字を出したり、前年度と比較したり、目標や達成率を出したりなど、より多くの情報を1枚の表の中に詰め込みたいとき、そんなときはピボットテーブルを使うよりも関数で処理してしまったほうが速く済む場合があります。
（それでも僕の場合はメンテの意味からも ピボットを使ってしまうことのほうが多いですけど…。Microsoft Queryも併用するのでそのほうが、「僕の仕事では」効率が良いためです。）
なので、いつも「ピボットテーブルを使ってはいけない」というわけではなく「（シートC）のような表を作りたいとき」「1枚の表に情報をつめこみたいとき」は、あえて「ピボットテーブルを使わないほうがいいケースが多い」ということだと思います。
いずれにしても、数字を見たいときは、（シートB）のように、１シート内にいくつかの異なる切り口の小さなピボットを置いていろんな角度から見ることも大切ですし、逆に（シートC）のように「1枚の表に情報をつめこんだ表」のほうが何かが分かりやすい場合もあります。
両方必要な場合もあります。
特に（シートC）は見慣れるとプロの方やコンサルさんにはそれだけで何かの判断材料になるのかもしれません。（ただ、現場の従業員さんはそういう方は少ないと思いますが・・・）
半面、会議の目的によっては、（シートC）のような表（あるいは、地域別・四半期別・前年比など付加したもの）では全く役に立たない場合もあります。
もしあなたが社長さんなら、「原因の発見と対策の考案」の会議をしたいと思った時、（シートB）と（シートC）のどちらが欲しいですか？
（シートC）の表が、例えば地域別・四半期別・前年比など諸々の列が付加されてより詳しくなったとして、で、現状把握、詳細把握、原因調査、対策考案、どれができそうですか？
普通で考えたら、地域別・四半期別・前年比などが出てたところで、「減った」「増えた」の事実が分かるだけで「原因までは分かるわけない」ですよね。
（数値分析的に特殊な能力や勘を持った人以外は。つまり現場の半数以上の人。）
原因が分からなければ対策が考え付くはずもありませんよね。
業種によっては「昨年データや四半期データなんか役に立たんだろ？毎年状況まったく変わるんだから。今はどうなのよ？今現在は！なんで数字が落ち込んでるの？原因は何？」ということもあると思います。
なら、もし会議の目的が「現状把握や原因調査、対策立案などをしたい」ということなら、必要なのは（シートB）であり（シートC）ではありません。
会議の出席者が経営トップだけでなく、現場の人たちも居れば尚更です。
なら、（シートC）のような表ばかりを関数で作りまくる意味がありますか？
無駄じゃない？
作成者の時間を奪ってない？
そんな仕事、見直して減らしてもいいのでは？
もっと重要なお仕事があるのでは？
（もちろん削れない理由もあると思いますし、CもBも必要なシーンもあると思います。もしそうならもちろんシートCを作り続ければいいと思います。お仕事内容の見直しの機会があるかも？というだけのことですので・・・。）
※（シートC）でも特定地域が極端に下がっていて「おかしい」となれば、経営トップはそれだけで、深く原因を探すまでもなく「地区別に戦略を！急務！」と決定づけることもできますが、その際でも、実際現場で対策を考案し実行する現場の従業員は、「もう少し細かいデータ」「状況」「原因」を欲しがると思います。なので、（シートB）のような表たちは必要になると思います。
注目すべき点は、（シートB）も（シートC）も、もとは、まったく同じ（シートA）から生み出されている・・・という点です。
まったく同じ表から、まったく次元の違うそれぞれが生み出されています。
目的によっては、かたや役に立ち、かたや、ほとんど役に立たない。それはTPOで変化していくものです。
どんな時に、どちらをどう作るかは、あなたの判断です。
もちろん、TPO（会議の目的等々）によっては、逆に（シートB）よりも（シートC）のような表が大切になってくる場合もあります。
結局は、全部の機能を、TPOに合わせて、コーディネイトバランスをうまく変えて、「何かを得意とする機能はそれに任せて活用していくのがよい」「機能もソフトも適材適所で良いとこどり・補い合う」、というのは変わらないと思いますので、「どれかの機能」を「使ってはいけない」というケースは、もしシーンが限定的であっても、基本、「ありえません」から、そのようにお考え下さい。
機能の使用頻度のバランス/ウェイトが変わるだけで「まったくもってどれかが使えない」、という事態にはならないはずです。
人それぞれ、業種も職種も会議や書類提出の目的もTPOで何もかもが違いますから、Excelの機能に関しては「本やWebに書いてあったから」というだけで「思い込み」「決めつけ」だけはしないほうが良いと思います。
是非、いろんな機能を、ご自分で試して、使ってみて、ご自分の答えを出してください。
当サイトでは、その意味でも、普段あまり使われないピボットや Microsoft Query についてお伝えさせて頂いています。
是非、「FM集計のできる バーコードPOSレジのサンプル」程度なら、本サイトの説明書通りにやっていただければ誰でも作れますので、どうぞ、そういうところからお試しになって、関数やVBAの位置づけをご自分なりにしてみてください。
基本的に・・・
どれかの機能に心酔していて、「これ一本覚えておけば全部できる・全部まかなえる・他の機能はほどほどでいい」ということを言う人や本のことは、全部まるまるは信用しないほうがいいです。（ついでに・・・「Excelで地図から何から何まで、Wordで作るような長文までも作る」、というのもその一種です。個人としては便利なのでいいと思うのでお好きにしたらよいのですが、チームとしては迷惑以外の何物でもありません。少なくとも「相手の立場を考えられない時に使う最終手段。」「今の自分にはこれしか方法がありませんでした。許してください。」、という類のものであって、「あれもこれもできちゃうよ？！すごいでしょ？！」、と自慢げにやるものではありません。）
そういう人は部下やお客様についても、そういう扱いをしかねません。
全部いっしょくたにしていい、という決めつけ。思い込み。
そういう人や本は、「自分の業種や職種の中だけで考えている可能性が高く」、「他人の業種や職種」「ましてや他人のコストのことなど、独学コスト、教習コスト、時間コスト、金額コスト」等々、ほとんど考えてないと思います。何でもタダじゃないことや、短時間に覚えられるわけでもないことを隠します。相手をめくらにさせようとします。自分が褒められでもしたいのでしょうか？
多くのことをカバーできる機能やソフトなどあるわけがありません。
もしそんなものがあるとしても、それは「絶対に儲かる」という話と同じです。
「セールストークの "何でもできます" は、結局は、"何もできないということと同じ" だから信用しないように」という話と同じです。
そういう人や本のことをむやみに信じると、あなたの業種・職種・立場・TOPにとって、本当にコスト削減や売上増（数字見たくらいで売上増にはなりませんが）に役立つ機能や手順を、ご自分で探そうとする機会を奪われて、スルーさせられてしまいます。
人は、よくわからないもの、に対しては盲目的に信じ込んでしまうので（僕なんて特にそうなので）、注意が必要です。
半分はもちろん便利な機能をお教えしてくれているので信じて活用すればいいですが、半分は信じないほうが無難です。
ご自分で実際に試してみて、動かしてみて、本の言うことは正しいか、間違いか、ご自分自身で、ご判断してみてください。
僕が今言ってることだってそうです。
怪しい。
盲目的に信じないで、自分で、Excelを動かす中でご判断ください。
また、「ITについての”すごい人や本”」に我々現場や経営者の立場から言いたいのは、「VBAプログラム、アルゴリズム、関数、ネストした数式、そんなこと考えないとこんな単純な足し算や構成比出しもできないのか？コンピュータなんだろ？数字を「分析」するプロなんだろ？足し算くらいちゃちゃちゃっとやれる方法を教えてくれよ。我々はコンサルやエンジニアになりたいわけじゃないんだ。数字が知りたいだけなんだ。プロセスなんていいんだ。きれいな表が作りたいわけじゃないんだ。俺のような「バカでも」「すぐに」「いつでも」「欲しい数字」が「Excelだけで」出せる方法を教えてくれよ。基本的なビジネスの定型集計がやりたいだけなんだよ。自作関数なんて使いたくない。ネストした数式なんて使いたくない。何も覚えたくないドシロートでもやれる方法を教えてくれ。覚える時間が無い。基本的なビジネスの定型集計やりたいだけなのに、なんでVBAなんて覚えなくちゃなんねんだ？なんで２０年ものあいだ機能が進化してないんだ？」ということです。
これまでの２０年と同じようにこれからの２０年／３０年も同じまま？
VBAと関数をバリバリ使いこなせないと永遠に俺たちにはExcelじゃあ何もできないの？
この先もこの２０年と変わらないの？
俺たちの子供も孫もVBAと関数バリバリじゃなきゃExcelで数字出せないのか？
２０年も？３０年も？
Excelはどこまで進化しないつもりなんだ？
イレギュラー集計じゃなくて定型集計だぞ？どんな業種にもある定型集計だぞ？
月度集計とかこんなよくある定型集計がしたいだけなんだよ。→こちら
Excelって２０年以上あるだろ？さすがにこんな定型集計、簡単にできるはずだろ？
コンピュータなんだろ？１秒間に何十億回って計算してるんじゃねえのかよ？
なんで２０年もの間、それが簡単に出せないの？
ラクになってないじゃん。
独学コスト、教習コスト、集計の仕事のコスト、その他諸々、下がってないじゃん。
生産性上がってないじゃん。
プログラマすら、ピボットのこと深く知らないじゃん。
Microsoftは、Accessはもう見捨てたんだろう？だったらExcelのほうでリレーショナルな機能やMSQueryをもっともっと強化してくれよ。
もちろん、「何も覚える気が無いならおとといきやがれ。」と言われてしまうでしょう。
「コンピュータは、何も覚えようとしない人間、コンピュータに寄り添おうとしない人間には、どんなに素晴らしいソフトがあったとしてもただの箱のまま」です。
でも、それでも、「コンピュータなんだろう？あんたら何年使ってんだよ？Excelのやり方２０年前と変わってねーじゃねーかよ？ほかのやり方教えてくれようとしたか？CPUが速くなっただけじゃねーか。」というのが本心であることも事実のひとつだと思うのです。
・・・なんてエラそうに言ってても・・・
・・・逆に 僕は ピボット＆ Microsoft Query びいきなのでそこが悪いところですね(^^)
反省します・・・。
他人のフリ見て我がフリ直さないと・・・。
僕の言っていることも話半分くらいで聞いてください。（僕が言っている「Excelの真の基礎」が役に立つのは、主にビジネス定型集計やビジネス定型リストアップの部分だけで、シュミレーションや高度で専門的、イレギュラーな集計にはあまり向きませんから利用頻度は落ちますので。）
でもちゃんと関数も使わせて頂いてますよ。(^^)
関数無しでは、ピボットも Microsoft Query も生き生きしてこないですから・・・。
ただ、「ピボット＆ Microsoft Query」 でわかるところはそれで出し、「無駄な集計はやめましょう」「こんな集計は無意味。どうせあとで見ないでしょ？ピボット＆ Microsoft Queryで必要に応じて出すだけでいい。」、と無駄な計算業務や無駄な書類作成を減らしてきたので 必要以上に無駄に使ってはいませんが・・・。
といいますか、僕は事務系のお仕事は零細の小売業でしかしたことがないし、僕の仕事では（シートC)のような表があまり必要なかったのでもう（シートC)のような表を作る時間がもったいないくてどんどん減らしました。
解析能力、分析能力が無かっただけかもしれないですが・・・。
大企業の方は（シートC)のような表をでっかくしたような表がいたるところで必要で、非常に有用なのかもしれません・・・。
もしそうでしたら無知であること、本当にごめんなさい。
（シートC）のような表は銀行さんに求められたときくらいだったかなあ・・・。
それでも資金繰り表とかそれに関連する表だったと思ったから、別に、関数ってこともないくらいですけど・・・。
最近は付き合いもないので、本当に作らなくなりました。
今はどうしても関数必要なところ（とき）だけ、Web検索しながら、慣れない手つきで必死で関数使ってます。
特に、関数を多用した表が回ってきたときに必死になります。
（もともと関数はそう使わないので頻度は多くないですが・・・(^^)）
では、以降、ピボットを使ったサンプル群になりますので（MicrosoftQueryも併用してまっすが）、どんなときにピボットが使えるのかとか、ピボットを使ってどうデータを読んでみたらいいのかとか、体験してみてください。
＊＊＊＊＊＊＊＊＊＊＊
★ 前述の シートA、シートB 的なものを使ったサンプル
ダウンロード（サンプルxlsファイルあり）
http://euc-access-excel-db.com/mag2charge/pos/pivot_mini_commentary.zip
上記の ZIPに同梱のWordファイルの説明書をPDF化したもの
ピボットの動かし方や初歩的なデータの見方などが書いてあります。
http://euc-access-excel-db.com/mag2charge/pos/pivot_mini_commentary.pdf
※本サイトのPDFはWord2010でPDF化したせいか、PDFの中にVBAコードなどが書いてあってもそれを正常にコピペできません。Zipの中にモトのdocファイルがあるPDFは、そのdocファイルのほうのVBAコードなどをコピペしてください。無い場合はすみませんが手打ちで入力してください。
＝＝＝＝＝＝＝＝＝
※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情報探す前にこちら読んだほうが早いです。
数ある中級者本の中では他の追随を許さぬ程、圧倒的にわかりやすく役に立つ本です。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
● Excel2000で30分で作るバーコードPOSレジのコア部分（定型集計効率化サンプル）
● GUI簡易SQL：Microsoft Queryの使い方（Excel2010でもほぼ同じ操作です）
～ビジネスデータ管理（コスト減等も）を2～100倍効率化するツールその1
● ピボットテーブルでできること
● ピボットテーブルの使い方
～ビジネスデータ管理（コスト減等も）を2～100倍効率化するツールその2
● ピボットテーブルの集計動作のイメージとソースの表の作り方
● Excel＋Wordで明細付きの顧客別差込み印刷（顧客別連続明細印刷・基本VBAゼロ）
※「Microsoft Query」を使用しているため各種条件も変更できるので
一度作ると条件別に印刷が可能（期間別、ランク別、地域別、明細内容等々）
