システムを入れた。データも入っている。それなのに、担当者の携帯は前と同じ回数だけ鳴る。「この案件、どうしましょう」という確認の電話が減っていない。

導入がうまくいかなかったときの典型的な風景である。そしてこのとき、多くの場合ツールの選定は間違っていない。移すべきものを移していないだけだ。

ツールが移すのは、作業と記録

業務をひとまとまりで見ると混乱するので、3つの層に分けて考えたい。

層中身ツールで移せるか
作業入力する、転記する、集計する、印刷する移せる
記録どこに、どんな形で残っているか移せる
判断例外か通常か、誰に確認するか、いつ止めるかそのままでは移らない

ツールを入れると、上の2つは確実に動く。手書きが画面になり、Excel がデータベースになる。ここは目に見えて変わるので、導入した実感も出る。

だが判断は担当者の中に残ったままになる。残ったままなので、判断が必要な場面では結局その人に確認が行く。電話が減らないのは、そのためである。

業務が変わったかどうかは、作業がどこへ移ったかではなく、判断がどこで行われているかで決まる。 画面がきれいになっても、決めている人と決め方が同じなら、業務は変わっていない。

判断が移らない理由は、書けないから

なぜ判断だけ移らないのか。意図的に隠されているわけではない。判断の基準が言葉になっていないため、システムに書きようがないからだ。

現場でよく見かける形は、こういうものである。

  • この取引先は数量がぶれるので、月末は在庫を多めに見る
  • この商品は指定の温度帯を外すと再検品になるため、積み込みの順番を変える
  • この担当者からの電話依頼は、後で書面が来ない前提で控えを残す

どれも判断だが、本人の中では「当たり前すぎて説明するほどのことではない」と処理されている。だから要件定義の場で「他に決めごとはありますか」と聞いても出てこない。出てくるのは、本人が「これは説明が要る」と自覚している部分だけである。

同じ構造は、手順書が更新されなくなる現象にも表れる（引き継ぎ資料が半年で読まれなくなる理由）。言語化されていない判断は、文書にもシステムにも移らない。 置き場所を変えても、移るのは作業と記録だけになる。

「何を作らないか」を先に決めた例

当社が公開している事例に、精肉卸のお客様の在庫・原価管理がある（導入事例）。

この現場では、同じ部位でも1塊ごとに重量が違う不定貫（重量が固定されていない商品の扱い）という条件があり、一頭・セット仕入の原価按分がベテランの勘に依存していた。ここで受注から請求まで全部を作り直そうとすると、判断の塊にまとめてぶつかることになる。

実際に行ったのは逆で、受注・売上・請求は既存の販売管理システムのまま残し、在庫と原価だけを画面化した。そして実装の前に画面と流れを一緒に確認し、「何を作らないか」も先に合意している。

範囲を絞ったから小さく終わった、という話ではない。判断が集中している領域と、そうでない領域を分けたから、移せるものだけを先に移せたという順番の話である。結果として、手書き・二重入力・勘に頼る原価計算が、誰でも同じ操作で回せる形に置き換わった。

変わったかどうかは、例外の量で測る

導入の効果を測るとき、ログイン数や登録件数を見ることが多い。だがこれらは「作業が移ったか」しか教えてくれない。判断が移ったかを知りたいなら、見るべき数字は別にある。

見る数字分かること
例外として処理した件数設計に入っていない判断がどれだけ残っているか
特定の担当者への確認回数判断がまだ個人に集中しているか
システム外（電話・口頭・付箋）で決まった件数業務がシステムを迂回しているか
差し戻し・やり直しの件数判断基準が共有されていないか

例外が減らないシステムは、まだ業務を変えていない。 逆に、例外の中身が「毎回違う理由」から「同じ3パターン」に収束してきたら、それは判断が言葉になり始めた合図で、次に自動化すべき範囲がそこに見えている。

導入前に確かめる4つの問い

機能一覧を比較する前に、次の4つを現場に当てて確かめておくと、判断の所在がはっきりする。

  1. 直近1か月で、通常と違う扱いをした案件はいくつあったか。 数えると、例外は例外でないことが分かる場合が多い
  2. その判断を、誰が、何を根拠に決めたか。 根拠が「経験」としか言えないなら、そこはまだシステムに書けない
  3. その人が3日休んだら、誰がどう決めるか。 答えが「止まる」なら、判断はまだ1人に集中している
  4. 決めた結果は、どこに残っているか。 どこにも残っていないなら、同じ判断が毎回ゼロから行われている

4つとも、ツールを選ぶ前に答えられる。そして答えられない項目こそが、導入後に「変わらなかった」と感じる原因になる。

当社が Chizel で対話による発見という形を取っているのも、この構造に対応するためである。白紙の要件定義書を渡して埋めてもらうのではなく、問いを重ねて判断の理由を引き出し、そのやり取り自体を記録として残す。

明日からの一歩

今動いている業務を1つ選び、直近1か月で「例外」として扱った案件を数えてみてほしい。件数だけでよい。

その数が想像より多ければ、次に入れるべきものは新しいツールではなく、例外を例外でなくす判断基準のほうである。数が少なければ、その業務は移せる可能性が高い。どちらに転んでも、機能一覧を眺めているより早く答えが出る。