全部Excel VBAでいいのか
内製DXの話をすると、「結局どの道具で作ればいいのか」という問いにぶつかる。
自分の結論から言えば、中小製造業のデータ加工業務の大半はExcel VBAで回せる。以前の記事でも書いたが、シートの役割を分離してデータシートとUIシートを分け、VBAで制御すれば、受注管理や進捗管理、負荷の可視化まで十分に対応できる。
しかし、全部Excel VBAでいいかと聞かれたら、それは違うと思っている。自分自身、業務の中核になるツールはC#などで作っている。Excelでも同じことはできるが、あえて別の手段を選んでいる理由がある。
ツールの規模と「育て続ける必要性」
Excel VBAと専用の開発言語の差は、小さなツールではほとんど見えない。
たとえば、受注一覧から納期別に件数を集計するツール。こういう一瞬で全体を理解できる規模のものなら、Excel VBAで何の問題もない。壊れたら作り直せるし、引き継いだ人もコードを見ればすぐわかる。
差が出てくるのは、ツールが育ってきたとき。業務に合わせて機能を追加し、ロジックが増え、複数の業務をまたぐようになったとき、Excel VBAには構造的なしんどさが出てくる。
Excel VBAで大きくなると何が起きるか
開発者の好みの問題ではなく、構造的な制約がある。
コードが本番環境と一体化している。 VBAのコードはExcelファイルの中に埋まっている。コードを変更するということは、本番で使っているファイルを直接いじるということ。壊したら本番が止まる。だから怖くて触れなくなり、ツールが凍結する。
変更履歴が残らない。 いつ、誰が、何を変えたかを追跡する手段がない。「先週まで動いていたのに」となったとき、戻す方法がない。
構造化に限界がある。 モジュール分割はできるが、大きなロジックを整理するための仕組みが乏しい。コードの見通しが悪くなり、一部を変えたら別の場所が壊れる。
これらは小さなツールでは問題にならない。しかしツールが育って複雑になると、内製DXの最大の強みであるはずの「変化への追従速度」が、VBAの制約によって失われていく。改善したいのに改善できない、というのは本末転倒になる。
専用言語が解決すること
C#やPythonのような専用の開発言語を使うと、この問題が構造的に解消される。
開発環境と本番が分離している。 コードを変更して、テストして、問題なければ差し替える。本番を直接いじる必要がない。
変更履歴が残る。 Gitのようなバージョン管理ツールが使える。いつでも前の状態に戻せる。
保守性が高い。 コードの構造化、テスト、デバッグのための道具が揃っている。引き継いだ人がコードを読みやすい。
要するに、専用言語を使う理由は高度なことがしたいからではなく、ツールを継続的に育て続けられる環境を確保するためになる。
判断基準は「業務の戦略的重要度」
では、どこにExcel VBAを使い、どこに専用言語を使うか。その判断基準は、開発の規模だけではなく、その業務が自社にとってどれだけ重要かで決めるのがいいと思っている。
ここで、内製DXにおける道具選びを三つの層に整理してみる。
第一層：コモディティ業務 → 専用ソフト
会計、給与、勤怠、販売管理など。業種を問わず共通する業務には、安価で安定した専用ソフトがある。ここは自分で作る必要がない。
第二層：小さな改善・業務効率化 → Excel VBA
帳票の自動生成、データの集計、ちょっとした入力支援など。一瞬で理解できる規模のツールなら、Excel VBAで十分。作り直しも簡単だし、社内の「Excelに強い人」が対応できる。中小製造業の内製DXで作るツールの大半は、この層に収まる。
第三層：差別化の源泉となる中核業務 → 専用言語
自社の競争力に直結する業務プロセス。受注から出荷までのデータの流れ、独自の原価管理、顧客ごとの仕様管理など。ここは業務の変化に合わせて継続的に改善し続ける必要がある。育て続けるツールだからこそ、保守性と改善のしやすさが求められる。
「育てるかどうか」で線を引く
三つの層を分けるもう一つの見方として、そのツールを育て続ける必要があるかどうかという基準がある。
作って終わりのツールなら、Excel VBAで十分。動いているならそれでいい。壊れたら作り直すか、そのとき改めて考えればいい。
一方、業務の変化に合わせて改善し続けるツールなら、改善しやすい環境で作る必要がある。コードを安全に変更でき、履歴が残り、壊しても戻せる環境。これは道具の好みではなく、継続的な改善を可能にするための条件になる。
そして「育て続ける必要があるかどうか」は、その業務が自社の差別化にどれだけ関わっているかで判断できる。差別化の源泉である業務は、市場や顧客の変化に合わせて常にプロセスが変わる。だからツールも変わり続ける必要がある。
大半はExcelでいい、だから迷わなくていい
この三層の整理で伝えたいのは、中小製造業の内製DXは大半が第二層で回るということ。
「Excelでいいのか、もっとちゃんとしたものを作るべきか」と迷う場面は多いと思うが、迷うくらいならExcelで始めていい。一瞬で理解できる規模のツールを、必要なところから小さく作っていく。それで十分に効果は出る。
専用言語の出番は、ツールが育ってきて「これはもう簡単には作り直せない」「変更するのが怖い」と感じたとき。そのときが、第二層から第三層への移行を考えるタイミングになる。
最初から第三層を目指す必要はない。Excelで始めて、必要に応じてステップアップすればいい。その段階的なアプローチこそが、中小製造業の内製DXに最も合ったやり方だと思っている。