せっかく覚えたVBAで自分だけの便利ツールを作ってうまくいくと嬉しいと思います。そのうち周りの人に使ってもらいたいとか、何か便利ツールを作ってあげたいと思うようになってきた人もいるのではないでしょうか。
今回はVBAで自分だけ効率化している状態から、人に使ってもらえるツールを作れるようにステップアップを図りましょう。
この記事は中級～上級です。
レベルについてはExcel VBAの実力（レベル）を定義してみる 初心者～三段をご参照ください。
目次
優しさは強さ
自分だけの便利ツールならコアな部分だけを端的に作ればよいです。ユーザーに入力ファイルを選ばせる場面も、ユーザーは自分ですから、メッセージボックスすら出さずにポンとダイアログボックスを出せばよいです。
人に使ってもらえるツールを使うということは、「〇〇データを選択してください」というメッセージボックスを出す、とかそのメッセージボックスで右上の×を押されたときに「キャンセルしますか」と確認したりすることです。
すでに作業中であれば、ユーザーはバツを押したときに、作業前の状態に戻ってほしいと思っています。加工作業中のデータなんていりませんから、その中途半端なブックが開いた状態で終わってほしくないし、ましてやVBEの画面なんて見たくありません。
これらは技術的に難しいことではありません。知らなくても調べればできることばかりです。ユーザーに優しいツールやシステムを作るということは、自分勝手ではなく、相手の立場を思いやる強さを持つということだと思います。
防げるエラーを確実に防ぐための日常的な習慣
前置きが長くなりました。相手の立場を思いやる前提ができたところで、使い勝手の良いツールを作るにあたり、日常的に心がけておきたいことを解説していきたいと思います。
失敗を資産にする
二度あることは三度ある。やってしまった失敗は失敗で終わらせるのではなく、大切に書き留めておきましょう。対策ができればそれはノウハウとなり、使い廻すことでより年季の入ったスキルになってきます。
VBAで言えば、
- 「完了しました」など×を押されても構わないメッセージボックス以外は戻り値を使った分岐を行う
- 入力データとして取り込んだブックは加工するのではなく、配列に格納して、原本はすぐに閉じる
- 成果物としてデータを生成する時は「完了しました」のメッセージを出す直前まで保存しない
- データの保存先はユーザーが選択するのか、元データと同じ場所に別名で保存するのか確認する
といったようなことが挙げられます。これらは一度やり方がわかってしまえば難しいことではありませんので、自分のものにしてしまうことで、スキルアップだけでなく、ユーザーに意見を聞くときも気を自然に利かせることができるようになります。
「データの保存場所は自分で選べたほうがいいですか？」みたいに。
ユーザーのやりたいことの本質をつかむ
自分のツールを作る時は、やりたいことがよく分かっています。しかし、人に頼まれてツールを作る時、注意したいのは、その人が求めていることの本質をつかむことです。
その人の作業の自動化をする、と考えると、作業そのものをプログラムしてしまいます。
例えば、エクセルシート上の作業で、VLOOKUPを使うために仕入れ先の名前と商品カテゴリをアンダーバーで区切った「〇〇商会_キッチン用品」といったキーを作るために一列挿入している、というような場合があります。
この作業の本質は仕入れ先と商品カテゴリがある範囲に存在しているかどうかを調べることが目的ですから、VBAでコードを書く際には一列挿入してキーとなる値をワークシート上に表示する必要はありません。
本質を知ることで、より無駄のないコードを書くことができます。これはコーディング作業の効率化だけでなく、プログラムの実行完了時間の短縮につながります。さらにその人の業務の本質やその人の仕事の進め方まで分かります。
非エンジニアはコーディングのプロではなく、業務改善のプロなので、本質をとらえることがプログラミングをする上でとても大事です。
コア部分を先に作ってしまうメリット
VBAでのツール作成は自分用のものだけでなく、人のためにツールであってもまずはコアの部分をアジャイル的に開発するのが最適です。
早く試作できる
データの取り込みや保存して閉じるときの挙動はさておき、まずは核になる部分に取り組むのがベストです。理由はユーザーが求める出力が得られるのか、仕様を早く実物をもって確認できるからです。
ユーザー思いの挙動やユーザーインターフェイスの作りこみはコアな作業部分が８割完了してから、じっくり仕上げていくとバランスの良いものができると思います。
ユーザー思いのインターフェースの設計が精密になり、結果的に手戻りが少ない
ユーザーフォームなどを使ってコアな作業に使うパラメータをユーザーに入力してもらうような場合でも、コア部分を先に作成すべきです。せっかく時間をかけて見た目などもこだわったUIを作成しても、「やっぱりパラメータは別のcsvファイルにまとめたものを取り込むことにする」などの変更があり得ます。
この時に「えー、この前言ってたことと違う！」と腹を立てては優しく強いホワイトカラーにはなれません。
手戻りにめげないのが強いのではなく、手戻りが少ないように作業を進めるのが、優しく強いホワイトカラーなのです。
入力データの取り扱い
コア部分ができたら入力データの取り扱いに移ります。しかし、これも挙動の仕様変更を見据えて作っておくことです。
たとえば、新しいデータを生成するのではなく、前回のファイルを更新して保存する作業を自動化するとします。この場合、元のデータを直接加工すると、なんかのエラーによってマクロの実行が中断されたとき、元のデータが失われます。
よく言われるのが、データをバックアップしておくことですが、ここでおすすめしたいのが、更新したくても、新たなデータを生成したくても、入力の元データは触らない、ということです。
配列を扱える人は必要なシートを配列に転記してすぐに入力データのブックは閉じておきましょう。
配列を知らない人は、入力データのブックをコピーして新たなブックを生成し、元のブックは閉じましょう。
更新が完了したら新しいブックを保存して閉じればOKです。元のデータが不要なのであれば元のデータを削除すればよいです。
こうすることで元のデータと同じ場所に更新済みファイルを保存するのも上書き（実際には新規作成と元データの削除）もできますので、保存の仕方の仕様変更にも簡単に対応できます。
テストデータを用意する
アジャイル的にユーザーを含めた開発に気軽に着手できるからこそ、リリースと開発段階を明確に分けましょう。そうでないと、いつまでたっても開発完了になりません。リリースした後の変更はバージョンアップとして管理します。
開発段階とリリースを分けるけじめがユーザーテストです。これは開発の為のデータではなく、あらかじめこういうデータでテストして合格だったらリリース、とユーザーと合意しておきます。
- 普段より圧倒的に大量のデータ
- 内容に不備があるデータ
- 極端に少ないデータ
などを用意しておきます。開発の最終段階ではこれらの対策を盛り込んでいきます。
すると、普段より圧倒的に大量のデータの場合なら、たとえ不具合なく作業が完了しても、
「この作業には数分かかります。実行してよろしいでしょうか y/n」といったメッセージボックスを
出したほうが良いかな、などと気づきがあります。
この気づきは先述の失敗を資産にする、から得た発想です。こうして完成度を高めていくことで
スキルを磨くだけでなく、ユーザーを思いやる使い勝手の良いツールができるようになっていくと思います。
こうしてスキルだけでなく思いやりの気持ちもはぐくまれ、しかも手戻りも少なく開発効率も上がっていきます。
皆さんも、自分だけの便利ツールを作る段階から人に使ってもらえるツールの作成へ一歩踏み出しませんか？
