ある日の雑談から始まった
たまたま経理の女性と話す機会がありました。
雑談の流れで、最近の業務効率化の話に。
「最近、何か頼まれて作ってるものあるんですか?」
すると、少し困った顔でこう返ってきました。
この時点で、
ちょっとだけ嫌な予感がしました。
嫌な予感は、だいたい当たる
念のため聞いてみます。
「ちなみに、どうやって実装してるんですか?」
返ってきた答えは、
ほぼ想定どおりでした。
「VBAでゴリゴリ書いてます!
もう3日目なんですけど、まだできなくて〜」
……ですよね。
VBAが悪いわけじゃない。
この方、実際にVBAを触った経験もある。
でもこれは、
どう考えても Power Automate の守備範囲
業務内容を冷静に見ると、かなりシンプル
やりたいことはこれだけです。
-
Outlookに請求書メールが届く
-
件名や差出人で判定
-
Teamsに通知する
Excel加工なし。
複雑なロジックなし。
画面操作もなし。
メール → 条件 → 通知
典型的なイベント駆動。
VBAで実装すると、こうなる(例)
VBAで書くと、だいたいこんな構成になるかなと思い書いてみた。
Private WithEvents olItems As Outlook.Items
Private Sub Application_Startup()
Dim olApp As Outlook.Application
Dim olNS As Outlook.Namespace
Dim inbox As Outlook.Folder
Set olApp = Outlook.Application
Set olNS = olApp.GetNamespace("MAPI")
Set inbox = olNS.GetDefaultFolder(olFolderInbox)
Set olItems = inbox.Items
End Sub
Private Sub olItems_ItemAdd(ByVal Item As Object)
If TypeOf Item Is Outlook.MailItem Then
Dim mail As Outlook.MailItem
Set mail = Item
If InStr(mail.Subject, "請求書") > 0 Then
Call PostToTeams(mail.Subject)
End If
End If
End Sub
Sub PostToTeams(subject As String)
' WebhookでTeamsにPOST
' JSON組み立て
' エラーハンドリング
End Sub
ここに、
-
Teams Webhook設定
-
JSON生成
-
エラーハンドリング
-
マクロ常駐問題
が乗っかってきます。
コード量以上に、精神的な負荷が重い。
3日ハマるのも、正直よく分かります。
僕なら絶対やりたくないw
Power Automateなら、こうなる
Power Automateの場合。
-
トリガー
-
「新しいメールが届いたとき」
-
-
条件
-
件名に「請求書」を含む
-
差出人が仕入れ先
-
-
アクション
-
Teamsに投稿
-
画面をポチポチして、
メッセージ文面を書いて終わり。
なんなら5分で形になる内容です。
比較してみると、差は明確
| 観点 | VBA | Power Automate |
|---|---|---|
| 作り始め | 重い | 軽い |
| 実行環境 | PC依存 | クラウド |
| トラブル調査 | つらい | 履歴で確認 |
| 引き継ぎ | ほぼ無理 | 画面見れば分かる |
| 変更対応 | コード修正 | 画面操作 |
今回のような
単純連携・通知系では、
正直、勝負になりません。
それでもVBAが選ばれてしまう理由
ここが一番大事なところです。
Power Automateが「知られていない」
これ、現場ではかなり大きい。
だから、
「できそうな方法」で着手してしまう
結果として、
難しい道を自分で選んでしまう。
技術力の問題ではなかった
今回のケース、
-
スキルが足りなかったわけじゃない
-
努力が足りなかったわけでもない
単に、
選択肢にPower Automateが入ってなかった
それだけです。
これ、かなり多くの現場で起きているのを実感します。
経理って結構閉じた世界で業務をしているので、
業務の凝集性が高い代わりに閉鎖的で新しいことになかなか気づけない、そんな特性がありそうなんですよね。
そりゃあ、普通に「今月の役員報酬いくら?」なんてやり取りをしているくらい、ヤバい情報をたくさん扱っている組織です。
なかなかオープンにできない事情も納得です。納得ですが、、
一番もったいないのはここ
Power Automateって、
-
Microsoft 365に含まれていることが多い
-
追加コストなしで使える
-
管理部門にめちゃくちゃ向いている
なのに、
現場ユーザーに存在すら知られていない
結果、
-
VBAで苦労する
-
個人PC依存の仕組みが増える
-
作った人が休むと止まる
という、よくない循環が生まれる。
じゃあ、どうすればよかったのか(反省)
今回の件で思ったのは、
-
「作って」と頼む前に
-
「どうやって作るか」を
-
少しだけ一緒に考える
これだけで、
3日分の努力は別の形になっていたはず。
とりあえずPower automateの使い方教えておきました。
総括:今回の話の本質
この話、
VBA vs Power Automate の優劣ではありません。
ポイントは3つ。
-
業務内容に合った道具を選べていなかった
-
Power Automateの知名度が現場で低すぎる
-
結果として、善意の努力が消耗に変わっていた
Power Automateは魔法じゃないけど、
知られていないせいで使われない
というのは、
さすがにもったいない。
最後に
もし現場で、
-
VBAで通知を作ろうとしている
-
マクロを常駐させようとしている
-
「これ、自動化できないかな…」と悩んでいる
人がいたら、
「Power Automateって知ってる?」
この一言だけで、
だいぶ未来が変わるかもしれません。