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

Excelの限界とシステム開発

Excelの画面を見つめながら、ため息をついた夜を今でも鮮明に覚えています。私は、建築内装やオフィス什器施工を行う会社の総務部門に在籍していました。地方に7拠点あり、全国の現場をカバーしています。日々の業務で最も頭を悩ませていたのは、車両費の確認作業でした。

まず、営業担当からは「来週の青森の現場、2トントラックでいくらかかる？」といった問い合わせがひっきりなしに届きます。また、各拠点には独自のルールがあります。そのため、料金体系もバラバラでした。

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

当時の私は、大きな限界を感じていました。Excelの枠組みの中でどれだけ高度なマクロを組んでも、共有や動作のボトルネックは解消できません。そう確信していたのです。そのため、誰でも自分のPCでスムーズに動かせる、単独のアプリケーションが必要だと考えました。それが、未知のプログラミング領域に足を踏み入れるきっかけとなりました。当時は、ただがむしゃらに現状を変えたい一心でパソコンに向かっていました。

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

まず、数あるプログラミング言語の中で、なぜVB.netを選んだのかをお話しします。じつのところ、理由は非常に単純です。VBAの延長線上にあると感じたからでした。VBAを触り始めた頃、最も感動したのは「ユーザーフォーム」機能です。無機質なセルの羅列ではありません。また、ボタンやテキストボックスを自由に配置できます。

次に、まるで本物のアプリケーションを作っているかのような高揚感を覚えました。「アプリケーションらしくてかっこいい」という純粋な憧れが、当時の私を突き動かす大きな原動力になっていました。

ところで、今振り返れば、言語の選定理由は非常に直感的でした。しかし、それが後に自分を成長させる大きな一歩となりました。まず、少しずつコードを書き換えました。思うようにボタンが反応した時の喜びは、今でも忘れられません。VBAを知っているからこそ、VB.netの世界にもスムーズに入っていけると楽観視していたのです。

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を起動できたのは数日後のことでした。

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

Visual Studioを開きました。とりあえず「Windows フォーム アプリケーション」のプロジェクトを作成します。画面に真っ白なフォームが現れた瞬間は、少しだけテンションが上がったものです。

また、ツールボックスからボタンやテキストボックスをドラッグ＆ドロップで配置していく操作感は、VBAのユーザーフォームとよく似ていました。「これならいけるかもしれない」と期待を膨らませたのです。しかし、コードを書こうとして手が止まってしまいました。画面には見たことのない記述がずらりと並んでいます。何をどう書けば正しく動くのか、全く理解できませんでした。

そして、今思えば、それがプログラミングの深淵に触れた瞬間でした。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がいかに初心者に優しい環境だったのかを痛感させられました。例えば、整数を入れるはずの変数に文字列を代入しようとすると、即座にエラーが出るのです。これまでは「なんとなく」で動いていたプログラムが、厳格なルールに縛られることに大きな戸惑いを感じました。

しかし、この厳密さこそが、アプリケーションの安定性を支えているのだと理解するまでに、そう時間はかかりませんでした。やがて、エラーメッセージの一つひとつが、実はプログラミングの基礎を教えてくれているのだと気づきました。その時、少しずつ視野が広がっていったのです。辛い作業でしたが、避けては通れないステップだったのだと今では感じています。

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

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

開発を決意してから2ヶ月が過ぎたある夜、ついにテスト用の料金データを使って「計算」ボタンを押しました。一瞬の間の後、正しい料金がポップアップで表示されました。「動いた…！」と誰もいないオフィスで思わず声が出たのです。VBAという慣れ親しんだ環境から飛び出しました。未知の言語で初めて自立したアプリケーションを生み出した瞬間です。その時の感動は、今でも私のエンジニアとしての宝物になっています。

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

しかし、これはまだ始まりに過ぎませんでした。たしかに、テスト用のデータは動きました。それでも、全国7拠点分の膨大なデータをどうシステムに組み込むのか。社内の全員が同時にアクセスするにはどうすればいいのか。本当の地獄が待ち受けていました。それは「データベース接続」と「実行速度の最適化」という底なし沼です。この時の自分はまだ知る由もありませんでした。

さらに、さらに、データの量が増えるにつれ、検索速度が極端に低下しました。何度もアプリケーションが応答停止したのです。データベースへのクエリの書き方を工夫し、インデックスを適切に配置する。そんな高度なチューニングが必要になるとは想像もしませんでした。さらに、トラブルに直面するたびに解決策を探し回りました。技術書を読み漁る日々が続いたのです。

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

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