Validation Rulesでユーザー体験を犠牲にした私の判断ミス

当時の私は、新しいSalesforce環境を構築したばかりで、とにかく「ビジネス要件を正確にシステムに落とし込むこと」に注力していました。特に、データ品質を高めることには並々ならぬ情熱を燃やしていたと記憶しています。その情熱が、思わぬ落とし穴を生んだわけですが。

商談の「契約交渉中」フェーズで承認者名と契約開始日を必須にした件

忘れもしない、とある新規導入プロジェクトでの出来事です。営業部門から「商談が『契約交渉中』のフェーズに進んだら、必ず承認者名（カスタム参照項目）と契約開始日（日付項目）を入力してほしい」という明確な要件がありました。もちろん、これはデータガバナンスの観点からも非常に重要な要件です。

当時の私は、これを純粋に「validation rulesの出番だ！」と判断しました。よし、これだ。完璧に制御できる、と。

AND(
    ISPICKVAL(StageName, "契約交渉中"),
    OR(
        ISBLANK(Approver__c),
        ISBLANK(Contract_Start_Date__c)
    )
)

上記のようなシンプルなルールを組み、エラーメッセージには「『契約交渉中』フェーズでは、承認者名と契約開始日の入力が必須です。」と設定しました。これはこれで、一見すると適切に見えますよね。当時の私もそう思っていました。

ユーザーの悲鳴と、私の「やらかし」

ところが、展開後すぐにユーザーからの問い合わせが殺到しました。一番多かったのは、「まだ承認者が決まってないのに、フェーズを進められない！」という悲鳴です。営業担当者は、社内会議で承認者を検討したり、顧客と契約開始日を調整したりする過程で、仮で「契約交渉中」フェーズに進めて、他の関連情報を入力したいというニーズがあったのです。

当時の私は「いや、要件は『契約交渉中になったら必須』だから、必須でしょ？」としか思っていませんでした。ユーザーは、「まずは仮保存して、他の情報を入力したり上長に相談したりしたい」という意図があったのに、validation ruleがそれを完全にブロックしてしまったのです。

さらに、こんな声もありました。「エラーメッセージは出るけど、どこを直せばいいのか分かりにくい」「『承認者名』と『契約開始日』どっちも空白だと、2回エラーメッセージが出るのかと思って混乱する」といったものです。確かに、私の設定したエラーメッセージは、どの項目が具体的に問題なのかを指し示していませんでした。

今なら別の選択をする：一時保存の許容とフェーズの定義見直し

今なら、この要件に対してはvalidation ruleを適用する前に、もっと深くヒアリングし、別の手段を検討するでしょう。

• 一時保存の許容: 必須項目の徹底も重要ですが、ユーザーが情報を整理・検討する過程で、一度「仮保存」できる柔軟性も必要でした。例えば、特定のユーザープロファイルや、レコードタイプによってはこのルールを適用しないといった除外条件を設ける、あるいは、より後工程のフェーズ（例: 「契約書作成済み」）に移行するタイミングで厳格にチェックするなど、段階的なアプローチを考えます。
• フェーズ定義の見直し: そもそも「契約交渉中」フェーズの定義自体が、ビジネスプロセスとシステム要件の間でズレていたのかもしれません。このフェーズに移行する前に、承認者名や契約開始日が決定しているのが理想形であれば、その前段階でプロセスを再設計すべきでした。あるいは、Salesforceのフロー機能を使って、承認者決定後に自動でフェーズを進める、といった設計も検討できたはずです。
• エラーメッセージの改善: 当時は短く簡潔なのが良いと思っていたのですが、具体的にどの項目を指しているのか、もう少し丁寧に伝えるべきでした。例えば、「承認者名が未入力です。『契約交渉中』フェーズでは必須となります。」のように、エラーの原因となる項目名を明記するだけでも、ユーザーの混乱は軽減されたはずです。

当時の私は、Validation Ruleは「絶対にデータを間違えさせないための最終防壁」と捉えすぎていました。しかし、ユーザーの業務フローを阻害してしまっては本末転倒です。この経験は、単なるデータ品質の確保だけでなく、ユーザー体験（UX）を考慮したシステム設計の重要性を痛感する、大きなきっかけとなりました。

これは当時の自分向けのメモだ。