第1回：PythonからExcel VBAへ 〜なぜ回帰したのか〜 VBA一人情シス
Excel VBAで業務効率爆上げ！一人情シスが語る「真の使えるアプリ」の作り方
第1回：PythonからExcel VBAへ 〜なぜ回帰したのか〜
開発の喜びと運用の現実：理想とギャップの始まり
業務アプリを開発することって、本当に楽しいですよね。特にPythonのようなモダンな言語や、Webアプリのフレームワークを使って「こんなシステムがあれば、もっと業務が効率化されるはず！」というアイデアを形にするのは、大きな喜びがあります。私も、新しい技術を学ぶワクワク感や、それを実業務に適用できる達成感に夢中になっていました。
しかし、実際にアプリをリリースし、運用が始まると、思い描いていた理想と現実の間に大きなギャップがあることに気づかされました。「アプリは問題なく動いているはずなのに、なぜかユーザーに使われない」「想定外の問い合わせばかりで、改善に手が回らない」といった状況に、一人情シスとして頭を抱える日々が始まったのです。
「動く」と「使われる」の溝：ユーザーとの認識のズレ
作ったアプリが技術的に正しく**「動く」ことと、現場で本当に「使われる」**ことの間には、深い溝がありました。開発者としては完璧だと思っていても、ユーザーのITリテラシーや、長年慣れ親しんだ業務フローは、新しいアプリの導入を阻む大きな壁になったのです。
例えば、Webアプリで入力フォームを美しくデザインしても、ユーザーはほんの少しの項目の違いや、慣れない操作に難しさを感じてしまい、結局使い慣れたExcelに戻ってしまう、という光景を何度も目にしました。ユーザーが何を「便利」だと感じるのか、その認識のズレが、アプリが使われない根本原因だったのです。
Webアプリの不便さ：細かい修正が「大仕事」になる現実
このギャップを埋めるため、ユーザーからの要望を受けてアプリの改善に着手しましたが、Webアプリの改修は想像以上に大変でした。特に痛感したのは、**「細かい修正が大掛かりになる」**という点です。
具体例として、請求書作成ツールをWebアプリで作った時のことです。消費税の計算ロジックには通常「切り捨て」や「四捨五入」といったルールがありますが、ある特定の顧客だけ「切り上げ」で計算する、という複雑な例外処理が発生しました。さらに、同じ請求書の中で、合計額の端数の1円を「いい感じのところで調整する」といった、ロジックでは表現しにくい感覚的な微調整が必要となるケースもありました。Webアプリの場合、このような「ちょっとした例外」や「感覚的な調整」に対応するために、ソースコードを修正し、テストを行い、再度デプロイするという一連の作業が必要で、数時間から半日、時には数日かかることもありました。ユーザーはすぐに修正を求めているのに、このリードタイムの長さが、Webアプリの柔軟性の欠如を痛感させました。
VBA再評価の理由：ユーザーが「自分で直せる」手軽さ
このような経験から、私はある考えに至りました。「もしかしたら、ユーザーが自分で直せるくらいの手軽なツールの方が、最終的には効率的なのでは？」と。そこで改めて着目したのが、他でもないExcel VBAでした。
Excelは、多くのビジネスパーソンが日々使っている身近なツールです。そしてVBAを使えば、そのExcelの中に、業務ロジックを直接埋め込むことができます。Webアプリのように特別な開発環境やデプロイ作業は不要で、ユーザー自身がVBAのコードを少し修正したり、Excelのセルや数式を調整したりするだけで、軽微な修正を自分たちで完結できる可能性が見えてきたのです。これにより、ユーザーと開発者の間の物理的・心理的な距離がぐっと縮まるのではないか、という期待が芽生えました。
VBAへの「回帰」：本当に「使える」アプリを求めて
私にとって、Excel VBAへの回帰は決してPythonやWebアプリの否定ではありません。それは、あくまで**「本当に業務で使われるアプリとは何か？」**という問いへの、私なりの答えを追求した結果でした。
ある日、私が作ったWebアプリの隣で、ユーザーが当たり前のようにExcelを開き、アプリから出力されたデータをピボットテーブルや関数で再加工しているのを見た時、衝撃を受けました。「彼らが本当に求めているのは、使い慣れたExcelの中で、自分たちで自由にデータを扱えることなのではないか？」と。この瞬間こそが、私がPythonやWebアプリでの開発からExcel VBAへと**「回帰」**する大きなきっかけとなりました。
Discussion