この記事でわかること
-
元スパコン技術者がなぜ「枯れた技術」であるVBAを推奨するのか
-
エンジニアほど陥りやすい「VBA学習の罠」と、マクロ記録のコードを「読み解かずに」活用する思考法
-
大量のログ解析やグラフ作成など「エンジニアリング業務」での具体的活用術
生成AIやノーコードツールの台頭により、プログラミングの敷居はかつてないほど下がっています。しかし、実際の開発現場やエンジニアリングの最前線では、「かゆい所に手が届かない」「ちょっとしたデータ加工に時間を取られる」という課題が依然として残っています。
かつて世界最速と謳われたスーパーコンピュータ「CRAY」を操り、原子力プラントの解析など高度なエンジニアリングに従事していた渡部守氏は、現在「Excel VBA」の普及に力を入れています。その実践的ノウハウを体系化した著書『エンジニアがExcel VBAを簡単に学べる本』（日経BP）は、現場で戦う多くの技術者から「即戦力の武器になる」と支持を集めています。
なぜ、最先端を知る技術者が、レガシーとも言われるVBAに着目するのか。そこには、エンジニアだからこそ共感できる「ツールとしての合理性」と、現場の生産性を爆発的に高めるための独自の哲学がありました。
渡部 守
理工系の大学卒業後、大手情報処理会社にて米CRAY社のスーパーコンピュータを用いた原子力プラントの熱流動解析に従事。その後、建設系3次元CADシステムのマクロ開発を経て、Excel VBAの可能性に着目。SEとして独立後は、C言語やJavaの講師を務める傍ら、独自のVBA教育メソッドを確立。現在はマクロプログラミングの普及活動を行っている。
エンジニアがExcel VBAを簡単に学べる本
出版社：日経BP 著者：渡部 守
目次
スパコンからExcelへ。原点は「CADのマクロ機能」にあった
渡部さんのご経歴を拝見すると、キャリアのスタートはスーパーコンピュータを使った原子力プラントの熱流動解析という、まさに「計算機科学の極地」のようなお仕事ですよね。そこから、もっとも身近なツールである「Excel VBA」へ専門領域を移された背景には、どのような経緯があったのでしょうか？
確かに、最初はFortran77（※1）を使って、流体の動きや熱の伝わり方をシミュレーションするような、ゴリゴリの科学技術計算をやっていました。当時はまだパソコンなんておもちゃのような時代で、スーパーコンピュータを使ってやっと計算ができるような世界でしたからね。
転機となったのは、その後に携わった建設業界向けの3次元CADシステムの開発です。実は「マクロ」という概念に深く触れたのは、ExcelではなくCADが先だったんです。
※1 Fortran77（フォートラン ななじゅうなな） 1977年に標準化されたプログラミング言語。数値計算や科学技術計算に特化しており、スーパーコンピュータによるシミュレーション分野などで長年使われている。
たしかに、CADも複雑な操作を自動化するためにスクリプトを書いたりしますよね。
そうです。CADの操作というのは非常に複雑で、毎回同じ手順を手作業で繰り返すのは現実的ではありません。そこで、操作手順を記録して再生する「マクロ機能」が必須だったんです。私が開発していたCADソフトにも、今のExcelにある「マクロの記録」と同じような機能を実装していました。
その後独立して、ある企業から「Excelで売上管理システムを作ってほしい」と頼まれたのが1997年頃。実は当時、私はExcelなんてほとんど触ったことがなかったんですよ（笑）。
えっ、それは意外です。
本屋に行ってExcelの解説書を１冊買ったんです。そうしたら、「マクロの記録」という機能があることが書いてあった。それを見て「なんだ、CADと同じじゃないか」と。これがあれば、メーカー（マイクロソフト）しか知らない内部の命令文を知らなくても、操作を記録するだけでコードが書ける。これはいけるぞと直感しました。
なるほど。CAD開発の経験があったからこそ、VBAという言語そのものではなく「操作を自動記録して再利用する」というアーキテクチャの強みにすぐに気づけたわけですね。
その通りです。多くのエンジニア、特に真面目なエンジニアほど、VBAを学習する際に「言語仕様」や「オブジェクトモデル（※2）」を最初から全部理解しようとして挫折します 。Excelの機能は膨大ですから、それを全部暗記するなんて不可能です。
でも、「マクロの記録」を使えば、やりたい操作のコードをExcel自身が教えてくれる。これはある意味、最強のドキュメントであり、開発支援ツールなんですよ。
※2 オブジェクトモデル アプリケーションが持つ機能を操作するための構造。Excelであれば「Application（アプリ） > Workbook（ブック） > Worksheet（シート） > Range（セル）」のように、機能が階層構造で管理されていること。
「マクロの記録」で生成されるのは、スパゲッティコードではない
ただ、プロのエンジニアの中には、「マクロの記録」で生成されるコードは冗長なスパゲッティコード（※3）と敬遠する人も多いですよね。
※3 スパゲッティコード 処理の流れが複雑に絡み合い、解読や修正が困難なプログラムコードのこと。マクロの記録を使うと不要な選択処理（Select）などが大量に含まれるため、こう呼ばれやすい。
そうですね、プログラマーとしてのプライドが高い人ほど、最初からきれいなコードを書こうとして、マクロの記録を使わずにゼロからコーディングしようとします。でも、それは、ことマクロ開発の場合には非常に効率が悪いのです。
昔は開発現場に分厚い電話帳のようなマニュアルが置いてあって、それをめくりながらコードを探していました。でも、「マクロの記録」があれば、操作するだけでその答え（コード）が出てくる。つまり、マクロの記録は「分厚いマニュアル」を不要にする効率良い機能なんです。
なるほど。マニュアルを引く代わりに、操作して答えを出させるわけですね。
ええ。生成されたコードがごちゃごちゃ汚くても、中身を全て理解する必要は毛頭ありません。私は「ブラックボックス（※4）として扱えばいい」と教えています。
例えば「セルに文字を表示させたい」と思ったら、どう書けばいいか調べるのではなく、実際に「文字を入力する操作」を記録すればいい 。コードの中身を解読する時間は無駄です。結果として動くコードが出てくれば、それでいいわけですから。
※4 ブラックボックス 内部の構造や動作原理を知らなくても、入力と出力の関係だけで利用できる状態のこと。渡部氏は、マクロ記録で生成されたコードの詳細は理解せずとも、機能として使えればよいという意味で使用している。
その割り切りは重要ですね。ただ、そのままでは汎用性がありません。どうすれば実務で使えるコードになるのでしょうか？
最大のポイントは、「固定部分」を「可変」に変えること。これに尽きます。 上記の例では、操作したセル範囲（例：Range("B2")）がそのまま固定値として記録されます。しかし、実務ではデータの位置や行数は毎回変わりますよね。
しかし、次の3ステップさえ踏めば、どんな複雑な操作でも自動化できます。
なるほど。しかし、エンジニア視点では、どうしても「オブジェクト指向」を意識して設計したくなると思うのですが。
そこが落とし穴なんです。VBAをオブジェクト指向型言語だと扱わないことが重要です。VBAはもともと、初心者でも扱いやすいBASIC言語（順次処理の手続き型言語）から発展しただけのものです。
VBAのなんちゃってオブジェクト指向の部分を使ってしまうと、かえってコードが複雑になり、VBA本来の単純な「手軽さ」が失われてしまいます。あくまで「手続き型言語」として割り切って使うのが、最も生産性が高いんですよ 。
エンジニアリング業務をハックする！ 大量データ処理とグラフ化の自動化
ここからは、具体的な活用事例についてお聞きしたいと思います。VBAというと「事務職の業務効率化」というイメージが強いですが、エンジニアリングの現場ではどのような使い方が有効なのでしょうか？
ものづくりをされているエンジニアの皆さんは、日々大量の数字データをExcelで扱っていると思います。ExcelのVBAが最も威力を発揮するのは「大量のデータの処理」と「データの可視化（グラフ作成）」です。
例えば、サーバーのログファイルや、実験装置から出力される計測データが大量にあるとします。これを手作業でExcelに貼り付けて、整理して、グラフにする……なんて作業をしていたら、日が暮れてしまいますよね。
はい、Pythonでやる手もありますが、環境構築が面倒だったり、結果を結局Excelで共有する必要があったりして、VBAでサクッとやりたいシーンは意外と多いと思います。
そうなんです。ここで紹介したいのが、「CSV等のデータファイルを直接読み込んで、必要な部分だけを抽出する」というテクニックです。通常、ExcelでCSVを開くと、全てのデータがシートに展開されます。しかし、データ行数が100万行を超えていたり、ファイルサイズが巨大だったりすると、Excel自体が固まってしまうことがあります。
そこで、VBAで必要なデータ（例えばエラーログや特定の時間の計測値など）だけをシートに書き出すのです。
この方法なら、巨大なデータファイルでも、重たいExcelにせずに高速で処理できます。これは、まさにデータのフィルタリングを行うエンジニアリングの処理に適していますよね 。
なるほど、Excelを「ビューアー」として使うのではなく、「データ処理エンジン」として使うわけですね。
その通りです。そしてもう一つ、エンジニアにおすすめなのが「グラフ作成の自動化」です。 実験データを整理する際、例えば「100個のデータファイルについて、それぞれ同じ形式のグラフを作ってレポートにする」という作業が発生したとします。これを手動でやると、範囲選択のミスも起きるし、何より精神的にきついです。
想像するだけで辛いです……。でも、グラフのVBAって、オブジェクトの階層が深くて難しくないですか？
そこで「マクロの記録」の出番です。 まず、1つのデータで手動でグラフを作ってみて、それを記録します。そうすると、グラフの種類（xlLineなど）やデータ範囲の指定方法がコードとして生成されます 。
ここで重要なのが、先ほど申し上げた「固定を可変にする」技術です。 記録されたコードには、Range("B1:C1,B26:C49") のように、ある1日分の範囲が固定で書かれています。これを、変数 k を使って Range("B1:C1,B" & k & ":C" & k + 23) のように書き換えるんです。
なるほど。k がデータの開始行で、そこから23行分（24時間分）下までを選択する、という式になっているわけですね。
そしてループの最後に k = k + 24 と書いて、次のデータの開始位置へずらしていく。 たったこれだけの工夫で、データが100日分あろうが1000日分あろうが、ボタン一つで瞬時にすべてのグラフが生成され、整列されるようになります。
ある電機メーカーの現場では、それまで社員が総出で何日もかけて行っていた実験データの集計とグラフ化作業を、私が作ったマクロでボタン一つ、数分で終わるようにしました。
数日かかっていた作業がボタン一つですか。それは劇的な変化ですね。現場の方々の反応はいかがでしたか？
経理部長からは「君のせいで部下の仕事がなくなってしまったじゃないか」と冗談交じりに怒られましたよ（笑）。 でも、それによって生まれた時間で、エンジニアは本来やるべき「データの分析」や「次の設計」に集中できるようになったんです。
「仕事がなくなる」というのは、自動化における最高の褒め言葉ですね。単なる時短ではなく、エンジニアが「本来の創造的な業務」に時間を使うためのVBAという視点は、非常に重要だと感じます。
「ExcelかAccessか」問題に終止符を。VBAによる高速化の極意
大量データを扱う場合、「ExcelではなくAccess（データベース）を使うべきでは？」という声を聞くこともあります。渡部さんはこの点についてどうお考えですか？
結論から言うと、数万〜数十万件レベルのデータであれば、わざわざAccessを導入する必要はありません。Excel VBAのチューニングで十分対応可能です。
よく、システム会社が「データ量が多いからデータベース化しましょう」とAccessやSQL Serverの導入を提案してきますが、それによって運用コストが跳ね上がったり、現場の人間がメンテナンスできなくなったり（属人化）するケースをたくさん見てきました。
確かに、Accessは使える人が限られますし、配布も面倒です。でも、VBAで数万件のデータをループ処理すると遅くなりませんか？
そこには明確なテクニックがあります。VBAが遅いと言われる原因の9割は、「画面描画」と「セルへの書き込み回数」です 。
まず、処理の最初に Application.ScreenUpdating = False と書いて、画面の更新を止めます。これだけで処理速度は数倍になります。
私の経験では、これらのテクニックを使うことで、処理速度を30倍以上高速化できたこともあります。 エンジニアの方なら、メモリ（配列）とI/O（※5）（セル操作）の速度差は直感的に理解できるはずです。VBAでもその原理は同じ。適切なアルゴリズムさえ組めば、Excelは驚くほど高速なデータ処理基盤になります。
※5 I/O（アイオー） Input/Outputの略で、データの入出力のこと。ここではメモリとディスク（または画面）との間のデータ転送を指し、一般的にこの処理は時間がかかる。
30倍はすごいですね！「VBAは遅い」というのは、言語のせいではなく、書き方の問題が大きいということですね。
その通りです。Accessを導入してブラックボックス化するくらいなら、全員が持っているExcel上で、高速なVBAを組んだ方が、メンテナンス性もポータビリティ（配布のしやすさ）も圧倒的に高い。これが「現場の最適解」であることが多いんです。
AI時代における「読み書き」のスキル。VBAはなくならない
最近ではChatGPTやCopilotなどの生成AIがコードを書いてくれるようになりました。「もうVBAを勉強する必要はないのでは？」という意見もありますが、これについてはどうお考えですか？
逆ですね。AI時代だからこそ、VBAの「読み書き（リテラシー）」が必要になります。
生成AIは確かに便利で私もよく使いますが、自分のやりたいことに対して微妙にズレていることも多々あります。
AIが出したコードがうまく動かなかったり、変な挙動をしたときに、自分で修正できる能力が必要だと。
そうです。プロとアマチュアのAI利用の違いはそこにあります。 アマチュアはAIが出したコードをそのままコピペして、実行しようとする。プロのプログラマーは、AIに「部品」（一部の機能）を作らせて、それを自分の書いたコードの中に組み込んで利用します。
なるほど。VBAという言語自体が、エンジニアにとっての「共通言語」や「基礎教養」のような位置づけになっていくのかもしれませんね。
VBAはなくならないと思います。忙しいエンジニアや非プログラマーが難しい文法の勉強なしで大量のデータ処理を手軽に且つ多彩にプログラムが組める言語はVBAしかありません。過去にMac版ExcelでVBAが廃止されたことがありましたが、すぐ次のバージョンで復活しました。CADの世界でも同様です。
VBAがもしなくなってしまったら、世界中のプログラミングに不慣れな人がプログラムを組める言語が無くなってしまう。だから簡単になくすことはできません。
それに、Python in Excelなども出てきましたが、専用のエディタ（VBE）があって、デバッグがしやすく、コンパイル不要ですぐ動くというVBAの手軽さは、現場での「ちょっとした自動化」において依然として最強のツールです。
新しい技術を追うことも大切ですが、足元の業務を確実に楽にする技術もまた、エンジニアにとって強力な武器になるということですね。
私は「日本の生産性を上げる」ことをモットーに活動していますが、そのためには一部のエリートエンジニアだけでなく、現場の多くの人が「プログラミング的思考」を持つことが不可欠です。その入り口として、VBAは最適なんです。
特に、実験データや商品データなどの大量処理に時間を取られているエンジニアの方々にこそ、VBAを活用してほしい。Excel作業に費やしている時間を短縮し、本来の生産的な業務に集中できる時間を増やしてもらいたい。そんな思いでこの本を書きました。それが結果として、日本の物づくりの発展に少しでも寄与できればと願っています 。
【取材後記】
かつてスーパーコンピュータで解析を行っていた渡部氏が、今はExcel VBAの普及に情熱を注ぐ。一見すると対極にあるように見えますが、「重要なのは、それを使ってどう課題を解決するか」という、エンジニアリングの本質的なメッセージを感じ取ることができました。
高度な技術力を持つエンジニアが、あえて泥臭いVBAを使いこなし、現場の生産性を劇的に変えていく。そんな「実利を取る」姿勢こそが、これからのエンジニアに求められるバランス感覚なのかもしれません。 机上の空論ではなく、明日からの業務を確実に楽にするために、まずはVBE（Visual Basic Editor）を開いてみることから始めてみてはいかがでしょうか。
ライター
