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