業務の隙間を埋める技術メモ。

「それ、作れるか?」より 「それ、作って大丈夫か?」を考えたい。 業務で“ちゃんと使える”かどうかを、 実際に手を動かして確かめたログを残しています。

「それ、VBAで作るやつじゃないですよね…」 〜Power Automate案件をVBAで3日溶かしかけた話〜

ある日の雑談から始まった

たまたま経理の女性と話す機会がありました。
雑談の流れで、最近の業務効率化の話に。

「最近、何か頼まれて作ってるものあるんですか?」

すると、少し困った顔でこう返ってきました。

経理主任から、
仕入れ先から請求書のメールが届いたら
Teamsに通知する処理を作ってって言われてて…」

この時点で、
ちょっとだけ嫌な予感がしました。


嫌な予感は、だいたい当たる

念のため聞いてみます。

「ちなみに、どうやって実装してるんですか?」

返ってきた答えは、
ほぼ想定どおりでした。

VBAでゴリゴリ書いてます!
もう3日目なんですけど、まだできなくて〜」

……ですよね。

VBAが悪いわけじゃない。
この方、実際にVBAを触った経験もある。

でもこれは、

どう考えても Power Automate の守備範囲


業務内容を冷静に見ると、かなりシンプル

やりたいことはこれだけです。

  1. Outlookに請求書メールが届く

  2. 件名や差出人で判定

  3. 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の場合。

  1. トリガー

    • 「新しいメールが届いたとき」

  2. 条件

    • 件名に「請求書」を含む

    • 差出人が仕入れ先

  3. アクション

    • Teamsに投稿

画面をポチポチして、
メッセージ文面を書いて終わり。

なんなら5分で形になる内容です。


比較してみると、差は明確

観点 VBA Power Automate
作り始め 重い 軽い
実行環境 PC依存 クラウド
トラブル調査 つらい 履歴で確認
引き継ぎ ほぼ無理 画面見れば分かる
変更対応 コード修正 画面操作

今回のような
単純連携・通知系では、
正直、勝負になりません。


それでもVBAが選ばれてしまう理由

ここが一番大事なところです。

Power Automateが「知られていない」

これ、現場ではかなり大きい。

  • VBAは聞いたことがある

  • Excelマクロは触ったことがある

  • Power Automateは名前すら知らない

だから、

「できそうな方法」で着手してしまう

結果として、
難しい道を自分で選んでしまう


技術力の問題ではなかった

今回のケース、

  • スキルが足りなかったわけじゃない

  • 努力が足りなかったわけでもない

単に、

選択肢にPower Automateが入ってなかった

それだけです。

これ、かなり多くの現場で起きているのを実感します。

 

経理って結構閉じた世界で業務をしているので、

業務の凝集性が高い代わりに閉鎖的で新しいことになかなか気づけない、そんな特性がありそうなんですよね。

そりゃあ、普通に「今月の役員報酬いくら?」なんてやり取りをしているくらい、ヤバい情報をたくさん扱っている組織です。

なかなかオープンにできない事情も納得です。納得ですが、、

 


一番もったいないのはここ

Power Automateって、

  • Microsoft 365に含まれていることが多い

  • 追加コストなしで使える

  • 管理部門にめちゃくちゃ向いている

なのに、

現場ユーザーに存在すら知られていない

結果、

  • VBAで苦労する

  • 個人PC依存の仕組みが増える

  • 作った人が休むと止まる

という、よくない循環が生まれる。


じゃあ、どうすればよかったのか(反省)

今回の件で思ったのは、

  • 「作って」と頼む前に

  • 「どうやって作るか」を

  • 少しだけ一緒に考える

これだけで、
3日分の努力は別の形になっていたはず。

とりあえずPower automateの使い方教えておきました。

 


総括:今回の話の本質

この話、
VBA vs Power Automate の優劣ではありません。

ポイントは3つ。

  1. 業務内容に合った道具を選べていなかった

  2. Power Automateの知名度が現場で低すぎる

  3. 結果として、善意の努力が消耗に変わっていた

Power Automateは魔法じゃないけど、

知られていないせいで使われない

というのは、
さすがにもったいない。


最後に

もし現場で、

  • VBAで通知を作ろうとしている

  • マクロを常駐させようとしている

  • 「これ、自動化できないかな…」と悩んでいる

人がいたら、

「Power Automateって知ってる?」

この一言だけで、
だいぶ未来が変わるかもしれません。