Ch4 01: 18時間の作業に18日間#
駐車場で車をぶつけられた。大したことはない——フェンダーがへこみ、バンパーにヒビが入り、塗装が少し剥げた程度。板金塗装屋に持っていくと、見積もりを書いて「18日くらいで仕上がります」と言われた。
18日間。実際の手作業は約18時間の修理に。
残りの17日間はどこに消えたのか？
この疑問が、スピードについてのまったく新しい考え方を切り開いた——テスラではなく、DVxポートフォリオ内の衝突修理会社で。答えを可視化してみると、シンプルかつ腹立たしいものだった。
1日目：車を預ける。保険の査定員が見に来る必要があるが、3日目まで来られない。車はただ置いてある。
3日目：査定員が来て、損傷を記録し、見積もりを保険会社に送る。保険会社の承認に2日かかる。
5日目：承認が下りる。店が部品を発注。届くまで4日。
9日目：部品が届いた。だが担当の技術者は別の車にかかりきりだ。あなたの車は列に並ぶ。3日待つ。
12日目：技術者がようやく着手。次の2日半——約18時間の労働——で修理が完了する。板金、塗装、組み立て。
15日目：車が品質チェックの列に入る。1日待つ。
16日目：品質チェック通過。洗車と引き渡し準備が必要だ。1時間で終わるが、ディテーリングチームが詰まっているため17日目まで回ってこない。
17日目：店から引き取りの日程調整の電話が来る。明日まで行けない。
18日目：車を引き取る。
18日間。実作業18時間。この二つの数字のギャップは、小さな非効率ではない。それ自体が問題なのだ。
私はこれをタイムギャップと呼んでいる——サイクルタイムとタッチタイムの距離だ。
サイクルタイムとは、プロセスが始まってから完了するまでの総経過時間。衝突修理の例では18日間。
タッチタイムとは、誰かが実際に作業している総時間。ここでは18時間。
そのギャップ——総所要時間の95%以上——は待機に呑み込まれている。作業していない。価値を生んでいない。ただそこにあるだけだ。
そして最も厄介なのは、この待機が見えないことだ。板金塗装屋を歩き回れば、誰もが忙しそうに見える。査定員は車を検査し、技術者はレンチを回し、部品デスクはサプライヤーに電話をかけている。一人ひとりは生産的だ。だがシステムは途方もなく無駄が多い。なぜなら、仕事が個人の稼働率を最大化するように組織されていて、各車両が何もしないまま過ごす時間は完全に無視されているからだ。
ほとんどのプロセス改善は、作業そのものを攻撃する。技術者はフェンダーを18時間ではなく16時間で修理できないか？ 塗装はもっと早く乾かないか？ 品質チェックをもっと短時間で精密にできないか？
悪い問いではないが、最初に問うべき問いではない。18時間の作業から2時間削っても、総サイクルタイムの約1%しか節約できない。3日分の待ち行列を削れば17%節約できる。テコは作業にあるのではない。待機にあるのだ。
これはほとんどのマネージャーにとって直感に反する。作業は目に見え、待機は見えないからだ。マネージャーが工場を歩き回り、技術者が懸命に働いているのを見れば、そこが最適化すべき場所だと感じる。駐車場で順番を待っている車は？ 見えない。ただ駐車してある車だ。どれだけ置いてあるか誰も追跡しない。その遊休時間のコストを誰も計算しない。
だがコストは巨大だ——2週間半も車なしの顧客にとって、遊休在庫にキャパシティを縛りつけている店にとって、待機日数分のレンタカー代を払う保険会社にとって。
待機は自分からムダだとは名乗らない。変装している。
行列待ちは「需要が旺盛」に変装する。店は大忙し！ いいことじゃないか？ だがフロー管理のない高需要は、駐車場で干上がる車が増えるだけだ。
承認待ちは「品質管理」の陰に隠れる。保険会社は修理を許可する前に見積もりを確認する必要がある。もっともに聞こえる。だがその確認に本当に2日必要なのか？ それとも、査定員が200件のバックログに溺れているから2日かかるのか？
部品待ちは「サプライチェーン・ロジスティクス」を装う。部品は発注、出荷、受入、検品が必要だ。サプライチェーンとはそういうものだ。だが最も使用頻度の高い20品目——修理の80%をカバーするもの——を事前に在庫しておいたら？「部品に4日」が一瞬で「棚にある」に変わる。
調整待ちは「専門分業」のふりをする。各段階に異なるスキルが必要だから、異なる人が担当する。確かにその専門性には価値がある。だが専門家間の引き継ぎがデッドゾーンを生む。板金が金曜の午後に終わり、塗装が月曜の朝まで始まらない。
どのケースでも、待機にはもっともらしい言い訳がある。そしてどのケースでも、その言い訳は説明であって正当化ではない。待機がなぜ存在するかを説明することは、それが存在しなければならないことを証明するのとは違う。
解決策は各ステップを速くすることではない。ステップ同士がぴったりくっつくようにシステムを再設計することだ——理想的には、間に何も挟まず、一つが終わったらすぐ次が始まる状態だ。
この衝突修理会社では、いくつかの構造的変革を行った。保険の事前承認を、一定金額以下の修理に対する包括的な承認に置き換えた——前の章で出てきた三条件フィルターを保険金請求処理に適用した形だ。よく使う部品を事前在庫し、80%の仕事から4日間の待ちを消した。待ち行列制を予約制に変え、車が到着した瞬間に技術者が作業を開始するようにした。各段階間の引き継ぎギャップ——板金、塗装、仕上げ——は、チームの同一拠点化とスケジュール同期で圧縮した。
結果：18日間が18時間になった。18時間の「速い作業」ではない——18時間の同じ作業だ。待機を剥ぎ取っただけだ。
ガイダンス#
最も重要なプロセスを選び、二つの数字を測定しよう。
- サイクルタイム： 始めから終わりまで、暦日でどのくらいかかるか？
- タッチタイム： そのうち誰かが実際に成果物に取り組んでいる時間はどのくらいか？
ギャップを計算する：（サイクルタイム − タッチタイム）÷ サイクルタイム × 100。
ギャップが70%を超えていれば——ほとんどのレガシープロセスではそうなる——最もレバレッジの高い改善ターゲットを見つけたことになる。進むべき方向は「作業を速くする」ではない。「待機を殺す」だ。
プロセス内のすべての待機期間を一つずつ確認し、問おう。この待機はどんなコスチュームを着ている？ 行列？ 承認？ 引き継ぎ？ 部品遅延？ それぞれについて、その根底にある目的を待つことなく果たせないか考えよう——事前承認、事前在庫、同一拠点化、スケジュール同期によって。
最速のプロセスとは、すべてのステップが最適化されたプロセスではない。すべてのステップが前のステップの直後に発動し、その間に何もないプロセスだ。