1年間ExcelVBAを勉強して驚いたのは処理の高速化の世界があるということ

ExcelVBAやAccessVBAなどのプログラミングの勉強を始めてだいたい1年ぐらいが経ちましたが、その中で非常に驚いたことがあります。それは、プログラミングには

「さらなる高速化の世界がある」

ということです。

 

このブログでは、1年程前からとあるきっかけによって、ExcelVBAによってつくられたマクロの威力について思い知らされた、といった記事をいくつか書いてきました。

 

というのも、普通に手作業で進めていたら1時間とかそれ以上かかっていたであろう仕事が、Excelのマクロを利用することによって文字通り「一瞬」で終わってしまったからです。

 

それからは、マクロやExcelVBAに魅了されて、自分でコツコツ勉強しながら実務でもちょっとずつ使っていくという日々が続きました。それから1年が経つのですが、プログラミングの世界を勉強していると経理の仕事とはまた違った世界を見ることができます。

 

プログラミングの世界を勉強していると、今までとは全く違う価値観を垣間見ることができるのですが、それは先にも書いたように

「さらなる高速化」

です。今回はこのことについていろいろと思ったことを書いていってみます。

ただでさえ超高速なのにさらに高速化しようとしていることに驚く

スピードを超過している車の速度計

経理や事務職の仕事でExcelVBAやマクロを使ったことがある人ならわかると思うのですが、仕事に合わせて適切にマクロを組むことができれば文字通り「一瞬」でプログラムが業務を処理をしてくれてます。

 

しかし、プログラミングの世界には驚くべきことに「さらなる高速化」をしようとしている人たちがいるようです。自分はこの事実を初めて知ったときは、

 

「えっ?ただでさえ速すぎるくらいなのに、これ以上まだ速くする必要があるの?」と驚きました。

 

最初のうちはこの事実にただただ驚くことしかできなかったのですが、「なんでそこまでするんだろう?」と考えた時、この理由として何となく心当たりはありました。

ブログやWebサイトの表示速度の高速化

例えばブログを書いたりしていると、どうすればもっと上手く書けるようになるだろうかと考えて、他の人はどんな風に書いているのだろうか見にいったりして、いろいろと知りたくなるものです。

 

そのようにインターネットであちこち見て回っていると、偶然にWebサイトの構築化とか、より専門的なサイトを見つけることがあります。そのようなサイトには

 

「読者のユーザビリティ向上のためには表示速度をより速めることが必要です」

 

といった言葉が書かれている時があります。最初のうちは、

「ブログやサイトを他の人に見てもらうためにそこまでする必要があるのだろうか?」

「表示速度の向上といった難しいことは、システムエンジニアやプログラマーなどその道の凄い専門家ならできることであって、自分のような普通の人間には関係ないだろう」

なんて思ったりしていました。

 

でもよくよく考えてみると、やっぱり遅いよりかは速い方が良いというのは理解できます。自分も何らかのサイトを見ようとした時、表示されるまでに1分とか2分もかかってしまったら、さすがにそこまで待ってはいられないので離脱します。

高速化のための2つのアプローチ

『VBAエキスパート公式テキスト Access VBA スタンダード』を最近読んでいたのですが、その中に「VBAの高速化」について書かれた箇所があります。そこには次のように書かれています。

P.186

高速化の考え方

高速化には2つのアプローチがあります。1つめは、できる限り無駄な処理を行わないこと、2つめは、より処理速度の速い処理を選択することです。

VBAのプログラミングにおいて高速化を図るには2つの方法があるということですね。それが、

  • 無駄な処理を行わない
  • より処理速度の速い処理を選択

ということらしいです。

 

処理の高速化を図るというのはVBAの世界にもあるようですね。この記述を見る前は、先に書いたように処理の高速化が必要なのはブログとかWebサイトの表示速度についてだけだと思っていました。

 

しかし、今回の公式テキストの記述やVBA以外の様々なプログラミング言語について書かれたサイトなどを見てみると、処理の高速化というのはプログラミングの世界全体について言えることのようです。

 

例えば『VBAエキスパート公式テキスト Access VBA スタンダード』には「無駄な処理を行わないヒント」として「無駄な処理の多くは、繰り返し処理や分岐処理の中に隠れています」とあり、その事例のひとつとして次のようなコードを記述しています。

P.187

For i = 1 To 10

     ‘処理1

     For j = 1 To 10

           ‘処理2

           For k = 1 To 10

                 ‘処理3

           Next k

    Next j

Next i

この場合「処理1」は10回の処理、「処理2」は100回の処理、「処理3」は1000回の処理をすることになります。本書では処理1の処理時間を1/100秒短縮しても全体で0.1秒しか短縮できないが、「処理3」の処理時間を1/100秒短縮すれば、全体で10秒の時間を短縮できると記述しています。

 

先に書いた高速化のための2つのアプローチの1つめである「無駄な処理を行わないこと」という視点で考えると、例えば2つも3つもネスト(入れ子)をする必要があるのかといったことや、途中で目的の処理ができたら、全ての処理をさせずに「Exit For」などで繰り返し処理を抜けるという方法が考えられます。

 

また、2つめのアプローチである「より処理速度の速い処理を選択」する視点だと、そもそもFor…Nextステートメント使わないという方法も考えられます。

 

以上の方法以外にも、本書では処理速度の速い処理をするためのヒントとして、事前バインディングではなく実行時バインディングを選択するという方法や、変数において適切な型かつ適切な適用範囲で宣言することによってメモリの無駄な消費を抑えられるとあります。

 

要は、VBAにおける処理の高速化のためにはいろんな方法があると、そのたくさんの方法の中からより高速で適切な手法を選択していくことによってVBAの処理の高速化を図ることができるということです。

マクロの実行時間を短縮するための高速化

もうひとつ、プログラミングの処理の高速化を考えるきっかけとなった本に『ExcelVBAを実務で使い倒す技術』というものがあります。この本はExcelVBAを実務で使う上で様々なテクニックが書かれており、読んだ感じではある程度ExcelVBAを知っている人向けかなと思います。

 

特に本書におけるp241からp251の「7-7 マクロの実行時間を短縮するテクニック」が印象に残りました。マクロの処理の高速化を図るにはいくつもの方法がありますが、その中のひとつに「計算回数を減らす」という方法があります。

 

その事例のひとつとして本書では、エクセルのシートに「10,000行×10列にテキストを書き込む」という処理を実行する次のようなコードが記述されています。

P.241

Sub putText()

 

Dim Start, Finish As Variant

Start = Time

 

Dim i As Long, j As Long

 

with Sheet3

   For i = 1 To 10000   ‘10000行分繰り返す

      For j = 1 To 10    ’10列分繰り返す

 

         ‘1つのセルに書き込む

         .Cells(i, j).Value = “hoge”

 

      Next j

   Next i

End with

 

Finish = Time

MsgBox “取得が完了しました” & vbLf & _

    “実行時間は” & (Finish – Start) & “でした”

 

End Sub

このプログラムの計算回数は「10,000行×10列=100,000回」となり、本書では処理が終わるまでの実行時間は「32.1875秒」と書かれています。

 

例えば人間が手作業でエクセルのセル10万個に「hoge」という文字列をコピペしていったら、おそらくとんでもない時間がかかるはずです。それを考えるとコンピュータに処理してもらえば32.1875秒になるので、数値は悪くないように思えます。

 

しかし本書では、次のようなコードにすることによって処理速度をかなり改善しています。

P.242

Sub putText()

 

Dim Start, Finish As Variant

Start = Time

 

Dim i As Long

 

with Sheet3

  For i = 1 To 10000

 

    ’10列のセルに書き込む

    .Range(.Cells(i, 1), .Cells(i, 10)).Value = “hoge”

  Next i

End with

 

Finish = Time

MsgBox “取得が完了しました” & vbLf & _

    “実行時間は” & (Finish – Start) & “でした”

 

End Sub

このコードは先ほどのコードとは違い、「A~J列に、一気にテキストを書き込む」という処理になっています。

 

人間の手作業に例えると、まずエクセルのシートのA1からJ1まで「hoge」をコピペします。その次にA2からJ2まで「hoge」をコピペしていって、それを1万行まで繰り返すといった感じです。

 

これだとプログラムにおける計算回数は「10,000回」になり、先ほどのコードの計算回数から10分の1になります。その結果、本書では実行速度が「3.765625秒」となっています。

 

処理速度が改善された理由として、A列からJ列までのテキストの書き込みを一度に処理することによって、列方向のFor分がなくなって、その分の計算をしなくてもよくなったことが挙げられます。

 

本書では、この後さらにもう一段、圧倒的に処理速度が改善できるコードが記載されています。興味がある方は購入しても全然損はないと思います。最初本書のこういった部分を読んだ時は、「あぁ、世の中にはこんなやり方もあるんだなぁ」といろいろと感動してしまいました。

 

ここまで書いてきて思ったのは、やはり自己流だけではなくて、いろんな人のいろんなやり方を見てみるべきだと思います。

 

他の人のサイトや今回の記事に書いたような本を読む前までは、プログラミングに関して自分にはそもそも「高速化」といった概念が全くありませんでした。

 

その理由としては、たぶんプログラムとかマクロなどを一度つくってしまったら業務を文字通り一瞬で処理してくれるので、「これ以上の高速化」まで考える必要がなかったんだと思います。

 

そのように新しい発見を得るためにも、多くの人のコードや本を見ることは決して損はないでしょう。

プログラミングの世界と経理の世界との比較

ここまでプログラミングの世界にはさらなる高速化とコードの効率化というものがある、といったことを書いてきました。このようなことが進められる理由や背景としては、やはり「扱うデータ量」が増えてきているからではないかと思いました。

 

昨今の企業戦略には、ひとりひとりの名前や生年月日に始まり、購買履歴や趣味嗜好なども取り入れて戦略が練られるなど扱うデータ量が日々増加しています。

 

そういった日々増えていくデータを扱うには手作業ではいろいろと限界があるはずです。そのため、プログラミングやそれによってつくられるシステムが重宝されるようになってきたと思うのですが、それでもまだ足りないということでさらなる処理の高速化が図られていったのではないでしょうか。

 

こういったやり方は、自分が今まで仕事をしてきた経理の世界とは全然違うと感じました。というのも、経理の世界というのは会計の知識について

  • 人間がいかに多く覚えられるか
  • 人間がいかに正確に処理できるか

に終始しているからです。

 

プログラミングについて勉強してきたからこそ感じるのですが、人間が覚えられる量や速さにはやはり限界があります。また、10個とか100個のデータぐらいのチェックであれば人間の目視でもいいでしょうが、これが1万とか100万個のデータになってくるとやはり人間の目視では限界があります。

 

特にこれからの世界では、扱うデータ量もより多くなっていくでしょうし、少子高齢化の影響によってますます人手に頼れなくなっていきます。そういった時に今までのやり方を踏襲していては、いずれどこかで限界が来るというか、長時間労働激務で多くの人が耐えられなくなっていくのではないでしょうか。

 

そういった世界が来た時に、プログラミングができてさらなる高速化、効率化ができれば、企業としても個人としても生き残っていけるのではないかと思います。

あわせて読みたい

こんな記事も読まれています

コメント