エクセルのVBAで販売実績データをプログラミングする事になった（その４）

エクセルのVBAで販売実績データをプログラミングする事になった（その３）の続きであるが、結果約束は守れなかったが、正式な約束でもない為、別に問題にもなっていない。つまり、私が内部的なスケジュールを設定しただけの事なので、先週末期限に結果を出さなくても、特に問題にはなっていない。

さて、今週も仕事の合間にプログラムを作っているが（一日延べ１時間ぐらい）、これがなかなか難しいと同時に、業務を知る事とイコールになっている事が大分わかって来た。つまり、現在の業務の実務処理を知る事とその結果の基幹システムのアウトプットと工場側のシステムの両方を知らなければ、ＶＢＡのプログラムが組めない事が分かってきた。逆を言うと、このプログラムを組むことで、かなりの実務的な部分が見えてきつつあると言う事でもある。

一方で、その業務フローと基幹システムシステムのアウトプットのシステムが分かってくると、それをプログラムする為に、ＶＢＡのプログラムを実践的に組んで行くという正に、実務的で一挙両得な仕事になっている。２０年？近くプログラムを組んでいないが、ＶＢＡでエクセルのプログラムを組むのが大分見えてきており、これはこれで、今後の強力な武器になりそうな気がしている。

エクセルのＶＢＡのデバッグ環境の一部が分かってきて、私が昔組んでいた、ＵＮＩＸのＣ言語の開発環境と比較するとかなり、便利になっていると思う。もう少し本格的な方面に進もうかとも思っているが、この辺のバランスは難しい。いずれにしても、今回の処理つまりプログラミングはするが、これはあくまで、暫定的と考えている。ＶＢＡのプロミングの面白さにはまりそうになっているが、これはまた別の話でもある。

エクセルのＶＢＡを大分理解して来たので、かなりの部分を定型化できると考えているが、それは私自身も含めて、現状の課題を知らなければ解決しようがない。つまり現状の課題とシステムが結びついて、初めて私のプログラミングの一部が完成すると思う。

つまり、プログラミングを覚えても、仕事にはならず、仕事を覚える事で初めて、プログラムに意味が出てくるし、効率を上げる事ができると言う事でもある。

ブログを書くならBlogWrite