ドキュメント整形ツール

システムタイトル：
　・銀行向けのパッケージソフト作成業務

業種：
　・金融業

システム概要：
　・日本銀行と金融機関との即時グロス決済（RTGS）を行うための、銀行向けのパッケージソフトを開発した際、ドキュメントフォーマットは決まっていたが、ヘッダ／フッタにプログラム名称を入れる都合上、どうしても変更し忘れてしまう、という状態であった。
　・面倒くさいことが大嫌いな私は、自チーム分に関してはドキュメント確認係を買って出て、自作の簡易ツールで塗り替えるようにしていた。
　・自チームだけヘッダ／フッタが正確だったうえ、速かったので元請け企業に不思議に思われ、種明かしをすると「全体で使いたい」ということで汎用向けにカスタマイズしたものをお渡しした。

システム構成：
　・サーバー　Windows NT 4.0。
　・クライアント　WIndows NT 4.0。
　・言語　Microsft Visual Basic 6.0

　・ドキュメント　Microsoft Word 97。

留意点：
　・ドキュメント一覧をExcelで作成し、ExcelからWordをコントロールするようにした。
　・元請企業の担当者は結構年齢が高かったため、なるだけわかりやすく、文字も大きめにフォームを作成するようにした。
　・併せて、一覧から選択したものは印刷もできるようにした。

その他：
　・途中でExcelのドキュメントも増えたが、拡張子で判断し対応するようにした。
　・わかる人にはわかるだろうが、この程度ならたいして時間はかからずに作成できる。
しかし現場では煩雑な作業から開放されたようで相当喜ばれた。VBAはこういう補助的な仕事には物凄く強いように思う。

クラスモジュールは使い分ける

Visual Basic 6.0　までのVBでは、クラスモジュールは継承ができない、オーバーロードができないなど、オブジェクト指向としては中途半端なものである。VBAのクラスモジュールも同様である。

それを中途半端と切り捨てるのではなく、その特徴に配慮して使い方を考えるとよい。

その結果として、使い方は２通りあると考えている。

ひとつは、通常のクラスモジュールの特性を活かした方法。これはデータベースへの接続をいくつも確保するような処理に有効であり、別のオブジェクト指向言語を操作したことがあれば使い方は概ね分かるだろう。この部分はクラスモジュールの応用編として別途解説する。

もうひとつは、該当ブックを起動中、もしくはExcelを起動中は常駐させる方法。モジュールを整理し可読性を高めるのに有効であり、これはあまり他の言語を経験していても考えない概念だろう。この部分はVBAに慣れた人には逆に敷居が低いだろうと思われるので、基礎編として別途解説する。

今後はこれを明確に分けて解説を行う。

関連ページ　このページより詳細なモジュールの説明あり
ブログトップへ
ブログ内検索キーワード
　クラス　モジュール

就職情報管理代行システム

Windows の 3.1 が出る前の頃だったか。パソコン向けデータベースとして、DBaseがデファクトスタンダードだった頃の話。大型汎用機上のシステムを主に行っていたが、周囲にはUNIXの仕事をしている連中も結構居た。Macやパソコンの仕事は、小さいながらもメンバーは居て、それなりの収益はあったようだ。
まだ大型汎用機とPCとデータを授受するにはデータの転送コマンドを使うしかなかった。

その頃、企業が就職情報として学生にダイレクトメールを送付し、そのレスポンスを管理する、ということを代行する会社の業務システムに携わったことがある。その会社、今となってはある業界の大手に上り詰めているが、創業間もない頃であり、当時は南青山にあった。仮称で Ａ社としておこう。

Ａ社は、各学校の学生リストを入手し、学生向けのＤＭを男女／学校／学部別や、このくらいの偏差値ランクの大学の何系の学生に何万通、というような条件で出力できるシステムを準備していた。
レスポンスはがきもいつ届いて、何回アプローチがあったか、コールセンターも持っており、電話の問い合わせも代行し、やはりそのレスポンスを管理し、企業にいくつかの観点でフィードバックするようにしていた。中には学生のデータをフロッピーに吸い上げ、納品するということもやっていた。

現在、こういうシステムを作成するなら、印刷部分が少々ネックになるかもしれないが、インフラ面にそれほど費用がかかるものでもない。システムを構築するにもさほど難しくない。個人情報保護やらを考えなければ、AccessとExcelの組み合わせでも構築は可能だろう。
しかし、当時は大型汎用機。Ａ社専用にストレージを用意できたわけではなく、学生データはストレージに常駐させておけず、処理前にテープからロードし、処理後にセーブしていた。データベースを用意するだけの容量もない（DBに詳しい人も稀だった、ということもある）ため、SAMやVSAMと言われるファイル形式を使っていた。

いやいや、これが大変であった。汎用機の処理やストレージが比較的空いている時間帯に処理をしていたのだが、朝のデリバリー便までに処理を終わらせ、印刷を終了し、裁断を終えていなければならない。
異常終了（アベンドとかアボートとか言った）などが発生したらオペレータレベルで対応できるモノでもなく、よく夜中に運用チームに呼び出された。場合によっては運用チームと一緒に運用に携わったりもした。また、遅れるとプリンター出力をした後の裁断作業にも人手が足りなくなる。そういう場合は真夜中に出力センターまで自転車を飛ばし、作業を手伝った。
フロッピーへの出力があったときは悲惨であった。汎用機上にできたファイルをフロッピーに入るサイズに分割し、ＰＣへ転送し、フォーマットは他部署で作ってもらったDBaseのツールを使って変更し、フロッピーに落とすのだが、これがすべて手作業であった。枚数が増えれば増えるほど並行して転送するＰＣが増え、転送速度が著しく低下した。作業が終わるのがだいたい朝４時とか５時。下手すると朝７時くらいに出勤してきた人と挨拶をしていた。

いまから考えると、運用側などに要員を増やしてもよさそうな作業量であったろう。しかし、当時勤めていた会社でも費用的には採算ぎりぎりだったようだ。まあ、マネジメントが下手だった、とかそういうことになるのだろう。
開発はともかく、核となるメンバーは課長を入れて３名しかいなかったし。一人は他社兼任だったので、下仕事はすべて私だった。

当時、同期やまだ周りは運用とか、下っ端のプログラマばかりであった。このプロジェクトでは５年以上先輩に指示を出すような立ち位置であり、会社としては、生意気な若造だった私におもしろい仕事を回してくれていたなと思う。
徹夜続きで大変なプロジェクトだったが、プロジェクトでは顧客と直接やりとりすることから、運用デリバリーまで、システム作りの全体を経験することができた。その経験が、システム作りの際にプロセスの全体に視野を広げられるきっかけになったと思う。