研究開発現場でのＶＢＡ（マクロ）の利用価値

　ある大手メーカーで派遣として開発試験の仕事をしていた時期があり、そこでVBAと出会いこれほど面白いものはないと思って、VBAの勉強を独学で続けています。

　私のいた現場では毎日、膨大なデータを計測し、それをまとめてグラフ化したり、過去のデータと照らし合わせたりということが日常であったのですが、VBAを使用してそれらを行っている人はあまり見受けられませんでした。

　そこで疑問に思ったのですが、自動車メーカーや家電メーカーで研究開発をする際にはVBAはあまり利用されないものなのでしょうか？

　できればメーカーでVBAを利用した開発支援ツールを作るような仕事がしたいと思っており、このような質問をさせて頂きました。

　また、開発支援を行う部署で働きたいと思った場合、他にどのような知識があればよいのでしょうか？

　よろしくお願いします。

No.1 ベストアンサー 回答者： imogasi 回答日時： 2011/12/03 19:58

>自動車メーカーや家電メーカーで研究開発をする際には

わたしはそういうところでの開発経験が無いので、あくまで私見ですが
思い当たる節があれば参考に
（１）ＶＢＡもエクセルで足したり、抜き出したりなど文系の、金額や件数・個数・人数を
扱っている場合はそれなりに使えるでしょう。
しかし統計（記述統計で無い）やＣＡＤや画像などになると、それをプログラムに載せる
背景智識や、ロジック（アルゴリズム的なこと）などが主になって、こちらで歯が
立たなくなる恐れがあります。
このコーナーでも理系の質問になると、回答がとたんに出なくなる。
今はまだＶＢＡなどやっているのは文系プログラマが多いのだと思う。
そういう職場へ入ったとして、内容（例えばば理系の、あるいは研究の）についていけるか
、ということ。例えば浮動小数点数の扱いなど、経験ありますか。
（２）今では職場は、レディメードのソフトやライブラリを使うのではないですか。
内容が複雑化して、一々勤務時間中に複雑な事項を組んで、デバッグしていては
能率が上がらないし、バグが怖い。
（３）ＶＢＡはあくまでエクセルなどのアプリの延長上に在る。
それ以外のものをやるにはＶＢと言うことになる。
インプットやアウトプットにエクセルシートが便利なだけで、内容はエクセルを
使う必然性がないものも多いと思う。ここの質問にも初心者でエクセルを使うから
エクセルの問題としている者がいるが見当違いのばあいがある。
エクセルはあくまで道具です。
（４）頭を使う分野は、ＵＮＩＸ系で勉強した人が多いかもしれない。学者・研究者の
世界などはエクセルＶＢＡなど出てこないように思うが。これは本質ではなく伝統
というものもある。

この回答へのお礼

ありがとうございます。

その道に進むためには理系のバックグラウンドが必要になるわけですね。

参考になりましした。

お礼日時：2011/12/04 17:29

No.2 回答者： TooManyBugs 回答日時： 2011/12/03 21:46

一般的に言えば研究開発部門ではVBAは中途半端な位置付けになっていると思います。

データー量が少ないらばわざわざVBAを用いなくとも表計算のマクロ程度で済む問題です。
せいぜい合計、平均値、最小、最大値位で使っても標準偏差くらい。

それ以上の事をするのであればVB、フォートランなどでプログラミングすることになるでしょう。
こちらであればちゃんとした予算処置や外注も可能でしょう。

この回答へのお礼

ＶＢＡでは帯に短し、襷に長しといったことですか。

高度なことをするには向かないのですね～

参考になりました。ありがとうございます。

お礼日時：2011/12/04 17:32

No.3 回答者： Siegrune 回答日時： 2011/12/04 15:06

研究開発現場にいたわけではないし、研究開発現場のシステムにかかわったことはあるけど

分野違いなので参考程度にしてください。

VBAを使って最も効果が高いのは、定型業務なんですが、
研究開発現場の仕事って、あまり同じ業務を繰り返すことが多くないんですよね。
一方で、毎回同じことを行う業務はすでにソフトウェアを開発していたり、
既存パッケージソフトを導入していたり。
例えば、同じ成分の計算でも、あるときはFeの、また別のあるときはCuの含有量を求めるとかで
計測方法も計測結果から成分を求める方法も異なるので結局毎回VBAを作るということに
なってしまうので結局、手作業のほうが早いということになりそうです。
グラフ化することについてでも同じことが言えます。
変な例で申し訳ないですが、ベクレル単位で出すのなら、10~100単位で普通のグラフを書けばいい
でしょうけどシーベルト単位で出すなら対数グラフのほうがよさそうです。
（測っているものも違いますが）
・・・

開発試験をはじめとした品質管理上の業務では定型業務が多いので、ニーズはあるのかもしれませんが、
頻繁に行う業務だとコストをかけてそのためのシステムを開発しているはずです。
結局、 ＶＢＡが活躍しやすいところというのは、頻度がある程度あって、システム開発するコストを
かけれないレベルの業務ということになるかもしれません。

この回答へのお礼

ご回答ありがとうございます。

研究開発では確かに定型業務は少ないですね。

それでもなお、ＶＢＡを活用できる場面があるのではないかと思い今回のような質問をさせていただきました。

＞ＶＢＡが活躍しやすいところというのは、頻度がある程度あって、システム開発するコストを
かけれないレベルの業務ということになるかもしれません。

この辺をもっと突っ込んだ内容のご回答を待ちたいと思います。

お礼日時：2011/12/04 17:42

No.4 回答者： MARU4812 回答日時： 2011/12/05 18:27

頻度に関しては、プログラムというだけで重要視すべき項目です。

どんなに間単なプログラムでも、開発に数日掛かります。
人件費で数万～数十万。1回しか使わないものにそのコスト
は合いません。
VBA だからではなく、「システム化する」事に対する費用対効果
を考える必要があります。

逆に、「システム化する」利点があるなら、状況に応じて適切な
言語を選べた方が良いですよね？VBA だけでなく、VBS、DOSコマンド
によるバッチ、その他の本格的なプログラミング言語と比べて
VBA が適しているから選ぶわけで、VBA しかできないのとは状況が
大きく異なります。
プログラムをメインの仕事として受注するなら、VBA の知識などは
ほんの一部に過ぎませんので、それだけで成り立つのは難しいです。
特定の現場へのコネなど、VBA だけできれば成り立つナニカが無いと
成立しないと思います。
「開発支援を行う部署」にわざわざ VBA だけできる人を求人する
企業は皆無だと思いますよ。

VB.NET Express Editon が無料で配布されるようになって、
コスト面での優位性も薄れたと思います。
VBA は10年以上前(VB6.0と同等)に考えられた仕組みで動いており、
シングルスレッドしか作れません。画面の部品として使えるもの
にも限りがあり、そもそも本格的なプログラムには物足りないです。
この状況で、わざわざ VBA で作る利点を出せるのは、Office
依存度が高い処理だと思われます。
ただし、Office も多機能です。
Office の VBA 以外の機能でほとんどカバーできるなら、これまた
意味がありません。

以上のような事から、「開発支援を行う部署」に採用されたい
なら、VBA だけでなく、幅広いシステムエンジニアとしての
知識が必要だと思います。
もしくは「研究開発をする部署」に入った上で通常業務の＋α
として Office の機能でカバーできない部分を VBA でフォロー
する。…しかしこの場合、開発のコストは見てもらえない場合も
多いです。実績を明確に示せなければ「余計な事をしている」
と判断されるかも。

そこまで考慮に入れた上で、「VBA を知らない」から非効率な
業務を行なっているところはたくさんあると思います。が、
それは「VBA を知らない」から「VBA の技術者の採用もしない」
と思います。そこに VBA を普及して効率化できれば、現場の神に
なれる可能性は高いですが、とにかくアプローチの仕方が難しい
でしょう。