Makeで業務自動化するシナリオ作成手順

Makeで業務自動化するシナリオは、業務を起点、途中の処理、実行結果へ整理し、起点モジュールから順に設定してテスト後に有効化する手順で作成します。いきなり画面上でモジュールを並べるのではなく、現在の作業を整理することが先決です。

この記事では、自動化する業務の選定からシナリオの作成、データの受け渡し、条件分岐、テスト、運用開始までを順番に解説します。

Makeで業務を自動化する仕組み

Makeでは、複数のWebサービスにまたがる定型作業を一つの流れとして組み立てます。最初に、シナリオの役割と自動化に適した業務を理解しましょう。

Makeのシナリオとは

シナリオとは、ある出来事をきっかけに、決められた処理を順番に実行する自動化の流れです。各サービスで実行する処理は、モジュールとしてシナリオ内に配置します。

たとえば、フォームに回答が届いた後、その内容を別のサービスへ登録して担当者へ通知する連携が考えられるでしょう。人がサービス間を移動して転記する代わりに、シナリオがデータを受け渡す仕組みです。

ただし、Makeに接続しただけで業務判断のすべてが自動化されるわけではありません。開始条件、渡すデータ、処理対象、失敗時の扱いを具体的に設定する必要があります。

自動化に向いている業務を見つける

候補にしやすいのは、同じ条件と手順で繰り返すデータ転記、登録、通知などです。発生頻度だけでなく、手作業による入力漏れや対応遅れが起きやすいかも確認してください。

一方、担当者が毎回内容を読み、状況に応じて複雑な判断を下す業務は、そのままではシナリオに落とし込みにくい場合があります。まずは機械的に判定できる範囲を切り出すのが現実的です。

最初の題材には、起点と完了条件を明確に説明できる小さな作業を選びましょう。対象を広げすぎない方が、テスト時に問題を切り分けやすくなります。

自動化する業務フローを設計する

Makeの設定前に、対象業務を「起点」「途中の処理」「実行結果」へ分解します。この設計が、後で追加するモジュールの順序と設定内容の土台になります。

処理を開始する起点を決める

起点では、どのサービスで何が起きたらシナリオを開始するのかを一文で表します。「新しいデータが登録されたとき」のように、出来事と対象を組み合わせてください。

あわせて、同じデータを繰り返し処理しないか、実行対象を見分けられるかも検討します。開始条件が曖昧だと、不要な実行や処理漏れにつながりかねません。

途中で必要な処理を洗い出す

起点から最終結果へ進む間に必要な作業を、実際の業務順に書き出します。データの取得、形式の変換、条件の判定、別サービスへの受け渡しなどを一つずつ分けるのが基本です。

この段階では、誰が何を見て判断しているかにも注目しましょう。判断基準を明文化できれば条件として設定でき、難しければ人による確認を残す選択ができます。

最終的に実行する内容を決める

最後に、シナリオが正常に終わったときの状態を定めます。単に「登録する」ではなく、どのサービスのどの情報が更新され、誰に何が通知されれば完了かまで具体化してください。

実行結果から逆算すると、途中で取得すべき項目も判明します。入力に必要なデータが起点で得られない場合は、追加の取得処理や業務フロー自体の見直しが必要です。

Makeでシナリオを新規作成する

業務フローを整理できたら、Makeで新しいシナリオを用意します。最初は起点となるモジュールを設定し、データを取得できる状態まで進めましょう。

新しいシナリオを作成する

Makeへログインし、シナリオを新規作成する操作から編集画面へ進みます。画面上の名称や配置は変更される可能性があるため、新規シナリオを作るための項目を確認してください。

編集を始める前に、先ほど書き出した業務フローを手元に置いておきます。業務フローを手元に置けば、必要なサービスと順序を迷わず選べるでしょう。

起点となるモジュールを追加する

最初のモジュールでは、シナリオを開始させるサービスと出来事を選びます。設計した起点と一致しているかを確かめ、必要に応じて監視対象や取得条件を指定しましょう。

似た名称の処理が複数ある場合は、データを取得する処理なのか、データを作成する処理なのかを区別します。最初に必要なのは、後続へ渡す元データを受け取れる設定です。

サービスへの接続状態を確認する

モジュールから外部サービスを利用するには、対象のアカウントとの接続や認証が必要です。表示される案内に沿って接続し、意図したアカウントが選択されているか確認します。

接続できない場合は、認証の有効性や利用権限を見直してください。組織で管理されたサービスでは、管理者側の許可が必要になることもあるため、推測で設定を進めないことが重要です。

モジュールをつないでデータを受け渡す

起点を設定した後は、業務フローの順番に後続モジュールを追加します。前段の出力を各処理の入力欄へ割り当てれば、サービス間のデータがつながるでしょう。

後続の処理モジュールを追加する

起点の次に行う処理を選び、対応するサービスとモジュールを追加します。変換や判定が必要なら、最終処理の前にそれらを配置してください。

一度に多くのモジュールを追加するより、一つ追加するたびに役割を確認する方法が安全です。どのモジュールが何を受け取り、何を出力するかを説明できる状態にしておきましょう。

前のモジュールのデータを割り当てる

後続モジュールの入力欄には、前の処理で取得した項目を対応付けます。たとえば、登録先が氏名と連絡先を要求するなら、元データに含まれる該当項目をそれぞれ割り当てる考え方です。

項目名が似ていても、データの意味や形式が同じとは限りません。日付、数値、選択肢などは、受け取り側が扱える形式になっているかを確かめてください。

入出力の対応関係を確認する

設定後は、各モジュールの入力項目と、その値を出す前段のモジュールを順に照合します。必須項目の空欄、異なる項目の割り当て、形式の不一致がないかを見ていきましょう。

確認しやすくするには、入力項目、参照元、期待する値をメモに整理する方法が有効です。後からモジュールを変更したときも、どの割り当てを直すべきか判断しやすくなります。

条件分岐で実行する処理を制御する

すべてのデータへ同じ処理を行わない場合は、判定条件と進行先を設計します。意図しない登録や通知を防ぐには、対象外データの扱いまで決めておきましょう。

条件に応じたデータの進行先
取得したデータはどの条件に当てはまるか
目的の条件を満たす
登録や通知など、目的の処理へ進める
別の条件を満たす
条件に対応した別経路へ送る
どの条件にも当てはまらない
処理を終了するか、確認用の経路へ送る

分岐が必要な条件を整理する

まず、処理を分けるために使う項目と判定基準を書き出します。担当区分、状態、入力内容など、取得データに含まれ、機械的に評価できる項目を選んでください。

条件は「対象かどうか」だけでなく、どの条件を満たしたらどの処理へ進むかまで対にします。複数条件が同時に成立する可能性があるなら、優先する経路も事前に決めておきましょう。

条件を設定して処理経路を分ける

設計した判定をシナリオへ反映し、条件を満たしたデータだけが目的の処理へ進むようにします。文字列の一致、数値の範囲、値の有無など、データの形式に合う判定方法を選ぶことが大切です。

設定後は、条件に合うデータと合わないデータの両方を用意して確認します。条件が広すぎる誤りを見逃さないよう、正常経路以外も確認しておきましょう。

条件から外れるデータの扱いを決める

条件から外れたデータは、その場で処理を終えるのか、別の経路へ送るのかを明確にします。対象外を放置せず、業務上の期待と一致する扱いを選んでください。

確認が必要なデータなら、人が後で確認できる場所へ記録する方法も考えられます。運用時の見落としを防ぐためにも、自動処理しないデータの行き先を決めておきましょう。

テスト実行してエラーを確認する

シナリオを運用する前に、想定したデータを使って全体を試します。停止した場合は、問題が現れたモジュールから原因を順番に切り分けましょう。

シナリオが途中で停止したときの切り分け
PROBLEM
テスト実行中にモジュールで処理が停止する
CAUSE
接続切れ、必須入力の不足、データ形式の不一致、条件設定の誤りなどが考えられる
FIX
停止したモジュールの入力を確認し、接続と設定を調べ、必要なら直前の出力へさかのぼる

テスト用データでシナリオを実行する

起点となるサービスに、実際の業務で扱う形式に近いテスト用データを用意します。そのうえでテスト実行を行い、モジュールが設計した順番で動くか確かめてください。

最初は条件に合う標準的なデータを使い、基本経路が最後まで通ることを確認します。次に空欄を含むデータや条件から外れるデータも試すと、想定外の動作を見つけやすくなります。

各モジュールの実行結果を確認する

テスト後は、最終結果だけでなく各モジュールの入力と出力を確認します。元データの値が保持されているか、変換後の形式が期待どおりかを順番に追いましょう。

通知が届いた、または登録が完了したという事実だけでは、すべての項目が正しいとは判断できません。処理先の内容も開き、欠落、重複、文字化け、誤った割り当てがないかを検証します。

エラー箇所を切り分けて修正する

エラーが出たら、まず停止したモジュールへ渡された入力を調べます。入力が正しければ、そのモジュールの接続状態、必須項目、設定条件を確認してください。

入力が誤っている場合は、直前のモジュールへさかのぼります。一つずつ確認を進めれば、複数の設定を同時に変更して原因が分からなくなる事態を避けやすいでしょう。

修正後は、問題が出たデータでもう一度テストし、後続処理まで正常に完了するかを確かめましょう。別のデータでも再確認すれば、特定の入力だけに依存した修正ではないかを判断できます。

シナリオを運用して定期的に見直す

テストに通ったシナリオは、業務に合うタイミングで実行できる状態にします。運用開始後も履歴と接続先の変更を確認し、放置しないことが重要です。

シナリオ運用後の確認ポイント
実行状態業務に合うタイミングで実行されているか確認する
実行履歴成功・失敗、対象データ、停止位置を確認する
処理結果期待した件数と内容が接続先へ反映されたか照合する
変更時業務手順、項目、条件、認証の変更後に再テストする

実行タイミングを設定して有効化する

業務上いつ処理する必要があるかを基準に、シナリオの実行方法やタイミングを決めます。即時性が必要なのか、一定の間隔でまとめて処理してよいのかを先に判断してください。

有効化する前には、接続先、対象データ、条件、最終処理をもう一度確認します。本番データを扱うため、誤った登録や通知が起きない状態を確かめてから運用へ移しましょう。

実行履歴とエラーを継続的に確認する

運用開始後は、シナリオが実行されたか、成功と失敗のどちらだったかを履歴で確認します。失敗があれば、対象データと停止位置を特定し、業務への影響を把握することが先決です。

エラーが出ていなくても、期待した件数や内容と一致しているかを定期的に見てください。条件設定のずれによる処理漏れは、明確なエラーとして現れない場合があります。

業務や接続先の変更に合わせて見直す

業務で扱う項目、判定基準、通知先が変わったときは、関連するモジュールと割り当てを見直します。接続先サービスの認証や仕様が変わった場合も、動作確認が必要です。

変更後は編集だけで終えず、影響する経路をテストしてください。設計時の業務フローも更新しておくと、後の修正で現在の設定と資料が食い違うのを防げます。

まとめ|Makeのシナリオは業務を分解して設定・テストしてから運用する

Makeで業務自動化するには、定型作業を起点、途中の処理、実行結果へ分け、設計どおりにモジュールとデータの割り当てを設定します。条件分岐では、対象外データの行き先まで決めることが重要です。

運用前には各モジュールの入出力をテストし、エラーを停止位置から切り分けてください。まずは転記や通知などの単純な作業を一つ選び、現在の流れを書き出すところから始めましょう。

>WordPress・AI・SEOの初心者向け情報を更新中!

WordPress・AI・SEOの初心者向け情報を更新中!

AI・WordPress・SEO初心者向けの記事を分かりやすく解説しています。人気記事もぜひご覧ください。

CTR IMG