目次
長く使われてきたCRMの設定を、あらためて棚卸しする機会がありました。担当者が入れ替わり、誰がいつ何のために作ったのか分からないワークフローが積み上がっている——中小企業では珍しくない状態です。
作業を始めてすぐに分かったのは、設定画面を眺めても現状は分からないということでした。一覧上は整然と並んでいて、有効・無効の区別もついている。それでも、実際の業務で何が起きているかは、この画面からは読み取れません。
この記事では、実案件（匿名）の棚卸しで見つかった誤認と、同じ失敗を避けるための確認手順を整理します。Zoho CRMを例にしていますが、考え方は他のCRM・SFAでも同じです。
この記事の結論
- 有効は「起動が許可されている」だけで、動いている証明ではない
- 稼働の判定は設定一覧ではなく実行履歴でしか行えない
- 休眠ルールは消えたのではなく、発火を待っている状態
最大の誤認：有効になっていれば動いている
棚卸しで最初に崩れた前提が、これでした。
ワークフローの一覧には、有効と無効の切り替えが並んでいます。有効になっているものを見れば「これが今動いている仕組みだ」と考えたくなりますが、これは誤りです。有効という状態が意味しているのは、条件が満たされたときに起動してよいという許可だけです。条件に合うレコードが一度も発生していなければ、そのルールは設定されてから一度も動いていません。
実際、有効になっていたルールのうち、直近の実行履歴に記録が残っていたのはごく一部でした。残りは、設定としては生きているのに、業務上は何もしていない状態だったのです。
ここを取り違えると、棚卸しの結論そのものがずれます。「有効なルールが多いから、この会社の自動化は進んでいる」という評価も、「有効なものは触ると危ないから残しておこう」という判断も、実態に基づいていません。
| 見ているもの | 分かること | 分からないこと |
|---|---|---|
| 設定一覧の有効/無効 | 起動が許可されているか | 実際に動いたかどうか |
| 実行履歴 | いつ、どのレコードで動いたか | 今後の発火条件 |
| ルールの条件定義 | どうなったら動くか | 現実にその条件が起きるか |
稼働状況を知りたいなら、見る場所は実行履歴です。設定画面は「設計図」であって「稼働記録」ではありません。
ワークフローが動かない原因は3つに分かれる
「ONなのに動いていない」と分かったあと、次に必要なのは原因の切り分けです。棚卸しで出てきたパターンは、大きく3つに整理できました。
- 条件に合うデータが発生していない：ルール自体は正常。かつての業務フローが前提で、その業務がすでに無くなっているケース。
- 条件が厳しすぎて合致しない：複数条件をすべて満たす設計になっていて、現実のデータでは成立しない。作った直後にテストしただけで放置されたパターン。
- 対象項目が使われなくなった：条件に指定した項目に、誰も入力しなくなっている。項目名は残っているので設定画面からは気づけない。
いずれも設定画面上は「正常に有効」です。だから履歴を見るまで発覚しません。
止まっていたルールが突然動き出すリスク
ここが、放置されたCRMで一番怖い部分です。
長く実行履歴のないルールを見ると、「もう死んでいる設定」と感じます。しかし実際には、死んでいるのではなく発火を待っているだけです。条件に合うレコードが一件でも入れば、その瞬間に動きます。
たとえば、数年前の商談ステージ名を条件にしたメール送信ルールが有効のまま残っていたとします。ふだんは何も起きませんが、誰かがそのステージ名を再利用した瞬間、意図しない相手に自動メールが飛びます。担当者は「そんな設定がある」ことすら知らないので、原因究明にも時間がかかります。
棚卸しの場では、休眠中のルールこそ意思決定が必要です。判断は次の3択に絞れます。
- 今後も使う → 残す。ただし発火条件を文書に残す
- 使わない → 無効化、または削除する
- 判断がつかない → 無効化して保留。有効のまま保留にしない
「よく分からないので有効のままにしておく」が、最も危険な選択です。
表示名とAPI名のズレが外部連携を壊す
もう一つ見つかったのが、画面上の表示名と、システム内部で使われるAPI名の食い違いです。
CRMの項目やルールには、人が見るための表示名と、外部システムから参照するためのAPI名があります。運用の中で表示名だけを変更していくと、この二つが次第にずれていきます。画面では「案件担当」と表示されているのに、API名は旧称のまま、といった状態です。
社内で画面を見て使う分には問題ありません。問題が出るのは、外部連携やスクリプトから項目を指定するときです。連携側は表示名を知りませんから、API名が分からないと処理が組めない。逆に、連携が動かないときに画面の表示名で探しても、該当する項目が見つからず、原因の切り分けに無駄な時間がかかります。
対策は単純で、棚卸しの際に表示名とAPI名の対応表を作っておくことです。項目を増やすたびに更新するルールにしておけば、連携の実装も障害対応も速くなります。なお、各サービスの仕様は変わるため、API名の扱いは最新の公式ドキュメントで確認してください。
レコード更新が別のルールを連鎖起動する
ワークフローの多くは、レコードの作成や更新をきっかけに動きます。そしてワークフローの処理内容にも、多くの場合「項目を更新する」が含まれます。
つまり、あるルールの実行結果が、別のルールの起動条件を満たしてしまう構造が生まれます。
意図して設計した連鎖なら問題ありません。怖いのは、別々の時期に別々の担当者が作ったルール同士が、たまたま連鎖している場合です。作った本人も連鎖に気づいていないので、「なぜかメールが二重に飛ぶ」「更新していない項目が変わっている」といった形で現れます。
棚卸しでは、各ルールの「起動条件」と「更新する項目」を並べて書き出し、更新する項目が他のルールの起動条件になっていないかを突き合わせます。この作業は手間ですが、一度作れば以後の改修が安全になります。
CRM設定の棚卸し手順
以上を踏まえた手順は、次の3ステップです。
- 実行履歴から見る：設定一覧ではなく履歴を起点にします。直近で実働しているルールを特定し、それ以外を休眠として仕分けます。まず「何が現実に動いているか」を確定させます。
- 休眠ルールを仕分ける：残す・止める・直すを、その場で決めます。保留にする場合も必ず無効化してから保留にします。有効のまま放置すると、いつか発火します。
- 連鎖とAPI名を確認：残すルールについて、起動条件と更新項目を一覧化し、連鎖の有無を確認します。あわせて表示名とAPI名の対応表を作り、外部連携から追える状態にします。
この順序なら、触ってはいけないものを先に見分けられます。逆に設定一覧から潰していくと、動いている大事なルールを止めてしまう事故が起きます。
よくある質問
Q. Zoho CRMのワークフローが有効なのに動かないのはなぜ？ 有効は起動が許可されている状態にすぎず、実行条件に合うレコードが発生しなければ一度も動きません。動いているかどうかは設定画面ではなく実行履歴でしか判定できません。
Q. 使っていないワークフローは削除すべき？ 止まっているように見えるルールも、条件を満たした瞬間に発火します。不要と判断したものは無効化または削除し、残す場合は発火条件を文書に残しておくのが安全です。
Q. CRMの設定棚卸しは何から始めればいい？ 設定一覧ではなく実行履歴から見ます。直近の履歴で実働しているルールを特定し、履歴が空のものを休眠として仕分けたうえで、残す・止める・直すを判断します。
まとめ
- 有効は起動の許可であって、稼働の証明ではない
- 稼働判定は実行履歴でしか行えない。設定一覧は設計図にすぎない
- 休眠ルールは消えたのではなく、条件が揃うのを待っている
- 表示名とAPI名のズレは、外部連携と障害対応のコストになる
- 棚卸しの順序は、履歴を見る → 休眠を仕分ける → 連鎖とAPI名を確認する
RENOYでは、長く運用してきたCRM・SFAの設定棚卸しから、自動化の再設計・外部連携までをご支援しています。「誰が作ったか分からない設定が残っていて、触るのが怖い」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。