定型業務は全てマクロ(プログラム)化できるか？

例：営業事務によるファイルの集計業務フロー

1. 営業者は決められたフォルダにExcelで作成した日報ファイル(A)を保存する
2. 営業事務は別のExcelファイル「訪問先一覧(B)」を開く
3. 営業事務は「A」に記載されている訪問先を「B」のシートにコピーペーストする
4. 上記の作業「1」～「3」を定期的に繰り返す

• 業務の流れが決まっている
• 定期的に行う作業である(単発作業でない)

VBAの練習的な意味合いでいえば、非常にシンプルな作業フローなのでとっかかりとしてはいいかもしれません。

上記の作業フローはマクロ化に適していると言いましたが、実際には下記の点も考慮する必要があります。

• 定期的の頻度、一回の作業量(日報ファイル数)
  例えば月に一回の作業で、一回の作業ファイル数も2個などでしたら、わざわざマクロ化しないでもいいかもしれません

• 作業自体の確定度合い
  プログラム化する際にこの点はある意味面倒な作業ですが必ず必要な点です。例えば、営業者が保存するファイル名(A)が変更されることはないか、あるいは同様にファイルAにシートが複数あった場合どれを使用するのか、などです。
  一般的にみれば営業者からは「見ればわかるだろ！」と怒られそうな点もプログラム化するには必要な作業となります。この点については下記項も参考にして下さい

• 将来的な作業内容の変更の可能性
  この点は非常に重要です。一度マクロやプログラムを組むと半永久的に使用することができます。ただ今後も「作業フローが同じ条件である」ということが前提になります。
  つまり変更の可能性が考えられると、マクロ化等をするときに変更した場合の動作の「振る舞いの幅」を考慮する必要が出てきます。
  ここで変更された内容が「想定外」ならば、その時点で大きなマクロの修正を余儀なくされ、業務自体に影響を与える可能性が出てきます。

イメージは掴んでいただけましたでしょうか？
「より使えるマクロ(プログラム)」を作成するには、その前に業務を行うフロー作業の前提を確定させる必要があり、それらが将来にわたって継続されるかどうか、変更される場合は何が想定されるのかを考慮してプログラミングしておく必要があります。
従ってこれらを考慮した定型作業プログラムを既に使ってる企業などは、それなりのスキルを持っている開発(業務)スタッフを有しているとも言えるでしょう。