事例 01 · 物流 — 30年続く会社の通関業務
物量が20倍になっても、現場が崩れない仕組みにしました。
徹夜が続き、人が辞めていく通関チェックの業務でした。何をつくるかが決まっていない状態から始め、韓国と日本の現場を調査してシステムを決めました。
- 現場調査から初版の完成まで
- 6週現場調査から初版の完成まで
- 同じ業務に必要な人員（導入1年以内）
- 10名 → 5名同じ業務に必要な人員（導入1年以内）
- 普段より物量が20倍に増えた日にも対応
- 最大20倍普段より物量が20倍に増えた日にも対応
- 以前は半年ごとに1〜2名が退職
- 退職者0名以前は半年ごとに1〜2名が退職
- いまも実際の通関業務で使用中
- 稼働2年目いまも実際の通関業務で使用中
何が問題で、何を変えたのか。
You do not have to read the long version — the table below is enough to judge by.
- Client
- 韓国と日本で30年以上、物流事業を営んできた企業
- The problem
- 日本向けの商品が増え、通関情報のチェックが急増。ミス・残業・退職が繰り返されていた
- The binding constraint
- お客様側の通関書類の書き方を厳しく制限すると、新規顧客の獲得に不利になりかねない
- What we first thought
- 担当者に候補を3つ見せて、人が最適な値を選ぶやり方
- What we found on site
- 物量が急増すると、担当者が全商品を開いて見る構造そのものがボトルネックだった
- What we did
- 機械が先にチェックし、担当者は判断が難しい商品から確認する構造に設計し直した
- Result
- 運用人員 10名 → 5名、最大20倍の物量に対応、導入後の退職者0名、現在も稼働中
開発ストーリー
最初のバージョンは、半分しか成功しませんでした。
現場で起きたことを、そのまま書きます。何が難しく、何を設計し直したのか。
01 · 発端
会議で部長が手を挙げました。
「このままでは通関業務が止まってしまいます。」
日本の大型セールのたびに、韓国から入ってくる全商品の通関情報を社員が手で確認していました。忙しい時期はまともに眠れないほどでした。
小さな入力ミスひとつが通関の遅延と責任問題に発展し、やがて顧客の信頼を損ない、社員の士気まで削っていきました。問題は業務効率ではありませんでした。事業が成長するほど現場が壊れていく、それが本当のリスクでした。
「迅速開発チーム、何か手はありませんか。」
お客様も、必要なシステムの姿を最初から分かっていたわけではありません。私たちも、機能の一覧からつくり始めることはしませんでした。
02 · 観察
開発より先に、働く人を見ました。
日本では、最終通関を担当する通関士の方々の話を聞きました。中心となる規定には共通の基準がありましたが、判断の境目にある商品は専門家ごとに解釈が違いました。規定をシステムに入れるだけで解ける問題ではありませんでした。
次は韓国の実務現場でした。ソウル郊外の物流倉庫2階の事務所で、約10名が通関情報を確認していました。8名が商品ごとに一次チェックを行い、リーダー級の2名が問題になりそうな内容を再確認していました。
説明を聞くだけにはしませんでした。実務者2名の作業を、それぞれ1時間ずつ横で見ました。 どの資料を参照するか、どこで手が止まるか、何を危険と判断するかをひとつずつ記録しました。
人によって判断基準が違うことは、誤りではありませんでした。
それこそが、システムが学ぶべき知識でした。
03 · 分かれ道
いちばん早くつくれる答えではなく、お客様が選べる複数の案をご提案しました。
現場調査のあと、三つの道を検討しました。
A · 入力を正しくする
お客様が最初から正確な通関情報を入力できるよう手助けする。いちばん速く、安い道。
採用せず — お客様の営業のやり方と衝突
B · 担当者の判断を助ける
商品ごとに候補を3つ見せ、担当者が最適な値を選択する。
先に採用 — 6週間で完成
C · 人が見るものを減らす
機械が先にチェックし、人は確認が必要なものだけを見る。
最終採用 — 現在もこの構造で稼働中
お客様と話す中で分かったことがありました。お客様の競争力には、通関書類の作成を柔軟に手助けするサービスが含まれていました。 入力基準を厳しくしすぎると、それが新規顧客を阻む壁になります。
開発にはいちばん短い道でしたが、お客様の事業には合わない道でした。
つくりやすい機能よりも、お客様が30年かけて築いた営業のやり方を先に理解しました。
04 · 最初のバージョン
6週間でつくり、実務の現場に入れました。
実務者の判断のしかたを学習させ、商品ごとに候補を3つ提示しました。担当者は3つから選び、どれも適切でなければ自分で新しい答えを入れました。人をすぐ置き換えるのではなく、熟練者の判断を助けるやり方から始めました。
通常の物量では安定して動きました。
05 · 限界
物量が5倍になったとき、ボトルネックが表面化しました。
ある日、普段の約5倍の物量が一度に入ってきました。候補を出しても担当者は全商品をひとつずつ開いて選ばなければなりませんでした。 精度は上がりましたが、急増した日の作業量は十分に減りませんでした。
「確認する作業のほうが、かえって大変です。」
一部の社員の反応でした。開発チームも揺れました。しかしその言葉が、次の解き方をはっきりさせました。
必要だったのは、より正確な推薦ではありませんでした。事業が急成長しても耐えられる処理の構造でした。
06 · 再設計
人が全件を見なくてよいように変えました。
3つの答えを見せて人が必ずひとつ選ぶやり方をやめました。代わりにAIが最も適切な答えを先に整理し、確信度の低い商品を切り分けて 見せるようにしました。
通関チェック — 全ての通関書類を確認するやり方 → 確認すべきものだけを示すやり方
BEFORE入荷商品 全件
100%
一次チェック · 担当者8名
商品ごとにひとつずつ開いて確認
再確認 · リーダー2名
問題になりそうな内容を再度確認
通関申告
物量が増えると、人数と残業も一緒に増える
AFTER入荷商品 全件
100%
AIが先にチェック
答えを整理し、確信度も一緒に付ける
確信度が高い
人の確認なしで通過
確信度が低い
担当者が優先して確認
通関申告
担当者が直した結果は、また学習に使われる
全件を同じ深さで見るやり方から、必ず見るべきものを先に見るやり方に変わりました。
物量が少ないときは確信度の低い商品から順に詳しく確認し、物量が急増したときはリスクの高い商品に確認の手を集中させます。
07 · 結果
1年後、成長はもう現場の危機ではなくなりました。
導入から1年以内に、通関チェックの運用人員は10名から5名に減りました。それでも、1日の物量が普段の20倍以上に増えた日まで、無理なく対応できることを確認しました。
以前はアルバイトを含めて半年ごとに1〜2名が退職していました。お客様のご報告によれば、導入後この業務での退職者は出ていません。
このシステムはデモで終わりませんでした。現在もお客様の実際の通関業務で動いています。
ご要望を書き取るだけにはしませんでした。
現場で実際に起きていることを、すべて見に行きました。
日本の通関の専門家と韓国の実務者に、同じ基準で会いました。
言葉にならないノウハウを観察しました。
言葉に整理されない個人ごとの判断基準を、横で見て記録しました。
要件ではなく課題から決めました。
整理された開発リストがない状態で、何から解くかを一緒に決めました。
お客様の営業のやり方を優先しました。
技術的に可能な解法よりも、30年かけて築いた営業のやり方に合う解法を選びました。
限界が見えた時点で、設計し直しました。
初版の限界を実際の物量急増で確かめ、中心のロジックを変えました。
人の仕事に順番をつけました。
確信度に応じて、担当者が先に見る商品を決められるようにしました。
公開して終わりにしませんでした。
現場のフィードバックを反映し、学習と改善が続く運用システムにしました。
機能をひとつつくったのではありません。
要は、推薦の精度を上げることではありませんでした。
事業が成長するほど残業と退職が増える構造を、 物量が増えても重要な判断に集中できる構造に変えたこと。
それが、このプロジェクトが生んだいちばん大きな変化です。
何をつくるべきか分からなくても大丈夫です。
社長は現場の課題をご存じです。その課題をどんなシステムで解くべきかは、はじめから整理できるものではありません。迅速開発は「要件をまとめてきてください」とは申し上げません。現場を見て、お話をうかがい、人がやることとシステムに任せることを一緒に決めます。
成長するほど残業が増えます。
物量が増えれば人も一緒に増やさなければならない構造です。
特定の社員に業務が集中しています。
その人がいないと業務が止まります。
課題は分かっていても、解き方が分かりません。
どんなシステムが必要なのか整理できていません。
開発会社に、うまく説明できませんでした。
依頼はしてみたものの、望む結果が伝わりませんでした。
No documents required · 60 minutes online · Japanese, Korean or English