みなさん、こんにちは！
タカハシ(@ntakahashi0505)です。
来る2023/07/20に、拙著「デジタルリスキリング入門 ――時代を超えて学び続けるための戦略と実践」（通称「#デジタルリスキリング入門」）が発売となります。
今回、出版をお願いしております技術評論社さまのご厚意により、当ブログに「本書の第0章を全文掲載しても良い」と許諾をいただきました。
ということで、本シリーズでデジタルリスキリング入門の第0章「リスキリングの先にあるものとは」をお送りしております。
前回はこちらの記事でした。
今回はその続き「プログラミングとの出会いから独立編」をお送りします。
では、行ってみましょう！
プログラミングとの出会いが人生を変えた
そんな中、あることが、ふと頭をよぎりました。あの連敗続きの転職活動で何度も何度も尋ねられた質問があったのを思い出したのです。
「プログラミングのスキルはありますか？」
そういえば、毎日遅くまで残業していた同僚は、いつもExcel作業に苦心しているように見えました。小さなノートPCの画面に、たくさんのExcelシートが重なり合うように開いて、締め切りに追われて泣きそうになりながら、マウスを操作していました。いや、Excelであれば、プログラミング言語VBAを使うことで、作業の自動化ができるかも知れない。そうすれば、毎日そこまで残業する必要はなくなるかも知れない。
そこで僕は独学でVBAのスキルを身につけるべく学習を開始しました。周りにはVBAを知っている人はいない、Webにはたくさんの情報がありましたが、コピペしてきても正しく動かないし、かといって一行一行のコードの意味はさっぱりわかりません。とくに悩まされたのが、いちいち発生するエラーとそのメッセージ、ダメなのはわかるけれども、どう解決したらよいか途方に暮れてしまいます。
このようにたいへん苦労しましたが、プログラミングの効果は抜群でした。残業しながらまるまる1週間かけてようやくこなしていた業務が、たった2日で完了できるようになりました。その他の業務も可能なものはすべて自動化、効率化をしていきました。これまで残業なしではこなせなかったチームの業務がすべて、すっぽり業務時間内に収まるようになりました。むしろ「お釣り」が返ってくるくらいでした。
僕は「これだ！」と思い立ち、2015年に独立を決意します。プログラミングをはじめとするテクノロジーの力を借りて、ルーチン作業をコンピューターにまかせることで、固定的な人件費が浮くことになります。浮いた人的リソースは、より人間がすべき創造性のある仕事に割り振ることができます。そのために、開発や人材育成にお金をかけるのは、理にかなっている投資です。
同業他社でも同じような業務を行っているのは知っていたので、その業務効率化を支援することで、当面のビジネスとして成立するのではないかと考えたのです。
書くことが首の皮一枚をつないだ
独立をする前に、同業の知り合いのつながりで3社ほど受注をしていたのですが、不運なことに、うち1社は契約を反故にされ、うち1社は踏み倒しにあってしまいました。
新たな営業活動も苦戦を強いられました。人件費と開発費または研修教育費を天秤にかけて、費用対効果でいえばメリットがあることは明らかだったとしても、多くの組織ではデジタル化、業務プロセスの変更を伴う提案に良い反応を示しませんでした。これは、DXがなかなか進まないのと同様の理由です。変化を嫌う、現状維持バイアスが強く作用していて、現状を変えることは相当に難しいということを知りました。準備金として用意していたキャッシュが底をつくかどうかの綱渡り、辛抱の時期が続きました。
独立から2年が経とうとするころ、根気よく続けていたブログが徐々に花開き、デビュー作「Excel VBAを実務で使い倒す技術」の出版につながりました。同時に、開発や研修の案件の問い合わせも少しずつ増えてきます。コツコツ更新してきた僕のブログ「いつも隣にITのお仕事」は、最大で月間130万PVを誇るサイトに成長したのです。なぜ、ここまでブログがヒットしたのかというと、僕自身が味わった課題を解決するための、とある仕掛けがうまくいったからです。
僕がVBAを学んでいたころから、Web上に関連記事はたくさんありました。それらは、主に2つに分類できました。あるやりたい業務に関してそのコードを全て掲載する記事と、VBAの構文に対してその書き方や意味を解説する辞書的な記事です。
「やりたい業務 VBA」で検索すると前者の記事が大量に出てきますが、そのコードをコピペすることはできても、コードが貼ってあるだけなので意味がわかりません。何か、自分の業務に合わせてカスタマイズをする必要があるなら、コードの意味を知る必要があります。そこで、コードに含まれるわからないワードについて検索すると、構文を解説する記事にたどり着きますが、すべてのワードについて検索するのには膨大な時間がかかります。さらに、そもそも自分ではじめから何かを組みたいときに、どういう手順でやればいいのか、それを学ぶ機会はどこにもありませんでした。
そこで、「いつも隣にITのお仕事」では、「やりたい業務 VBA」を組み始めてから完成するまで、手順を追って解説するシリーズ連載をするようにしました。たとえば、「請求書を自動でつくるVBA」であれば、これまでは1記事でそのコード全体を掲載するものしかありませんでした。そこで、それを完成させるまでの手順を細かく記事化して、20記事ほどで完成させるようなシリーズにしました。各記事で、新しく登場する構文は1つか2つに限定し、コードは数行ずつ追加されます。連載に合わせて、読者も自らの環境で実際に動作をさせながら読めるように工夫をしました。連載を読み終わって、完成する頃には、そのコードの全ての意味を理解できます。
もともと、1ツール1記事だったものが、20記事になっているわけなので、PV数もそれだけ稼いでくれるという仕組みです。
ノンプログラマーの世界にも良質な文化を
あるとき、ITエンジニアが集まる交流イベントに参加しました。自己紹介タイムで「どんな言語をやっているんですか」という話になったときに「VBAやっているんです」と挨拶すると、「ああ、VBAですか…」と、なんだか僕を可哀想な目で見るような微妙な反応をされたのを覚えています。
さらに、TwitterでVBAに関する情報を眺めていると、VBAを良く思っていなかったり、蔑んだり、場合によっては「VBAはプログラミング言語として認めない」というような言説も見受けられました。
どうやら、本職のプログラマーが使用する他のプログラミング言語と、ノンプログラマーも多く使用しているVBAとの間に大きな溝があるように感じました。そしてその理由は、普及してきた歴史の違いにあるのではないかと考えました。
VBAという言語は、ノンプログラマーにも使える言語として普及してきた背景があります。ノンプログラマー向けだからということで、とにかく動けばいいというニーズがどうしても前面に出てしまう傾向にあります。プログラマー向けの他の言語の入門書は、変数やデータ型、制御構文、関数などの基礎からしっかり積み上げるタイプのものが多いのに対して、VBAの入門書は、まずは動かすことを優先して、基礎の積み上げは二の次にされていることが多いように見えました。
かつ、ノンプログラマーの多くは非IT部門に在籍していることから、作成したプログラムは組織で管理されずに、属人的に作成され、管理されることになります。ひとまず動けばいい、他人に見られることはない、そのようなスタンスになりがちです。結果的に、読みづらく、変更や修正がしづらいコードによる、困りもののプログラムが量産されやすい、そんな歴史があったのではないかと思います。そして、本職のプログラマーが、そのようなプログラムや開発の様子を見る機会があったとするなら、あまり触れたくないものだと、拒否反応を示すというのはあり得る話です。
しかし、この点については、VBAという言語が悪いという話ではなくて、本職のプログラマーのみなさんが蓄積してきたような、プログラムは読みやすくて、変更しやすいコードで書こう、チームで管理しようという文化を育てられてこなかったのが問題なわけです。
その良質なノウハウの蓄積をノンプログラマーの世界にきちんと輸入して、文化として定着させるのが必要と考えて世に出したのが、2017年4月に出版した僕のデビュー作「Excel VBAを実務で使い倒す技術」という書籍になります。この書籍は、たくさんのご支持をいただきまして、5年以上経った今でも書店やネットで順調にお手にとっていただいています。
（つづく）
