VBAはなぜ負債化するのか

結論

　VBAからVBAの仕様書を作成するVBAを書きました。（Document of VBA, for VBA, by VBA）（完成品はこちら）

はじめに

　VBA（Visual Basic for Application）が世に登場して四半世紀。解説本や解説サイトも多数存在し、趣味グラマーがITリテラシの低い職場で無双するためのツールとなりました。それは文系が跋扈する行政事務職の中でも例外ではなく、そうしたいわば「ハイパー事務屋」が日々の業務を支えているのが現状です。
　確かにVBAは非常に便利なツールですが、一方で問題点も多数指摘されています。特に問題となっているのが「後継者いない問題」ではないでしょうか。
　趣味グラマーがVBAでプログラムを作成し、職場ではローコストかつ効率的に業務が遂行できるようになった反面、開発者の異動や退職で管理が行き届かずいわば「魔法の箱」と化してしまったプログラムを多数見てきました（過去の私も恥ずかしながらそうした負債を残してしまいました……）。

なぜVBAは負債化するか

　VBAが負債と化す理由は概ね次の点ではないかと考えます。

マニュアル（仕様書）を作らない

　システムの発注に関しては仕様書を、そして発注時には操作マニュアルや仕様書等の資料を納品させることは必須事項です。システムに明るくない所管課であってもこれらのことは守れるようになってきています。しかしながらこれが自分のことになると途端に実行されません。
　自分の胸に手を当てて考えると次のことが原因なのではないかと思います。

• 作っているときは神になった気持ちなので、そんなの残さなくても大丈夫に思える
• 仕様書の作成は突き詰めると、コーディングした内容をもう一度文書化することなので、二度手間に思う
• チームではなく、個人で作成することがほぼ100％

　作っているときはすごく複雑なアルゴリズムも大体わかった気になっています。後から見直してみて「なんて天才的なアルゴリズムだ……このVBAを書いた人は神かな？　あっ私だ」みたいなことがよくあります（ありますよね？）。
　またVBAは共同編集に弱いので、大体個人で開発しています。誰とも進捗を共有しない開発作業において共有するための文書が作成されないのは当然のような気がします。

VBA作成は業務ではない

　私を含めた行政事務屋に求められているのは「業務の遂行」であって「VBAの作成」ではありません。大量に素早く正確といった、効率よい業務処理は求められますが、手段は不問です。
　一方仕様書の作成を始めとしたベンダに要求するような納品物の作成は当然ベンダにおいては業務として行うため、そこに対価が発生します。
　某ラーメン漫画でハゲのメガネの方がおっしゃってますが「金銭のやり取りは責任の重さ」であります。
　つまりVBAで仕事をする際の責任の差が仕様書作成から足を遠ざけさせる原因です。

組織の中での温度差

　誰でも書けるようになってきたと豪語したVBAですが、とはいえ地方公務員業界においてはそこまで人材に溢れているわけではありません。向き不向きもありますし、開発者が在籍中にその知識や技術を習得しようとしてくれる存在が稀有なため、仕様書を作っても読まない・読めない・読めるレベルのものができないという問題があるのではないかと思います。

ではどうするか（アルゴリズム）

　アプローチとしては大きく2つあって、一つは組織としてVBAの開発を業務としてしまうことです。きちんと業務化することにより、職責が生まれ、また組織としても対価を払う以上監督責任や、職員の育成の体制を作る必要があります。
　外注するばかりでは費用も肥大化するばかりですし、外部に対して発注した内容を精査できる人間を育成しないことにはベンダに足元も見られることになります。行政だから文系だからと尻込みせずこれからはそう言った人材を育成していくことが大事ではないかと考えます。
　しかしながら組織として職務として組み込むとしても、組織内でその評価をできる人間がいないことも事実。人材育成できる人材を育成するレベルなのが現状ですし、ローコードやノーコードのツールが生まれている現状VBAの未来はないかもしれません。そのため一旦これは脇に置いておきます。
　もう一つ有効と思われるのが今回の本題で、要するにVBAのコーディングをした時点でVBAのドキュメントが完成すればよいのです。

VBA仕様書の作成

コーディングガイドラインの作成

　要するに仕様書とはコードがどんな挙動をするのかということ。です。
　そこで「VBA　コーディングガイドライン」でググると、こことかこことかをとかいろいろなサイトのものがヒットしますが、些末な部分は好みとして、エッセンスは「わかりやすい名前を付ける」「コメントは書かない」ということではないでしょうか。
　変数や関数に明瞭な名前がついていればコメントによる説明は不要ですし、コード変更に伴うコメントの管理も必要ありません。これはいい。

問題点

　とはいえ、コーディングガイドラインがあるからと言ってそれが守られるわけではありません。また、コードそのものを読まなくてはいけないので、結構労力がかかります。
　プログラミングをしていて思う「三大やりたくないこと（俺調べ）」は

• 帳票やインターフェースの作成
• テスト
• 他人のコードを読む

　です。リーダブルなコードを書いたからといてそれを仕様「書」として投げられるとうんざりします。

仕様書雛型

　コーディングガイドラインに沿ってコーディングしたときの記載すべき要点を雛型として作成し、コーディングした内容を転記すればある程度内容がまとまりつつ、そこまで作成に労力は必要ないのでは？
　JavaDocをはじめとしたAPI仕様書を参考に最低限の項目を列挙すると、以下のような項目があればよいのではないでしょうか。

• コンポーネント
• プロシージャ
• プロシージャの概要
• 引数
• 返り値の型
• 呼び出すプロシージャ・クラス・フォーム

　コンポーネントととはコードが書かれる部分のことです。Excelならば、シートモジュール、ThisWorkbook、標準モジュール、クラスモジュール、フォームの4（5）種類
　プロシージャにはSub、Function、3種類のPropertyの5種類があります。
　引数や返り値の型は宣言部分を見れば自明ですが、頭出ししておきます。

問題点

　これでなんとなくVBAを引き継げるものが作れそうな気がしました。
　しかしながらやはり2度手間になるのは避けられません。特に呼び出すプロシージャ等は列挙するのがとてもめんどくさい。
　なんとか自動化したい！

VBADocの作成

　JavaにはJavaDocという仕組みがあります。これは指定のフォーマットでコメントを書くことでそこからドキュメントを生成するという仕組み。何とかVBAにも輸入できないかと考えてみました。
　この疑問に行き当たるまで知りませんでしたが、VBAでは実はVBEを操作することが可能なようです。（参考サイト）
　これはすごい。これを利用してVBADoc作ってみました。（次回へ続く）