ｖｂａのプロかどうかの基準

VBAで飯食っていける人(プロ)はほんの一握りですね・・・。

VBA関連の本書いている人はプロといえるのかもしれませんが、
VBAで飯食ってないひともクラスぐらいは普通だし。

こんにちは。

私は、プロとは名乗れるものではありませんが、いくつか見聞きしてきたものがあります。そして、いくつかの論点から語れるとは思います。軽々にプロが何である、とは言うつもりもありませんし、あくまでも、私見ですから、議論や中傷はお断りします。

まず、資料からです。

「本」を出してお金を得ている人なら、一応はプロとは言えるとは思うのですが、ある著者の内容は、まったくMicrosoft 側が示す基準には外れていて、私の目からは、それがプロだとは言いがたいものもありました。技術的に、プロレベルの書籍は、軒並み売れていません。読者側の批判もつよいようです。だから、1年程度で絶版になってしまいます。そういう事情から、あえて資料から言わせていただくと、残念ながら、英語の書籍を求めるしかないと思います。どう考えても、プロフェッショナルな資料は、もう日本語では手に入りそうにありません。特に、WordやOutlook は、条件的には不可欠なのに、VBAの資料は入手するのが困難です。たとえば、オライリーの書籍などは、内容的には難しくありませんが、興味深いです。なぜなら、視点が違うからです。

余談ですが、すべてがプロ仕様の内容とは言いませんが、出版社の九天社の倒産は、惜しいことをしました。また、アスキーのMicrosoft Office の書籍と、日経BPの同書籍では、大学と小学校ぐらいの差があるように思います。

次に、ソフトウェアです。

以前のDeveloper、Visual Studio Tools for Office, 現在のVS2008Pro が使いこなせることが条件になってくると思います。つまり、商用の証明機関 (CA) のデジタル証明書をつけるには、現在ではこうしたもので、COMやActive X で作るものが主流になっていると思うのです。むろん、現行のOffice添付のアドインが、すべてそうだとは言いませんし、実際に、Accessでは、このようなことは言えないし、Excelにおいても、それで、プロの製作のものだということではありません。ただ、以前、Microsoft サポートで、わたし的な理解ですが、「VBAの作成者は、著作権保護を言うなら、プロジェクトのロックのセキュリティを期待してはいけない、コンパイラでDLLにすべきである」と書いてあった覚えがあります。VBAで作成したものと、コンパイラでビルトしたものは、趣向が違うので、そうしたツールが絶対的ではありませんが。

次に技術。

プロフェッショナルな技術的な基準というものは、あるとは言いにくいですが、プロジェクトAのある方が、その基準のようなものを出しました。現在、VBAエキスパート・プロフェッショナルの試験の基準にもなっているわけですから、その資格や内容に問題はないと思います。ところが、その方が直接は言ってはいないのですが、VB6, VB.Net, HTML, VBS,ASP, C++, C の他の言語の知識を背景にして、VBAを使いこなすということのようです。ここの掲示板でも、それに該当する人物はいますが、クラスがどうこうというような、レベルとは違うと思うのです。たとえば、クラスというか、オブジェクト指向にしても、VBAから上り詰めていくことは不可能に近いわけで、C言語などからの概念から、派生してきたものだ、と考えるわけです。だから、私個人、VBAからは、技術として到達するものには限界があると思います。

一般的なプロとしての作業。

一般的に、プロの場合は、カスタマにヒアリングをして、その要望の概要をつかみます。結果的に相手の要望に満たないものを作ったら、いくら技術があってもプロとはいえません。しかし、製作する側は、その仕事をすべて知っているわけではないので、どの部分にポイントがあるかを見出さなければなりません。カスタマはプログラマではないので、肝心なことを曖昧な言い方をしたり、また、会社側が、表に出来ないような部分を、VBAで盛り込まなくてはならないというのは、特別なヒアリング技術が必要かもしれません。その仕事を理解しているのがベストですが、必ずしもそうとはいえません。それで、期限を区切られるというのですから、楽な仕事とは言えません。

また、私の感覚ですが、レイアウト的な才能が必要のような気がします。Excel、Access や　Wordでも、プロの作ったものが垢抜けているなと思う点は、そこに違いがあるようです。以前、愕然とさせられたことがありました。技術論とは違った部分が存在するようです。それこそはプログラムの技術だけの問題ではないので、経験的な差なのかもしれません。

私が教わったことは、ユーザーが遭遇しうるすべてのエラーに、プログラムとして対処するということでした。他にも、プロのコードは美しいものだとか言っていましたが、私には、分からないです。美的感覚よりも、機能的なものだと思っています。この場合は、個々の技術とは関係のないものが含まれていると思うのです。

もうひとつ、VBAとは直接関係がないかもしれませんが、私が知っているプロは、コーディングのスピードがまるで違うということです。私などは、まるで和英辞典を引きながら英文を書いているようなものです。それに、インテリセンスやヘルプでつづりを調べてしもうことがあります。そういう機能のおかげで、曲がりなりにも格好はつくのです。私は、もう年齢的にも才能も届かないのですが、世の中には、まるで同時通訳のレベルで、猛烈なスピードでコーディングをしている人たちがいるのです。とうてい、私などには敵わないです。

　1人の異端なVBAでご飯を食べている人の参考意見です。

　少なくとも○○が使いこなせればプロという風に考えている間はプロではありません。
クラスモジュールが使えるかどうか。確かに使えるとあれこれいいこともあります。ですが、それはあくまでとある問題解決をするための1手段にしか過ぎません。
　本来のプログラマーのあるべき姿は、とある問題を解決するために、その問題をできるだけ広い目線で捕らえてそれぞれの場合に応じて適した手法でその解を与えることだと私は思っています。
　効率のいいプログラムを書いて、可能な限り早く模範的なプログラムを書くことは重要な要素です。しかし、VBAのように他の人もメンテナンスする可能性のあるものならなおさらですが、他に使用する人のレベルを考慮したプログラムを作成することを求められることもあります。また、プログラムのソース面でもそうですが、他にも速度を優先なのか、使い勝手を優先なのか、はたまた簡単さが優先なのか絶対的な解は存在しません。(堅牢性の高い仕組みで作るなど揺らぎにくいものもありますが)
　どれだけ高等なテクニックを用いて作っても、使用者の要望・期待に添えられるあるいはそれを超えている結果を与えられなければ、ただのなまくらなプログラムになってしまいます。逆に、テクニックはたいしたこと無いのに市販してもいいくらいのとてつもない完成度に仕上げてしまう人がいるのもまた確かです。
　確かにテクニック・手法・手段は非常に重要です。ですが、それを踏まえた上で、それらの手法・手段を引き出しにしてその引き出しを多く持ち、その多くの引き出しから最適解になるように柔軟に手法・手段を組み合わせられる人こそプロというものではないかと私個人は考えます。