『ザ・クリスタルボール』は、在庫管理だけの本ではありません。水漏れ事故によって従来のルールを守れなくなった店舗が、そこから新しい仕組みを発見していく物語です。本記事では、うまくいった例外対応をその場限りで終わらせず、「次の標準候補」として成果とリスクの両面から検証する考え方を仕事へつなげます。
みなさんこんにちは！サラリーマンの大樹です！
仕事をしていると、普段のやり方を変えざるを得ない瞬間があります。
「今回は時間がないから、いつもの手順を減らそう」
「急ぎだから、普段とは違う進め方にしよう」
「人が足りないから、やることを絞ろう」
そんなときです。
面白いのは、その“例外対応”が意外とうまくいくことがあることです。
問題も起きない。
仕事も速く進む。
成果にも大きな影響がない。
それなのに状況が落ち着くと、
「じゃあ、いつものやり方に戻そう」
となる。
僕はここに、仕事を改善する大きなヒントがあると思っています。
もちろん、
「うまくいったならルールなんて全部なくしてしまえばいい」
という話ではありません。
むしろ逆です。
僕の今の仕事では、独断で物事を進めることはかなり危険です。
普段とは違うやり方で進めて、結果的に問題が起きなかったこともあります。
ただ、そのときに僕が考えるのは、
「問題が起きなかったこと」と、「安全なやり方だったこと」は同じなのか。
ということです。
もし問題が起きたら影響が大きい。
しかも、そのリスクを十分にヘッジできていない。
そう判断したときは、僕は元の方法へ戻します。
一方で、僕は仕事では常にスピードと成果を重視しています。
もっと速く、もっと成果につながるやり方があるなら変える。
必要なら周囲へ提言して、やり方そのものを変える。
だから、
「元に戻すか、変えるか」
は意外と難しい判断です。
このことを考えるきっかけになったのが、エリヤフ・ゴールドラットの『ザ・クリスタルボール』でした。
表面的には、在庫管理の本です。
でも僕には、
「普段なら疑わないルールを、どうやって次の標準へ変えるか」
という本にも見えました。
この記事で伝えたいことは一つです。
うまくいった例外対応は、元に戻す前に「次の標準候補」として検証する。
良い例外は捨てない。
ただし、検証せず標準にも変えない。
これが今回、一番伝えたいことです。
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/2e9b9f95.816cbab3.2e9b9f96.332eb183/?me_id=1273418&item_id=13691284&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fvaboo%2Fcabinet%2Fitems%2Fbk0154%2Fim250305039025.jpg%3F_ex%3D128x128&s=128x128&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
「元に戻す」が、いちばん安全だと思っていないか
トラブルが起きたら、元の状態へ戻す。
これは自然な考え方です。
システムが止まったら復旧させる。
予定が崩れたら組み直す。
人が足りなくなったら元の体制へ戻す。
僕たちは無意識に、
「通常運転へ戻ること＝問題解決」
と考えています。
もちろん、復旧が必要な場面はあります。
ただ、一つだけ考えてみてほしいことがあります。
その“通常運転”は、本当に最適だったのでしょうか。
例えば、時間がなくて会議を一つ減らした。
でも、特に困らなかった。
普段より簡単な資料で進めた。
でも、必要な議論はできた。
人が足りず、いくつかの業務を一時的に止めた。
でも、成果への影響は小さかった。
それでも状況が戻れば、また全部復活する。
なぜか。
一つは、
「今までそうしてきたから」
です。
長く続いているやり方ほど、必要性を疑いにくくなります。
会議には理由がある。
承認には理由がある。
資料には理由がある。
もちろん、本当に必要なものもあります。
でも、
長く存在していることと、今も必要であることは同じではありません。
むしろ仕事の中で厄介なのは、
「明らかに無駄な仕事」
よりも、
誰も疑わなくなった仕事
ではないでしょうか。
無駄だと分かっているなら、まだ改善できます。
怖いのは、
「これは普通だから」
という理由で、そもそも検証されなくなることです。
『ザ・クリスタルボール』では、事故が「当たり前」を壊した
『ザ・クリスタルボール』の物語は、きれいな改善計画から始まりません。
きっかけは、水漏れ事故です。
主人公ポールが働く店舗では、地下倉庫が使えなくなります。
それまでのように大量の商品を置いておくことができなくなる。
結果として、従来より少ない在庫で営業せざるを得なくなります。
普通に考えれば不安です。
在庫が少ない。
商品が足りなくなるかもしれない。
欠品が増えるかもしれない。
売上が落ちるかもしれない。
だから本来なら、
「早く元の在庫量へ戻したい」
と考えるはずです。
ところが、実際には予想していたような悪化が起きません。
むしろ、思いがけない成果が見えてきます。
ここで僕が面白いと思ったのは、
「在庫を減らせば儲かる」
という表面的な話ではありません。
もっと前です。
もし水漏れ事故がなかったら、彼らは今までの在庫ルールを疑っただろうか。
ここです。
「欠品を避けるには、多く在庫を持つ必要がある」
「店舗には、これくらいの商品を置いておくべきだ」
それまで当たり前だったルールです。
普通に営業している限り、その前提を外すのは怖い。
もし外して売上が落ちたらどうするのか。
だから、試さない。
ところが事故によって、
試すかどうかを選べなくなった。
普段のルールを守れなくなったから、別の方法で運営するしかない。
そこで初めて、
「本当にこの在庫量は必要だったのか」
を現実の結果で確かめられるようになります。
僕には、この水漏れ事故が、
普段なら外せないルールを強制的に外す装置
のように見えました。
危機そのものが価値なのではありません。
危機によって、
今まで検証できなかった前提が、検証できる状態になった。
そこが重要です。
仕事でも、似たことがあります。
時間がない。
人が足りない。
予定が崩れる。
急な変更が入る。
すると僕たちは、普段のやり方を守れなくなる。
そのときに生まれた例外対応を、
「今回は特別だった」
だけで終わらせるのか。
それとも、
「なぜこれでも回ったんだろう」
と考えるのか。
ここで改善の深さが変わると思います。
例外が成功しても、すぐ正解にはならない
ただし、『ザ・クリスタルボール』は、
「在庫を減らしてみたらうまくいった。だから全部減らそう」
という話ではありません。
そこが大事です。
ポールたちは、結果を見ます。
品切れと売上の関係を見る。
利益率を見る。
補充の仕組みを見る。
商品が売れてから、次の商品が届くまでの時間を見る。
需要予測への依存も考える。
つまり、
「うまくいった」という結果だけではなく、「なぜうまくいったのか」を調べていく。
ここで初めて、偶然と仕組みを分けられます。
例えば、在庫を減らしたこと自体が成功理由なのではなく、
売れた商品を短いサイクルで補充できるようにする。
需要の変化を見ながら在庫の持ち方を調整する。
店舗単位ではなく、チェーン全体で在庫の位置を考える。
そうやって、
少ない在庫でも欠品を抑えられる仕組み
へ変えていく。
本書で扱われるDBMも、重要なのは名前ではありません。
一度決めた数字を守り続けるのではなく、現実の変化を見ながら必要な在庫を調整する。
つまり、
現実を固定された計画に合わせるのではなく、仕組みの方を現実に合わせていく。
さらに重要なのは、その考え方が一店舗だけの偶然として終わらないことです。
成果が出た。
理由を調べた。
再現できる仕組みにした。
そして、店舗からチェーン全体へと考え方を広げていく。
ここまで行って初めて、
例外対応が“新しい標準”になる。
僕はここが、仕事に持ち帰るうえで一番大切だと思いました。
例外対応で成果が出た瞬間は、
改善が完成した瞬間ではありません。
改善候補が見つかった瞬間です。
「問題が起きなかった」と「安全だった」は同じではない
ここは、僕自身の仕事でもかなり意識している部分です。
僕はスピードを重視します。
成果につながるなら、やり方も変えます。
今までの方法にこだわる必要はないと思っています。
一方で、今の業界では独断で物事を進めることはかなり危険です。
普段とは違うやり方で進めても、結果として何も問題が起きなかったことはあります。
その場だけ見れば、
「これでいいじゃん」
と思える。
確かに速い。
大きな問題も起きていない。
だったら次からも同じ方法で進めればいい。
そう考えることもできます。
でも、僕はそこで、
「もし問題が起きていたら、どうなっていたか」
を考えます。
今回問題が起きなかったのは、
本当に安全な方法だったからなのか。
それとも、
たまたまリスクが表面化しなかっただけなのか。
ここは全く違います。
僕自身、結果として問題なく終わっても、リスクヘッジが十分ではないと判断した方法については元へ戻しました。
その方法で成果は出た。
スピードも出た。
その場では大きな問題もなかった。
それでも、
「次もこのままでいい」とは判断しなかった。
問題が起きたときの影響を考えると、無視できないリスクが残っていたからです。
僕にとって重要だったのは、
「一度うまくいったか」
ではありません。
同じやり方を繰り返しても、本当に大丈夫か。
そこでした。
だから元に戻した。
でも、それは
「新しいやり方は失敗だった」
という意味ではありません。
むしろ逆です。
その例外対応によって、
何を減らせば速くなるのか。
どこにリスクが残るのか。
何を残せば安全性を担保できるのか。
考える材料が増えた。
つまり、
例外対応を検証した結果、「今回はそのまま残さない」と判断した。
それでいいと思っています。
例外対応を検証するというのは、
何でも新しい方法へ変えることではありません。
残すものと、戻すものを分けることです。
ここを間違えると、
「スピード重視」
が、
「チェックを飛ばす」
「勝手に進める」
「結果が出ればいい」
へ変わってしまう。
それは改善ではありません。
僕が仕事で重視しているのは、
ただ速くすることではありません。
成果につながる速度を上げることです。
そのためには、成果だけでなくリスクを見る必要があります。
うまくいった例外は、「次の標準候補」として残す
では、例外対応がうまくいったとき、何を見ればいいのか。
僕なら、6つに分けて考えます。
まず、
何を変えたのか。
普段のやり方から、
何をやめたのか。
何を減らしたのか。
何を飛ばしたのか。
何を違う方法にしたのか。
ここを曖昧にしない。
次に、
何が良くなったのか。
速度なのか。
意思決定なのか。
顧客対応なのか。
チームの負荷なのか。
成果なのか。
そして、
何が悪化しなかったのか。
品質は落ちなかったか。
情報共有は崩れなかったか。
必要なチェックは抜けなかったか。
ここまで確認したら、さらに一歩進みます。
問題が起きなかっただけではないか。
潜在的なリスクを見る。
これが一番重要です。
問題が起きなかったことは、リスクがなかった証明ではありません。
もしリスクが残っているなら、
次に考えるのは、
そのリスクだけを別の方法で制御できないか。
です。
ここが、
「元に戻す」
と、
「そのまま残す」
の間にある第三の選択肢です。
例えば、ある工程を減らすと仕事は速くなる。
でも、重要な確認漏れが怖い。
なら、
全部元へ戻すのではなく、
重要なチェックだけ残す。
案件の条件によって確認レベルを変える。
リスクが高いときだけ追加確認する。
そうすれば、
速さを残しながら、危険だけを減らせる可能性があります。
最後に、
平常時でも同じ結果が出るか。
他の人でも使えるか。
再現できるか。
ここまで見て、
初めて標準化を考える。
この考え方を直感的に理解するうえで、映画『シックス・トリプル・エイト』も面白いです。
第二次世界大戦中、大量の郵便物が滞留し、従来のやり方では処理が追いつかない状況が生まれます。
6888部隊は、今までの方法をそのまま頑張るのではなく、勤務体制や郵便物を整理する仕組み自体を変えていきます。
重要なのは、
「もっと頑張った」ではなく、「流れを変えた」こと。
制約によって従来の方法が通用しない。
だから仕組みそのものを変える。
成果が出たら、そこで終わらず、次でも使える形にしていく。
この構造は、『ザ・クリスタルボール』とよく似ています。
例外が生まれたとき、
昔のやり方へ戻すだけが答えではありません。
その例外を、次の仕組みに変えられるか。
そこまで考えて初めて、改善になります。
個人の工夫で終わらせず、仕組みに変える
僕は仕事では、スピードと成果をかなり重視しています。
もっと良いやり方があるなら変える。
必要なら提言する。
そして、仕組みそのものを変える。
ここで大事なのは、
自分だけが速くなって終わらないことです。
個人がこっそり工程を飛ばす。
本人は速い。
でも他の人には再現できない。
リスクも本人しか分からない。
その人がいなくなれば、元へ戻る。
これでは組織として改善したことにはなりません。
逆に、
「この工程を減らしたら速くなった」
「成果は落ちなかった」
「ただし、このリスクが残る」
「だから、このチェックだけ残そう」
まで整理できれば、
個人の工夫を仕組みに変えられます。
僕が常にやり方を変えるのも、
単に新しいことが好きだからではありません。
スピードと成果につながるなら、今までのやり方に固執する理由がない
と思っているからです。
ただし、変えるなら再現できる形にする。
リスクがあるなら制御する。
必要なら周囲へ提言する。
そうして、
「例外的に速かった人」
ではなく、
「普通にやっても速い仕組み」
へ変えていく。
今回の記事で言いたい「次の標準」は、ここです。
仕事の例外を見逃さないために、戻す前に5分だけ検証する
では、明日から何をすればいいのか。
大げさな改善活動は必要ありません。
次に、
「今回は特別対応だった」
という仕事が終わったとき。
元に戻す前に、5分だけ振り返ってみてください。
見るのは5つです。
1. 今回、普段と何を変えたか。
2. その結果、何が良くなったか。
3. 何が悪化しなかったか。
4. どんなリスクが残っていたか。
5. そのリスクを制御できるか。
これだけです。
特に振り返る価値があるのは、
納期が急に短くなったとき。
人手が足りなくなったとき。
顧客や上司から急な変更が入ったとき。
トラブルが終わった直後。
こういうときです。
普段ならやらない変更が発生しています。
そこには、
今までの仕事の前提を検証できるデータ
があります。
考えた結果、
「やっぱり元へ戻そう」
でもいい。
僕自身、リスクを考えて戻したことがあります。
逆に、
「この部分は残せる」
なら残す。
「リスクだけ対策すれば使える」
なら改善する。
重要なのは、
無意識に元へ戻さないこと。
一度だけ、判断することです。
改善とは、「元に戻すこと」ではなく、次の標準をつくること
『ザ・クリスタルボール』は、在庫管理の本です。
水漏れ事故によって、今までの在庫ルールを守れなくなる。
例外的な運営をする。
予想とは違う成果が出る。
そして、
なぜそうなったのかを調べる。
補充を変える。
在庫の置き方を変える。
店舗だけでなく、チェーン全体へ考え方を広げる。
僕は、この流れそのものが仕事の改善に使えると思っています。
トラブルが起きた。
普段の方法を使えなくなった。
別の方法を使った。
うまくいった。
そこで、
「じゃあ次もこれでいい」
とは考えない。
なぜうまくいったのか。
リスクはなかったのか。
平常時でも再現できるのか。
そこまで考える。
そして、
残すべきものだけを残す。
戻すべきものは戻す。
改善すべきものは改善する。
だから、
うまくいった例外対応は、元に戻す前に「次の標準候補」として検証する。
これが、僕が『ザ・クリスタルボール』から一番仕事へ持ち帰りたい考え方です。
次に仕事で、
「今回は特別だったから、元に戻そう」
と思ったとき。
その前に5分だけ考えてみてください。
何を変えたのか。
何が良くなったのか。
何が悪化しなかったのか。
どんなリスクが残ったのか。
そのリスクは制御できるのか。
元に戻すなら、それでいい。
でも、もし残せるものがあるなら。
それは単なる例外ではありません。
あなたの仕事の、次の標準になるかもしれません。
コメント