VBA
Excel VBAのUserFormはなぜ開発費が高くなる？プロが見ている「画面」の裏側
ぴーす君
「この処理、画面（UserForm）でできない？」
VBAで業務ツールを作っていると、こんな要望をいただくことがあります。
もちろん、できます。
UserFormを使えば、Excelのシート上ではなく、専用の画面を作って入力や操作を行うことができます。
ただ、開発する側からすると、「画面にする」というのは、単純に入力欄やボタンを配置するだけではありません。
そして、UserFormを使った開発では、その「画面をどう動かすか」が開発費に影響することがあります。
UserFormを使うと、なぜ開発費が高くなるのか
まず、UserFormそのものが高いわけではありません。
費用に影響するのは、UserFormを使って何を実現するのかです。
例えば、
入力された値が正しいか確認する
必須項目が入力されているか確認する
エラーがあれば表示する
入力内容によって別の項目を表示・非表示にする
ボタンを押したときに処理を実行する
処理が終わったら画面を切り替える
といったことがあります。
これらはすべて、画面を「置く」だけでは実現できません。
利用者が操作したときに、何が起きるのか。
そこまで考えて、プログラムを作る必要があります。
UserFormでは「それをどう動かすか」を作る
例えば、「数値だけ入力できるようにしたい」という要望があったとします。
Excelのシートであれば、入力規則など、Excelがもともと持っている機能を利用できる場合があります。
しかしUserFormでは、そう簡単にはいきません。
数字以外が入力された場合、
その入力を受け付けないのか
エラーメッセージを表示するのか
入力欄を赤くするのか
入力が終わった時点でチェックするのか
空欄は許可するのか
小数やマイナスはどうするのか
などを決める必要があります。
つまり、
「数値だけ入力してほしい」
という一言が、
「数値以外が入力された場合に、画面をどう動かすか」
という仕様に変わります。
これは数値入力に限った話ではありません。
「選択肢から選んでほしい」「入力された内容によって次の項目を変えたい」「登録前に確認したい」など、画面上で利用者に何かをしてもらうたびに、その動きを考える必要があります。
UserFormでは、Excelが用意している機能だけに頼るのではなく、必要な動きをVBAで作っていくことになります。
「エラーなら赤くしてください」は、本当に小さな修正？
例えば、完成したUserFormを見て、
「エラーになった項目は赤くしてください」
と言われたとします。
依頼する側からすると、見た目を少し変えるだけに感じるかもしれません。
しかし、開発する側では、
「何をエラーとするのか？」
から考える必要があります。
さらに、
いつエラー判定するのか
どの項目を赤くするのか
エラーが解消されたら元の色に戻すのか
複数の項目がエラーになった場合はどうするのか
エラーメッセージは表示するのか
エラーがある状態で登録ボタンを押せるのか
といったことも決める必要があります。
このように、見た目の変更に見えても、実際にはプログラムの変更になることがあります。
特にUserFormでは、画面の変更が処理の変更につながりやすいのです。
UserFormを使う＝高くするため、ではありません
ここまで読むと、
「じゃあ、UserFormを使わない方がいいのでは？」
と思われるかもしれません。
もちろん、そういう話ではありません。
UserFormを使うことで、
操作する場所を分かりやすくする
入力する項目を限定する
入力ミスを減らす
利用者が余計なシート操作をしなくて済む
複数の処理を一つの画面にまとめる
といったメリットがあります。
そのため、業務内容によってはUserFormを使う方が適していることもあります。
つまり、UserFormを使うのは、
「開発費を高くするため」ではなく、「その業務に必要な操作性を実現するため」
です。
開発者は、その要件にUserFormが適しているのかを検討したうえで、必要であればUserFormを使います。
それでもUserFormを使う価値はある？
ここで考えたいのが、費用対効果です。
例えば、毎日何人もの担当者が使うシステムで、入力ミスが頻繁に発生しているのであれば、入力を制御できるUserFormに費用をかける意味があるかもしれません。
一方で、月に一度だけ担当者が使うツールであれば、
「そこまで画面を作り込む必要がありますか？」
という判断もできます。
UserFormは「できるか、できないか」だけで考えるものではありません。
その操作性に、どこまで費用をかける価値があるのか。
ここも含めて検討する必要があります。
費用を抑えるために、依頼する側ができること
UserFormを使わないことが、開発費を抑える方法とは限りません。
むしろ大切なのは、最初に画面で何をしたいのかをできるだけ具体的にしておくことです。
例えば、
誰が使うのか
何を入力するのか
何を選択するのか
入力ミスがあった場合はどうするのか
エラーをどのように表示したいのか
登録ボタンを押したら何をするのか
登録後はどの画面に戻るのか
などです。
最初の段階で決まっていなかったことが、開発途中や完成後に、
「やっぱりここも画面に入れてほしい」
「この場合は別の動きにしてほしい」
「このエラーも表示してほしい」
となると、そのたびにプログラムの変更が必要になります。
もちろん、途中で仕様が変わること自体は珍しいことではありません。
ただ、画面に関する変更は、単純な文字やセルの修正よりも、開発範囲が広がりやすいということは知っておいてほしいところです。
「UserFormで」と伝える前に
「UserFormで作ってほしい」という要望が悪いわけではありません。
ただ、開発を依頼するときは、
「UserFormを使ってください」
だけではなく、
「画面で何をしたいのか」
を伝えてもらえると、開発する側も検討しやすくなります。
もしかすると、UserFormを使う必要がないかもしれません。
逆に、要件を確認した結果、
「これはUserFormにした方が使いやすいですね」
となるかもしれません。
重要なのは、最初から手段を決めてしまうことではなく、やりたいことに対して、どの方法が適しているのかを考えることです。
UserFormは便利な機能です。
ただし、その便利さを実現するためには、画面の見た目だけでなく、そこにある一つ一つの「動き」を作る必要があります。
だからこそ、UserFormを使ったVBA開発では、開発者が見ている「画面の裏側」にも、費用が発生するのです。