AIによって、業務アプリや自動化の仕組みを作る時間は短くなりました。以前なら数週間かかった試作品を、数日で動かせる場面も増えています。
しかし、作れることと、現場で使われることは別です。新しい入力画面を用意しても、従来のExcelやメールが残る。自動化しても、担当者が念のため手作業で再確認する。管理者が利用を指示しても、忙しくなると元の方法へ戻る。このような状況は、機能を追加するだけでは解決しません。
システム導入の難所は、技術から人間の行動へ移っています。この記事では、現場が変化を受け入れない理由を心理学・行動経済学の考え方から整理し、「どう説得するか」ではなく「どう設計すれば自分から使うようになるか」を考えます。
現場の抵抗は、非合理とは限らない
新しいシステムが使われないと、「変化を嫌う人がいる」「ITに苦手意識がある」と説明されがちです。しかし、現場側から見ると、使わない方が合理的な場合があります。
たとえば、会社全体では月20時間を削減できるシステムでも、入力担当者だけは項目が増えるかもしれません。経営者は早く数字を見られるようになりますが、現場担当者には確認依頼が増える可能性があります。導入後に問題が起きたとき、責任の所在が不明確なら、慣れたExcelも残しておきたいと考えるのは自然です。
また、「属人化をなくす」という説明も注意が必要です。その業務を長く担当してきた人にとって、例外を判断できることや、周囲から頼られることが自分の専門性になっている場合があります。作業をなくす提案が、本人には「自分の価値をなくす提案」と聞こえることがあります。
したがって、抵抗を本人の性格だけで説明してはいけません。少なくとも次の4つに分けて確認します。
| 抵抗の背景 | 現場から見た状況 | 導入側が確認すること |
|---|---|---|
| 直接のメリットがない | 会社は得をするが、自分の仕事は増える | 利用者本人の作業は何分減るか |
| 専門性や立場を失う | 自分が不要になるように感じる | 新しい運用で本人の役割をどう残すか |
| 失敗時の責任が不明 | 新システムの間違いを自分が負う | 承認、取消、履歴、戻し先があるか |
| 実行する余裕がない | 通常業務を続けながら移行できない | 二重運用の期間と支援時間を確保できるか |
なぜ現状のやり方が選ばれ続けるのか
現状維持は「何もしない選択」ではない
行動経済学では、現在の状態を基準にした選択肢が選ばれやすい傾向を現状維持バイアスと呼びます。SamuelsonとZeckhauserは、選択肢に現状が含まれると、その選択が増えることを実験や実際のデータから検討しました。Status quo bias in decision making
業務システムの場合、従来の方法にはすでに学習コストを支払っています。操作を覚え、例外時の対応を知り、誰に聞けばよいかも分かっています。一方、新しい方法には次の不確実性があります。
- 覚える時間がどれくらい必要か
- 本当に以前より速くなるか
- 例外が起きたときに処理できるか
- 間違えた場合に元へ戻せるか
- 導入した仕組みが半年後も使われているか
つまり現状維持には、「慣れている」という感情だけでなく、移行コストと不確実性を避ける意味があります。新しい仕組みの最終的な効果だけを説明しても、導入直後の負担が解消されなければ行動は変わりません。
使いやすさより先に「自分に役立つか」が見られる
情報システムの受容を説明するTechnology Acceptance Modelでは、「役に立つと感じること」と「容易に使えると感じること」が重要な要因として扱われています。Davisの研究では、知覚された有用性は、知覚された使いやすさより利用との強い関連を示しました。Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology
これは、画面を分かりやすくすれば必ず使われるわけではないことを示唆します。操作が簡単でも、自分の仕事が楽になると感じなければ利用は続きません。
「会社全体の生産性が上がる」では遠すぎます。利用者ごとに、次のような直接的な便益へ翻訳する必要があります。
- 入力担当者：同じ内容を二度入力しなくてよい
- 確認担当者：不備がある行だけを見ればよい
- 経理担当者：数字から元の申請や明細へすぐ戻れる
- 現場責任者：進捗確認の問い合わせに答えなくてよい
- 管理者：担当者が休んでも処理状況を確認できる
自分で決められない仕組みは、自分の仕事になりにくい
自己決定理論では、自律性、有能感、関係性という心理的欲求が、主体的な動機や自己調整を支えると整理されています。Self-Determination Theory and the Facilitation of Intrinsic Motivation
システム導入に置き換えると、完成品を突然渡して「明日から使ってください」と指示する方法は、自律性と有能感の両方を損ないやすくなります。何を変えるか決められず、使い方にも自信がない状態だからです。
反対に、現場担当者が例外条件や表示項目の決定に関わり、小さな改善を自分で提案できれば、仕組みは外部から押し付けられたものではなくなります。ただし、会議へ参加してもらうだけでは不十分です。意見が実際の仕様や運用へ反映される必要があります。
属人業務には心理的な所有感が生まれる
心理的所有感は、法的な所有とは別に、対象を「自分のもの」と感じる状態を指します。組織における心理的所有感の理論では、対象へのコントロール、深い理解、自己投資などが所有感につながる経路として整理されています。Toward a Theory of Psychological Ownership in Organizations
長年育ててきたExcel、本人だけが知る確認手順、取引先ごとの例外対応には、相当な自己投資があります。それを「古いから廃止する」と扱えば、作業だけでなく本人の蓄積まで否定されたように感じられます。
必要なのは、属人性をそのまま温存することでも、知識を吸い上げて本人を外すことでもありません。本人の価値を次のように移します。
以前：自分だけが作業できる
↓
移行中：自分が判断基準と例外を定義する
↓
移行後：自分が運用ルールと改善を管理する
作業者としての価値を、判断基準を設計し、他の人が再現できる状態を作る価値へ変える考え方です。
心理を踏まえた業務改善の7ステップ
1. 機能ではなく、変えたい行動を決める
「申請システムを作る」ではなく、導入後に誰がどう行動するかを定義します。
- 現場担当者が、作業終了時に実績を登録する
- 上長が、不備のある申請だけを確認する
- 経理担当者が、金額差のある取引だけを調べる
- 担当者自身が、軽微なルール変更を反映する
画面や機能は、行動を支える手段です。対象行動が曖昧なままでは、システムは完成しても業務は変わりません。
2. 現在の担当者が守っている価値を調べる
業務手順だけでなく、その人が何によって評価され、何を失いたくないと感じているかを確認します。
- 周囲から何を頼られているか
- どの例外を判断できるか
- 間違いを防ぐために何を確認しているか
- 新しい仕組みで不安なことは何か
- 最も面倒だと感じている作業は何か
ここでは「なぜ非効率な方法を続けるのか」と聞くより、「このやり方だから防げている問題は何か」と聞く方が、現在の方法が持つ価値を把握できます。
3. 会社のメリットより先に、本人のメリットを作る
最初の機能は、経営者が欲しい集計画面ではなく、利用者本人の負担を減らすものから選びます。
たとえば、会社が欲しいのは月次レポートでも、現場担当者の最初の便益は入力候補の自動表示かもしれません。経理が欲しいのは自動仕訳でも、営業担当者の便益は請求状況への問い合わせが減ることかもしれません。
本人が最初の利用で効果を感じられるまでの時間を「初回価値到達時間」として短くします。全体最適を完成させてから使ってもらうのではなく、小さな個人メリットを先に出します。
4. 既存業務の中に新しい行動を置く
新しいシステムのためだけに、別の時間や別の入力を要求すると定着しにくくなります。作業完了、承認、請求など、すでに存在するきっかけに新しい行動を結び付けます。
たとえば、「毎日17時に新システムへ転記する」より、「作業完了ボタンを押すと報告と請求候補が同時に残る」方が、新しい習慣を追加せずに済みます。
バックオフィスだけで入力を増やすのではなく、現場の業務が進む過程で必要な記録が残るようにします。これはバックオフィス効率化の進め方でも扱っている、入口から会計までを一続きにする考え方です。
5. 小さく並行運用し、差異を見せる
いきなり旧手順を止めると、問題があったときに現場が戻れません。一方で、並行運用を無期限に続けると二重作業が固定化します。
対象を1拠点、1取引種別、1か月分などに限定し、新旧の結果を照合します。APIが成功したかではなく、件数、金額、例外、元資料への参照が一致するかを確認します。
試用する
→ 新旧の結果を比較する
→ 差異の原因を直す
→ 新しい運用を正本にする
→ 旧運用を参照専用にする
→ 廃止する
旧手順の廃止日まで決めることが重要です。
6. 現場から出た改善案を実際に反映する
利用者が使い始めると、「この項目も表示したい」「この場合だけ別にしたい」といった要望が出てきます。これは要件漏れだけでなく、利用者が仕組みを自分の仕事として考え始めた兆候でもあります。
ただし、すべての要望を機能化する必要はありません。要望を次の3つに分けます。
- 作業を減らすために必要
- 間違いや責任リスクを減らすために必要
- 特定の人の好みであり、全体には不要
採用しない場合も理由を返します。意見を聞くだけで何も変わらなければ、参加は形式的なものになります。
7. 操作ではなく、改善判断を引き継ぐ
マニュアルを渡すだけでは、作った人への依存が残ります。引き継ぐべきなのは、操作手順に加えて次の内容です。
- なぜこの項目が必要か
- どのデータを正本とするか
- 例外時に誰が判断するか
- 変更してよい部分と、確認が必要な部分
- 改善要望をどう評価するか
- システムが止まったときの戻し方
目標は、外部の製作者に質問しなくても、社内で小さな改善を判断できる状態です。
