「誰がやっても同じ」を目指してきたが、それだけでは足りなかった ― 物流の現場で学んだ、仕組みと経験の線引き ―

社労士開業準備中のともちかと申します。
これまで、勤怠システムの再構築やクラウドPBX、ナビダイヤルの導入など、いくつかの改善事例を紹介してきました。
数字も出しましたし、効果も書きました。
ただ、誤解のないように書いておきたいことがあります。

あれらは、最初からうまくいったわけではありません。

どの取り組みも、途中で問題が出て、原因を調べて、やり方を変えています。
話として書けるのは結果だけですが、そこに至るまでには失敗があります。
今回は、その典型例を一つ紹介します。
物流会社で庫内改善に取り組んでいた頃の話です。

①数字は、明らかに偏っていた

オフィス家具の物流倉庫で、出荷指示のデータを分析していた時のことです。
特定のロケーション群に、出荷指示が極端に集中していました。
倉庫では商品ごとに保管場所（ロケーション）が決まっています。
そこに作業者が向かい、指示された商品を取り出す。
この動きが特定の場所に偏れば、当然そのエリアは混雑し、作業効率が落ちます。
なぜそこに集中するのか。
出荷指示が出ている商品を一つずつ調べていきました。

②原因は、商品の「大きさ」だった

浮かび上がってきたのは、意外な事実でした。
集中していたのは、細かい部材系の商品ばかりだったのです。
オフィス家具の倉庫で扱う商品の多くは、デスクの天板や脚、書類保管キャビネット、ワゴンといった大型品です。
これらはフォークリフトでなければ運べません。
しかし実際には、デスクを組み立てるために必要な配線カバーやフックといった、手で持てるサイズの小物製品も数多くあります。
そしてこの小物の出荷指示が、想像以上に多かった。
問題は、これらも全てフォークリフトでピッキングしていたことです。
手で持てる小さな部品を取りに、わざわざフォークリフトを走らせる。
1件あたりは些細な非効率でも、件数が多ければ全体に効いてきます。
しかも大型品を扱うフォークリフトと動線が重なるため、混雑にも拍車をかけていました。

③対策：小物専用エリアを新設した

そこで、小物製品を集めた専用エリアを新たに設けました。
手で運べるものは、フォークリフトを使わずに人が直接ピッキングする。
大型品のエリアとは動線を分ける。
理屈としては明快です。
結果、ロケーションごとの負荷は狙い通り緩和されました。
出荷指示の集中は解消し、フォークリフトの走行も減りました。
数字の上では、間違いなく改善です。

④しかし、別の場所に問題が移っただけだった

ところが、しばらくして新しい問題が表面化します。
小物の梱包作業が、そのエリアに集中し始めたのです。
考えてみれば当然でした。
小物を一箇所に集めれば、そこでピッキングされた商品の梱包作業も同じ場所に集まります。
ピッキングの負荷は分散できましたが、その先の工程で新たな滞留が生まれていました。
ロケーションの混雑という目に見える問題は解決しました。
しかし現場全体で見れば、作業の詰まりが後ろにずれただけです。
数字だけを見ていれば、改善は成功と評価できます。
実際、当初の指標は良くなっていました。
それでも現場は楽になっていない。
この状態を放置すれば、「改善したはずなのに、なぜか忙しい」という不信感だけが残ります。

⑤3方向から手を打ち直した

そこで、梱包工程を含めて設計をやり直しました。
打った手は3つです。

　1. 梱包作業そのものを分散させる
エリア内に梱包場所を複数設けました。
1箇所に持ち込む前提だったものを、作業が発生する場所の近くで完結できるようにします。
物理的な集中を、物理的に解く方法です。
　2. 繁忙時間帯に応援が入る仕組みをつくる
作業量は一日中一定ではありません。
出荷指示が集中する時間帯に、他エリアから応援を回す運用を組みました。
配置を固定せず、負荷に応じて人を動かします。
　3. 仕分けと梱包を別工程に分ける
それまで一人が続けて行っていた作業を、仕分けと梱包に切り分けました。
工程を分ければ、それぞれを並行して進められます。
一人が最後まで抱える構造をやめたということです。

物理的な配置、人の動かし方、工程の切り分け。
同じ問題に対して、異なる層から手を打っています。

⑥この失敗から学んだこと

部分最適は、全体最適ではありません。
当たり前のようですが、改善に取り組んでいると見落とします。
目の前の指標が良くなると、そこで達成感が生まれてしまうからです。
私が最初の対策で見ていたのは「ロケーションごとの負荷」という一点でした。
その指標だけを見れば、対策は成功しています。
しかし現場は、ピッキングだけで完結する場所ではありません。
その先に梱包があり、出荷があります。
改善とは、負荷を減らすことであって、移動させることではありません。
減ったように見えて、実は別の場所に移っているだけ。
この見分けがつくかどうかが、改善が本物になるかの分かれ目だと思っています。

⑦それでも、仕組みだけでは埋まらない部分がある

ただ、この一件を通してもう一つ気づいたことがあります。
こちらのほうが、私にとっては大きな学びでした。
全てを仕組みで解決できるわけではない、ということです。
私の理想は、はっきりしています。

誰がやっても同じ結果になる状態をつくること。

突き詰めれば、マニュアルを読む必要すらないほど作業を簡素化することが、私の目指すところです。
属人化した業務は、担当者が休めず、引き継げず、その人がいなくなった瞬間に止まります。
しかし物流の現場では、その理想がそのままは通りませんでした。
理由は、扱っていた商品にあります。
オフィス家具は、荷姿がバラバラなのです。
デスクの天板、脚、キャビネット、ワゴン、そして手で持てる小物。
形も重さも強度も違います。
同じ「デスク」でもサイズ違いがあり、梱包形状も一定ではありません。
こうなると、標準化には限界があります。

●    入庫時 …… どの棚のどの位置に置くか。サイズと重量と出荷頻度を見て判断する
●    保管時 …… 積み重ねてよいものと、そうでないもの。破損リスクの見極めが要る
●    積み付け時 …… トラックの荷台にどう配置するか。荷崩れを防ぐ組み合わせは無数にある

これらを全てルール化しようとすれば、条件分岐が膨大になり、かえって読まれないマニュアルができあがります。
最終的には、現場の経験がものを言う領域が残ります。

⑧経験を、否定してはいけない

改善に取り組む人間が陥りやすい失敗があります。
属人化を全て悪と決めつけることです。
私も一時期そう考えていました。
仕組みで解決できないのは、標準化が足りないからだ、と。
しかし、荷姿が一定でない商品を安全に効率よく扱えるのは、経験を積んだ作業者だからです。
その判断は、数字にもマニュアルにも書き表せません。
それを「属人化している」と切り捨てれば、現場は壊れます。
経験による判断は、無碍にしてよいものではありません。

⑨では、何を仕組み化するのか

ここに、私なりの落としどころがあります。
判断そのものではなく、判断しなくてよい部分を仕組みにする。
小物専用エリアを設けたのは、まさにこれでした。
「これは手で運べるか、フォークリフトが要るか」という判断を、毎回作業者にさせるのではなく、置き場所を分けることで判断そのものを消したのです。
その上で、残った判断—どう積むか、どう保護するか—は、経験のある人に委ねる。
全てを均そうとするのではなく、経験を使うべき場面に集中してもらうという考え方です。
こう整理してから、改善の見方が変わりました。
目指すべきは「経験をなくすこと」ではなく、「経験がなくてもできることに、経験を使わせないこと」です。

⑩バックオフィスでも、同じことが起きる

この構造は、総務の仕事でもそのまま当てはまります。
入退社の手続きや勤怠管理等は、ルールが明確なので仕組み化できます。
実際、私が前職及び現職で取り組んできた改善の多くは、この領域です。
一方で、仕組みにしきれない仕事もあります。
従業員から相談を受けたとき、どこまで踏み込んで聞くか。
制度を説明する際、相手の状況に応じてどう伝えるか。
トラブルが起きたとき、誰にどの順番で話を通すか。
これらは、経験と関係性の中でしか判断できません。
マニュアル化しようとすれば、かえって形骸化します。
だから私は、手続きや作業は徹底的に仕組み化し、人と向き合う部分に時間を残すという方針を取っています。
効率化の目的は、人が判断すべきことに集中できる状態をつくることだと考えているからです。

⑪改善で一番抜けやすいのは、Cです

物流の現場で叩き込まれたPDCAですが、実際に回してみると、どこで止まるかがはっきり分かります。

Cが抜けるのです。

計画を立て（Plan）、実行する（Do）。
ここまでは誰でもやります。
仕組みが動き出せば形になりますし、達成感もある。
しかしその後、本当に良くなったのかを調べる（Check）という工程が、驚くほど飛ばされます。
私が小物専用エリアを作ったときも、そこで終わっていたかもしれません。
ロケーションの負荷は数字上で改善していたので、報告する材料は揃っていました。
梱包工程の滞留に気づけたのは、たまたま現場を見に行ったからです。
作って満足してしまう。
これは改善に関わる人ほど陥りやすい落とし穴だと思っています。
自分が手をかけたものだけに、うまくいっている前提で見てしまうからです。
そしてCを飛ばすと、その先のAも打てません。
何が起きているか分からないまま次の手を考えても、それは改善ではなく思いつきです。
Cまでやって、はじめてAにつながる。
順番を飛ばせないのが、このサイクルの厳しいところだと思います。

⑫だから、必ず「その後」を見に行く

この経験以降、施策を打った後に必ず確認するようにしています。
見ているのは次の3点です。

●    前後の工程で、新しい滞留が起きていないか
●    数字は良くなったが、現場の実感は変わっていないと言われないか
●    一部の人に負担が寄っていないか

特に3つ目は重要です。
改善したつもりが、実は誰か一人の頑張りで支えられている。
そうなれば属人化を招くだけで、効率化とは呼べません。
そして確認した結果、また問題が見つかれば、原因を調べて次の手を打ちます（Act）。
そこからまた新しいPlanが始まります。
PDCAは、1周して終わるものではありません。
私にとっては、Cで見つけた課題が次のPになる、その繰り返しでしかありません。

⑬回し続けると、Pが変わってくる

面白いのは、この繰り返しを重ねていくと、計画の質そのものが変わってくることです。
Pの段階で、Cが予見できるようになります。
「この施策を打つと、次はここに負荷が移るのではないか」
「この工程を分けると、引き継ぎのときに困る人が出るかもしれない」
過去に自分が見落とした場所を覚えているので、計画の時点で確認すべき項目が浮かんでくるのです。
そうなると、Cを織り込んだPが立てられるようになります。
実行する前から、どこを見に行くべきかが決まっている状態です。
もちろん、それでも想定外のCは出ます。
予見できるのは、あくまで自分が経験した範囲だけだからです。
ただ、それは困ることではありません。
想定外が出たら、また回せばいいだけです。
小物エリアの梱包集中も、当時の私には予見できませんでした。
しかし今なら、同じ設計をする前に梱包工程を確認します。
一度痛い目を見たぶん、次の計画に組み込めるようになったということです。
以前紹介した備品在庫管理アプリは、その積み重ねの上にあります。

あの時、棚の配置見直しや発注のまとめ方は、設計の段階から見込んでいた効果でした。
物流でロケーション管理のデータが何に使えるかを知っていたからです。「作ってから考える」のではなく、「何を確認するために作るか」を決めてから着手できたということになります。
回した回数だけ、Pの精度が上がる。
PDCAは、そういう意味でも奥が深い仕組みだと思っています。

最初から成功する改善は、ほとんどない

これまで紹介してきた事例も、同じ道筋をたどっています。
備品在庫管理アプリも、就業規則の問い合わせアプリも、動かしてみて分かったことを反映しながら形を変えてきました。
設計段階で見込めることがあっても、それで完成にはなりません。
予見できたのは確認すべき項目であって、確認した結果までは分からないからです。
作った時点は、完成ではなくCの入口です。
そして、どこまで仕組み化するかという線引きも、やってみなければ分かりません。
やりすぎれば現場が窮屈になり、足りなければ属人化が残る。
その調整もまた、回しながら見つけていくものです。
だから、うまくいかなかったときに落ち込む必要はないと思っています。
差が出るのは、失敗を失敗のまま終わらせるか、次の一手の材料にするか。そこだけです。

バックオフィスの効率化や生成AIの実務活用について、引き続き発信していきます。
ぜひフォローいただけると嬉しいです。