»VBA利用における視点¶Attention現時点では書き殴りのメモです。業務フローを、下記の分類で再帰的に単一の業務プロセスに分割し、どの業務プロセスについてVBAで定型化自動化できそうか、という視点で分析をしていく。実現するためには、各プロセスのインプット/処理/アウトプットを厳密に定義する必要がある。曖昧なインプット、曖昧な処理、曖昧なアウトプットでは、実装ができない。インプット、処理、アウトプットの仕様について客観的に妥当性の確認できてから、自動化に着手するべきである。(あとで揉めないために)明確なインプット、処理、アウトプットの仕様があると、テストを作りやすい(はず)。インプット/処理/アウトプットを厳密に定義することで、下記の効果が得られる。(定義する過程で、下記が明確になる効果が期待できる。(定義することで、下記の可能性が生まれる。暫定的かつ気軽な自動化ツールと考える¶VBAは一時的な暫定ツールと考える。方が筋が良いと考えているため。手元で簡便に作れる特徴を活かして、自動化ロジックを起してみる。ロジック自体は言語を超えて使えるため、本格的なツール開発前のプロトタイプとして使える。各種作業の実績取得ツールとして考えてみる。自分達の各種業務のリードタイム、工数を客観的に取るツールとして考えてみる。"業務プロセスにあわせてツールを作る"から、"ツールを便利にするために..."、に立場が変化しやすい。肥大化したツールは修正が難しく、"ツールの仕様がこうだから、業務プロセスをこうする"、という本末転倒が起きやすい。肥大化したツールは仕様の把握が難しくなり、また肥大化に伴い関連ドキュメントの保守も難しくなることから、"仕様はソースを読め"、"肥大化してソースを読むのが困難"もしくは"なんでこんなロジックになっているのか誰も知らない"など、業務からの乖離が起きやすい。肥大モジュールのリスク処理が一箇所こけると、ツール全体が使えなくなるリスクがある。バグの修正工数がよみづらい。作成した人しか修正できない場合がある。テストがされてない場合、後からテストを追加するのはツラい。プロセスに合うツールを作成する。"ひとつの事をうまくできる"モジュールを作る。複雑な事をさせたい場合は、業務プロセスに従い、単機能モジュール間をファイル受け渡しで実現する。類似の処理は同じモジュールでできないか考えてみる。汎用的な要求であれば、モジュールを拡張してみる。非汎用的な要求であれば、新規モジュールを作成してみる。(VBAはクラスの継承ができないため)VBAコーディング上の視点¶シート(GUI)は、下記のみで利用する。)表やチャート(グラフ)のインプット/アウトプットGUI特有の操作(オートフィルタ/ソート)や演算関数(例えばvlookupなど)を利用しない。