自動化の前に、意味を

隠れた入力

自動化プロジェクトは、たいていプロセスから始まるように見えます。データを集め、ルールを適用し、結果を送る。しかし実際には、プロセスの下に隠れた入力があります。それは組織の意味です。何を顧客と呼ぶのか。いつプロジェクトは完了するのか。どの情報源が正本なのか。誰が例外を認められるのか。

人は文脈、習慣、関係性によってこれらへ答えます。ソフトウェアは同じ不可視の層に頼れません。意味を暗黙のままにすると、自動化は曖昧さを取り除くのではなく、曖昧さをインフラに変えてしまいます。

手作業は遅いからこそ、人が矛盾に気づき、社会的に修復できることがあります。自動化されたプロセスは、前提が間違っていたと誰かが理解する前に、内部的には整合した誤りを何千件も生み出せる。組織が合意していない規則を、システムだけが忠実に実行するのです。

だから壊れたプロセスの自動化は、単に効果がないだけではありません。出力がソフトウェアらしい確信を帯びることで、壊れ方そのものを見えにくくします。

モデルやWorkflow Toolを選ぶ前に、組織は自分たちの概念を検査可能にすべきです。重要なEntity、その関係、意思決定のLifecycle、主張できるStatus、各遷移に必要なEvidenceを定義する。

完璧なEnterprise Ontologyは必要ありません。必要なのは、業務上の結果を持つ意味についての、小さく生きた合意です。良い定義は実際の判断に接続され、世界が変わったという証拠があれば更新できます。

意味、権限、証拠が明示されると、自動化はずっと単純になります。システムは、自分が何を知り、何をしてよく、どの証拠を残し、いつ人の前で止まるべきかを判断できる。WorkflowはIntegrationの寄せ集めではなく、組織の意図の表現になります。

意味は、システム完成後に付け足す文書ではありません。信頼できるシステムを構築可能にする基盤そのものです。仕組みより先に、意味を。