前エントリで、ノウハウ継承がうまくいかなかった話を書いた。その振り返りの中で、何度も行き当たるのは「現場に余裕がない」という問題である。
引き継ぎのドキュメントも、「オレだったらこうする」というモデル成果物も、読んで学ぶ時間がなければ意味を持たない。判断力を育てるためのケース問題も、日常タスクで手一杯の人には「今やらなくていいもの」になる。
つまり、引き継ぎの失敗は、それ単体の問題ではないだろう。その下には、現場がずっと手一杯で、何も改善できない構造がある。今回はそこを整理してみたい。
なお、本文で述べる改革側とは、有意の対象ではない。要は特定の誰かではない。あの部署の…この部署の…と仕事には色々ある訳だ。よって総体であると思ってほしい。
また、そもそも改善施策を行おうとする動きは良いことであるし、尽力者は評価されるべきだ。なぜならば、何もやらないを選択する保守的な風土では、前進しようという意志自体が称賛されるべきだからだ。というかそうなってほしいと思っている。
だから、これは嘲笑はとうぜん、意図してない。どちらかと言えば、自身の悩みに近い。施策導入で何が不幸を生み、どうすればいいものなのかということを書き留めたかったので、考えてみた。
何が起こりやすいのか
まず、現象を並べてみる。これは経験則的な事例である。
- 日常タスクだけで稼働がほぼ埋まっている
- 効率化の方法は潜在的にはあるが、それを実装する余裕がない
- 新しい提案が出ても、見る基準は「自分に飛び火しないか」「自分がすぐ理解できるか」になる
- 提案を読んで学ぶ時間が取れないので、理解に手間のかかるものほど弾かれる
- 結果として、方法は常に「現状踏襲」が選ばれる
一方で、改革が動くときは、たいてい改革側主導になる。ところがその中身は、
- 「それAIでできるでしょ」(ただし方法は抽象的で実証したことはない)
- 「他グループの管理簿を全部修正させればいい」(ただし誰がどう調整するかは考えられていない)
といった、実現性の検証がない方法論であることが多い。そして7割程度は、本人ではなく別の誰かが施策を実装する。そうして「さあ、便利になっただろう」と言って導入される施策は、現場にとってはほとんどの場合、手数を増やしただけの方法論になる。
私はずいぶんと提案はしたつもりだったが、「あなたは文句ばかり言って提案がない」と過去に実際に起きた事故の未然防止を機械化する、といった地に足のついた見解を出そうとしても、むしろ採用されにくいのが悩みだったと思う。
問題分析
1. 余裕がないから改善できず、改善しないから余裕が生まれない
一番根っこにあるのはこれだ。
効率化には、最初に時間の投資が必要になる。仕組みを作る時間、試す時間、覚える時間。ところが満稼働の現場には、その投資に回す時間がない。よって改善もされず、作業量は減らず、翌月もまた満稼働になる。
組織論ではこれに近い現象が「能力の罠」と呼ばれているようだ(AIが教えてくれた)。目の前の作業に追われて改善に時間を割けず、改善しないから作業が減らず、ますます改善できなくなる。
ここで大事なのは、このループは放っておいても自然には抜けられない。誰かが意図的に時間を作らない限り、構造的にずっと続く。
2. 改革が「仕事を増やすもの」として学習されている
現場が現状踏襲にこだわるのは、単に怠慢だからではない。
改革側主導の施策が「手数を増やすだけ」で終わるたびに、現場は「改革とは仕事が増えることだ」と学習する。すると、次にどんな提案が来ても、中身を見る前に身構える。私も、受け手としては、まあそうだ。
困るのは、本当に手数を減らす提案まで、同じ箱に入れられてしまうことである。実証に基づいた小さな自動化と、根拠のない大きな方法論。その違いを見分けるには中身を読む必要があるが、満稼働の現場にはその時間すらない。
3. それは成功したのか
施策がうまくいかない理由は、施策の中身だけではない。評価判定方法にも問題がある。
改革側にとってのゴールは、多くの場合「導入したこと」で止まる。ある仕組みを作るとする。その時点で便利にしたことにする。その後に現場で問題が改善されたとか、手数が本当に減ったかという経過観察は、誰も測っていない。
そして、増えた負担は改革側の視界に入らない場所に押し出される。
たとえば「他部署の管理簿を全部修正させればいい」という施策を行うとする。それは一行の指示だが、実際には次の作業が発生することは、概ね想像されない。
- 他グループへの修正依頼と、その背景説明
- 修正内容の調整と、認識のすり合わせ
- 修正漏れや誤りの確認
- 差し戻しと再確認
- 修正が終わるまでの間の、暫定運用
「AIを使って業務改善すれば、効率が変わる」とはよく言われたものだが、こういった風潮がある状態の環境では、非常に懸念がある。AIに限った話ではないが、新しい技術を導入すれば効率化できる、という期待だけで施策を始めると、出力の検証や手直しといった新しい作業が発生する。結果として、もともとの作業に新しい作業が上乗せされることになる。そうすると、とうぜん出力の検証や手直しという新しい作業が生まれ、最終的にはサンクコストで導入されるが、実際は廃れる。
つまり、コストは消えたのではなく、どこかに移っていることには気付く必要がある。
4. 現場は「増えた」と言わない
「あなた達の業務改善をしてあげるからやりなさい」「さあ、便利になっただろう」と言われた場で、「むしろ手数が増えました」と返すのは難しい。言えば「使いこなせていない」と受け取られかねない。保身に寄ってる風土だと、最も取りにくい選択肢である。
なので現場は波風を立てたくないので、黙って、増えた手数を黙々と吸収する。
そうすると、施策は表向き「問題ない」らしいと評価される。反論が出ないので、改革者の自信はむしろ強化され、次も同じような方法論が出る。
改革側の中では改善が進んでいるように見えて、現場では悪化している。 まるで帳簿が二つあるような状態で、しかもお互いに相手の帳簿は見えていない。
5. 詰めることが、余裕のなさを固定する
ここに、前回書いた「なぜ引き継ぎができていないのか」と上から詰められる構造が重なる。
問題が起きると詰められる。詰められた現場は保身に寄り、判断を上に投げ、確認待ちが増え、作業は遅れる。遅れると、さらに余裕がなくなる。
結局、問題は「現場の努力不足」として扱われるので、本当の原因である工数の見積もり方や施策の立て方には、誰も手をつけない訳だ。
6. 運用は先回りが評価されにくい
基本的に、システムは「何も起きないこと」が運用成果である。先回りして事故を防いだ人の働きは、目に見えにくい。一方で、何かが起きたときの失敗は目立つ。
この非対称性があるので、改善や未然防止に時間を使う人ほど報われにくく、目の前の作業を黙ってこなす人の方が安全になる。これも、現場が改善に向かわない理由の一つだと思う。
全体像
- 現場が満稼働で、改善に投資する時間がない。技術学習もしない
- 改善が動くときは主に管理側がメインの改革者主導になり、地に足つかずの実証の薄い方法論を選択する
- 施策は「導入したこと」で成功とされ、増えた手数は現場に押し出される
- 現場は「増えた」と言わず、黙って吸収する
- 余裕がさらに削られ、「改革とは仕事が増えること」と学習する
- 実証のある提案まで弾かれ、現状踏襲が選ばれる
- 問題が起きると詰められ、現場はさらに保身に寄る
- 作業は減らず、1に戻る
方向性
ということで、方向性としての持論を述べたい。
原則:改善は「手数が減ったか」で判定すべき
というかやはり本来こうだと思う。
施策の成功を「導入したこと」ではなく、「手数」で判定する。この一点が変わるだけで、根拠のない方法論は自然と淘汰され、実証のある小さな改善こそ評価されるべきであるという私なりの結論を得た。
1. 手数を見える化する
主要な定常作業について、次のようなものを記録するデータは必要である。
| 作業 | 月あたりの回数 | 1回あたりの時間 | 確認・差し戻しの回数 | 備考 |
|---|---|---|---|---|
| X | 1 | 3時間 | 2回 | 前工程の遅れで待ちが発生しがち |
| Y | 4 | 1時間 | 3回 | 手作業での目視確認 |
| Z | 10 | 30分 | 1回 | 記載ルールの確認に時間がかかる |
施策の前後でこれを比べれば、手数が減ったのか増えたのかが、角を立てずに事実として示せるので、そういったデータを表現として持ちたいものだ。
問題は、それ自体が面倒なことである。とにかくみんな計測をしないし、「工数表」を複数の別の関係者が複数作成し、それぞれに記載してくれというオーダーはよく見た。これは地獄である。そこの自動化すら必要なのだろう。
2. 小さく、実証のあるところから始める
やはり、私は大きな方法論ではなく、過去に実際に起きたことから始めるべきだと思っている。
- 過去に起きた事故やヒヤリハットのうち、確認漏れが原因だったものを洗い出す
- その確認を、手作業から機械的なチェックに置き換える
- 置き換えた結果、確認時間とミスがどれだけ減ったかを記録する
「過去にここで間違えた」という実例があるものには、どんなに小さくショボく見えるものでも効果に根拠がある。そして、使い出しは批判が出るだろうが、どうせ2, 3人が動かせば結果が出てしまうので、使う人に理解を求めない。
「AIでこうすればできる」との違いは、根拠が過去の実例にあるか、未来の期待にあるかである。
3. 読ませない、覚えさせない、完成品で渡す
満稼働の現場に、新しい仕組みを理解してもらう余裕はない。よって、改善は理解を求めない形で強引に渡すしかないだろう。
- 説明を読まなくても、使えばすぐ楽になる状態で渡す
- 「何が減るか」を一行で示す(例:「毎月の突合作業が1時間から10分になる」)
- 使い方は最小限にし、既存の作業の流れを大きく変えない
飛び火を警戒する人にも、「自分の仕事が減る」話は届きやすい。
4. 余裕は「作る」しかない
能力の罠は、放っておいても抜けられない。余裕は意図的に作る必要がある。
一つは、やめる作業を決めることである。定常作業を棚卸しすると、目的が分からなくなったまま続いている作業や、誰も見ていない報告が見つかることがある。それをやめるだけで、改善に回せる時間が生まれる。ぶっちゃけ、私は、異動をトリガーにあらゆる会議や問題介入を捨てた瞬間、そこそこコミットの時間がある。「ああ、こんなに時間あったのか」と驚かされている。
もう一つは、改善の時間を枠として確保することである。たとえば週に1〜2時間でも、改善のための時間をあらかじめ予定に入れておく。空いた時間にやろうとすると、その時間は永遠に来ない。Googleの20%ルールは、実は驚くほど理にかなっていることが今更把握できた。
どちらも、現場の判断だけでは決められないので、管理者の合意が必要になる調整が必要になることが課題だろう。よい生産性には、とうぜんスペックに少し余裕を設けるに良いに越したことはないことは多くの人が理解しているはずであるが、経営観点では最低限あれば大丈夫でしょ、という結論になりがちである。異動だの退職だの、そういったイベント以外の方法で、常勤のメンバがそうできる組織環境が望ましいと、認識を改めないとキツい。
やらないこと
方向性と同じくらい、やらないことを決めておくのも大事だと思う。
- 実証のない大きな方法論から始めない
- 他のグループや現場に、見えない形で作業を押し出さない
- 「導入したこと」を成功と呼ばない
- 現場が「増えた」と言えない空気のまま、施策を進めない
自分の立ち位置でできること
正直に言うと、施策の立て方や、組織の評価の仕組みまでは、自分の手の届く範囲ではない。自分が価値を生む行為としてできるのは、せいぜい次のあたりだ。
- 手数を見える化する材料を残す
- 過去の実例に基づいた、小さな仕組みを完成品として残す
- 問題を「現場の努力不足」ではなく「構造」として言語化し、上に伝える
全部を変えようとすると、もはや何も出来ない。とはいえ、こういったことの推進力が出来る政治力を身につけると、相当仕事できるマンになるだろう。そうした人を目指したいものである。
手一杯の現場は、正直そこに怠けや学習意欲がないことはYesだろう。が、それより先に余裕がないから改善できず、改善しようとすると仕事が増え、増えたと言えないまま次の施策が来る。その構造の中で、誰もが自分の立場では合理的に動いている。
なので、改善の物差しを「導入したか」から「手数が減ったか」に変えること。そして、余裕は自然には生まれないので、意図的に作ること。ということが良い指針にあると結論する。