連載：Excel VBAを「設計」してみよう #01
はじめに
生成AIに「こんなExcelマクロを作って」と頼むと、VBAのコードをかなり簡単に作ってもらえるようになりました。
分からないコードがあれば説明してもらえます。エラーが起きれば原因を調べてもらえますし、修正案も提示してくれます。
さらに、
「この受注管理システムをオブジェクト指向で設計してください」
と頼めば、クラスの候補や、それぞれの役割まで提案してくれます。
ここまでAIがやってくれるのであれば、こんな疑問も出てきます。
これからも、プログラミングや設計を勉強する必要があるのでしょうか？
私はむしろ、AIを使うようになってから、基礎となる知識を理解していることが、以前とは違った意味で重要になったと感じています。
その理由を考えるところから、このシリーズを始めたいと思います。
想定読者
人事、経理、総務、営業など、ITを専門としていなくても、業務改善のためにExcel VBAを使っている方を主な読者として想定しています。
VBAの書き方だけでなく、AIが生成したコードや設計を自分で評価するための考え方を一緒に学んでいきます。
AIは「答え」を出してくれる
例えば、AIにこんな依頼をしたとします。
Excel VBAで受注管理システムを作りたい。
顧客、商品、注文、注文明細を扱えるように、オブジェクト指向で設計してください。
すると、例えば次のような設計案が返ってくるかもしれません。
Customer
顧客を管理する
Product
商品を管理する
Order
注文を管理する
OrderItem
注文明細を管理する
OrderService
注文に関する処理を行う
OrderRepository
注文データの保存を担当する
さらに、
Dim order As Order
Set order = New Order
といったコードまで生成してくれるでしょう。
一見すると、よく整理された設計に見えます。
では、この設計をそのまま採用してよいのでしょうか。
「AIがそう言っているから」でよいのか？
先ほどの設計について、少し考えてみます。
なぜ
OrderServiceが必要なのでしょうか？
Order自身に処理を持たせてはいけないのでしょうか？
OrderRepositoryまで用意するのは、このExcel VBAには大げさではないでしょうか？
CustomerとOrderには、どのような関係を持たせればよいのでしょうか？
もちろん、これもAIに質問できます。
例えば、
「先ほどのクラス設計の問題点を指摘してください」
と頼めば、自分で作った設計について問題点を挙げてくれるでしょう。
別のAIに同じ設計を見せて、セカンドオピニオンを求めることもできます。
つまり、
AIに設計してもらう
↓
AIに問題点を指摘してもらう
↓
AIに改善してもらう
という使い方も可能です。
それでも、最後に一つ問題が残ります。
複数の答えの中から、どの答えを採用するのでしょうか？
AIの答えを評価するのも人間
これはプログラミングだけの話ではないと思います。
AIが何らかの答えを提示してくれたとき、
- これは正しいのか
- 自分の目的に合っているのか
- 他の方法の方がよいのではないか
- そのまま使って問題ないのか
を考える必要があります。
もちろん、その検証にもAIを使えばよいと思います。
私は、AIに回答を作ってもらい、その回答を別の観点からAIに検証させるという使い方も非常に有効だと考えています。
しかし、
「何を確認すべきなのか」
を人間側がまったく分かっていなければ、AIから返ってきた検証結果そのものを評価することが難しくなります。
例えば、AIが、
「単一責任の原則に反しています」
と指摘したとします。
「単一責任」とは何かを知らなければ、それが本当に問題なのか判断できません。
別のAIが、
「この程度の規模ならクラスを分割しない方がシンプルです」
と言ったら、今度はどちらを採用すればよいのでしょうか。
人間がすべてのコードを暗記し、何も調べずに書ける必要はないと思います。
しかし、
大事なところは、自分自身でも理解しておく必要がある。
私はAIを使うほど、そのことを強く感じます。
知識が不要になるのではなく、使い方が変わる
これまでプログラミングを学ぶ大きな目的の一つは、自分でコードを書けるようになることでした。
VBAなら、
変数
↓
If
↓
For
↓
Sub / Function
↓
配列
↓
Collection / Dictionary
と知識を増やしながら、自分でプログラムを作れるようになっていきます。
しかしAIの登場によって、「コードを作る」という部分の多くを支援してもらえるようになりました。
だからといって、知識が不要になるとは私は考えていません。
むしろ、知識を使う場面が変わってきているのだと思います。
やりたいことを考える
↓
AIに依頼する
↓
AIが答えを出す
↓
検証する
↓
問い返す
↓
別案と比較する
↓
採用するか判断する
ここで人間に求められるのは、
「何を基準に評価するのか」
という判断軸です。
AIがコードを書くようになればなるほど、「コードを書けるか」だけではなく、出てきたコードについて考えられるかが重要になってくるのではないでしょうか。
そこで「設計」を学んでみる
これはExcel VBAにも当てはまります。
AIにVBAを書いてもらうだけなら、クラスやオブジェクト指向を深く知らなくても、動くコードを作れるかもしれません。
しかし、
なぜこのクラスが必要なのか？
このクラスは何を担当すべきなのか？
なぜこの処理をここに置くのか？
このクラスと別のクラスは、どのような関係なのか？
将来仕様が変わったら、どこを修正するのか？
こうしたことを考えようとすると、単なるVBAの文法だけではなく、「設計」という視点が必要になります。
その判断軸を身につける方法の一つが、オブジェクト指向を学ぶことだと私は考えています。
だから、このシリーズでは、
AIより上手にVBAを書く
ことを目標にはしません。
そうではなく、
AIが提案したコードや設計を見たときに、「なぜこうなっているのか？」を自分自身で考えられるようになる
ことを一つの目標にします。
クラスを作ることがゴールではない
そのため、このシリーズではいきなりクラスモジュールの文法から入りません。
また、
クラスをたくさん作れば、オブジェクト指向になる
とも考えません。
まず、
何が問題なのか
↓
どんな役割があるのか
↓
誰が何を担当すべきなのか
↓
どのように責任を分けるのか
↓
それをVBAでどう表現するのか
という順番で考えます。
場合によっては、
「ここはクラスにしない方が分かりやすい」
という結論になるかもしれません。
それも立派な設計判断です。
オブジェクト指向やクラスは目的ではなく、問題を整理するための手段です。
このシリーズで考えていくこと
このシリーズでは、Excel VBAを題材に、
- なぜ大きくなったVBAは理解しづらくなるのか
- 標準モジュールだけではいけないのか
- 何をクラスにすればよいのか
- クラスには何を担当させるのか
- 業務の中からどうやってオブジェクトを見つけるのか
- AIが提案した設計をどう評価するのか
といったことを、一つずつ考えていきます。
専門用語を覚えることから始めるのではなく、
「なぜ、そうするのか？」
をできるだけ大切にしたいと思います。
AIを使わないために勉強するのではありません。
むしろ逆です。
AIをもっと有効に使うためにも、自分自身が判断するための軸を持つ。
その一つとして、Excel VBAのオブジェクト指向と「設計」について一緒に考えていきましょう。
まとめ
今回もっとも伝えたかったことは一つです。
AIが答えを出してくれる時代だからこそ、私たちは「答えを出すため」だけではなく、「答えを評価するため」に学ぶ必要がある。
AIはコードを書いてくれます。
設計案も提示してくれます。
その答えを検証するために、さらにAIを使うこともできます。
それでも最後に、
「この答えを採用してよいか？」
を判断するためには、人間自身にも判断軸が必要です。
Excel VBAにおける、その判断軸の一つがオブジェクト指向や設計の知識です。
「AIが書いたから正しい」ではなく、
なぜ、この設計なのだろう？
と考えられるようになる。
このシリーズでは、そこを目指していきたいと思います。
次回
次回は、
「1000行のVBAがつらくなる本当の理由」
について考えます。
コードが長いから分かりにくいのでしょうか。
それとも、もっと別のところに原因があるのでしょうか。
まずはオブジェクト指向から少し離れて、私たちがVBAを「分かりにくい」と感じる理由から考えてみます。