【前編】「VBAでできることはやり尽くした」完全文系が独学でVB.netに越境した日の記録

Excelの限界とシステム開発

Excelの画面を見つめながら、ため息をついた夜を今でも覚えている。建築内装やオフィス什器施工を行う地方の7拠点で、全国の現場をカバーする。そんな会社の総務部門にいたのだ。日々の業務で最も胃を痛めていたのが、車両費の確認作業だった。営業から「来週の青森の現場。2トントラックでいくらかかる？」という問い合わせがひっきりなしに飛んでくる。各拠点には独自のルールがあり、料金体系もバラバラだったのだ。

これまではVBAを駆使して、なんとか業務を回していたのだ。Excelの中にマクロを組み込み、自動で計算させる仕組みを作った。だが、所詮はExcelである。共有フォルダに置いたファイルは誰かが開いていると「読み取り専用」になり。データが重くなれば頻繁にフリーズしたのです。

限界を感じていた。Excelという枠組みの中でどれだけ高度なマクロを組んでも。このボトルネックは解消できない。誰でも自分のPCでサクサク動かせる、単独のアプリケーションが必要だったのだ。それが、未知の領域に足を踏み入れるきっかけだった。

VBAとVB6への憧れ、VB.netの選択理由

まず、数あるプログラミング言語の中で、なぜVB.netを選んだのか。理由は単純で、VBAの延長線上にあると思ったからだ。VBAを触り始めた頃、最も感動したのが「ユーザーフォーム」だったのだ。無機質なセルの羅列ではなく、ボタンやテキストボックスを自由に配置できる。まるで本物のアプリケーションを作っているかのような高揚感があった。「アプリケーションっぽくてかっこいい」という純粋な憧れが。

原動力になっていたのです。

VB6への憧れ、VB.netへの無謀な挑戦

もう一つの理由は、会社で稼働していた基幹システムの存在だのだ。それはVB6で作られた、いかにも一昔前の業務システムという風貌をしていた。グレーの背景に、立体的なボタン。一見古臭いが、キーボードだけで高速に操作できるその設計には。職人技のような美しさがあったのだ。以前、自分でも受注管理システムをVBAで自作した際。密かにその基幹システムのユーザーインターフェースを模倣した。

あの無骨な画面を、今度は本物のアプリケーションとして自分の手で生み出したい。VB6の正統進化とも言えるVB.netなら。それができるはずだと信じ込んだのです。

当然ながら、VBAとVB.netは似て非なるものである。当時の自分は、言語の仕様や環境の違いなど知る由もなかった……。ただ「VB」という名前に引き寄せられ。無謀にも独立した.exeツールを作ることを決意したのです。

バラバラ料金表の統合

次に、開発のターゲットは明確だった。全国の拠点でバラバラに管理されている「車両・遠方現場料金表」の統合である。運送業や施工業における料金の基本は、出発地から現場までの距離（km）だのだ。しかし。実務の最前線では「いちいち地図アプリで距離を測る暇などない」という声が圧倒的だった。そのため。

各拠点の担当者が長年の経験から「都道府県・市区町村単位」で料金を一発で出せる手作りのExcel料金表を運用していた。現場の知恵としては素晴らしいのだ。だが、全7拠点の料金表を集めてみると、背筋が凍った。フォーマットが全く違うのです。

これを一つにまとめ、誰でも瞬時に検索できるツールを作る。データベースの概念すら怪しい非エンジニアにとって、それは途方もない作業に思えた。しかし、このバラバラな情報を整理し、統一されたルールを定義しなければ。システム化は不可能だのだ。何日もかけてExcelのデータを睨みつけ、共通の項目を抜き出していく。泥臭いデータクレンジングの作業が延々と続いた。

Visual Studioの洗礼

データの整理に目処が立ち、いよいよプログラミングの準備に取り掛かる。ここで最初の大きな壁に激突した。開発環境の構築だのだ。VBAなら、Excelを開いて「Alt + F11」を押すだけでいい。すぐにコードを書き始められる。しかし。VB.netでアプリケーションを作るには「Visual Studio」という専用の開発環境が必要だったのだ。

マイクロソフトのサイトからインストーラーをダウンロードしたところまでは良かった。だが、インストーラーを起動して表示された画面を見て、頭を抱えた。

一方で、「.NET デスクトップ開発」「ASP.NET と Web 開発」「Azure の開発」「Node.js 開発」。聞いたこともない専門用語が画面いっぱいに並んでいる。どれにチェックを入れればいいのか、皆目見当がつかないのだ。勘を頼りにいくつかチェックを入れると。右下に表示された必要なディスク容量は数十ギガバイトに膨れ上がっていた。

職場の貧弱なパソコンのハードディスクを圧迫する数字を見て、血の気が引く。

ようやくインストールが完了し、Visual Studioを起動できたのは。それから数日後のことだった。黒を基調とした洗練された画面は。ExcelのVBAエディタとはまるで別次元のオーラを放っていた。

VBAからVB.NETへ、オブジェクト指向の洗礼

Visual Studioの画面を開き。とりあえず「Windows フォーム アプリケーション」のプロジェクトを作成してみた。画面に真っ白なフォームが現れた瞬間は、少しだけテンションが上がった。ツールボックスからボタンやテキストボックスをドラッグ＆ドロップで配置していくのだ。このあたりの操作感は、VBAのユーザーフォームとよく似ている。これならいけるかもしれない。

そう思ったのも束の間、コードを書こうとして手が止まったのです。

VBAからVB.net、オブジェクト指向の壁

そのため、VBAであれば。ボタンをダブルクリックして「Sub CommandButton1_Click()」の中に処理を書けば動く。しかし、VB.netのコードエディタには見慣れない言葉が溢れていた。

「Public Class Form1」
「Inherits System.Windows.Forms.Form」
「Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click」
クラスとは何かのだ。継承とはどういう意味か。ObjectやEventArgsとは何者か。

VBAの「手続き型」の考え方に染まりきっていた頭には。VB.netの基盤である「オブジェクト指向」の概念が全く理解できなかったのだ。ネットで検索しても「クラスは設計図で、インスタンスはそこから作られた実体です。たい焼きの型とたい焼きに例えると…」というお決まりの説明が並ぶばかりだ。たい焼きの話はわかったが。目の前の料金計算ツールをどう作ればいいのかは全くわからないのです。

厳格な型・スコープの壁

見えない壁に何度も跳ね返されたのだ。変数の一つを宣言するだけでも、スコープ（有効範囲）や型の厳密な指定が求められる。VBAがいかに緩く、初心者に優しい環境だったのかを痛感させられた。

パネル/vbnet-code-editor-red-squiggles.webp

動いた！初の自作アプリ、旅路の始まり

しかし、オブジェクト指向という概念を完全に理解するのは早々に諦めた。今の自分に必要なのは、美しいコードを書くことではない。目の前の業務課題を解決するツールを動かすことだのだ。そう割り切ってからは。ひたすら「動くコード」をコピペしては修正する泥臭い作業に没頭した。意味がわからない部分はブラックボックスとして扱い。とにかく自分の思い描く画面遷移や計算処理を形にしていく。

開発を決意してから、実に2ヶ月が経過していた。ある夜、ついにテスト用の料金データを使って。拠点と現場を選択し「計算」ボタンを押した。一瞬の間の後、画面に正しい料金がポップアップで表示されたのだ。「動いた…！」
誰もいないオフィスで、思わず声が出た。VBAという慣れ親しんだぬるま湯から飛び出し。未知の言語で初めて自立したアプリケーションを生み出した瞬間だった。

データベース最適化の泥沼

しかし、これはまだ長い道のりの第一歩に過ぎなかった。テスト用の数行のデータなら動くが。全国7拠点分の膨大な料金データをどうやってシステムに組み込むのか。単一のパソコンではなく。社内の全員が同時にアクセスして使えるようにするにはどうすればいいのかのだ。本当の地獄。つまり「データベース接続」と「実行速度の最適化」という底なし沼が待ち受けているとは。この時の自分はまだ知る由もなかった！。

さらに、パネル/vbnet-first-hello-world-success.webp

関連リンクとチェックリスト

Visual Studioの画面を開き、新しいプロジェクトを作成しようとしました。ここでもまた、様々な選択肢に戸惑いました。「Windowsフォームアプリ」「WPFアプリ」「コンソールアプリ」。どれを選べばいいのか、全くわかりません。とりあえず「Windowsフォームアプリ」という言葉が、VBAのユーザーフォームに一番近い気がして、それを選択しました。真っ白なフォームが表示されたとき、ようやく「これだ！」と直感的に思えました。しかし、そこからが本当の戦いの始まりだったのです。

まず、手始めに

まず、手始めに、VBAで使っていたボタンやテキストボックスをフォームに配置しようとしました。しかし、VBAエディタのようにドラッグ＆ドロップでポンと置けるわけではありません。ツールボックスからコントロールを選び、プロパティウィンドウで細かな設定をする必要があります。フォントや色、サイズなど、見た目を整えるだけでも一苦労でした。VBAでは直感的にできていたことが、VB.netでは一つ一つ丁寧に設定しなければならない。その違いに、最初は途方もない手間を感じました。しかし、逆に言えば、それだけ細かく制御できるということでもあります。VBAでは表現できなかった、より洗練されたユーザーインターフェースが作れるかもしれない。そう考えると、少しずつワクワクしてきました。

そして、いよいよコードを書き始めました

そして、いよいよコードを書き始めました。VBAの知識を頼りに、ボタンをクリックしたらメッセージボックスが表示される、というごく簡単な処理を記述しようとしました。しかし、VBAで慣れ親しんだ「MsgBox」が、そのままでは使えないのです。代わりに「MessageBox.Show」という記述が必要でした。他にも、変数の宣言の仕方、イベントハンドラの書き方など、VBAとは異なる文法に次々と直面しました。そのたびに、インターネットで検索し、試行錯誤を繰り返しました。まるで、今まで知っていた言語とは少しだけ違う、新しい方言を学ぶような感覚でした。最初は戸惑いましたが、少しずつコードが意図した通りに動き始めると、小さな達成感が積み重なっていきました。

特に苦労したのは、データベースとの連携でした

特に苦労したのは、データベースとの連携でした。ExcelのデータをSQLiteという軽量なデータベースに移行し、それをアプリケーションから操作しようと考えたのです。データベースの設計から始まり、テーブルの作成、データのインポート、そしてアプリケーションからのSQL文の発行。これらの作業は、プログラミングの「プ」の字も知らなかった私にとって、まさに未知の領域でした。エラーメッセージが出るたびに頭を抱え、夜遅くまで調べ物に没頭しました。しかし、試行錯誤の末、ようやくアプリケーションからデータベースのデータを取得し、画面に表示できた時の感動は忘れられません。バラバラだった拠点ごとの料金データが、統一された形で瞬時に表示された瞬間、これまでの苦労が報われたような気がしました。

開発を進める中で、最も重要だと感じたのは

開発を進める中で、最も重要だと感じたのは、やはり「検索」機能でした。ユーザーは、膨大な料金データの中から、特定の条件に合致する情報を瞬時に見つけたいと考えています。そこで、様々な検索条件を組み合わせられるようなUIを設計し、SQLのWHERE句を動的に生成するロジックを組み込みました。最初は単純な文字列検索しかできませんでしたが、徐々にAND検索やOR検索、範囲指定検索など、複雑な条件にも対応できるように機能を拡張していきました。ユーザーが求める機能を形にしていく過程は、まるでパズルを組み立てるようでした。一つ一つのピースがはまっていくたびに、システムが完成に近づいていく手応えを感じました。

振り返ってみると、VBAからVB.netへの移行は

振り返ってみると、VBAからVB.netへの移行は、想像以上に大きな挑戦でした。しかし、その過程で、プログラミングの基礎だけでなく、データベースの概念、UI/UXの重要性、そして何よりも「自分で問題解決する力」を身につけることができました。あの時、Excelの限界を感じ、一歩踏み出す勇気を持てたからこそ、今の私があるのだと感じています。プログラミングは、単なるコードを書く作業ではありません。それは、目の前の課題を解決し、人々の業務をより良くするための強力なツールなのです。この経験を通じて、私はプログラミングの面白さと可能性に魅了されました。そして、これからも新しい技術を学び続け、様々な課題を解決していきたいと強く思っています。

学習サービスとアンケート