結論から書くと、この実験は失敗した。
駐車場の残り台数を無線で知らせるタイミングを決めれば、確認の往復を減らせると考えた。しかし実際に見えてきた問題は、台数を数える方法ではなかった。報告するかどうかが人の判断に依存し、提案した側には新しいルールを導入する権限がなかった。
仕組みの案は作れた。それでも現場には入れられなかった。今回は、その理由を誰かへの批判ではなく、現場改善の失敗記録として残す。
1. この実験について
| 実験ID | EXP-002 |
|---|---|
| 状態 | 実験失敗 |
| 試したテーマ | 駐車場の残り台数を報告する基準のルール化 |
| 成功条件 | 誰が担当しても同じタイミングで報告できる |
| 失敗条件 | 必要性が共有されず、人ごとの判断による運用が続く |
| 今回の判定 | 失敗 |
施設名、個人名、正確な規模など、現場を特定できる情報は記載しない。記録するのは、改善案を導入できなかった構造である。
2. 現場で困っていたこと
駐車場の利用が増える時間帯には、残り何台入れるのかを確認し、必要に応じて無線で共有する。問題は、報告のタイミングが明文化されていなかったことだった。
ある人は早い段階から残り台数を知りたがる。別の人は満車に近づくまで報告を求めない。担当者も、何台になったら連絡すべきかを自分で判断する。そのため、同じ状況でも報告回数とタイミングが変わる。
最初は「台数をもっと正確に確認すればよい」と考えた。しかし振り返ると、本当の困りごとは確認精度ではない。報告ルールが人の判断に依存していたことだった。
3. 最初に考えた仮説
報告する残り台数を決めれば、無線連絡を減らしながら、必要な情報を同じタイミングで共有できるのではないかと考えた。
仮説は単純だった。
- 残り台数の基準を決める
- 基準に達した時だけ報告する
- 誰が担当しても同じ動きにする
- 基準外の確認連絡を減らす
数字で基準を作れば、経験の差を小さくできるように見えた。
4. AIと一緒に考えた改善案
AIと整理し、次の三段階で報告する案を考えた。
- 残り20台になった時点で、混雑が進んでいることを報告する
- 残り10台になった時点で、満車対応の準備が必要なことを報告する
- 満車になった時点で、受け入れ方法の変更を報告する
この案なら、「今は報告するべきか」を担当者が毎回考える必要がない。受け取る側も、報告された数字から次の準備を判断できる。
ただし、数字は現場に合わせて調整する必要がある。20台と10台が正解という意味ではない。重要なのは、判断の節目を共有する考え方だった。
5. 実際に見えてきた問題
案を考えるところまでは進んだが、実施段階で別の問題が見えてきた。
現場では、報告を必要と考える人と、現在のやり方で困っていない人がいる。長く担当している人は、経験から混雑の進み方を判断できる。その人にとっては、新しい数字の基準を追加する必要性が低い。
一方、経験が少ない人や別の位置で働く人にとっては、判断基準が見えない。ここに認識の差があった。
つまり、「ルールがない」という事実だけでは、ルールを作る理由として十分ではなかった。現在の運用を担っている人が困っていなければ、変更の必要性は共有されにくい。
6. なぜ導入できなかったのか
提案者に導入権限がなかった
現場で気づいた人が、必ずしも運用を変更できるとは限らない。下の立場から案を出すことはできても、全員が守るルールとして決定する権限はなかった。
経験者の判断が既存の仕組みになっていた
明文化された基準がなくても、その場を回している人の経験によって仕事は動いていた。その判断は属人的だが、現場では実績のある方法でもある。外から数字のルールを入れると、経験を否定されたように受け取られる可能性もある。
変更する利益を共有できなかった
無線が何回減るのか、聞き直しがどれだけ減るのかを測る前に、導入が止まった。現在の方法を変える負担に対して、改善効果を具体的に示せなかった。
仕組み案の内容だけを考え、導入する人、承認する人、影響を受ける人を実験設計に入れていなかった。
7. 今回の判定：失敗
今回の判定は失敗とする。
報告基準の案を作ったこと自体は成果だが、成功条件は「案ができること」ではない。現場で共有され、誰が担当しても同じタイミングで報告できることだった。
実際には導入されず、人ごとの判断による運用が続いた。したがって成功条件は満たしていない。
失敗の原因は、20台、10台という数字が間違っていたことではない。導入権限と現場慣習を確認せず、手順だけを設計したことにある。
8. 今回分かったこと
小さな仕組みでも、正しい案を作れば導入できるとは限らない。
- 誰が運用変更を決められるのか
- 現在の判断を誰が担っているのか
- その人は何に困っているのか
- 変更する利益を数字で示せるか
- 試験運用を許可できる人は誰か
これらを確認しないまま手順を作ると、使われない仕組みになる。
AIはルール案、チェックリスト、報告文を短時間で作れる。しかし、AIが現場の権限を与えることはできない。人間関係、慣習、経験への敬意、決定権の所在は、技術とは別に扱う必要がある。
AI時代でも、改善を止める大きな要因はツール不足ではなく、「誰が決めるのか」「なぜ変えるのか」が共有されていないことかもしれない。
9. 次に同じような現場で試すなら
次回は、ルール案を作る前に導入条件を確認する。
- 困っている人を確認する
- 運用を決められる人を確認する
- 現在の方法で困っていない理由を聞く
- 一日または一時間だけの試験運用を提案する
- 無線回数、聞き直し回数、報告漏れを比較する
- 結果を見て、正式導入するか戻すかを決める
最初から全員のルールを変えようとせず、限定した時間と担当者で試す方が導入しやすい。
また、成功条件にも「権限者の合意を得る」を追加する。手順が完成しただけでは成功にしない。
研究結果
今回の研究結果は、現場改善では仕組みの内容より先に、導入権限と現在の慣習を確認する必要があるということだった。
報告ルールを数字にすれば属人化を減らせる可能性はある。しかし、その場を回している人が必要性を感じず、提案者に決定権がなければ、仕組みは実験段階にも入れない。
これは改善案を実施できなかった失敗である。同時に、次の仕組み作りで最初に確認すべき条件が分かった失敗でもある。小さな仕組みの作り方では、成功例だけでなく、導入できなかった理由も改善資産として残していく。
更新履歴
- 2026-06-16 初版公開
- 2026-06-22 ライトチェックで更新履歴を追加
コメント