ServiceNow全社導入で学んだ、「現場が使うシステム」の条件

システムを導入したのに使われない。これは、機能が足りなかったから起きるのではありません。むしろ機能は十分にあるのに、現場が旧来のやり方に戻ってしまう——このほうがずっとよくある失敗です。

この記事では、人事として16年、採用・評価・労務・組織設計に関わり、ServiceNow の全社導入をPMとして経験した立場から、「導入したのに使われないシステム」に共通する構造と、現場が実際に使うシステムの条件を、一般論として整理します。

「使われないシステム」の3つの構造

導入プロジェクトを最後まで走らせて分かったのは、使われない理由は感情論ではなく、たいてい設計に原因があるということです。代表的な3つを挙げます。

1. 申請が旧運用と二重化している

新しい申請フローを作っても、旧来のメールや紙、Excelの依頼書が併存し続けるケースです。現場からすると、システムに入力してもどうせ後から「念のためメールでも」と言われるなら、システムは仕事を減らさず増やす存在になります。

二重化は、たいてい「移行期間だから」という言い訳とともに始まり、そのまま定着します。旧運用を止める意思決定をセットで行わないと、新システムは「余計な一手間」として敬遠されます。

2. 入力項目が現場の語彙になっていない

システムの入力画面が、製品の標準用語や情報システム部門の都合で作られていると、現場は自分の業務と項目を頭の中で変換し続けることになります。

「申請区分」を選べと言われても、自分のやりたいことがどの区分に当たるのか分からない。選択肢が製品の内部概念のまま並んでいる。この摩擦が積み重なると、「分かる人に聞いてから入力する」となり、結局その「分かる人」に業務が集中して形骸化します。項目の言葉は、ベンダーの言葉を現場の言葉に翻訳するで書いたとおり、翻訳が効いているかどうかがそのまま使われやすさに出ます。

3. 例外処理が設計されていない

標準フローは綺麗に作られているのに、現実に頻発する例外——急ぎの差し戻し、承認者の不在、部署をまたぐイレギュラーな依頼——の逃げ道が用意されていないパターンです。

現場の仕事は例外の連続です。標準フローしか通れないシステムは、例外が起きるたびに止まり、そのたびに「システム外で処理する」抜け道が生まれます。一度抜け道ができると、人はそちらが楽なので、標準フローのほうが使われなくなります。

現場が使うシステムの条件

裏返すと、使われるシステムの条件が見えてきます。

旧運用を止めきる

新しい仕組みを入れることより、古い仕組みを止めることのほうが難しく、そして重要です。二重化を許すと、現場は必ず楽なほう・慣れたほうに流れます。止める対象と時期を、導入計画の中で明示的に決める必要があります。

現場の言葉で入力できる

入力画面に並ぶ言葉が、現場が普段使っている言葉であること。ここが揃っているだけで、教育コストも問い合わせも大きく減ります。裏側の設計は製品標準に寄せつつ、表に出る言葉は翻訳する。この分離が効きます。

例外に逃げ道がある

例外をゼロにはできないので、例外もシステムの中で扱えるように設計します。「急ぎ」「代理承認」「差し戻し」といった現実の運用を、抜け道ではなく正規のルートとして用意しておく。例外を排除するのではなく、例外を織り込むことが定着の分かれ目です。

入力の見返りがある

現場が入力した情報が、後で自分たちの役に立つ形で返ってくること。入力しっぱなしで何も返らないシステムは「やらされ仕事」になります。入力が進捗の可視化や次の判断につながると、入力する意味が生まれます。これは要員計画の運用でも同じで、計画が実行に接続されているかどうかが定着を左右します。詳しくは要員計画の「実行管理」とは何かで整理しています。

使われる設計は、導入前から始まっている

これらの条件に共通するのは、どれも「システムを選んだ後」ではなく「選ぶ前・設計する前」に効いてくるということです。旧運用を止める合意、現場の語彙の把握、例外の洗い出し——いずれも現場の業務を理解していないと設計できません。

高機能な製品を選ぶことより、自社の業務と運用をどこまで解像度高く把握できているかのほうが、使われるかどうかを決めます。導入の成否は、契約書にサインする前の準備でほぼ決まっているというのが、実務での実感です。

まとめ

• 使われないシステムは機能不足ではなく、申請の二重化・現場の語彙でない入力項目・例外処理の欠落という設計に原因がある
• 使われる条件は、旧運用を止めきる・現場の言葉で入力できる・例外に逃げ道がある・入力に見返りがある
• これらはすべて導入前・設計前の準備で決まり、自社業務の理解度がそのまま定着を左右する

私は現在、Capability起点の要員計画・実行管理SaaS（Sakigake Workforce）を複業で開発しています。システムを入れたのに使われない、という課題に心当たりがある方は、下の窓口からお気軽にご相談ください。「導入する側」を16年やった立場で、現場の言葉で一緒に整理します。