「この作業、Power Automateで自動化できませんか？」
Microsoft 365を使った業務改善では、このような相談を受けることがあります。
例えば、
- メールが届いたらSharePoint Listsへ登録したい
- Formsに回答があったらTeamsへ通知したい
- ステータスが変わったら担当者へメールしたい
- 期限が近づいたら自動でリマインドしたい
こうした処理は、Power Automateを使えば実現できるケースがあります。
しかし、ここですぐPower Automateを開いてフローを作り始めると、後から苦しくなることがあります。
Power Automateで失敗する原因は、フローの作り方を知らないことではありません。
自動化する業務そのものが整理されていないことです。
今回は、企業の業務自動化を支援する中で重要だと感じている、Power Automateを作る前の「業務フロー設計」について解説します。
Power Automateを作り始めてから「例外」が見つかる
例えば、「問い合わせメールを受信したらSharePoint Listsへ登録する」という業務を自動化するとします。
一見すると、非常にシンプルです。
メールを受信
↓
SharePoint Listsへ登録
これだけなら、Power Automateのフローも簡単に作れます。
ところが、実際の業務を詳しく聞いていくと、次のような条件が出てくることがあります。
- メール以外に電話や口頭でも問い合わせを受けている
- 添付ファイルがある場合がある
- CCで受信するケースがある
- 問い合わせ内容によって担当者が異なる
- 特定の条件では別の担当者へ回す
- 回答を書いている途中では送信したくない
- 回答済みのものは再処理したくない
すると、
Power Automateを作る
↓
例外が見つかる
↓
条件分岐を追加する
↓
別の例外が見つかる
↓
さらに条件を追加する
という状態になっていきます。
ここで重要なのは、複雑なのはPower Automateではなく、元の業務であるということです。
最初にPower Automateを開かない
業務自動化を考えるとき、最初にやるべきことはPower Automateを開くことではありません。
まず、現在の業務を整理します。
例えば問い合わせ対応であれば、大きな流れは次のようになります。
問い合わせ発生
↓
受付
↓
内容確認
↓
担当者決定
↓
調査
↓
回答
↓
完了
そのうえで、それぞれの工程について、
- 誰が行うのか
- 何をきっかけに始まるのか
- どの情報を使うのか
- どんな条件で次へ進むのか
- どんな例外があるのか
を整理していきます。
Power Automateは「最後」につくる
業務自動化は、次のような順番で考えると整理しやすくなります。
- 現在の業務を整理する
- 必要なデータを整理する
- 人が行う部分と自動化する部分を分ける
- Power Automateを設計する
- 運用・エラー対応まで決める
つまり、Power Automateは業務改善のスタート地点ではなく、整理した業務を仕組みに落とし込むための後工程です。
業務フローを描くと「自動化する場所」が見えてくる
業務フローを整理したからといって、すべての工程を自動化する必要はありません。
むしろ重要なのは、人が判断すべき部分と、システムへ任せられる部分を分けることです。
| 業務 | 考え方 |
|---|---|
| メールの受信 | 自動化しやすい |
| SharePoint Listsへの登録 | 自動化しやすい |
| 担当者への通知 | 自動化しやすい |
| 問い合わせ内容の専門的判断 | 人が行う |
| 回答内容の最終確認 | 人が行う |
| ステータス変更後の通知 | 自動化しやすい |
「自動化できるから自動化する」のではなく、「機械に任せるべき仕事を自動化する」。
この判断が、シンプルで運用しやすいフローにつながります。
次に「データ」を整理する
業務フローが見えてきたら、次に考えるのがデータです。
Power Automateは、何らかの情報を受け取り、その情報を使って処理します。
例えば問い合わせ管理なら、
- 受付日時
- 問い合わせ者
- 問い合わせ内容
- 受付チャネル
- 担当者
- ステータス
- 回答内容
- 回答日
などの情報が考えられます。
これらをどのような形式で持つのかによって、後のPower Automateの作り方も変わります。
業務フローとデータ構造は、別々ではなくセットで設計する必要があります。
SharePoint Listsのデータ設計については、「SharePoint Listsで業務システムを作るなら、最初に『列』を作ってはいけない」でも詳しく解説しています。
トリガー・条件・アクションは最後に決める
ここまで整理できて、初めてPower Automateの設計に入ります。
Power Automateのフローは、大きく考えると次の要素で構成されます。
Trigger（トリガー）
何が起きたら処理を開始するのか。
例えば「メールを受信した」「Formsに回答があった」「SharePoint Listsのアイテムが更新された」などです。
Condition（条件）
どの条件で処理を分岐させるのか。
例えば「ステータスが回答済みか」「特定のカテゴリか」などを判定します。
Action（アクション）
条件に応じて何を実行するのか。
例えばSharePoint Listsへ登録する、Teamsへ通知する、メールを送るといった処理です。
業務が整理されていれば、これらも自然に決まってきます。
Power Automateのフローは、業務フローをシステム上に翻訳したもの。
この考え方を持つと、Power Automateから設計を始める危険性が分かりやすくなります。
そもそも「自動化しなくていい仕事」もある
業務フローを描くもう一つの理由は、現在行っている処理そのものが必要なのかを確認するためです。
例えば、次のような業務があったとします。
Aさんからメールを受信
↓
BさんがExcelへ転記
↓
Cさんへメールで連絡
↓
Cさんが別のExcelへ転記
Power Automateを使えば、この転記やメール送信を自動化することはできます。
しかし、本当に考えるべきなのは、
そもそも、2つのExcelへ転記する必要があるのか？
ということです。
業務改善では、
- その作業をなくせないか
- ほかの作業とまとめられないか
- それでも必要なら自動化できないか
という順番で考えることが重要です。
ムダな業務をそのまま自動化しても、ムダな処理が高速になるだけです。
「自動化率100％」を目指さなくていい
Power Automateを導入すると、「せっかくなら全部自動化したい」と考えたくなることがあります。
しかし、例外処理まで無理にすべて自動化すると、条件分岐が増え、フローが巨大化することがあります。
その結果、
- どこで何をしているのか分からない
- 作った人しか修正できない
- 業務変更のたびに大規模な修正が必要になる
- エラーが起きても原因を追いにくい
という問題につながります。
例外的なケースは人に残し、定型的で判断ルールが明確な部分を自動化するという選択もあります。
自動化の目的は、自動化率を上げることではありません。業務全体を楽に、安定して回せるようにすることです。
いきなりPower Automateで自動化すると何が起きるのか
業務を整理せずにPower Automateを作る場合と、先に業務を整理する場合を比較すると、違いが分かりやすくなります。
業務を整理しないまま自動化すると、運用を始めてから例外や追加要件が次々に見つかり、条件分岐が増えていきます。
その結果、フローが複雑化し、属人化しやすくなります。
一方で、業務を先に整理すれば、
- 不要な処理をなくす
- 必要なデータを明確にする
- 人が判断する部分を明確にする
- 自動化する部分を限定する
ことができます。
結果として、シンプルで分かりやすく、変更にも強いフローを作りやすくなります。
「動くフロー」と「運用できるフロー」は違う
Power Automateでフローを作り、テストで正常に動けば完成。
そう考えたくなりますが、企業で使う場合はそれだけでは不十分です。
運用まで考えるなら、例えば次の点も決める必要があります。
- 誰がフローを管理するのか
- エラーが起きたとき誰へ通知するのか
- 担当者が異動したらどうするのか
- 例外時には誰が手動対応するのか
- 業務ルールが変わったとき誰が修正するのか
- 作成者が不在でも運用を継続できるか
「動く」ことと、「会社で継続して運用できる」ことは別です。
Power Automateの設計には、フローだけでなく運用ルールまで含まれます。
こんなPower Automateになっていたら、一度業務設計を見直す
現在使っているPower Automateについて、次のような状態になっていないでしょうか。
- 条件分岐が大量にある
- Apply to eachが何重にもなっている
- 同じようなフローが何本も存在する
- 作った本人しか修正できない
- エラーになると原因が分からない
- 業務変更のたびにフローを修正している
- 個人名やメールアドレスをフロー内へ直接多数設定している
- 「なぜこの処理が必要なのか」を説明できる人がいない
一つでも当てはまるからといって、必ず悪いフローというわけではありません。
ただし、Power Automateそのものではなく、その前の業務設計を見直す余地がある可能性があります。
Power Automateは業務を整理してくれるツールではない
Power Automateは、Microsoft 365のさまざまなサービスを連携し、定型業務を自動化できる便利なツールです。
しかし、Power Automate自身が現在の業務を整理し、「この業務は不要です」「この判断は人に残しましょう」と決めてくれるわけではありません。
整理されていない業務を自動化すれば、整理されていない業務が高速で動くだけです。
だからこそ、Power Automateを作る前に、
業務整理
↓
不要な作業の見直し
↓
データ設計
↓
人とシステムの役割分担
↓
Power Automate
↓
運用設計
という順番で考えることが重要です。
Power Automateを作る前の「業務整理」からご相談いただけます
株式会社uniteでは、Power Automateのフローを作ること自体を目的にはしていません。
まず現在の業務を整理し、
- そもそも必要な作業なのか
- どこを人に残すのか
- どこを自動化するのか
- どのようなデータが必要なのか
- 運用後に誰が管理するのか
というところから、自動化の仕組みを設計します。
「Power Automateを作ってみたが複雑になってしまった」
「自動化したい業務はあるが、どこから手をつければいいか分からない」
「作った人しかフローを直せない」
といった段階からでも構いません。
Power Automateを作る前に、まず業務そのものを一緒に整理してみませんか。
