マクロ高速化の正しい手順とVBAの書き方 − GoGoマクロ!のWebサイト

HOME > マクロの高速化 > マクロ高速化の正しい手順とVBAの書き方

マクロ高速化の正しい手順とVBAの書き方


今回は、
「プログラムを高速化する手順、間違えていませんか?」
と題して、

案外 間違ってる人の多い「マクロ高速化の手順」と、それに伴う プログラム開発で重要な「見える化」というものについて解説します。


まず、結論から言ってしまうと、プログラムの高速化とは・・・
完成してからやるものだ! ということです。

プログラムの高速化、すなわち、コードのチューニングというものは、 完成したプログラムに対して行うものであります。

それは、何もプログラム開発だけに限った話ではありませんので、たとえば 車好きの人であれば、ホンダが開発したF1マシーンのエンジンを、マクラー レンのメカニックがチューニングしてより高速化を図っていくのと一緒だと 思えばイメージしやすいかと思います。


話を戻しますが、よく初心者の方が作成中の(開発途中で未完成の)プログラムコード を拝見しますと、

 Application.ScreenUpdating = False

このような1行がいきなり入っているケースというのを時より見かけます。


これは、知る人ぞ知る(VBAの中・上級者ならたぶん誰でも知っている!?) 「シートの更新を非表示にする」というための一文ですが、

これを時間の掛かるループ処理の前などにちょっと入れておくと、各段に その処理スピードが上がるということはよく知られているものです。


けど、ちょっと待ってください!!
このプログラム、まだ完成していないんですよね!?


これは、プロの場合でも下手なプログラマーによくありがちな話ではあるんですが、 未だ完成もしていない、プログラムを開発中の最中に、 いわゆる「見えない化」してしまうから、ダメなんです。

特に、Excel VBAの場合の高速化とは、すなわち「見えない化」に他なりません。 (動作を見せないようにすることにあります。)


そもそも、ハードウェアとは違って形の無い”無形物”であるプログラム (すなわちソフトウェア)という物は、だから、それをどうやってその形 無き厄介なものを上手く見える形で取り扱っていくか、、それに尽きるわけです。

プログラム作りで最も重要なのは、「見える化」であるわけです。


長年のシステム開発現場での私の経験上でも、仕事の遅いプログラマーほど、 何故だか必ずその逆をやってしまう傾向にあります。

わざわざ「見えない化」をして、作りづらくしてしまうんです。。。(汗)



で、先ほどのマクロの構文というのも「非表示にする」ということですから、 それは「見えない化」に他なりません。

少々専門的な話で言えば、この世にコンピュータという物が誕生して以来、 ソフトウェアという厄介な”無形物”を、人間がいかに効率よく作り上げるか、 その方法について先人達が築き上げてきた知恵というのが、すなわちソフト ウェア開発の理論であり、プログラム開発技法であり、システム工学の根幹 を成すものであるわけです。

私もそれを富士通などの新入社員達に長年教え込んできたわけなんですが、 目に見えない物をどうやって見えやすくするか、ソフトウェア工学なんて ものは、詰まる所、その方法論に尽きるわけです。

わかりますかね?


まぁ、そんな難しい話はさておきですが、
そのように、そんな基本に反した(わざわざプログラムの動作を「見えない化」 してしまう)よくある具体例というのを挙げてみますと、


[A]

  For i = 1 To 5000
    Cells(i, 3).Value = Cells(i, 1).Value / Cells(i, 2).Value
  Next i



このようなループのプログラムを書いて動作テストをしている人がよくあるか と思いますが、

これが、当講座で教えるプログラムの場合では、これは必ず


[B]

  For i = 1 To 5000
    Range("A" & i).Select
    a = ActiveCell.Value
    Range("B" & i).Select
    b = ActiveCell.Value
    c = a / b
    Range("C" & i).Select
    ActiveCell.Value = c
  Next i



と、こうした書き方を(あえてこれを奨励して)教えているわけです。


このどちらも、A列をB列で割った答えをC列に表示するという処理ですので [A]も[B]も出る答えはまったく一緒ですが、

この2つの違いって、わかりますか?

そうです、これが[A]の「見えない化」と[B]の「見える化」の違いということです。


要するに、これは割り算の計算ですから、途中に欠損データなどがあるといわゆるゼロ割 というエラーを起こす可能性がありますので、そのような場合にはエラーが出で止まります。

それで、上の[A]のプログラムでは、そのようなエラーが出た場合には、 デバッグをしない限りそのエラーデータの場所を特定することができません。

一方、下の[B]の場合では(この講座の書き方では)データシートを見るだけで 一瞬でエラー箇所の特定ができてしまいます。その場所にカーソルがあるから です。一目瞭然です。

これが、「見えない化」されたプログラム([A])と「見える化」された プログラム([B])との一つの大きな違いであるわけです。

おわかりになりますか? この違い。開発者にとっては実に大きな違いですよね。


試しに、一度この2つ作ってデバッグをしてみれば、いま言ったこの2つの 違いというのがよくわかるだろうと思いますが、見た目[A]の方が行数 少ないのですっきりしてよさそうにも見えますが、この書き方ではエラーの発 生時には、

まずエラー画面のデバッグボタンを押して、VBE画面でループ変数の中身を 覗いてみて何行目がエラーなのかをチェクしてから、データのあるシートを開 いて、マウスの中ボタンなどでコロコロと何行までのスクロールをしていって、 やっとエラーデータのある行に辿り着く・・ということになります。(疲)

おまけに、エラー行がずっーと下の方だったりするとスクロールしてる間に行 数忘れて行き過ぎちゃったりして、また実行&デバッグからやり直しだぁ〜〜 なんてことも多々あったりするだろうと思います。(笑)

それが[B]の書き方であれば、もう一発です。デバッグはおろか、スクロール すらする必要がありません!エラーが発生した行にカーソルがありますから。。。


以前にも、できるSEが設計したソフトやツールというものは、処理が終わっ た時点でのそのフォーカス位置まで、ちゃんと考えて設計しているものだ・・・、 といった話をしたと思いますが、

使ってるソフトやツールがどうにも「これ使いづらいなぁ〜」と思ったら、 それは大概、その逆の能無しSEが作ったソフトだと思って間違いありません。 (すいません、「能無し」とは少々言い過ぎました。。)

でも本当、そのアプリ作った人に文句の一つも言ってやりたくなることって よくありますよね。(笑)
(処理が終わったり中断したりした時のカーソルの移動位置までは考えて作っ ていないので、ユーザーにとってそれが非常な使いにくさを生むわけです。)


もちろん、この読者の皆さんはサンデープログラマー(たぶんアマチュアの!?)であると 思いますので、そこまで考えて作る必要性はないかと思いますが、 でも、これは考えるまでもなく、いつもこの講座でやっている「マクロの記録」 的な作り方をするだけで、必然的にそうした「見える化」されたプログラムに なってくれるというわけなんですから、

それをわざわざ「見えない化」して開発しにくくしてしまうなんて、その必要 はもうとうありませんね。素直にそのまま作っていけばよいだけなので・・・。


もう一つ肝心なことは、プログラマーというのは(ただ使うだけの立場の人とは 違って、)その動きを確認しながら作っていきたい、という願望がある(願望を 持たなければいけない)ものだと思うわけです。

実行した時に画面がちらちら動くのが(目がちかちかして)嫌だ・・という方 も多いとは思いますが、でも、せっかく自分が手塩に掛けて作ったプログラム でありますので、少なくとも完成するまでの間は、その動く様というのを 目を皿のようにして見ていてあげたい・・というほどの愛情と親心は持って いてもバチは当たらないだろうと私は思っている次第です。(笑)

だから、自分がいま作ってるプログラムの動きは極力、可能な限りは見える ようにしておいていただきたいと思います。それが「見える化」です。
大げさに言うと、それがコンピュータとのコミュニケーションです。 (これはちょっと大げさに言い過ぎたかも知れません。。)

開発ドキュメント(作ったプログラムの詳しい内容を紙に書き記すこと)も 含めて、その「見える化」こそが、より早く、より確実に、プログラムという 得体の知れない、目には見えない物を作る為の、ソフトウェア開発技法の 基本中の基本、根幹を成すものであるわけです。



あと付け加えて言うと、確かに上記のプログラム例では[B]より[A]の方が その処理時間は2〜3倍以上速くなるかと思いますので、最初に言ったように 完成後にチューニングを行ってループ内を書き直すという事はやぶさかではない とは思いますが、

ただ、そうした高速化の為のプログラムチューニングというのは、あくまでも 完成してから(完成後に)やることでありますから、始めから、もしくは作っ てる途中で、それをやってはなりません。そこだけは決して間違わないように してください。

開発途中にわざわざ「見えない化」をしてしまって 作り辛くするようなことだけは、決してしないように、くれぐれもご注意ください。

まず一応の完成をみて(きちっと動作確認をして)、それでどうしても、もっと 速くしたい、しなければならない、という場合には(その完成品はちゃんと バックアップを取った上で!)、高速化の為のプログラムチューニングに チャレンジする。という手順でやってください。それが王道ですし、 その手順しかあり得ません。


でもまぁ、あえてもう一言だけ言わせてもらうと、そもそもエクセルのマクロ化自体が、 「3時間の手作業が10秒になる・・」という話であるわけなのですから、それが10秒か、30秒か、 それを問題にしても仕方がないだろう(誤差の範囲だろう)、と思うわけです。

誤差の範囲というのは、たとえば3百万円の高級車をもし大特価で千円!で 売っていたとしたら買うけれど、3千円なら私は買わないよ!なんていう人 がいますか?という話です。

元々が3百万円の金額であれば、千円か3千円か?というのはまったくの誤差 範囲にすぎませんので、それを問題視する人はまずいないだろう思うわけです。

それと同様に、元々3時間かかってやっていたExcelの手作業がマクロを 作って30秒。それが遅いからといって、それを10秒に短縮するためにわざわざ 時間を掛けて高速化のチューニングに取り組む・・・

そんな必要があるのか?ないか?それについは、よくよく”時間対効果”というものを 考えた上で、それでもどうしても必要とあれば、先ほど言った手順でチューニングを 行ってください。

でも、さほどその必要性がないのであれば、そんなチューニングに貴重な時間を 費やすより、どんどん次のマクロ作りに励むべきだ、と間違いなく私はそう思います。 (よほど暇で暇で仕方がないという人であれば、これは心行くまでやっても構わない とは思いますが。。)


更に、加えて言えばその後にそのマクロに何か修正や追加を加えなければなら ないとなった場合にも、「見えない化」での開発を余儀なくされてしまう羽目 に合いますので、高速化はここの最初にも言った

 Application.ScreenUpdating = False

これを完成後に 1行入れておく ということだけにしておいたほうがよいと、 いつもそう私はアドバイスをしています。

これであれば、次回の修正時にはこの1行をコメントアウト(頭に ' のマークを 入れておくだけ!)して切り替える、それだけで何の手間もなく「見える化」と 「高速化(見えない化)」の切り替えができてしまうわけなので、後々の事まで 考えれば、これなら非常に楽ですね。

ちなみに、うちで昔行ったベンチマークの結果では、この1行を入れた場合と 入れない場合とでは、概ね15倍ものスピードの差が出ています。



おさらいですが、


・「見えない化」やちゃってはいませんか?
・プログラムのチューニングは、完成後にやることです!



最近では、電力モニターと呼ばれる家庭の消費電力を手元のモニターに表示 させるソフトがあるそうですが、ただ電力の使用量を人間に「見える化」したというだけで、 それを導入した家庭や企業というのは平均で15%もの節電効果が出ているそうです。 「見える化」の効果というのは、人間の心理や行動に与える影響というのがいかに大きいのか がわかりますね。

ぜひ、皆さんもプログラムの「見える化」ちょっと意識して、今後のマクロ 作り やってみてください。


NEXT >>
154秒→11秒に、14倍の差が出ました。・・・画面更新の非表示
高速化 目次へ


 

マクロ初心者(入門者)の皆さんへ

こんにちは、「Go!Go! エクセルマクロをはじめよう!」筆者の三太郎です。
私はこの道25年、現役バリバリのベテランSE(システムエンジニア)をしています。 なので、業界にどっぷり染まってしまった IT業界人 です。(笑)

マクロ(エクセルのプログラミング)がどれだけ便利なものなのか・・・ ということは、 皆さんもうよくお分かりいただけてる(!?)ものと思いますが、でも 「やっぱ、中々取っつき難い、ハードルが高い、素人には難しい。」 そう感じている方も多いかと思います。

エクセルをほぼ1日中使ってる人が多い職場であっても、マクロを使える人はほとんど居ません。 (30人の職場で精々1人か2人居ればいいほうかと思います。。) 私は、そのような現状(PC仕事の非効率)を改善して、日本にもっと効率良いIT化の機運を 高めて行きたい!そう願って、今から十数年前にこのようなメルマガ講座を始めました。

マクロを始める為の条件は、エクセル上級者ではありません! 頻繁にエクセルを使ってる人、 ただそれだけです。エクセルの操作レベルはまったく関係がありませんので、 エクセルユーザーの全ての皆さんが当メルマガ講座の参加対象者です。

パソコン仕事で この上なく便利なエクセルのマクロ というものを、もっと多くの人に知って欲しい、使って貰いたい。その想いだけで、長年メルマガの 無料配信を続けてきました。今では、この分野では異例とも言える1万人を超える大勢の皆さんに ご登録いただいているメルマガ講座に成長いたしました。 読者の皆さんからのご声援のお陰です。本当、ありがとうございます。

当メルマガ講座では、簡単に出来るマクロ作成法のコツとその手順を教えています。 とにかく作って、動かす。だから楽しくなってきます。 VBAのカタカナ用語や難しい仕組みの理解、構文暗記といった従来型の不必要な勉強は一切しません! なぜなら、エクセル作業の自動化にその必要は一切ないからです。 初心者がすぐに挫折するカタカナ用語羅列のマクロ勉強なんて、殆どの人には役に立ちません!

マクロとは、エクセルの作業を自動化する為の道具に過ぎません! マクロを組む為に難しいプログラムの仕組みや わけのわからないカタカナ専門用語を覚える必要など毛頭ないわけです。 私はこれまで十数年間、大勢の読者に教えてきて、Excel自動化に成功した沢山の人を生み出してきた 経験で、そう断言します! (本屋に並ぶVBA参考書のライターレベルの人の言うことを真に受けて、 あなたに必要のない”勉強の為の勉強”をしてしまわぬよう、 くれぐれもご注意ください。)

ここでは、「これからマクロを始めてみようかな?」と思ってる方や、 すでにどこかで勉強して「すぐに挫折してしまった・・(>_<)」という方に、 安心して勉強のできる方法とその実習環境とが用意されています。 もし、あなたが過去に挫折した経験者であれば、きっと私が常々言っている 勉強すべき事とすべきでない事 その違い(ここの初心者学習環境の素晴らしさ・・)というものがすぐに分かっていただけるだろうと思います。

マクロ(VBA)というのは多義に渡ります。アマチュアのサンデープログラマーから ベテランの上級者やプロに至るまで、実に幅が広いものです。 初学者には到底 必要のない 難しい部分まで勉強してしまうから当然、 必ずずぐに挫折する事になります。

残念ながら、「まだピカピカの小学一年生(初心者)に、いきなり掛け算や割り算はおろか、 三角関数や微分積分までも教えてしまうような痛ましい光景」を、ネットでも参考書でもセミナーでも、 VBAの世界ではたくさん目にします。

だから、「何を勉強するか」ではなく「何を勉強しないか」 初心者にはその正しい選択が重要なんです。勉強の範囲を 初心者の領域(Excel業務の効率化)だけに絞ってやりさえすれば 、さほど難しく考える必要はありません。それで、難しく、さっぱりちんぷんかんぷんだと思っていたマクロが 楽しく、 どんどん楽しく、勉強できるようになります。

→ エクセルマクロを10分で理解する!(YouTube動画)


あなたもこの三太郎式マクロ勉強法で、面倒なExcel仕事の自動化を ぜひ、この他にはない画期的な方法で実現してください。あなたの 参加を(下記無料メルマガへのご登録を)お待ちしてます!! (少々、力説し過ぎて話長くなりました。すみません。m(__)m)

 
最新号 は、下記にアドレス登録すると無料配信されます。

▼マクロ講座の登録はこちら((無料)) まぐまぐ
Go!Go! エクセルマクロをはじめよう! (マガジンID:0000135169)   
メルマガ登録
  メールアドレス: