だからログを取り始めた
改善に取り組んでいると、
必ず最後にやってくる作業がある。
振り返りだ。
改善は「やっている最中」より「まとめる時」がつらい
改善活動を進めている最中は、
正直そこまで困っていない。
目の前の課題があり、
やるべきことがあり、
判断を重ねていくだけだ。
つらいのは、その後である。
- いつ、何をやったのか
- どこで詰まったのか
- どの判断が効いたのか
これをあとから思い出して整理する段階になると、
一気に大変になる。
記憶をたどり、
メールや資料を探し、
日付を推測する。
この作業は、
改善そのものよりもしんどいと感じることが多い。
まとめ直しが大変なのは、記録していないからだ
考えてみれば、理由は単純だった。
改善の途中では、
- 記録を取っていない
- 取っていたとしても、断片的
- 最終的な成果だけが残る
だから振り返りの段階で、
もう一度「物語」を作り直すことになる。
その結果、
- 実際よりも単純な流れになる
- 詰まりや揺れが消える
- 判断の経緯が抜け落ちる
改善が「きれいな成功談」になってしまう。
だから、Formsでログを取ればいいのではと思った
ここで浮かんだのが、
改善の途中を、そのまま残すという発想だった。
難しいことはしない。
- いつ
- どんなことが起きたか
これだけを、
Formsで淡々と入力する。
Excelにまとめるわけでもなく、
文章を整えるわけでもない。
あとで使う前提のログとして残す。
それなら、
振り返りのために再構成する必要がなくなる。
ログにすれば、あとから「分析」もできるかもしれない
もう一つ、気になっていたことがある。
改善が進みにくい理由は、
対象の業務そのものではなく、
改善活動の進め方にあるのではないか、という疑問だ。
たとえば、
- どの工程で時間がかかっているのか
- どのタイミングで止まりやすいのか
- 判断が遅れるのはどこか
これらは、
成果だけを見ていても分からない。
しかし、
改善のログが時系列で残っていれば、
改善活動そのものを観察できる。
ログを分析することで、
- 改善が止まりやすいポイント
- 想定以上に時間を要している工程
- 繰り返し発生している詰まり
そういった「改善の本質」が
見えてくるかもしれない。
あくまで、今は仮説だ。
まだ、うまくいくかは分からない
正直に言えば、
- この方法が正しいか
- 他の現場でも通用するか
は、まだ分からない。
分析の仕方も、
指標も、
これから考える段階だ。
今やっているのは、
「改善ログを取り始めた」という事実だけである。
記録として、ここに残しておく
それでも、
改善を振り返るたびに感じていた
あの「まとめ直しのしんどさ」からは、
確実に一歩離れられそうだと感じている。
改善を、
- 記憶に頼らず
- 成果だけにせず
- 時間の流れとして残す
そのための試みとして、
この改善ログを続けてみる。
今日はその動機と考えを、
記録としてここに残しておく。
コメント