EXCEL-VBAオンリーから脱出するための手順

# 内容
仕事でEXCEL＋VBAを使っているが、この先を考えるとやはり知能のブラッシュアップが必要である。いかに学習コストを下げつつ、ITスキルを高めていこうかというのが、本トピックの狙いである。

# 一般的な日本企業における業務アプリの現状

非ＩＴ企業で長年、勤めた経験から言うと、現状は下記の状況である。

・業務におけるITツールの使用目的は、文書作成と、情報収集、情報整理に集約される
・大半の業務がEXCELアプリケーションで実現されている
・EXCELが存在しなければ、大半のビジネスマンは仕事ができないといっても過言ではない
→　メールだけ見ていれば業務完結という、マネジメント層は対象外であるが）

# EXCELアプリケーションの現状
・EXCELは、データ整理、文書作成など何にでも応用できる
→　いわばEXCELは高機能な罫線付きノートといったところ

・一部のマクロ職人が効率化を考えてVBAマクロに取り組んでいる
→　マクロはブラックボックス化され、ソースも属人に埋没してしまう

# マクロ開発の現状
・エクセルの開発環境は手ごろさは認めざる得ない（VBEを開けば、やりたいことをサクッと実現できる）
・シートにデータが書かれているので、さらにはデータベース化なんて一切不要
・配列の宣言も不要、ファイルの入出力も不要となり、セルで見える化できてデバッグ用としても手ごろすぎる

# 脱出したい点
・VBAのごとく、30分程度の納期を与えられて、悩まずすぐにコード化できて動くものを作れること
→仕事に直結しないと、回りからは何の尊敬にも値しないので


# 検討事項
* エディタはVSCODEを使いこなすこと　→　いつの間にやら、これが主流。。。

・まずはVBA→VBに移行して、さくっとマイクロソフト系の開発環境になれてみる

・デスクトップアプリを自作して、次にはWEBアプリ
→　.net をしばらくどっぷりやってみるか


思うに
・やはりマイクロソフトから離れられない気がする
→　ただAI、IOTなんかは、やはりPYTHON？なのか？

・OSS化していく延長上には、GITHUBやdockerhubのようになっていくんだろう
→　LINUXはどっちかというと、ラズパイなどの小型デバイス寄りの技術だろう

・WEBアプリ、スマホアプリも、ZAMARINなどが出てきたので、windowsにも軍配がありそう

・これからの時代は、GITHUBが名刺代わりになると書いてある
→　おれもQiitaなんかで、ブログの延長している場合ではないな。。。
（マークダウンも書けず、すでにアラフィフのおっさん。やることがしょぼい）

# EXCEL-VBAに飽き足らない
会社でもEXCELを使った仕事は今更ながら多すぎる

そこでVBAを覚えて、いろいろプログラミングの模索をしているのであるが・・・

実際のところ、そろそろ限界である。

最近はＵＩＰＡＴＨなどの、ＲＰＡツールがＶＢＡの次に使われるものと
言われているが・・・

## Win32Api
さてＶＢＡを拡張しようと思ったら、まっさきに取り組むのはＤＬＬ開発である。

ＤＬＬというのは、コンパイル済みのＥＸＥファイルで、
そこに関数などを書いておけば、これをＶＢＡから使うことができる。

さて仕事で、使うとなったら、どんな時が考えられるだろう？

* 画像処理
* ＡＩ処理
* ＲＰＡ処理（いわゆるＥＸＣＥＬアプリケーションの外側の開発）

## 勉強法
そんなわけで、いきなりプログラム開発環境が必要になるのであるが、
なにせ最新のVISUAL　STUDIO　2019をインストールしても、
そもそもVBA拡張を素人がやっている時代は、もう10年も前である。

ゆえに、最新のＩＤＥを入れても、そもそもチンプンカンプンなのである。

それに、最近のトレンドは、WINDOWSよりも、ＷＥＢの方にシフトしているので、
そもそも時代錯誤もはなはだしいのである。

## オープンソースの活用
画像処理系で言えば、ＯＰＥＮＣＶを使いこなすことが、一番良い。

しかしながら、ＯＰＥＮＣＶはｃ＋＋、ＰＹＴＨＯＮを正式にカバーしているが、
そうなると、入りやすい順番で言えば、ＰＹＴＨＯＮ一択になってしまう。

この時に困るのが、ＷＩＮＤＯＷＳでＰＹＴＨＯＮを動かす環境を
作る必要がある。

特に、仕事での使用だと、素人が作ったアプリをわざわざＰＹＴＨＯＮを入れて
使ってもらうことは、ハードルが高すぎる。

その選択としては、ＷＥＢアプリにしてしまって、ＰＹＴＨＯＮ処理を
隠蔽してしまうことが手っ取り早い。

なので、それが選択できるような状況であれば、そこそこＰＹＴＨＯＮを使えばいいだろう。

## ＷＥＢアプリ開発
さて、気軽にＯＰＥＮＣＶや、ＡＩ開発と言ったことに取り組むのは楽だ。
しかしながら、いざアプリとしてサービス構築するとなると、
この先には、地獄の覚悟が必要である。

まずＷＥＢを立ち上げるのに、ＰＹＴＨＹＯＮでサーバーを書く必要がある。
そのためには、ＦＬＡＳＫやＤＪＡＮＧＯと言ったフレークワークの勉強が必要である。

その後に、クライアント側を構築するにあたっては、
ＨＴＭＬ，ＣＳＳ，ＪＡＶＡＳＣＲＩＰＴ（Ｊクエリー）などと言う
いまどきの言語を総ざらいする必要がある。
（正直言って、ＶＢＡからスタートした素人では、少なくとも3か月はかかるだろう）

## ｃ＋＋
そこで、いまさらながら舞い戻ってくるのであるが、
デスクトップアプリの方であるが、これがまたまた難解である。

何故かというと、VISUAL　STUDIOというツールを完璧に使いこなす必要がある。

このソフトが一筋縄に行かないのは、マイクロソフトのWINDOWS技術を
完全に理解しないとならない。

それこそｃ＋＋と言えば、ＷＥＢ技術が一般になる前の言語なので、
いわゆるフレームワークが古い。

最近は、．ＮＥＴというフレームワークが一般的であるが、
．ＮＥＴはｃ＃、ＶＢしかサポートしていないからだ・・・

それにＥＸＣＥＬにはバージョンがあって、３２ｂｉｔと６４ｂｉｔで
せっかく作ったライブラリが動かなくなったりして、
いわゆる最新技術のフレームワークで、そもそもコンセプトの古い
ＥＸＣＥＬ，ＶＢＡをマッチさせるのは、至難の業になってくる。

# 取り組むべきもの
さて、こういう風につらつら、書いてきたが、
ＶＢＡの次に取り組むものとしては、やはり現時点では、
ＯＰＥＮＣＶをｃ＋＋で使いこなすのが、
最優先になってくる。

# C#というもの
さて、ｃ＋＋の前に、C#は一体なんぞや？
という疑問が出てくる。

そもそも、ＶＢＡを知っている人間からすれば、実はＣ＃ではなく
ＶＢの方が、入りやすいのではないかと思ってしまう。

しかしながら、世の中の流れなのか、はっきり言って、ＶＢ．ＮＥＴでの
入門は、すごく危険である。

とにかく実行速度が、遅くなるらしくて、．ＮＥＴの技術を
使いこなすのであれば、その経過でＶＢを触るのもありである。

しかしながら、最終的にはＣ＃を触ることが、一つの選択にはなってくる。

## OPENCVSHARP
一応C++の関数を、C#でも使えるようにする、ライブラリが世の中には存在する。

しかしながら、そもそもｃ＋＋でのコンパイラも使いこなせないものが
C#に飛びつくのは、かなり危険である。

C#というのは、そもそもＪＡＶＡとよく似た文法であって、
そこの世の中の流れを、マイクロソフトが対抗したものだ。

なので、C#が完全に使えるようになってくると、やっとエンジニアとしては
飯が食える状態になったと言えるのではないか。

（しかしながら、世の中と３０年以上のギャップを埋めるには、
相当の代償を払わないと、いまの現役エンジニアにはかなわないだろう）

# 総まとめ
アラフィフのオッサンエンジニアが、いまから頑張ってできることは
この長い時代の技術の進化を、頑張れば数年でワープできることだ。

だから、昔の書物を入手して、最新の技術から俯瞰して、
その技術を学びなおすことが良いと思う。

これはスマホ一色の現代人が、そもそもスマホが出てくる前の
時代をタイムマシンに乗ってさかのぼっていくようなものだ。

## 先人の知恵を借りるという事
いつの時代にも、学ぶべきものはある。

先人の知恵と言うものは、つねに馬鹿にはならないし、
現代人だからと言って、先人が歩いた道を知らずに、
どうやって道を切り開いてきたかの、そのエッセンスを知らずには、
この先の道を進むことはできないである。

## 吉村昭の小説「漂流」
私の大好きな小説に、吉村昭の「漂流」と言うのがある。

この中で出てくる主人公は、江戸時代の船乗りで、
無人島に流れ着き、たった一人で、その困難を乗り越えて、
最終的には何十年もかけて、日本に帰ってくるという偉業を無しとげている。

もしも、仮に今の自分が、その難破船に乗った一員だったとして、
ケータイ電話も、食料も何にも持たずに乗船していたら、
いくら現代に生きて、いろんな知識を持っていたとして、
この状況で、生き抜く知恵を出すことはできない。

要するに現代人は、現代だから存在できるのであって、
江戸時代に行ってしまえば、おそらく当時の人よりは
劣っていて、時代の差と言うものは、何の優位性もないという事である。

昔の人の知恵を馬鹿にすることはできない。
つまり、今を学ぶということは、つまりそれは過去を知ることである。

# 最近の振りかえり
ある程度、独学だけで勉強を勧めつつ、
決して社内でITエンジニアとして仕事ができる環境がない前提において、
どうやって、自分の職場の環境を変えていくのか？
そこがテーマである。

自分がITエンジニアと大きく環境が異なると思っているのは、
普段の業務が日本語でのかな入力（たまに中国語入力も含める）
などとやっていると、まずキーボード入力とかパソコンに向かい合う意味付けと言うものが
いわゆるIT企業人と比べて全く異なっている。

おそらくIT企業においては、コードを書くことがコミュニケーションの大半になってくるのだろうが、
まず日本語の、「かな入力」しか体に馴染んでいないことが、
大問題である。

最近、PYTHON関係の動画をよく見るのであるが、
だいたい海外のITプログラマは、英語を主体とした言語環境にあって、
まずプログラム言語＝英語がベースになってくる。

そこで重要なのが、英語を話せるような感覚で、
キーボードをポチポチできているのか？

そのことが、今後のプログラマ人生において重要な位置づけであること痛感する。
（それこそ、最近は日本語の文章やメールでさえも、音声チャットなどで
入力することが、合理的な場合もあるが、同じように
プログラムを音声入力で出来る時代になった場合に、
まず日本人は、英語を話せないという壁で躓いてしまうのではないかと思う）

# 目指す方向
まず英語を勉強して、英語の文章を目にするようにする。
プログラム言語の解読において、なるべく英語のドキュメントを参照にする。
キーボードの入力に際しても、ブラインドタッチをする際に、
これまでは「日本語かな入力」を多用しているが、
これからは、ブラインドタッチの英語入力に力を入れる。
（タイピングするという行為は、言語の学習において、正確性という意味で、
非常に練習になると考えられる。）

## キーボード練習
いろいろソフトがあるが、まずワープロ等の文書作成の業界人ではない限り
プログラマは、プログラマに特化した、VISUALSTUDIOなどの
ＩＤＥツールを多用して、これらの支援を得るべきである。

しかしながら、ＧＵＩ環境が適しているのかと言えば、
やはりテキストーベースでSHELLを触れる方が、
いいに決まっているだろう。

## 言語
さてプログラム言語であるが、現在のところ大きく大別すると、
デスクトップアプリにするのか？
ＷＥＢアプリにするのか？

ここが大きく帰路に立つ部分である。

業務で使うアプリなんていうのは、インストールでカチッとしたものを
配布するのがいいのか？　
それともブラウザ上に、あたかもサービスを受ける人が居るように
依頼業務にしてしまうのか？
ここが悩みどころであるが。

しかしながら、最近得られた一つの結論としては、
デスクトップアプリの開発は、かなりハードルが高くて、
これからのＩＴエンジニアは、やはりWEBベースの仕事が大半になってくるのではないかと
思っている。

まず、デスクトップエンジニアになろうとするのであれば、
特定の機種（windows，LINUX、MAC）などの
ハードウェアの知識が必要になってくる。

ここでのネックは、マイクロソフト、ＡＰＰＬＥなどの
メーカーと密接な関係にあるということである。

例えば、いま大半のサラリーマンが、仕事をしている環境と言うのは
マイクロソフト（ＷＩＮＤＯＷＳ）の一択であって、
大半がOFFICE製品と、それに親和性のあるVBA一択と言うのが
現状であるから・・・

これがいつの時代に、OFFICE製品から脱却するのか？
それはおそらく、マイクロソフトとともに人生を歩むのみで、
いつになったら、VBAはこの世の中から無くなるのか？
（そういう先の読めない世界になってくる）

## 目的を明確化する
最近、PYTHONを使ったWEBアプリ開発をかなりやっているが、
PYTHONが優れていると思う理由は、（他の言語も同じかもしれないが)
ソースが無料で簡単に入手できる。

これに尽きるのではないかと思っている。

もちろん、フロントエンドなどの開発でも、
JSのライブラリなど、世の中には優れたものが
ゴロゴロと転がっている。

しかしながら、これらのフレームワークは、それこそ山ほどあり、
一つ一つを極めていくには、いったい何時になったら
すべてをクリアできるのかは、まったく見えてこない。

## 所詮はフォルダとソースの組み合わせ
VBAリーマンの大半は、構造化プログラマと言っても過言ではない。
しかしながら、世の中のプログラム言語と言うのは、
だいたいにおいて、フォルダとその組み合わせで成り立っており、
それこそ、モジュールやクラス単位で、開発が進められている。

それぞれのモジュールをテストして、部品の一つ一つを完成させ
それを組み立てていくことで、最終的な巨大なアプリケーションは完成している。

ＷＥＢのページもしかり、デスクトップアプリもしかりである。

さて、我々ＶＢＡリーマンが、そこまでのことを望まれているかと言えば、
実はそんなことはなくて、マクロで合理化できるというのは
あくまで手でポチポチしている作業を、自動でさくっとというのが
望まれる範囲である。

なので、そういう業務を仕事で展開しようとすると、
へたにデスクトップアプリなどを作成しようとはせず、
フロントエンドで、仕事の依頼者側の中身を示し、
あとはバックエンドで、受付してサーバー内部で
こちょこちょして、返信するという行為につきるのである。

## ＶＢＡへの組み込み
ＶＢＡのベースとなるには、EXCELといったアプリケーションがベースになってくる。
しかしながら、ブラウザを中心とする業務委託をベースにすれば、
ブラウザ上に、所望のEXCELファイルを並べておいて、もしくはダウンロードできる状態にしておいて、
それを使う側が、適当に処理を委託して、帰ってきたものを受け取るというのが
比較的、ＥＸＣＥＬ業務との親和性があってよいと考える。

下手にＶＢＡをこねて、ＥＸＣＥＬ内部に埋め込んだとしても、
極めて保守性が低下してしまうだけであるので

## バックエンドの構築
さてサーバー側での処理をさせるとなると、当然のことながら課題になってくるのは
どこにサーバーを置いたらいいのか？
ということであるが、これは適当にＬＡＮ上にＰＣ１台を置いて
そいつのＩＰアドレス＋ポートを解放してやれば済むだけである。

公開範囲を広げてあげたいのであれば、社内セキュリティのある
ＡＷＳクラウド等を借りるということになる。

最近はＷＩＮＤＯＷＳやＬＩＮＵＸのＯＳが乗った、
ＮＡＳなどというのも存在するので、それをサーバー代わりに使うのもアリだ。

しかしながら、最近はＡＷＳレンタルを社内ＩＴ部門に相談するのが
ベストという結論になった。

このときＡＷＳはWINDOWSにするのか？　LINUXにするのか？
という選択は悩むが、おそらくローカルPCで開発するのであれば
WINDOWSにならざる得ない・・・

## 言語について
再度、バックエンド側の言語について、話を戻すが、
ファイル等の処理の基準が、あくまで、PDFや、OFFICE製品ということであれば、
ライブラリが豊富な言語に一択される。

以降が自分の最終的な選択であるが、

* PYTHON

* C#（ASP.NET）

上記の２択がVBAを卒業して、次のステップとして最有力と考える。

これに付随する、JavaScript,HTML,CSSなどは、
もちろん、ある程度の痛みを覚悟して、
経験を積む必要があるが・・・

さて、ASP.NETを選択した時点で、かなりややこしい
マイクロソフトとの付き合いが始まるのは
覚悟せざる得ない・・・

XAMLなどの、余計な知識が、HTML以外に必要になるのは
本当に避けたいところであるが・・・

自分がマイクロソフトを押すのは、
やはりWINDOWSを知るというのが前提にあるので、
LINUX,MACしかやらない人間であれば、
それは全く必要がない
（しかしながら、世の中のＰＣがWINDOWSが流通している限り
これに向かわないことは出来ない訳で・・・
はやくOFFICE製品が、CHOROME-PCに置き換わる時代になってもらいたい
ところであるが。。。）

## 当面の目標
かなり個人的な話になってくるが、以下を今後の取り組みとする。

１）DJANGOフレームワークで、WEBサービスを構築する
　DJANGOを使うことで、MODEL,VIEWといった概念と、フォルダの構成などの知識を得る。
　またPYTHONを使うことで、テストやドキュメントの作成など、
　おおよそのITエンジニアとして得るべき知識を得ることができる。

２）C#(ASP.NET.CORE)の学習
　c#という言語は、ほんとうに良く出来ている言語だと思う。
　しかしながら、マイクロソフトのVISUALSTUDIOというIDEは本当に癖のあるアプリだ。
　とくにデスクトップアプリのフレームワークが、WINDOWSFORM、WPFなど、
　いろいろ賛否両論のあるものを習得せねばならない。

　ASP.NETでさえ、ASP.NET.COREなどもあったりして、
　マイクロソフトとともに、オープンソースに向き合うトレンドに
　付き合っていかねばならない。

３）当面は以下は手を出さない

* NODE.JS　多くのライブラリや、リポジトリなど、たくさん出回っている。
　もちろんフロント、バックの言語が共通化するなどで、これからの時代にマッチしているのかもしれない
　
* RUBY,PHP　これも時代に逆行するので、いまは時間がもったいないので着手しない

* c,c++　これはWIN32APIとの接続性は良い。ただしDLL開発などにハマると
　どんどんマニアックな方向性になってしまう。

# 最後に　
　どうしてもVBAでやりたくなったら、それこそ.NETフレームワークに置き換えた
デスクトップアプリ化になるが、そのときはC#もしくはVBをガッツリやらなければならない。
（しかしながら、こういう業務は、後になってもメンテナンスができないなど課題が残るので、
なるべくは、サービス自体をＷＥＢアプリ化できる範囲にとどめた方が無難と考える）

# ６年後の結論

1. キャリアの転換：エンジニアとしての経験を積んだ後、別のキャリアに移行を検討
　エンジニアリングに関連する職種としては、プロジェクトマネージャー、テクニカルライター、コンサルタントなど

2. 仕事に対するモチベーションの低下：エンジニアリングの仕事に対する情熱、興味の欠落
　新しい技術やプロジェクトへの関与の欠如、モノトーンなタスク、あるいは組織や環境の問題など

3. 就業環境の変化：職場の人間関係、組織の方針、労働条件などが不満足な方向に変化
　エンジニアリングの仕事自体に対する意欲が低下し、転職を検討するようになった