不満は出る。でも、それだけで終わる場合がほとんどだ
「また同じトラブルが起きた」。
会議でそう言われた翌週、同じ手順ミスが繰り返された。誰もが「おかしい」と感じている。でも3ヶ月後、その不満は誰の口からも出なくなった。慣れたのではない。諦めたのだ。
私がいた現場でも、同じことが何度も起きた。不満はあった。でも、不満を言う人と、仕組みに変える人の間には、明確な差があった。その差は「能力」でも「経験年数」でもなかった。「最初の一歩の置き方」だった。
よくある失敗パターン
「意識を上げよう」で終わらせる。
「もっと丁寧に確認してほしい」「次から気をつけよう」。気持ちはわかる。でもこれは仕組みに変えたのではなく、個人に負担を移しただけだ。翌月には同じことが起きる。
不満が感情のまま止まる。
「なんでこんな手間がかかるんだ」「毎回この作業は無駄だ」。この段階で止まる人は多い。感情は正しい。でも「何が、どこで、何回起きているのか」に変換できていない。問題が見えないまま、解決策を探しても動けない。
改善を大きく考えすぎる。
「ここを直すなら、全体の工程を見直す必要がある」。こうなると、何もできなくなる。改善は小さく始めていい。全体を変えなくても、今週ひとつだけ変えられることは必ずある。
なぜ不満が仕組みに変わらないのか
個人の努力不足ではない。
問題は「不満を問題に変換するステップ」が現場に存在しないことだ。学校でも研修でも、「不満をどう仕組みに変えるか」は教えない。だから現場に入った人は、感情を持ちながらも、それを構造に落とす言語を持っていない。
加えて、現場では「問題を見つけた人が責任を持って解決する」空気が生まれやすい。それが怖くて、不満を口にできない人も出てくる。改善しようとした人が損をする構造になっている。
これは個人の問題ではなく、組織設計の問題だ。
放置するとどうなるか
同じ失敗が繰り返される。それだけではない。
現場に「どうせ変わらない」という空気が広がる。改善提案が出なくなる。ベテランが退職したとき、その人の経験とともに、改善の種も消える。
引き継ぎが雑になる。新人は同じ場所で詰まる。そのたびに誰かが対応に時間を取られ、残業が常態化しても、原因を疑う目が失われていく。
顧客対応でも同じことが起きる。「うちはいつもこうです」が通用しない場面で初めて問題が可視化される。そのときには、すでに対応コストが大きくなっている。
属人化が進んでいる現場では、仕組みより先に「誰かが抜けたとき何が起きるか」を整理する必要がある場合もある。[医療機器保守の一人依存リスク](/medical-device-maintenance-solo-dependency-risk/)はその入口として参考になる。
仕組みに変える人の考え方の違い
仕組みに変える人は、不満を「観察可能な事実」に変換している。
「なんで毎回間違えるんだ」を「この手順の第3ステップで、月に2〜3回同じミスが起きている」に変える。この変換ができると、解決策が見えてくる。「第3ステップにチェック項目を1行追加する」「その項目だけ別の人が確認する」。小さな変更で、問題の発生頻度が変わる。
仕組みとは、ツールや制度だけではない。「誰が、何を、いつ、どの順番で確認するか」が決まっている状態のことだ。それが文書でも、ホワイトボードでも、付箋でも、機能すればいい。
修理品質のばらつきがどこから来るかを掘り下げたい場合は、[現場の修理品質がバラつく本当の原因](/maintenance-quality-variation-customer-request-risk/)も合わせて確認してほしい。
改善を始めるための判断基準
まだ手作業でいい場合がある。月に1〜2回しか起きない、担当者が固定されている、手順が安定しているときは、無理に仕組み化しなくていい。
テンプレートで十分な場合もある。同じ作業が繰り返されている、新人と経験者で結果がバラつく、引き継ぎで抜け漏れが出るなら、まずテンプレートから始める。
ツール導入を考えるのは、担当者が変わるたびに品質が変わる、記録の所在がわからなくなる、複数拠点で同じ基準を保てていないときだ。
判断は「今、どこで一番コストが発生しているか」で決める。全部を一気に変えようとしない。
今日できる改善手順
Step 1：不満を事実に変換する
「〜が面倒だ」を「〜が、〜という状況で、週に何回起きている」に書き直す。これだけで、問題の輪郭が見えてくる。紙1枚に書くだけでいい。10分でできる。
Step 2：最も小さい変更を探す
「何を1つだけ変えたら、この問題が半分になるか」を考える。チェックリストの1行追加でも、確認タイミングの変更でも、担当の振り分けでも構わない。「全部直す」ではなく「1点だけ変える」に絞る。
Step 3：1週間だけ試す
完璧な仕組みを作ろうとしない。1週間だけ試して、うまくいかなければ変える。その繰り返しが、気がつくと現場の標準になっている。
残業が常態化している現場では、その原因が属人化にある場合も多い。[メンテナンスの属人化と残業の関係](/maintenance-personalization-overtime-cause/)は、構造を整理するうえで参考にしてほしい。また脱属人化の考え方については[こちら](/medical-device-maintenance-depersonalization/)でも整理している。
よくある質問
そんな時間がない、と感じたらどうするか
「時間がない」は本当のことが多い。でも時間がないまま放置すると、同じトラブル対応で時間を消費し続ける。Step 1の「事実に変換する」作業は10分でできる。まずそれだけでいい。仕組み化はその後でいい。
上司や管理職が変える気がない場合は？
自分の担当範囲の中だけで試すのがいい。承認が必要な大きな変更ではなく、「自分の作業手順を少し変える」レベルから始める。成果が見えてから話すほうが、提案は通りやすくなる。
何から手をつければいいかわからない
「最近いちばん疲れたトラブル」を1つ思い出す。それが起きたとき、何が足りなかったか。チェックリストか、連絡手順か、確認のタイミングか。その1点を変えることが最初の一歩になる。
小さな不満はすべて仕組み化が必要か
必要はない。「月に1回以下」「影響範囲が自分だけ」なら、手作業で十分な場合も多い。仕組み化は目的ではなく、繰り返しの手間と品質のばらつきを減らす手段だ。目的と手段を混同しないことが大切だ。
ツール紹介
現場の不満を仕組みに変える第一歩は、記録と可視化だ。何が、どこで、何回起きているかを整理するだけで、解決の方向が見えてくる。
記録・可視化ツール
点検・保守の記録を一元管理できるツールを使うと、繰り返し発生している問題が自然と浮かび上がる。NotionやGoogleスプレッドシートでも構わない。チェックリスト機能や記録の蓄積がしやすい専用ツールを使うと、Step 1の「事実に変換する」作業が楽になる。まず今の現場で何を記録しているかを棚卸しするところから始めるといい。
プロセス標準化ツール
作業手順の標準化には、テンプレートや手順書の共有ツールが役立つ。Google WorkspaceやMicrosoft 365の共有ドキュメントでも始められる。大切なのはツールの機能より「誰もが同じ手順を見られる状態を作ること」だ。現場に合う形で最小限から始める。それが、仕組みの起点になる。
コメント