VBAその1 Windows OSがある限りVBAがある

K北さんへ
※この文章はちょっと蛇足が多い。
蛇足が必要ないときは次の記事へ飛んでほしい。

VBAをやるなんてくそだな~。
Railsやって、日本のスタートアップで重宝されたいな。
どーせならCCNAからDockerもやってScala学んでガチのFull Stackになりたいな。
PythonとかJuilaやってTensorflow、MXNet、Keras使い倒してAIエンジニアぶりたいな。
Matlabやって良いとこ出を醸し出したいな。
などなど、きっとVBAと聞いた途端に拒否反応が出て隣の芝が青く見えたかもしれませんが、僕らのようなレガシーな職場(SES業界では現場と呼ぶが)で、スタバで見かけるMacとは無塩バターのように無縁の、低スペックのWindows PCが闊歩し、新しいツールが全く導入されない、上司がそもそもSlackすら使ったことないようなIT企業のわりに間接業務の嵐の職場で働いている私たちに、唯一無駄な作業から身を守り、本当に価値のある仕事に割くための時間を与えてくれる神様のような存在は、フロントエンド言語でも、Railsのようなスーパーフレームワークでも、ましてはAI搭載したRPAでもなく、VBAだと思っています。(ごめん、RPAは期待できるけど)
そもそもWindows OS上で実行されるものは、ほぼすべてVBと名の付くもので自動化できます。
(VBAやVBscriptなど)
だからさ、諦めずにちょっとの期間だけお付き合いください。

まずやること
VBAで業務を自動化しよう。
しかし、自動化しようにも手順書や業務フローがない業務も沢山あるよね。
なので、アプローチの方法はこうです。
①フロー化
②文書化
③自動化

①フロー化について
これはPMを巻き込んでやろう。(Project Managerの事で、AMからPMまで死ぬまで働く。の略語ではないよ。)
絶対に巻き来ないとイケナイ。なぜならここでやりたい事はフローを書く事による「見える化」だけでなく、「要らない作業を減らす」事なんだ。
自動化する時に重要な事は、今やっている作業を全てプログラミング化することじゃなく、まずは、「してもしなくても良い作業を見つけ出し、金輪際それはしないと決定する」こと。
そして必要な作業だけを「業務フロー」として書き起こし、お客さんとも合意すること。(これは運用チーム独特かもね)
合意を取るときに(所謂、お客さんと握る。決してへんなものを握り合うわけじゃない)、身内の1番偉い人とお客様側の担当者に話を通さないといけないから、まず前者であろうPMを巻き込むんだ。
(今の現場ではPMじゃなくて小職で結構)

K北さんがこの“現場”に来た時、「さぁここに座ってこれをやってくれ」と言われた業務の束の中には、「何のためにやっているのか」僕らもお客さんも分からないものが実は結構あったりする。
要は「必要だと思い込んでやってるもの」だ。
それを愚直に文句を言わず行うのは作業者として美学を感じずには居られないが、上に物申すのが現代の正しい働き方だと思う。
煙草を咥えながら「あ?これやらないといけないんですか?まじだるいんですけど」と。
上の人がその要望に対して用件を聞き、素直に対応してくれないなら、そんな職場すぐ辞めても良いくらい。
なぜなら、こんだけ新しい技術がどんどん出てくる世の中で、意味のない仕事を社員にさせ続けるような企業は、大かれ早かれ淘汰されるから。
自分の将来にとってもよくないので、そうしよう。
ごめん煙草は冗談でした。
ジョイントを巻いて。が、正しいかな。

因みにここでのフロー化は「SES業界の運用チームが作る”業務フロー“」の事で、フローチャートの事ではないのでメカドック。
フローチャート化は②に含まれます。

②文書化
文書化は以下2つから成り立つ。
1 フローチャート化
2 各作業を言葉にする

1はVBAのコードをモジュール化する時に役立つ
2はVBAのコード内のコメントにそのまま対応するイメージ
これはこの前口頭で伝えた通りなんだけど、ちょっと文章にすると伝わりにくくてごめんなさい。

③自動化
自動化はあくまでも手段である。
ゴールは目標達成である。
その目標が例えば、「パワーポイント資料を10枚印刷すること」と定義づけられているのであれば、ちょっと間違っている。
SES系の運用業務の目標は、基本的にはお金をもらうことである。
お金をもらうということは契約によって定義されているはずなので、後は成果物を提供することである。
成果物はサービス提供範囲や条件で細かく定義されていることが多いが、結局は「お客さんを満足させる」ことである。
それ以上でもそれ以下でもないと思う。
これはかなり消極的な目標設定であるが、運用業務の中ではひとつの真実だと思う。

めちゃくちゃ極端な例だけれど、プロジェクトメンバーの全員がサボって何の価値も提供しない状態であるが、めちゃくちゃ可愛い女の子がお客さん側の責任者のご機嫌を取り、お客さんがそれに満足しお金を払ってくれて契約も更新してくれれば、それでいいのである。
例えはよくないけれど、伝えたいことは、「自動化は手段であって目的にはならない」ということである。
目的はあくまで顧客満足である。
とりあえず今はそういうことにしておく。

では自動化はなぜ存在するかと言うと、顧客満足度を上げることに他ならない。
自分たちの業務を楽にするという側面はもちろんあるけれど、それが目的にはならない。
目標を「自分の業務時間を圧縮し自由な時間を確保し新しい知識を身につけ転職もしくは副業するための時間を捻出する」と定義した場合は、自動化は自分のためのものになるが、「顧客満足度を上げる」と定義した場合は、自動化はみんなのためのものになる。

なぜ先にこんなことを話してるかと言うと、「導入のジレンマ」にハマらないようにするためである。

ちなみに導入のジレンマという言葉は今思いついた造語である。

導入のジレンマというのは、自分一人で作ったツールをチームや第三者に提供した時に起こる問題点のことである。

問題点とは使ってもらえないことである。

使ってもらえないという状態は、以下三つに大別できる。

1 使い物にならない

2 利用者が使いたくない

3 管理者側が使いたくない

こういった状態に陥ってしまう理由は「開発者側が自分以外の視点を十分に持っていないこと」。に帰結する。

要はマスターベーションである。

マスターベーションで作ったツールは誰も使いたくない。自分だけが良いというさもしい精神で作られたものは、ゴメンなのだ。

導入のジレンマにハマらないようにするためには、「そもそもこれは顧客満足度を上げるために作っている」という視点を忘れないようにすることだと思う。

とはいえ、いきなりたくさんの人の利用を想定し全ての人が満足するツールを作ることは大変難しい。

自分なりのアドバイスは、「隣の人が喜ぶものを作る」である。

少なくとも今一緒に働いている隣の人がこれを使ったら喜んでくれる。そんなものを想像して作ると、導入のジレンマを回避できるし、発生したとしても乗り越えることができる。

抽象的な話はここまでにしておいて具体的な話をすると、②の2で文章化した業務をカテゴリーで分けるのが第一ステップ。

そのカテゴリーとは「自動化のしやすさ」と「自動化された時のインパクト」である。

「自動化のしやすさ」とは「開発工数」と言い換えることができる。「自動化された時のインパクト」とは「自動化によりなくなる工数」である。

カテゴライズが終わったら、開発工数が最も低い項目の中で「なくなる工数」が大きい順に実際の開発作業を始める。

自動化された時のインパクトが大きい順に開発作業を始めてはいけない。

理由はそもそも開発工数を捻出しないといけないからである。私たちは自動化ツールを作るためにここで働いているのではなく、定常業務をこなすためにここで働いている。なのでまとまった開発の時間を確保するのがとても難しい。(めちゃくちゃ暇な現場だったら別に考えなくても良いんだけど)

まずとっつきやすいものから開発し始める。というアプローチがこういう現場では正解である。と自分の今までの経験から切実に思います。