レッスン5：ワークフロー自動化——ツールとツールをつなぐ

このレッスンで学ぶこと

複数のサービスをつなぐという考え方を理解する
定期実行と条件実行の違いを説明できる
送りすぎない通知の設計を身につける
つなぐ前に業務そのものを減らせないかを考える視点を持つ
ワークフロー自動化のよくある失敗パターンを把握する

前のレッスンでは、フォーム／データベース型のツールを使って、申請・台帳・集計という業務アプリを組み立てる発想を学びました。このレッスンでは、レッスン1で紹介した4分類のうち「ワークフロー自動化型」を扱います。これは、複数のサービス同士をつなぎ、あるサービスで起きた出来事をきっかけに、別のサービスで処理を走らせる仕組みです。

複数のサービスをつなぐという考え方

日々の業務では、複数のサービスやアプリを行き来しながら作業を進めることが多くあります。フォームで受け付けた申請の内容を、表計算ソフトに転記する。カレンダーに予定が入ったら、関係者にメッセージで知らせる。特定の条件を満たしたら、担当者にメールを送る。これらは、レッスン2で学んだトリガー・アクション・条件分岐が、サービスをまたいで動いているだけです。

ワークフロー自動化型のツールは、この「サービスをまたぐトリガーとアクション」を、コードを書かずに設定できるようにしたものです。「サービスAで何かが起きたら、サービスBで何かを行う」という文をそのまま設定画面に落とし込む、という感覚に近いものです。

flowchart LR
  A[フォームで申請が送信される] --> B[自動化の仕組みが検知する]
  B --> C[表計算ソフトに1行追加する]
  B --> D[チャットツールに通知を送る]

この図が示すように、1つのトリガーから複数のアクションを、複数の別々のサービスに向けて実行できるのが、ワークフロー自動化型の強みです。手作業であれば、フォームの内容を確認し、表計算ソフトを開いて転記し、チャットツールを開いて通知文を書く、という3つの作業が必要でした。それを、あらかじめ決めた設定に任せられます。

💡 ポイント ワークフロー自動化型のツールがつなぐのは「サービス」ですが、その内側で動いている考え方は、レッスン2で学んだトリガー・アクション・条件分岐とまったく同じです。1つのツールの中で完結するか、複数のサービスをまたぐかの違いにすぎません。

もう1つ、条件分岐を含む例も見ておきましょう。「問い合わせフォームが送信されたら、内容に緊急度の高い単語が含まれているかを確認し、含まれていれば担当者に即座に通知し、含まれていなければ台帳に記録するだけにとどめる」という仕組みは、次のように整理できます。

トリガー：問い合わせフォームが送信された
条件分岐：緊急度の高い単語が含まれているか
アクション（含まれる場合）：担当者へ即座に通知する
アクション（含まれない場合）：台帳に記録するだけにする

サービスをまたぐ場面でも、トリガー・アクション・条件分岐という同じ3つの問いに答えれば、設計を組み立てられることがわかります。

定期実行と条件実行

ワークフロー自動化型のツールにおけるトリガーは、大きく2種類に分けられます。

定期実行は、決まった時間や間隔で、繰り返し動き出すトリガーです。「毎週月曜の朝9時に、先週分の申請件数を集計して通知する」というように、カレンダーに沿って動きます。

条件実行は、何らかの出来事が起きたときに、その場で動き出すトリガーです。「フォームが送信されたら」「表の値が変わったら」というように、出来事をきっかけにします。レッスン2で扱ったトリガーの多くは、この条件実行にあたります。

種類	きっかけ	向いている場面
定期実行	決まった時刻や間隔	定例の集計、週次・月次のまとめ通知
条件実行	特定の出来事の発生	申請の受付、状態の変化への即時対応

「毎日決まった時刻に、その日の未処理を確認して知らせる」というように、定期実行と条件実行を組み合わせることもよくあります。即時性が必要な場面には条件実行、まとまった単位で確認したい場面には定期実行、という使い分けが基本です。

📝 補足 定期実行の間隔を短く設定しすぎると、実行のたびに処理が走り、つなぎ先のサービスに負荷がかかることがあります。「本当にその頻度が必要か」を考えてから間隔を決めましょう。

定期実行と条件実行を組み合わせた例を、図で確認しておきます。「フォームが送信されるたびに台帳へ記録し、加えて毎週金曜の夕方に、その週の件数をまとめて報告する」という仕組みです。

flowchart TD
  A[フォームが送信された] --> B[台帳に記録する]
  C[毎週金曜17時になった] --> D[その週の件数を集計する]
  D --> E[担当者に週次報告として通知する]

条件実行の流れ（AとB）と、定期実行の流れ（CからEまで）は、互いに独立して動きます。即時の記録は条件実行に任せ、まとまった振り返りは定期実行に任せるという役割分担が、この図から読み取れます。

通知の設計——送りすぎない

ワークフロー自動化を導入すると、真っ先に増えるのが通知です。便利さのあまり、あらゆる出来事に通知を設定してしまい、かえって通知が埋もれてしまう、という失敗がよく起こります。

通知を設計するときは、次の問いを自分に投げかけます。

この通知は、受け取った人が何かの行動を起こす必要があるものか
一覧を見れば済む情報を、わざわざ通知として送っていないか
同じ内容の通知が、1日に何度も届くようになっていないか

「行動が必要な通知」と「記録として残ればよい情報」を混ぜてしまうと、受け取る側は、どの通知に反応すべきかを毎回考えなければならなくなります。結果として、本当に重要な通知まで見落とされるようになります。

⚠️ 注意 「念のため関係者全員に通知しておこう」という設計は、一見丁寧に見えますが、通知が増えるほど、1件あたりの重要度が下がって見えてしまいます。通知は「誰が」「何をするために」受け取るのかを、1件ずつ確認してから設定しましょう。

つなぐ前に業務そのものを減らせないかを考える

ワークフロー自動化型のツールを使い始めると、「つなげられるものは、すべてつないでおきたい」という気持ちが生まれやすくなります。しかし、自動化する前に立ち止まって考えたいことがあります。それは、「このつなぎ込みは、本当に必要な業務を自動化しようとしているか」という問いです。

そもそも不要な承認の段階、誰も見ていない集計、形骸化した報告といった業務は、自動化しても不要な業務が速く回るだけで、業務全体の負担は減りません。むしろ、「自動で回っているから」という理由で、見直す機会そのものが失われてしまうこともあります。

つなぎ込みを設計する前に、次の順番で考えることをおすすめします。

この業務は、そもそも必要か：なくしても困らない業務であれば、自動化ではなく廃止を検討する
この業務は、簡略化できないか：確認する人数を減らす、入力する項目を減らすなど、業務そのものを軽くできないか考える
軽くした業務を、自動化する：ここまで済ませてから、初めてつなぎ込みの設計に入る

💡 ポイント 「自動化」は、業務を軽くする手段の1つであって、目的ではありません。重い業務をそのまま自動化すると、重いまま速く回る仕組みができあがるだけです。まず軽くしてから、自動化する順番を守りましょう。

よくある失敗パターン

ワークフロー自動化を導入する際に、繰り返し見られる失敗パターンを整理しておきます。

つなぎすぎて、全体像が誰にも分からなくなる：いくつものサービスが複雑に絡み合い、1つ止まると、どこに影響が出るのか誰も把握できなくなる
エラー時の対応を決めずに動かし始める：つなぎ先のサービスが一時的に応答しないとき、処理がどうなるかを確認しないまま本番で使ってしまう
手作業の抜け道が残ったまま、二重で動いてしまう：自動化を導入したのに、念のためと手作業も並行して続け、同じ処理が二重に走ってしまう
担当者が1人しか仕組みを理解していない：設定した本人以外、誰も中身を把握しておらず、担当者が不在のときに誰も直せない

最後の「担当者が1人しか理解していない」という状態は、次のレッスンで扱う「作った仕組みを止めない」という課題に直結します。ワークフロー自動化は便利な分、複数のサービスが絡み合いやすく、属人化のリスクが特に高い領域でもあります。

📖 もっと詳しく 決まった操作を人の代わりに繰り返し実行する仕組みとして、ノーコードのワークフロー自動化とは別に、パソコンの画面操作そのものを自動で代行する仕組み（RPAと呼ばれる領域）も存在します。両者は目的も設計の考え方も異なるため、本コースでは深く扱いません。

まとめ

このレッスンでは、以下のことを学びました。

ワークフロー自動化型のツールは、複数のサービスをまたいでトリガー・アクション・条件分岐を組み立てる
トリガーには、決まった時刻で動く「定期実行」と、出来事で動く「条件実行」がある
通知は「行動が必要なもの」に絞り、送りすぎない設計を心がける
つなぎ込みを設計する前に、業務そのものを廃止・簡略化できないかを考える
よくある失敗は、つなぎすぎ、エラー対応の未設計、手作業との二重運用、担当者の属人化である

次のレッスンでは、4分類の3つ目である「サイトビルダー型」を扱い、Webサイトやページをノーコードで作る発想を学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。