R社以外にお仕事のオファーがあったのが、S社。ブログのランキングをご覧になって探し当てて下さったそうです。
ここのお話はかなり興味があり、やれるものならやってみたいものなのですが、それには一つ越えるべき関門があります。そう、S社で企画が採用される必要があるのです。
ひとしきりご担当者様に企画案をお渡ししましたが、もっともっとがんばらないと！とネタ作りに奔走する日々です。
企画が通り、手が少し空いたらまた書こうと思います。
VBAの技術者のニーズってどのくらいあるだろうか？
コンピュータ技術者からすればVBAなんて言語のうちに入らない、という認識があるようだ。大手ベンダーでVBAに特化した連中が居るなんてことも聞いたことがない。
VBAのユーザーは中小ベンダーや個人、もしくは社内のシステム部門やユーザー部門である場合がほとんどである。
ということで、あまり大手からの案件は出てこないのである。
私がExcelと関わったのは、Excelのバージョンが5.0のときである。4.0ではまだワークシート関数であったが、このバージョンからVBAになった。ある金融機関でインターフェースに利用する案件であったが、当時ほとんど資料もない時代であった。
当時はどこに頼んでいいのか分からなかったからなのか、私の勤めていた会社が受注した。
その後、VBAは2000年問題の解析、ステップカウンタなど、色々なツールとして利用していた。
しかし、ExcelのVBA案件のまともな案件は、その案件と、５年前の案件、そしてここ２年くらい携わった案件くらいで、その中でもまともな開発は最後のものだけである。
世のVBAができる、という人はほとんどがこの形態である。だから小規模なツール程度ならこれで十分だろう。というよりも、VBAで多くを望んではいけない、ということなのかもしれない。
しかし、Excelはともかくとして、Accessの案件は結構大規模なものが多い。小規模なものを含めてもニーズとしては意外とあるのだ。市場ニーズを見るために、ときどき案件情報を検索するが、Accessの方が断然規模が大きい。
しかしながら、どの案件も単価が安い。確かに身近なので簡単にできそうな気もするが、AccessやExcelのVBA案件で複数人で開発する、というケースは私自身は経験があるが、あまり聞かない。逆に言えば「ほとんど一人に任されてしまう」のではないだろうか？となると、要件定義や設計、開発も一人でできるのが望ましいことになるが、その単価と技量は釣り合わないのではないか？
実際、当人が自信たっぷりで作成したといわれる、Accessでできたものを見ても「何じゃこりゃ！」ってのは多い。困ったものである。
是正できるような記事を書かないとなぁ、と思いつつ、今日も酒に溺れる。
先日お仕事をご依頼下さった会社のひとつ、仮にＲ社としますが、お話を聞いてきました。創業間もない会社にもかかわらず面白い仕事をたくさんお持ちで、見据えている先、ベクトルは近いところがあるなと感じました。
そのＲ社の案件の一つで「Excel VBA のフレームワークが欲しい」とのことでした。
私がブログ冒頭で「共通関数群の提供と解説」と書いておりますが、それを加速化できる、有り難いお話しです。
実を言うと、フレームワーク自体は概ね作成済みなのです。ただ、実験的に作ったりこともありコードがいい加減に書いてあったりするものがあります。
今回のことを契機に、整備して早めにご提供し、更にＲ社様のご意見を聞いて採り入れられるものは加えていこうと企んでいます。