半年前に自分で組んだのシナリオを開いたとき、本当に何もわからなかった。
「Google Sheets / Search Rows」が4つ並んでいて、どれが何のデータを取ってきているのか。「HTTP / Make a request」が3つあって、それぞれどのAPIを叩いているのか。フィルターが2つ入っているが、何の条件でフィルタリングしているのか。
47モジュールのシナリオを1時間かけて読み解いて、修正箇所を特定した。修正自体は10分で終わった。読み解きに1時間かかった。
この記事でわかること：
- 保守できないシナリオの共通パターン
- 設計をやり直した具体的な変更点（命名・分割・コメント）
- やり直してみた感想（良かった点・まだ課題な点）
半年後に自分のシナリオが読めなかった話
何が起きたか
クライアント案件で、Gmail受信→データ整形→スプレッドシート転記→Slack通知、という処理を自動化していた。最初に組んだのが半年前。ワークフロー自体は問題なく動いていたので、ほぼ触ることがなかった。
で、仕様変更があって「転記先のスプレッドシートを変えたい」という話になった。ちょっと修正すればいいだけの話なのに、シナリオを開いたら全然わからなかった。
なぜ読めなくなったのか
後から分析すると、理由はシンプルだった。
「組んだ時点の自分しかわからない情報」がシナリオに含まれていた。モジュールの名前はデフォルトのまま（「Google Sheets / Search Rows」「HTTP / Make a request」）。何のためにそのフィルターを入れたのかを示すメモがない。なぜそのシナリオ構成になったかの経緯がどこにも残っていない。
半年前の自分は「組んだばかりだから全部わかっている」という状態だった。でも半年後の自分は、もはや他人と同じだった。
保守できないシナリオの共通パターン
同じ経験をした人の声をコミュニティで見てみると、「保守できない」シナリオにはいくつか共通するパターンがある。
1. モジュール名がデフォルトのまま
「Google Sheets / Search Rows」「HTTP / Make a request」のように、何をしているかが名前からわからない状態。モジュールが増えれば増えるほど読み解くのが辛くなる。
2. 1つのシナリオに機能を詰め込みすぎ
「受信・整形・転記・通知」を全部1シナリオでやっている。どの部分で何が起きているかの境界が消える。
3. コメントがゼロ
「なぜこの処理を入れたか」「このフィルターはどんな例外対処か」が記録されていない。
4. 条件分岐の根拠がない
フィルターや条件分岐が入っているが、なぜその条件にしたかがわからない。
設計をやり直した話：モジュール命名から変えた
やり直すのに丸1日かかった。設計方針を考えながら実装も変えていったので思ったより時間がかかった。変えたこと3つを書く。
命名ルールを決めた
まず、モジュール名に「機能プレフィックス＋内容」という形式を使うようにした。
GS-受信メール取得：Googleスプレッドシートからメールデータを取ってくるモジュールSL-エラー通知：Slackにエラー通知を送るモジュールHTTP-送り先API：外部APIにリクエストを送るモジュール
プレフィックスはサービスの略称（GS=Google Sheets、SL=Slack、HTTP=HTTPリクエスト）にした。これで一覧を見ただけで「どのサービスを使っているモジュールか」がわかる。
日本語で名前をつけることにした
英語でやっていた部分も日本語に変えた。Makeは日本語のモジュール名を設定できる。最初は「日本語でいいのか」という感覚があったが、実際に使ってみると格段に読みやすい。
英語でも短くて明快な名前がつけられる人は英語でいい。ただ、日本語の方が即座に意味がわかるなら日本語にする方が合理的だと思っている。
シナリオの粒度を変えた：1シナリオ1役割
「受信・整形・転記・通知」を全部1シナリオでやっていたのを、分割した。
- シナリオA：メール受信・データ整形
- シナリオB：スプレッドシート転記
- シナリオC：完了通知
シナリオAの完了をシナリオBのトリガーにして繋げるように構成を変えた。
分割した後は、修正が格段に楽になった。「転記先を変えたい」ならシナリオBだけ修正すればいい。シナリオAやCには触らなくていい。
1シナリオあたりのモジュール数は「最大20個」を目安にしている。それ以上になったら分割のサインだと思っている。ただこれは感覚値で、処理の種類によって適切な数は変わる。
メモ・コメント機能を使うようにした
Makeにはモジュールにメモを追加できる機能がある。右クリックで「Add note」を選ぶと、そのモジュールに付箋みたいなメモが追加できる。
この機能を、フィルターや条件分岐のモジュールに必ず使うようにした。MakeのNote機能やRename機能の具体的な使い方はeasy-wandの解説記事で確認できる。「なぜこの条件を入れたか」を30〜50字で書いておく。
例：
– 受信メールの件名が空の場合はスキップ（空件名は古いデータの可能性があるため）
– 転記先URLが変わった場合は処理を止めて通知する（2023年10月の仕様変更対応）
この一行があるだけで、半年後の自分が「なんでここにフィルターが入ってるんだろう」と悩む時間がなくなる。
やり直してみて正直どうか
設計をやり直してから3ヶ月が経った。正直に言う。
「読みやすくなった」は本当だ。先週、別のシナリオを修正したとき、迷わず修正箇所を特定できた。以前なら1時間かかっていたものが15分で終わった。
ただ、全部解決したわけではない。
命名ルールは決めたが、毎回「このモジュール名、これでいいか」と考えてしまう。迷うのは「粒度が細かすぎる名前」vs「大雑把すぎる名前」の境界で、まだルールが固まり切っていない。
あと、分割したシナリオを繋ぐ設計が増えると、「シナリオAがどのシナリオを呼んでいるか」の管理が別で必要になる。メモをどこかに残しておかないと、今度はシナリオ間の関係が見えなくなる。
設計の問題は解決したけど、今度は管理の問題が出てきた、という感じ。ノーコードツールはこのあたりが難しい。コードなら構造をgitで管理できるが、Makeのシナリオはそれができない。Makeのシナリオ設計全般についてはこまろぐの記事も参考になる。
まとめ
Makeのシナリオは「動けばいい」ではなく、「3ヶ月後の自分が修正できるか」まで考えて設計する方が、長期的に楽になる。
最初から全部やるのは大変なので、最低限やっておいてほしいのはモジュールの命名だ。デフォルト名のままにしておくのが一番後悔する。命名だけで、可読性は劇的に変わる。
シナリオ分割やコメントは、シナリオが複雑になってきてから導入する形でいい。ただ、導入するなら早めに越したことはない。後から直すのは、僕みたいに丸1日かかる。
合わせて読みたい
– Make（旧Integromat）の使い方：日本語で解説する初回シナリオ作成ガイド
– Makeのエラー自動復旧を組んでみた：Resume/Breakの実装手順まとめ
コメント