EUC開発の心得について

最近，仕事の関係でEUC開発のことを考えています。EUCとはEnd User Computingの略ですが，仕事の効率性とか正確性を高めるために，手作業や手計算をコンピュータに代替させるべく，現場でプログラムの開発を行うことです。

よくある事例は，MicrosoftのExcelとかAccessとかWordにおいてはVBA（Visual Basic for Applicationの略で，Visual Basicというプログラミング言語の簡易版）というプログラミング言語が手軽に使えるようになっているので，これらを用いて計表作成EUCや宛名印刷EUCを開発するといったもので，どこの職場にもそういうのが得意な（好きな）社員がいるものです。業務によっては，手作業で何日もかかっていた仕事が劇的に短縮されることもあり，ホントに便利なものですが，よくある不幸として，EUCを開発した社員が後に人事異動や退職してしまったために，EUCの簡単な手直しを行える社員がいなくなり，次第にEUCがごみとなり，昔の「原始時代」に戻ってしまうといったケースです。幸い，ワタクシの職場にはVBAを扱える，あるいは扱う潜在能力がある社員が比較的豊富であり，EUCのメンテナンス要員は確保できている状況です。しかし，当初のEUC開発が個性的なプログラミングによって行われるケースも少なくなく，こうなると残された者たちのメンテナンスは容易ではありません。

そこで，当初のEUC開発の段階で開発者が何か心がけておくことで，その後のメンテナンスがかなりやりやすくなるのではないか，そう考えて，以下に何点かあげてみました。

　専門的な業務プロセスとそうでない業務プロセスをプログラム内で明確に役割分担せよ

他人が作ったEUCがメンテしづらいのは，専門的な業務プロセスとそうでない業務プロセスを一連のプログラムとして記述してしまっているからかも知れません。単純な宛名印刷EUCであれば，条件に合った顧客の名前と住所をデータベースから拾ってきて印刷用フォームに並べて順番に印刷する，といった感じでしょうから，一連のプログラムとして記述しても比較的メンテ容易だと思います。
しかし，証券投資リスク計表作成EUCのような複雑なものであれば，専門的なリスク指標の計算部分については専門知識のある社員がVBAあるいはVB（Visual Basicの略で，VBAの上級版）で開発する一方，データベースからの情報収集や計表印刷といった専門的でない部分のプログラミングについては，通常の社員がVBAで開発するという役割分担がいいと思います。
もう少し具体化すると，専門性の高い計算ロジック部分については，VBを用いたDLL（Dynamic Link Libraryの略で，それ自体では稼動せずに他のプログラムから呼び出されて必要な機能を提供するタイプのプログラム形態）の形で開発し，専門的でない部分からDLLを呼び出す形にするのがいいと思います。

　専門性の高い計算ロジック部分についてはC/C++/C#を捨ててVBに移行せよ

専門性の高い計算ロジック部分についてはVBを用いたDLLの形で開発することを上で推奨しましたが，従来こうした保守本流のプログラミングは，C/C++/C#といった，いわゆるC言語ファミリーの独壇場でした。（なお，Webアプリの開発ではJavaの独壇場かも知れませんが，本稿のフォーカスと異なるため，特段言及しません。）
ワタクシのプログラミング人生からすると，C言語ファミリーに大きく傾倒した時期もあり，同様のキャリアを持つ「お仲間」と同様に「Basicなんて初心者向け言語だ」といったやや差別的な気分がなくもなかったんですが，MicrosoftのVBに賭ける最近の意気込みがかなり本気であると最近知りました。VB2008やVB2010は，同時期のVC#2008やVC#2010と同程度のオブジェクト指向言語へと進化しており，バカにしてはいけないと思った次第です。
C言語ファミリーは，メモリの占有や解放にややナイーブすぎ，またVBAから入った学習者にとっての文法ギャップが小さくないという気がします。VBAとVBは当然ながら文法ギャップは小さく，「専門性はあるがプログラミングはあまり経験がない」といった社員にとってもVBはハードルの低い存在ではないでしょうか。

　専門性の高い計算ロジック部分については関数ライブラリの形でなくクラスライブラリの形で公開せよ

先ほど，専門性の高い計算ロジック部分については，VBを用いたDLLの形で開発し，専門的でない部分からDLLを呼び出す形にするのがいいと述べましたが，このDLLなるプログラムファイルをどういう形で完成させるかという話です。
DLLというプログラムファイル形式は1990年代から使われ始めましたが，当時は関数しかDLLで提供できませんでした。オブジェクト指向プログラミングの知識がない人々にとってはそれでもまったく困らないわけですが，関数の代わりにクラスをDLLで提供できれば，専門性が相対的に低いVBAユーザーにとっても自然にオブジェクト指向プログラミングの恩恵を受けられる可能性が高まります。
こう述べても，オブジェクト指向プログラミングやクラスの意味がわからないと，イメージが伝わらないと思います。これについては稿を改めて述べたいと思いますが，VBAプログラマの底上げが自然に図られるのではないかという主張だけは伝わったのではないでしょうか。
なお，クラスをDLLで提供するためには，C言語ファミリーではC/C++でなくC#で開発しなければなりません。同様に，Visual BasicではVB2002以降のバージョンで開発しなければなりませんが，最近のVB2008であれば十分といえます。

いったんおしまいにします。