「ピボットテーブルを使ってはいけない」と書かれている市販書籍については、どう考えたらいいのでしょう??※この記事は後半ごろに、問題提起のため、Excelユーザーの声として敢えて品のない言葉遣いが出てきます。ご気分を害してしまったら本当に申し訳ございませんが、品の良い言葉だと問題提起にも何もならないと思い、使ってしまいました。本当は良くないことです。本当に申し訳ございません。』に足りない視点を表現している優れた大人な考え方のWebページの「良い事例」を先にご紹介しておきます。ピボットテーブルは「表形式」でさらに使いやすくなる特にお若い方々は、↑こういう書き方のできる、「人格の」優れた方からExcelの基礎やデータ管理の基礎を習いましょう。習うと、いつか自分が痛い目を見てしまいます。あと、「ピボットを使うとモトデータ(ソースとなる表)の行や列が増えたときにいちいちデータ範囲を設定し直さなければならいから使えない」、という意見がありますが、これは間違いです。昔から・・・、つまり(Excel97はどうかわかりませんが)、最低限2000~2016のほぼ全てのバージョンで、ピボットのソースとなる表において「名前の定義」の機能で「=OFFSET($A$1,0,0,COUNTA($A:$A),COUNTA($1:$1))」という式を、シート名に関係なくまんまでコピペすることによって、ソース表の行や列がどれだけ増えようと減ろうとも、いちいちデータ範囲の再設定をする必要はありません。以下の記事もご参考にしてください。2つ(「=OFFSET($A$1,0,0,COUNTA($A:$A),COUNTA($1:$1))」とテーブル機能https://euc-access-excel-db.com/tips/ct08_exceltruebasic/ct080820_make_table_rule/src012007以降なら「テーブル」という機能も用いることができます。古くて関数ばかりを推奨するExcelのWebページには、このことが抜け落ちているページしか存在しないので盲信しないようにご注意ください。Queryを経由させてそこそこ複雑な条件でデータ(レコード)を絞り込んだシート(表)を作ると、それもピボットのソースにできます。Query側でソース表の条件をころころと変えて絞り込み、都度、連動してピボット集計できるのでかなり便利で、無駄なVBAを排除できます。Queryなら連動するのでできるのです。「2007以降のテーブル機能」ではソースの表の列と行の増減には連動してくれますが、フィルタ結果は連動してくれません。Queryを経由したシート(表)にも「=OFFSET($A$1,0,0,COUNTA($A:$A),COUNTA($1:$1))」での名前定義ができますので、行や列が増えても減っても、ピボットソースの範囲の設定変更は要りません。Queryでの絞り込み結果によって行や列が減ったときでも、「空白」項目の集計が出てくることもありません。この記事は、その前提でお読み下さい。最近よく目にするのが、市販書籍において、「ピボットテーブルを使ってはいけない」という感じで書かれているものです。このことについてどう考えたら良いでしょうか?本当に「ピボットテーブルを使ってはいけない」のでしょうか?そのことについて、皆さんが悩んでしまうといけないので少し書かせていただきました。POSレジデータや、他人からもらうデータで次のような明細形式の表をソース表(おお元の表)としてもらうことがあります。このとき上図のソース表をもとに、新たに作成する表として、例えば次のような2つのタイプがあったとします。(シートB)ピボットテーブルを1シート内に小さく、しかし、数を多めにたくさん使う。(シートC)1枚の表の中にできるだけ多くの情報を詰め込む。(ピボット不使用)(シートB)の場合は以下のような感じです。(シートC)の場合は以下のような感じです。「ピボットテーブルを使ってはいけない」と声高に叫ばれていたり、「ほどほどに」と書かれている市販書籍は、多くが、(シートC)のような表やこれのもっと大きくなった表を「関数をバンバン使って」作る場合に限っていると思います。(大抵は前後のどこかにそう断り書きがしてあります。断り書きが無ければそのような文脈のはずです。)別の言い方をすると、「関数バンバン使う系」の「関数信者」の人しか、「ピボットテーブルを使ってはいけない」とはまず言わない、とも言えます。(いずれにしましてもケース限定のそう大した話ではないと思いますので、それほど気にしないでください。地域別に四半期ごとに数字を出したり、前年度と比較したり、目標や達成率を出したりなど、より多くの情報を1枚の表の中に詰め込みたいとき、そんなときはピボットテーブルを使うよりも関数で処理してしまったほうが速く済む場合があります。ピボットを使ってしまうことのほうが多いですけど...。Queryも併用するのでそのほうが、「僕の仕事では」効率が良いためです。)なので、いつも「ピボットテーブルを使ってはいけない」というわけではなく「(シートC)のような表を作りたいとき」「1枚の表に情報をつめこみたいとき」は、あえて「ピボットテーブルを使わないほうがいいケースが多い」ということだと思います。いずれにしても、数字を見たいときは、(シートB)のように、1シート内にいくつかの異なる切り口の小さなピボットを置いていろんな角度から見ることも大切ですし、逆に(シートC)のように「1枚の表に情報をつめこんだ表」のほうが何かが分かりやすい場合もあります。両方必要な場合もあります。(シートC)は見慣れるとプロの方やコンサルさんにはそれだけで何かの判断材料になるのかもしれません。付加したもの)では全く役に立たない場合もあります。出てたところで、「減った」「増えた」の事実が分かるだけで「原因までは分かるわけない」ですよね。(数値分析的に特殊な能力や勘を持った人以外は。)原因が分からなければ対策が考え付くはずもありませんよね。業種によっては「昨年データや四半期データなんか役に立たんだろ?毎年状況まったく変わるんだから。今はどうなのよ?今現在は!なんで数字が落ち込んでるの?原因は何?」ということもあると思います。したい」ということなら、必要なのは(シートB)であり(シートC)ではありません。会議の出席者が経営トップだけでなく、現場の人たちも居れば尚更です。(シートC)のような表ばかりを関数で作りまくる意味がありますか?無駄じゃない?作成者の時間を奪ってない?そんな仕事、見直して減らしてもいいのでは?もっと重要なお仕事があるのでは?(もちろん削れない理由もあると思いますし、CもBも必要なシーンもあると思います。シートCを作り続ければいいと思います。お仕事内容の見直しの機会があるかも?というだけのことですので・・・。(シートB)のような表たちは必要になると思います。注目すべき点は、(シートB)も(シートC)も、もとは、まったく同じ(シートA)から生み出されている・・・という点です。同じ表から、まったく次元の違うそれぞれが生み出されています。目的によっては、かたや役に立ち、かたや、ほとんど役に立たない。それはTPOで変化していくものです。どんな時に、どちらをどう作るかは、あなたの判断です。TPO(会議の目的等々)によっては、逆に(シートB)よりも(シートC)のような表が大切になってくる場合もあります。結局は、全部の機能を、TPOに合わせて、コーディネイトバランスをうまく変えて、「何かを得意とする機能はそれに任せて活用していくのがよい」「機能もソフトも適材適所で良いとこどり・補い合う」、というのは変わらないと思いますので、「どれかの機能」を「使ってはいけない」というケースは、もしシーンが限定的であっても、基本、「ありえません」から、そのようにお考え下さい。機能の使用頻度のバランス/ウェイトが変わるだけで「まったくもってどれかが使えない」、という事態にはならないはずです。人それぞれ、業種も職種も会議や書類提出の目的もTPOで何もかもが違いますから、Excelの機能に関しては「本やWebに書いてあったから」というだけで「思い込み」「決めつけ」だけはしないほうが良いと思います。いろんな機能を、ご自分で試して、使ってみて、ご自分の答えを出してください。ついてお伝えさせて頂いています。バーコードPOSレジのサンプル」程度なら、本サイトの説明書通りにやっていただければ誰でも作れますので、どうぞ、そういうところからお試しになって、関数やVBAの位置づけをご自分なりにしてみてください。基本的に・・・どれかの機能に心酔していて、「これ一本覚えておけば全部できる・全部まかなえる・他の機能はほどほどでいい」ということを言う人や本のことは、全部まるまるは信用しないほうがいいです。(ついでに・・・「Excelで地図から何から何まで、Wordで作るような長文までも作る」、というのもその一種です。個人としては便利なのでいいと思うのでお好きにしたらよいのですが、チームとしては迷惑以外の何物でもありません。少なくとも「相手の立場を考えられない時に使う最終手段。」「今の自分にはこれしか方法がありませんでした。」、という類のものであって、「あれもこれもできちゃうよ?!すごいでしょ?!」、と自慢げにやるものではありません。)そういう人は部下やお客様についても、そういう扱いをしかねません。全部いっしょくたにしていい、という決めつけ。いう人や本は、「自分の業種や職種の中だけで考えている可能性が高く」、「他人の業種や職種」「ましてや他人のコストのことなど、独学コスト、教習コスト、時間コスト、金額コスト」等々、ほとんど考えてないと思います。何でもタダじゃないことや、短時間に覚えられるわけでもないことを隠します。相手をめくらにさせようとします。自分が褒められでもしたいのでしょうか?多くのことをカバーできる機能やソフトなどあるわけがありません。そんなものがあるとしても、それは「絶対に儲かる」という話と同じです。信用しないように」という話と同じです。TOPにとって、本当にコスト削減や売上増(数字見たくらいで売上増にはなりませんが)に役立つ機能や手順を、ご自分で探そうとする機会を奪われて、スルーさせられてしまいます。人は、よくわからないもの、に対しては盲目的に信じ込んでしまうので(僕なんて特にそうなので)、注意が必要です。半分はもちろん便利な機能をお教えしてくれているので信じて活用すればいいですが、半分は信じないほうが無難です。ご自分で実際に試してみて、動かしてみて、本の言うことは正しいか、間違いか、ご自分自身で、ご判断してみてください。僕が今言ってることだってそうです。盲目的に信じないで、自分で、Excelを動かす中でご判断ください。「ITについての”すごい人や本”」に我々現場や経営者の立場から言いたいのは、「VBAプログラム、アルゴリズム、関数、ネストした数式、そんなこと考えないとこんな単純な足し算や構成比出しもできないのか?コンピュータなんだろ?数字を「分析」するプロなんだろ?足し算くらいちゃちゃちゃっとやれる方法を教えてくれよ。我々はコンサルやエンジニアになりたいわけじゃないんだ。数字が知りたいだけなんだ。プロセスなんていいんだ。きれいな表が作りたいわけじゃないんだ。俺のような「バカでも」「すぐに」「いつでも」「欲しい数字」が「Excelだけで」出せる方法を教えてくれよ。基本的なビジネスの定型集計がやりたいだけなんだよ。自作関数なんて使いたくない。ネストした数式なんて使いたくない。何も覚えたくないドシロートでもやれる方法を教えてくれ。基本的なビジネスの定型集計やりたいだけなのに、なんでVBAなんて覚えなくちゃなんねんだ?なんで20年ものあいだ機能が進化してないんだ?」ということです。これまでの20年と同じようにこれからの20年/30年も同じまま?VBAと関数をバリバリ使いこなせないと永遠に俺たちにはExcelじゃあ何もできないの?この先もこの20年と変わらないの?俺たちの子供も孫もVBAと関数バリバリじゃなきゃExcelで数字出せないのか?20年も?30年も?Excelはどこまで進化しないつもりなんだ?イレギュラー集計じゃなくて定型集計だぞ?どんな業種にもある定型集計だぞ?月度集計とかこんなよくある定型集計がしたいだけなんだよ。→こちらExcelって20年以上あるだろ?さすがにこんな定型集計、簡単にできるはずだろ?コンピュータなんだろ?1秒間に何十億回って計算してるんじゃねえのかよ?なんで20年もの間、それが簡単に出せないの?ラクになってないじゃん。独学コスト、教習コスト、集計の仕事のコスト、その他諸々、下がってないじゃん。生産性上がってないじゃん。プログラマすら、ピボットのこと深く知らないじゃん。Microsoftは、Accessはもう見捨てたんだろう?だったらExcelのほうでリレーショナルな機能やMSQueryをもっともっと強化してくれよ。「何も覚える気が無いならおとといきやがれ。」と言われてしまうでしょう。「コンピュータは、何も覚えようとしない人間、コンピュータに寄り添おうとしない人間には、どんなに素晴らしいソフトがあったとしてもただの箱のまま」です。それでも、「コンピュータなんだろう?あんたら何年使ってんだよ?Excelのやり方20年前と変わってねーじゃねーかよ?ほかのやり方教えてくれようとしたか?CPUが速くなっただけじゃねーか。」というのが本心であることも事実のひとつだと思うのです。びいきなのでそこが悪いところですね(^^)反省します・・・。他人のフリ見て我がフリ直さないと・・・。僕の言っていることも話半分くらいで聞いてください。(僕が言っている「Excelの真の基礎」が役に立つのは、主にビジネス定型集計やビジネス定型リストアップの部分だけで、シュミレーションや高度で専門的、イレギュラーな集計にはあまり向きませんから利用頻度は落ちますので。)でもちゃんと関数も使わせて頂いてますよ。してこないですから・・・。わかるところはそれで出し、「無駄な集計はやめましょう」「こんな集計は無意味。Queryで必要に応じて出すだけでいい。必要以上に無駄に使ってはいませんが・・・。無かっただけかもしれないですが・・・。大企業の方は(シートC)のような表をでっかくしたような表がいたるところで必要で、非常に有用なのかもしれません・・・。無知であること、本当にごめんなさい。(シートC)のような表は銀行さんに求められたときくらいだったかなあ・・・。それでも資金繰り表とかそれに関連する表だったと思ったから、別に、関数ってこともないくらいですけど・・・。最近は付き合いもないので、本当に作らなくなりました。今はどうしても関数必要なところ(とき)だけ、Web検索しながら、慣れない手つきで必死で関数使ってます。関数を多用した表が回ってきたときに必死になります。(もともと関数はそう使わないので頻度は多くないですが・・・(^^))では、以降、ピボットを使ったサンプル群になりますので(MicrosoftQueryも併用してまっすが)、どんなときにピボットが使えるのかとか、ピボットを使ってどうデータを読んでみたらいいのかとか、体験してみてください。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コードなどをコピペしてください。無い場合はすみませんが手打ちで入力してください。追記(某サイトにある書籍のレビューとして書き込んだ文章です。)「特定の機能を否定する文章を売り物に書くこと」はプロにあるまじき愚行Execelは本当にすごいソフトだと思いますが・・・、とりあえず、Excelの機能は強いて大きく分けると2つくらいのくくりに分けることができます。100%というわけではないですが、でもおおむね、以降に挙げた(a)~(i)のような感じに分けることができると思います。(後半の(d)以降は多くの人が教えてもらっていません。バージョン2000のExcelでもできるんですけど・・・。※ほんとうはもっとあると思いますけど、省略しました。SQL)とSQLでのリレーション(SQL=ある意味データ管理の基礎・世界標準で「Excelの基礎」とは違います。=ソフトを選びません。=複式簿記と同じくらい有名=「集計関数」も含んでいます。※こちらも、もっとあるかと思いますけど、省略。==========このとき、「(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)メンテナンス性に優れたプログラムコードはこの本を頼りにしていては死んでも書けない(って、私も書けないですけど。xlsm、xlsx、xlsの量産をし続ける。(05)よって、書けば書くほど、どんどんと「スパゲッティ状態」になって苦しくなってくる(06)ユーザーフォームの使い方も無駄な使い方をしているので、誤解する人が増える(07)セルとシートの操作しかできない(08)グラフ、QueryTableオブジェクト、ピボットのVBA操作などこれっぽっちもできない(09)「マクロの記録機能」をオブジェクト調査だけでなく、実務に活かす技術は身に付かない。(10)ExcelVBAのことが分かったとか、自分は中級、といった誤解をし、つまらぬ自信過剰に陥る恐れがある。読めない」状況に陥る。(12)他の初心者本と同様、クラスモジュールのことは理解できないし、また、どのモジュールにどのように作ったプロシージャを、どこからどのようにCallできるかもわからないので、1回作ったプロシージャの再利用ができず、効率が悪い(13)他の初心者本と同様、値やオブジェクトを返さない自作関数、値やオブジェクトを返す自作関数を作れないので、効率が悪い。値やオブジェクトを返す自作関数を作ってみなければ、ヘルプもオブジェクトブラウザも読めない。(14)他の初心者本と同様、SQL、QueryTableオブジェクト、ADO、DAO、ODBC、などを使った、別のxls、xlsx、xlsm、を「閉じたまま」書き換えたりができないので、効率が悪くなるケースが出てくる(15)他の初心者本と同様、COMオートメーションができず、効率が悪くなるケースが出てくる。Query=SQL)とピボットをVBAで操作できないので、効率が悪くなるケースが出てくる。(17)他の初心者本と同様、エラーを自力で解決できないし、Q&Aサイトで質問したところで、回答をくれた方の回答の意味が理解できない。プロパティを使わなくても、「横方向のループ処理」としても一応使えることにもなる、ということ・・・等々の「基本中の基本」がまったく書いてありません。そんなの、セルアドレスベースのループだけじゃないんだから、絆創膏プログラムにしたって、絶対に教えないといけない項目だと思いますけど・・・。プロパティのことすら。・・・などの基本も書いてありません。これらも、「絆創膏プログラム」であっても最低限必要な項目です。パソコン操作のスタートはどんなソフトでもまずは「選択から」です。(選択とクリックが同時になることも多いですが)Excelの場合は「セルの選択」。ExcelVBAであれば、RangeプロパティやCellsプロパティ、Rangeオブジェクトを返す何か、です。そのことすらきちんと書いてありません。「オブジェクトの取得」が「オブジェクトの選択と同じような意味」であること、や、「オブジェクト式を書くということであること、そしてそれは階層構造を省略するとエラーになることもあり、また、省略すると現在アクティブじゃないシートに対する裏方での操作ができない」といったことも書かれていません。それに、どうやってエラー解決するんでしょうかね?エラールーチンのことも書いてないし。Each文の詳細説明にあてればよかったのにと思ってしまいます。これ、言っちゃ悪いですけど、著者だけじゃなく、編集の人もちょっと・・・と思ってしまいます。少なくとも、編集の人も、まったくVBAを理解できてませんよね。編集の人がVBAをまったく理解できていないため、著者の「使命感や国益に貢献したいという想い」からくる内容に何のアドバイスもできていません。いう内容じゃないですよね?この本・・・。なれればそれでいいんだ」ということだったとしても・・・。読めない」状況に陥る。』と書いた理由がお分かりになるのではないでしょうか?こんないい加減な内容で、「たった1秒で仕事が片づく」というタイトルも、どうなの?と思ってしまいます。VBAに触れた人は当然、そうはなって、びっくらこくんでしょうけど・・・。集めたイレギュラー作法の絆創膏プログラミングの本ですよ。これが正しいとは誤解しないでください。とっかり、としてご利用ください。」、ということを但し書きとして何度も何度も随所で説明しないといけません。なければ、初心者の方が誤解をし、国益にはならないし、それに、「たった1秒で仕事が片づく」というタイトルが「国益とはほど遠い安直なふざけたタイトル」となりかねません。いう危険性もあることを前提として読むなら、他の初級本とともに、結構役に立つ本だと思います。(一度つまづいた人が疑問に思うところが、ある程度解消されるような書き方がしてある箇所もありますし、基本、大変にわかりやすくは書いてありますので。おお!こんな方法が!ということも書いてあって大変に勉強になります。但し書きが少なすぎて、初心者を「誤った道に放り込む」危険性はありますが・・・。)ただ、この本だけを読むと、「VBAそのもの」を「誤解する」と思いますので、特に初心者の方は、「まじめに多少なりとも高効率性・メンテナンス性をもったコードを書きたい」なら、せめて、終わりのほうの(01)~(03)に挙げたような本も読まれるとよいと思います。少なくとも本書は「教科書」ではありません。これを「教科書」として、じゃあ現場で使えるかというと、「絆創膏プログラミング」としてだけしか使えず、やっぱりすぐに限界がきたり、現場の混乱を招くと思います。」を『生みかねない』ともいえるかもしれません。その一例として、P315の「Variant型」の変数の説明で、「型を使い分けようとすることでハードルが上がるならそんなものまったく必要ない」と説いています。Variant型の変数はたしかに便利ですけど、ただ、「あえて型を細かく指定して、おかしな値が入ったときはあえてエラーが出るようにしたい。Variant型の変数はユーザーがセルにどんな間違った値を入れても代入時にはエラーを出さないし、型も稀に意図しない型に勝手に内部変換して余計なエラー・あるいは・エラーのない質の悪いおかしな挙動・を引き寄せてしまうことがあるから。」といった注意は書いてありません。有名なのは、Inputboxでユーザーから入力された値は「それが数字であっても文字列型データとしてプログラムに返ってくることになります。代入された、という扱いになります。」ということなどです。Variant型変数を使う場合は、例えば関数で返ってきたものがどんな型のデータなのか?を常に意識しなければならないといえばそうです。そんなシーンは少ないかもしれませんが、結局は型の勉強を最初からやっていれば「そんなトラブルにはもともと出会わない」です。それに明確に型を指定していれば、代入時やその後の処理でエラーになるから「なんで?」となり、そこでひとつ自然に勉強ができます。」と書いてあるから、「あ!数値に変えてあげればいいのね!?」とすぐにわかります。Variant型だとエラーにすらならないので、Step実行だけのチェックじゃあ「ちゃんと300って入っているし・・・」、なんて感じで気づけない初心者が多いと思います。周囲に分かる人が居なければ、下手すると数日悩みます。」の意味すらわからない・・・とか。呼べる?一事が万事、こういう姿勢で教えてくれちゃうことになるの?→たいていそうなります。これがどういうことか、わからない人はいないと思いますけど、著者はそれでも「そんなもの(型指定なんて)まったく必要ない。全部・いつでも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割だけでメシが食えちゃっています。「Q&Aサイトに質問したけど意味わかんない!」となるだけです。(プログラマじゃない人で、「やってるうちに自然にわかってくる人」なんていうのはほんのひとにぎりです。これを読んでいるあなたは多分、そうじゃありません。)「誰でもできる」というようなことも書いてありますが、それも大きなウソ、です。現実はそんなに甘くありません。「レッスン料払えるだけのお金と時間とやる気がある人」「独学するならそれを上回る熱量のある人」「コツコツ地道に続けられる人」「しか」、「基本的には」、自力でVBAで色々作れるようにはなりません。自力でのエラー解決なんて夢のまた夢。誰でもできるってわけじゃない。」っていうのが「真実」なのに、「誰でもできる」という「嘘」を平気でつく。誰でも「始める」、ことはできますけど・・・・。VBAは「中級以上に上がらなければ、何の効果も出ないもの」です。普通、「VBAの中級」というと、前述の(01)から(17)までを「全部解決・クリアできる人」を言います。(私はグラフが動かせないので初級です。)それまでに挫折すれば、かけた時間とお金が全部無駄になります。これは、「そのVBA、頼むから個人だけで人知れずひっそりと使ってくださいね?」、「頼むから本書のVBAの内容で他人のデータまで操作しないでくださいね?社内共用のデータなんて死んでも触らないでね?」、「少なくとも私のデータは頼むからこのVBAで触らないでくださいね?」というレベルの話・・・・、というかそういう感じの本の内容・・・・です。私なら、この本「だけ」を読んだ人には、「もちろんこの本もとっても有益だけど、但し書きが少なすぎてバカな勘違いもしやすいから、頼むからこの本と、この本と、この本も絶対に一語一句、理解しておいてね。わからないところは全部僕に聞いて。」と、追加で他の本を数冊渡します。本書のような「絆創膏プログラミング」としてしか使えず、「ソースのExcelファイルのデータの持ち方も考えない非効率データを量産させる方法を得意げに教える本」、「プログラミングしてしまったがために新たなデータ管理のムリムダムラと現場の混乱を生みかねない本」を「教科書」と言っていいのかどうか?というところだと思います。少なくとも「教科書」と呼べるようなスタンダードなものではありません。(もちろん、著者の独自性はあっても全然OKですけど、まとめ方が悪いと、やはり「教科書」と書かれてしまうと現場としては「いい迷惑」です。『ヘルプもオブジェクトブラウザも使えず・オブジェクトに何が含まれているかさえきちんと理解できていない・オブジェクトを返す自作関数すら作れない・この本がスタンダードだと勘違いする初心者』が激増してしまうから・・・。本書は、とっかかりのためだけ、の「イレギュラー作法・筆者の趣味作法・筆者の好きな作法の絆創膏プログラミング本」、であり、「教科書」ではありません。)ここ数年で発売された「教科書」と銘打った本は、多くがコンサルの自己満本、そのコンサルの勝手なルールの強要、コンサル以外の他の業種・職種・シーンを全く考えてない、という側面が強いと思います。そんな本を本当に「教科書」と呼んでいいのかどうか?出版社や編集者はいったい何をしているのか?「即戦力がほしい」という求人と同じ。自社内であきらめずにコツコツ時間をかけて人材を育て上げる視点がない。すごいしほしいけど、それ一辺倒ではいつか大コケします。「両方」の視点がないと・・・。「自社内でコツコツ時間をかけて人材を育て上げる視点がない。自社にない、ということを意味すると思います。「そんな悠長なこと言ってるヒマあるか!」という考えに凝り固まり、即戦力の人ばかり求めれば、結果、「他人の幸せを願うことでしか、自分が幸せになることはできない。それを考える余裕を作れないほど詰め込みすぎればいずれ風船ははじけ飛ぶ。」という基本から大きく外れます。本書を読んだ後、あるいは、読む前に、以下の(01)~(03)のような本(特に02と03)は絶対に読んでおかないと、本書だけでは、「悪いVBAのまま」それに終始することになると思います。(ちなみにですが、ExcelVBAのレジェンドさんたちの初心者本は、初心者の方はあまり読まないほうが無難です。初心者目線で書かれておらず理解できにくいですから・・・。)そして「(11)必ず限界がきて、でも、「他のワンランク上の本が全然読めない」状況に陥る。」ということになると思います。十分にお気を付けください。初心者の方と自称中級者の方・・・。(著)「超」初心者用ですが、でも、、初心者の方が陥りやすいエラーへの対処、初心者がおこなうべき考え方、などがよくまとまっています。(著)こちらも、初心者の陥りやすいエラーへの対処、初心者がおこなうべき考え方、などがよくまとまっています。本書よりも、「もっと詳しい」VBAコードの「訳し方」が載っています。Each文がコレクションだけでなく配列にも使えることが書いてあります。「一般変数(文字ベース変数や生データ)の操作とオブジェクト変数(オブジェクト)の操作に分けられて説明されている」し、初心者本としてはいろんな点から「隠れた名著」、です。(著)初心者の方には、8章以降がちょっと難しいですが、こういう「真の意味でちゃんとした先生」に習わないと、結局、VBAを誤解したまま進むことになると思います。本書には書いてないけど「必須」の「ローカルウィンドウの使い方・その他」、など、VBAを誤解しないように進むための考え方が(初心者の方とっては)豊富に書いてあります。この本でわからないところがあったら、必ずわかる人に聞くといいです。基本、この本を読んで理解できない箇所が一か所でもあれば、「ExcelVBAを正しく理解できていない」、ということになります。この本は「指標」になります。他の初心者本は、そういう使い方ができません。RangeとCellsのループの違いのことや、ステップアップするために次の段階ですべきことが書いてあります。この先生は、どのレジェンドさんよりも「ちゃんとして」ます。ヘルプやオブジェクトブラウザをいいかげんに済まさない先生、初心者に対してだからこそそこから逃げない先生は、どのレジェンドさん達をも差し置いて、私が知っている中では今のところこの先生だけです。私は、ExcelVBAのレジェンドさんたちはある意味、ExcelVBA教育を間違ったと思っています。少なくとも、「ヘルプとオブジェクトブラウザを初心者でもわかるように説明すること」からは、レジェンドさんたちは今でも逃げまくっています。「経験させないから育たない」ということを全くわかっていません。彼らのせいで、5~10年分くらいは、「データ管理の基礎」と「それをサポートするVBA」の学習を後退させたのではないか?とすら思っています。20年前の自著と同じ教え方しかしてなくて進歩がありません。ある意味あぐらかいているとも言えるかもしれません。私はExcelよりも先にAccessVBAなどを20年前から初めて、一応30台規模の零細様のRDBシステムもどきの面倒を13年ほど見させていただいています。Accessもろくに扱えませんが、ただまあ、でも今ようやくExcelVBAを勉強し始めました。ExcelVBAは超ド素人です。「ExcelVBAのレジェンドさん達がVBA教え方を間違った・そして今も間違ったまま全然変わってない」というのは「習う側」としての率直な感想です。(04)そして以下の最強のリファレンス本。(著)↑かなり便利です。Web検索するよりも早くて便利かも?やれることだけでなく、やれないことなどもたくさん書いてあり、実務において大変に便利です。本書を読むだけでは、使いこなせないでしょう。(01)~(03)も読まないと理解できないと思います。(著)「自称」ではなく、「真の中級」に上がりたい人は絶対に買ったほうがよい本です。クラスモジュールや自作イベント自作のオブジェクトなどについてもわかりやすく書かれていますし、オブジェクトや関数などの深いところのお話もあって、他の書籍ではまず得られない「的を得たTips」がかなりそろっています。「中級者の色んな迷いをかなり消し去って上級者へのきっかけを間違いなくつくってくれる本」です。Web情報探す前にこちら読んだほうが早いです。数ある中級者本の中では他の追随を許さぬ程、圧倒的にわかりやすく役に立つ本です。挫折するオブジェクト式やプログラム(プロシージャ)の書き方、挫折しない書き方、の違い。送信メールが受信トレイに入ってしまうトラブルの回避、など。ODBCでQueryTableオブジェクトを自動作成するサンプルコード)。2000以降の全バージョンで使えると思います。~ついでに、セルの値で結果表示を自動で切り替える「パラメータクエリ」のVBAでの自動作成も。~★★Access2000VBA・Excel2000VBA独学~Win32API。eChromeを例に。(Excel、Word、Access、などが32bit版のモノでしか使えませんが、OSは64bitでも大丈夫です。Windows10Proの1511の32bitにVMWareをダウンロード・インストールする方法(1607、1703以降の32bit版も基本的には同じです。「安全」な、Youtube動画のダウンロード方法6つ。挫折するオブジェクト式やプログラム(プロシージャ)の書き方、挫折しない書き方、の違い。送信メールが受信トレイに入ってしまうトラブルの回避、など。ODBCでQueryTableオブジェクトを自動作成するサンプルコード)。2000以降の全バージョンで使えると思います。~ついでに、セルの値で結果表示を自動で切り替える「パラメータクエリ」のVBAでの自動作成も。technology.。