VBA利用における視点¶
Attention
現時点では書き殴りのメモです。すいません。
視点1. 業務プロセス分析の1ツールと考える¶
- 業務フローを、下記の分類で再帰的に単一の業務プロセスに分割し、どの業務プロセスについてVBAで定型化自動化できそうか、という視点で分析をしていく。
- Inbound (時間到来、メール、ファイル、Webなど)
- 前処理 (事前チェック、承認など)
- 本処理 (データ更新など)
- 後処理 (事後チェック、記録、報告など)
- Outbound (メール、ファイル、Webなど)
- 上記の "VBA定型化自動化" を実現するためには、各プロセスのインプット/処理/アウトプットを厳密に定義する必要がある。
- 曖昧なインプット、曖昧な処理、曖昧なアウトプットでは、実装ができない。
- インプット、処理、アウトプットの仕様について客観的に妥当性の確認できてから、自動化に着手するべきである。(あとで揉めないために)
- 明確なインプット、処理、アウトプットの仕様があると、テストを作りやすい(はず)。
- 上記 "各プロセス" のインプット/処理/アウトプットを厳密に定義することで、下記の効果が得られる。
- 間接効果 (定義する過程で、下記が明確になる効果が期待できる。)
- 各プロセスのそもそもの目的、意図 (Why)
- 各プロセスにおける処理ロジック(仕様) (How)
- 必要/不要となっている作業や情報項目など (What/Who/When/Where)
- 直接効果 (定義することで、下記の可能性が生まれる。)
- 各プロセスのスリム化(間接効果経由で)、類型化の実現 (仕様のシンプル化、共通認識の容易化)
- 各プロセスの自動化もしくは省力化の実現 (作業工数の効率化、作業品質の安定化)
- (長期的には)プロセス類型の蓄積による業務プロセス分析能力の向上、ツール開発工数の低減、変化対応の柔軟化 (改善サイクル化)
視点2. 暫定的かつ気軽な自動化ツールと考える¶
- VBAは一時的な暫定ツールと考える。
- MicroSoftにおけるVBAのロードマップが不明
- 個人的には Unix化/Web化/API化 の方が筋が良いと考えているため。
- 手元で簡便に作れる特徴を活かして、自動化ロジックを起してみる。
- ロジック自体は言語を超えて使えるため、本格的なツール開発前のプロトタイプとして使える。
- 各種作業の実績取得ツールとして考えてみる。
- 自分達の各種業務のリードタイム、工数を客観的に取るツールとして考えてみる。
視点3. 肥大化させない¶
- ツール肥大化は自己目的化しやすい
- 開発当初の "業務プロセスにあわせてツールを作る"から、"ツールを便利にするために..."、に立場が変化しやすい。
- 肥大化したツールは修正が難しく、"ツールの仕様がこうだから、業務プロセスをこうする"、という本末転倒が起きやすい。
- 肥大化したツールは仕様の把握が難しくなり、また肥大化に伴い関連ドキュメントの保守も難しくなることから、"仕様はソースを読め"、"肥大化してソースを読むのが困難"もしくは"なんでこんなロジックになっているのか誰も知らない"など、業務からの乖離が起きやすい。
- 肥大モジュールのリスク
- 処理が一箇所こけると、ツール全体が使えなくなるリスクがある。
- バグの修正工数がよみづらい。
- 作成した人しか修正できない場合がある。
- テストがされてない場合、後からテストを追加するのはツラい。
- プロセスに合うツールを作成する。
- "ひとつの事をうまくできる"モジュールを作る。
- 複雑な事をさせたい場合は、業務プロセスに従い、単機能モジュール間をファイル受け渡しで実現する。
- 類似の処理は同じモジュールでできないか考えてみる。
- 汎用的な要求であれば、モジュールを拡張してみる。
- 非汎用的な要求であれば、新規モジュールを作成してみる。(VBAはクラスの継承ができないため)
VBAコーディング上の視点¶
- シート(GUI)は、下記のみで利用する。
- ユーザインタフェースのインプット/アウトプット (設定や入力項目、結果出力など)
- 表やチャート(グラフ)のインプット/アウトプット
- GUI特有の操作(オートフィルタ/ソート)や演算関数(例えばvlookupなど)を利用しない。(ソースコードの見通しが悪くなる)