新しいシステムを使い始めると、現場から「ここも自動化したい」「この場合だけ表示を変えたい」といった意見が出ることがあります。この状態は、外部の製作者が要件を考え続ける状態とは異なります。利用者が仕組みを自分の仕事として捉え、改善対象を発見し始めているからです。
一方、要望箱を作っても何も集まらない、集まった要望が放置される、すべて実装してシステムが複雑になるといった失敗もあります。
この記事では、現場から改善提案が出て、社内で判断し、小さな変更を継続できる運用の作り方を解説します。
改善提案がないことは、満足を意味しない
意見が出ない理由には、次のものがあります。
- 問題を言うと自分の仕事が増える
- 使い方が悪いと言われそう
- 上司や製作者の判断を否定することになる
- 以前も伝えたが何も変わらなかった
- どこまで変更できるか分からない
- 困っていても元のExcelで回避できる
- 要望を整理して説明する時間がない
沈黙は、問題がない証拠ではありません。提案するコストが、期待できる効果より高い状態かもしれません。
心理的安全性だけでなく、反映可能性が必要
心理的安全性は、対人関係上のリスクを取っても安全だというチーム内の共有認識として整理されています。Edmondsonによる51チームの研究では、心理的安全性は学習行動と関連していました。Psychological Safety and Learning Behavior in Work Teams
システム改善では、間違い、不明点、不満、例外を報告しても責められないことが必要です。ただし、心理的安全性があれば自動的に提案が増えるわけではありません。
現場は次も見ています。
- 言った内容が誰に届くか
- いつ判断されるか
- 採用されない場合に理由が返るか
- 自分たちで変更できる範囲があるか
- 変更によって本当に仕事が楽になったか
「言っても変わらない」という経験が続けば、提案は止まります。
不満・不具合・改善提案を分ける
すべてを「要望」として受け取ると整理できません。
| 種類 |
例 |
対応 |
| 不具合 |
保存できない、数字が誤っている |
優先して修正し、影響範囲を確認 |
| 運用上の不明点 |
誰が承認するか分からない |
ルール・権限・説明を修正 |
| 回避行動 |
Excelへ出して手修正している |
システムが満たしていない役割を調査 |
| 改善提案 |
不一致だけ表示したい |
効果と影響を評価して判断 |
| 個人の好み |
ボタンの色を変えたい |
共通性と優先度を確認 |
回避行動は特に重要です。本人は提案していなくても、画面外のExcelやチャットが改善箇所を示しています。
改善が回る5段階
1. 利用中の行動を観察する
「困っていることはありますか」と聞くだけでは、本人が慣れてしまった不便は出てきません。実際の業務を一緒に見ます。
- 同じ情報を二度入力していないか
- 画面から別の資料を探していないか
- 全件を手計算で確認していないか
- 口頭やチャットで補足していないか
- システム外へ出して加工していないか
2. その場で短く記録できるようにする
長い改善提案書を求めません。最低限、次の4項目で受け付けます。
- どの作業で起きたか
- 何に困ったか
- 現在どう回避しているか
- どうなると助かるか
解決策まで現場に考えてもらう必要はありません。
3. 判断日と判断者を決める
要望は毎週または隔週で確認します。緊急性、頻度、影響人数、事故防止、削減時間、他業務への影響で判断します。
| 判断 |
現場へ返す内容 |
| 採用 |
いつ、どこまで変更するか |
| 試す |
対象者と期間、確認する指標 |
| 保留 |
何が分かれば再判断するか |
| 見送り |
理由と代替手段 |
4. 小さく変更し、同じ人に使ってもらう
要望を出した本人が、変更後に業務を完了できるか確認します。作った側のテストだけでは、問題が解消したか分かりません。
5. 結果を共有する
「対応しました」だけでなく、転記が何回減ったか、確認時間がどう変わったか、別の部署に影響がなかったかを共有します。提案と結果がつながると、次の改善案を出す意味が生まれます。
参加させれば所有感が生まれる、とは限らない
利用者が作る過程に関わることには価値がありますが、形式的な参加は逆効果です。意見を聞いても結果が決まっている、採否の理由が返らない、失敗した試作を本人の責任にすると、参加コストだけが残ります。
自己決定理論では、自律性や有能感などが主体的な動機を支えるとされています。Self-Determination Theory and the Facilitation of Intrinsic Motivation
現場参加では、少なくとも次を明確にします。
- 本人が決められること
- 他部署との調整が必要なこと
- 法令や会計上変更できないこと
- 試して戻せること
- 最終判断者と判断日
改善会議を30分で回す
長い定例会議は続きません。対象業務を一つに絞り、次の順番で確認します。
- 前回変更した内容は使われたか
- 旧手順や回避行動は残っているか
- 新しい例外は何件あったか
- 次に試す変更を一つ決める
- 判断者と確認日を決める
機能の要望一覧ではなく、業務上の問題と結果を管理します。
改善提案を評価する基準
声が大きい人の要望だけを採用しないよう、共通基準を置きます。
- 発生頻度
- 1回あたりの時間
- 影響する人数
- 金額や事故への影響
- 差し戻し・問い合わせへの影響
- 他部署の負担
- 運用変更だけで解決できるか
- 将来の修正コスト
AIで簡単に作れる機能でも、維持、権限、データ、例外への影響があります。「作れるから作る」ではなく、業務全体の効果で判断します。
自走状態を測る指標
改善案の数だけを追うと、細かな要望が増える可能性があります。次を組み合わせます。
- 回避行動が見つかり、記録された件数
- 提案への回答までの日数
- 試した改善の利用率
- 旧手順の残存率
- 改善後の時間・差し戻し・問い合わせの変化
- 社内担当者が自分で変更した件数
- 外部製作者への質問なしで解決した例外の割合
最終目標は、要望が多いことではありません。現場が問題を見つけ、社内で優先順位を判断し、必要な変更を実施できることです。
まとめ
現場から改善提案が出ないとき、アイデア不足とは限りません。言うと仕事が増える、否定される、反映されない、変更範囲が分からないという経験が沈黙を作ります。
改善提案を増やすには、受付口よりも、その後の判断と返答を設計します。実際の回避行動を観察し、短く記録し、判断日を決め、小さく試し、結果を本人へ返します。
システムが使われ始めるまでの設計はシステム導入が現場で使われない理由、利用者本人の便益から始める方法は業務改善で現場メリットをどう作るかで解説しています。シクミAIでは、実際の運用で使われるまで改善し、判断基準と変更方法を社内へ引き継ぎます。
