知識の倉庫の整理はてなブログからワードプレスに引っ越しました。ここでは中小企業診断士の勉強記や経理、派遣社員として働いて気づいたこと、その他にプログラミング関連やVBAについて思ったことを書いています。現在はJavaScriptを勉強中。2018.08.29ExcelVBAやAccessVBAなどのプログラミングの勉強を始めてだいたい1年ぐらいが経ちましたが、その中で非常に驚いたことがあります。それは、プログラミングには「さらなる高速化の世界がある」ということです。このブログでは、1年程前からとあるきっかけによって、ExcelVBAによってつくられたマクロの威力について思い知らされた、といった記事をいくつか書いてきました。いうのも、普通に手作業で進めていたら1時間とかそれ以上かかっていたであろう仕事が、Excelのマクロを利用することによって文字通り「一瞬」で終わってしまったからです。それからは、マクロやExcelVBAに魅了されて、自分でコツコツ勉強しながら実務でもちょっとずつ使っていくという日々が続きました。それから1年が経つのですが、プログラミングの世界を勉強していると経理の仕事とはまた違った世界を見ることができます。プログラミングの世界を勉強していると、今までとは全く違う価値観を垣間見ることができるのですが、それは先にも書いたように「さらなる高速化」です。今回はこのことについていろいろと思ったことを書いていってみます。高速化のための2つのアプローチマクロの実行時間を短縮するための高速化プログラミングの世界と経理の世界との比較あわせて読みたいただでさえ超高速なのにさらに高速化しようとしていることに驚く経理や事務職の仕事でExcelVBAやマクロを使ったことがある人ならわかると思うのですが、仕事に合わせて適切にマクロを組むことができれば文字通り「一瞬」でプログラムが業務を処理をしてくれてます。プログラミングの世界には驚くべきことに「さらなる高速化」をしようとしている人たちがいるようです。「えっ?ただでさえ速すぎるくらいなのに、これ以上まだ速くする必要があるの?」と驚きました。最初のうちはこの事実にただただ驚くことしかできなかったのですが、「なんでそこまでするんだろう?」と考えた時、この理由として何となく心当たりはありました。ブログを書いたりしていると、どうすればもっと上手く書けるようになるだろうかと考えて、他の人はどんな風に書いているのだろうか見にいったりして、いろいろと知りたくなるものです。そのようにインターネットであちこち見て回っていると、偶然にWebサイトの構築化とか、より専門的なサイトを見つけることがあります。そのようなサイトには「読者のユーザビリティ向上のためには表示速度をより速めることが必要です」といった言葉が書かれている時があります。「表示速度の向上といった難しいことは、システムエンジニアやプログラマーなどその道の凄い専門家ならできることであって、自分のような普通の人間には関係ないだろう」なんて思ったりしていました。考えてみると、やっぱり遅いよりかは速い方が良いというのは理解できます。自分も何らかのサイトを見ようとした時、表示されるまでに1分とか2分もかかってしまったら、さすがにそこまで待ってはいられないので離脱します。スタンダード』を最近読んでいたのですが、その中に「VBAの高速化」について書かれた箇所があります。そこには次のように書かれています。高速化には2つのアプローチがあります。1つめは、できる限り無駄な処理を行わないこと、2つめは、より処理速度の速い処理を選択することです。VBAのプログラミングにおいて高速化を図るには2つの方法があるということですね。無駄な処理を行わないより処理速度の速い処理を選択ということらしいです。処理の高速化を図るというのはVBAの世界にもあるようですね。この記述を見る前は、先に書いたように処理の高速化が必要なのはブログとかWebサイトの表示速度についてだけだと思っていました。今回の公式テキストの記述やVBA以外の様々なプログラミング言語について書かれたサイトなどを見てみると、処理の高速化というのはプログラミングの世界全体について言えることのようです。スタンダード』には「無駄な処理を行わないヒント」として「無駄な処理の多くは、繰り返し処理や分岐処理の中に隠れています」とあり、その事例のひとつとして次のようなコードを記述しています。iこの場合「処理1」は10回の処理、「処理2」は100回の処理、「処理3」は1000回の処理をすることになります。本書では処理1の処理時間を1/100秒短縮しても全体で0.1秒しか短縮できないが、「処理3」の処理時間を1/100秒短縮すれば、全体で10秒の時間を短縮できると記述しています。For」などで繰り返し処理を抜けるという方法が考えられます。2つめのアプローチである「より処理速度の速い処理を選択」する視点だと、そもそもFor...Nextステートメント使わないという方法も考えられます。以上の方法以外にも、本書では処理速度の速い処理をするためのヒントとして、事前バインディングではなく実行時バインディングを選択するという方法や、変数において適切な型かつ適切な適用範囲で宣言することによってメモリの無駄な消費を抑えられるとあります。要は、VBAにおける処理の高速化のためにはいろんな方法があると、そのたくさんの方法の中からより高速で適切な手法を選択していくことによってVBAの処理の高速化を図ることができるということです。マクロの実行時間を短縮するための高速化もうひとつ、プログラミングの処理の高速化を考えるきっかけとなった本に『ExcelVBAを実務で使い倒す技術』というものがあります。この本はExcelVBAを実務で使う上で様々なテクニックが書かれており、読んだ感じではある程度ExcelVBAを知っている人向けかなと思います。マクロの実行時間を短縮するテクニック」が印象に残りました。マクロの処理の高速化を図るにはいくつもの方法がありますが、その中のひとつに「計算回数を減らす」という方法があります。その事例のひとつとして本書では、エクセルのシートに「10,000行×10列にテキストを書き込む」という処理を実行する次のようなコードが記述されています。Subこのプログラムの計算回数は「10,000行×10列=100,000回」となり、本書では処理が終わるまでの実行時間は「32.1875秒」と書かれています。人間が手作業でエクセルのセル10万個に「hoge」という文字列をコピペしていったら、おそらくとんでもない時間がかかるはずです。それを考えるとコンピュータに処理してもらえば32.1875秒になるので、数値は悪くないように思えます。本書では、次のようなコードにすることによって処理速度をかなり改善しています。Subこのコードは先ほどのコードとは違い、「A~J列に、一気にテキストを書き込む」という処理になっています。人間の手作業に例えると、まずエクセルのシートのA1からJ1まで「hoge」をコピペします。その次にA2からJ2まで「hoge」をコピペしていって、それを1万行まで繰り返すといった感じです。これだとプログラムにおける計算回数は「10,000回」になり、先ほどのコードの計算回数から10分の1になります。その結果、本書では実行速度が「3.765625秒」となっています。処理速度が改善された理由として、A列からJ列までのテキストの書き込みを一度に処理することによって、列方向のFor分がなくなって、その分の計算をしなくてもよくなったことが挙げられます。本書では、この後さらにもう一段、圧倒的に処理速度が改善できるコードが記載されています。興味がある方は購入しても全然損はないと思います。最初本書のこういった部分を読んだ時は、「あぁ、世の中にはこんなやり方もあるんだなぁ」といろいろと感動してしまいました。ここまで書いてきて思ったのは、やはり自己流だけではなくて、いろんな人のいろんなやり方を見てみるべきだと思います。他の人のサイトや今回の記事に書いたような本を読む前までは、プログラミングに関して自分にはそもそも「高速化」といった概念が全くありませんでした。その理由としては、たぶんプログラムとかマクロなどを一度つくってしまったら業務を文字通り一瞬で処理してくれるので、「これ以上の高速化」まで考える必要がなかったんだと思います。そのように新しい発見を得るためにも、多くの人のコードや本を見ることは決して損はないでしょう。プログラミングの世界と経理の世界との比較ここまでプログラミングの世界にはさらなる高速化とコードの効率化というものがある、といったことを書いてきました。このようなことが進められる理由や背景としては、やはり「扱うデータ量」が増えてきているからではないかと思いました。昨今の企業戦略には、ひとりひとりの名前や生年月日に始まり、購買履歴や趣味嗜好なども取り入れて戦略が練られるなど扱うデータ量が日々増加しています。いった日々増えていくデータを扱うには手作業ではいろいろと限界があるはずです。そのため、プログラミングやそれによってつくられるシステムが重宝されるようになってきたと思うのですが、それでもまだ足りないということでさらなる処理の高速化が図られていったのではないでしょうか。いったやり方は、自分が今まで仕事をしてきた経理の世界とは全然違うと感じました。いうのも、経理の世界というのは会計の知識について人間がいかに多く覚えられるか人間がいかに正確に処理できるかに終始しているからです。プログラミングについて勉強してきたからこそ感じるのですが、人間が覚えられる量や速さにはやはり限界があります。10個とか100個のデータぐらいのチェックであれば人間の目視でもいいでしょうが、これが1万とか100万個のデータになってくるとやはり人間の目視では限界があります。これからの世界では、扱うデータ量もより多くなっていくでしょうし、少子高齢化の影響によってますます人手に頼れなくなっていきます。いった時に今までのやり方を踏襲していては、いずれどこかで限界が来るというか、長時間労働激務で多くの人が耐えられなくなっていくのではないでしょうか。いった世界が来た時に、プログラミングができてさらなる高速化、効率化ができれば、企業としても個人としても生き残っていけるのではないかと思います。コメントをキャンセルメールアドレスが公開されることはありません。