予告通り、このEC事業の委託運送会社を変更するためにゆうパックプリントRと格闘するシリーズ、前回から2週間を経ての続き,そして最終回を投稿します。前回はこちら
前回から何をしていたかというと…本番移行直前で現場での導入作業をしていました。その途中、今回協力してくれたエンジニアに状況を話して助言求めていると彼は言いました。
「本番環境には魔物が住んでいる」といつも思っています。 本番環境で動かしてみると、色々出てきますよね。
そう、その魔物退治をしていました。今日はそのお話しを少し。中小企業の業務改善をしようと思うと現代ではほぼ必然的に業務システムの入れ替えということが起き、誰かがこれをやらなければならないのですが、なかなか社内にそんな人材はいないですよね…。そして、それを担える外部人材もなかなか見つかりません。外部に頼んでもやたらと高いことを言われますし…
中小企業の「DX」の現実を知る弊社がその主要な部分を担って実現したお話です。
①複数セクター間の調整
今回の事例で言えば、弊社が状況や関係者間の関係を分解して、日本郵便さんにシステムや資材を提供してもらいいくつかの契約を行い、サトー様に一部のシステムを提供してもらい、現行会社さんに終了のご連絡し、運送会社とトライアルを行い…といくつもの会社との間で漏れなく進行させ、しかもこの間の順番を調整しないとそれぞれが独立して進められてゴールに行きつけるものではありません。たとえば、日本郵便のwebサービスが開設されないとサトーのシステムの一部機能が検証できない、ということが起きました。
初めてのことであっても何を準備することが必要なのかを全部自分で洗い出し、そのうえでそれを日程管理し、多少のバッファを自分で持ちながらゴールへ行きつけさせないといけないわけです。しかも、開始日は、安全のためセールと重ならない日程でかつ月曜日(荷物が多い）、金曜日（翌日すぐに対処するということができない）以外を選ぶ必要があるなど制約があります。
さらに、各セクターが出してきたToDoリストが正か、というと、それは対象業務に対して必要最小限でしかなく、周辺の業務運用を含めるともっと様々な要素がある、ということは自社側が把握して確認する必要があります。たとえば、今回だと不良返品等の「着払い返送」に関する業務フローがそれでした。日本郵便の担当の方は、「発送を移管」することについて一生懸命ですが、こちらとしては、その他の業務も一括して日本郵便に移管する必要があるので、これも考慮に入れる必要があり、それを洗い出すのは、日本郵便ではなく、社内の仕事であり、そして社内に聞いてもあまり的確な答えは返ってきません。結局自分で業務全体を理解して洗い出す必要があるのです。
そのためには、システムではなく、「業務全体」そして、それを担当している「社員の力量や性質」をよく知っている必要があります。ところが、この会社は営業と物流センターがそれぞれ相当の規模があり、両方をよく知っている社員がいない…そこを埋めたのが当社でした。
もう一つはこうしたプロジェクト進行は、その場で一個一個の課題をつぶしていかないとメールで一日1往復を着実にやり取りして…というようなやり方では到底締め切りに間に合いません。そして、システム案件でシステムに弱いメーカー営業を窓口にやり取りしていたのではらちが明かず、担当SEに直接電話で確認するようなパスを確立することが必要です。それにはそこそこ業務を把握していて切り盛りできる人がこっち側の窓口で気合入れて待ち構えている、というようなことを理解していただく必要があります。そして図々しく電話で回答を毎日何度も迫り、粘り強く前進していき、解決しない場合に備えて別対策を別途用意するということを積み重ねていきます。昔私は、PMP（プロジェクトマネジメントプロフェッショナル)を保有していたのですが、理屈を知っていることと、こういうことをバイタリティをもってバリバリと進めることとはまた別問題です。ただ、もちろんそこではバッファ管理やリスク評価などの体系的知識も必要です。今回もずいぶん役に立ちました。（資格は失効させましたが）
そして、「他社の人ともカジュアルに話せる」「(少なくとも仕事上は）仲良くなれる」能力も重要です。
②Point of No Return ルビコン川を渡る時
どんなプロジェクトも経済性や実現性が見込めなくなったら中止するべきです。それは国でも企業でも同じです。それまでにいくら投じたかは判断に加えてはいけないのであり、未来の費用対効果で決めるべきです。ただ、どんなプロジェクトにも、ここを超えると後戻りができないポイント(Point Of No Return）が存在します。今回のプロジェクトでは、現在配送してもらっている会社に、「●月●日を最後にご依頼を中止します。」とお伝えすることでした。これは、その会社は、一日３～5人の荷物の処理要員を当社のためにアサインしてくれているので、その人繰りを考えれば少なくとも前月中にはお伝えしてあげないとご迷惑をおかけしてしまいます。
コンペで負けた(今回は提案を出すことを辞退されて不戦敗だった）とはいえ、高い品質とそこそこ安いコストで10年にもわたって担当してくれていた現行会社には感謝こそあれ、何ら文句をいうものではありませんし、物流センターの現場社員はこれからも他業務では現行会社さんには協力していただく必要があります。その意味では、現場に、「経営方針上、上での決定でやむを得ず変更しますが、これからも別業務ではどうぞよろしく」と言いやすい環境を作ってあげる、つまり経営が悪者になり、それに対して現場は共闘する、という構図を用意してあげることが必要です。
ということで…私が現行会社の支店長にお電話しご説明し、そして日程に過誤がないよう取締役や物流責任者、そして相手の会社のセンター責任者をCCに入れて、そのあとメールしました。その支店長とは、過去1年で2度私が商談でお会いしているからできることです。あなたの会社で使う外注コンサルはそこまで泥をかぶってくれますか？
そして、言ってしまえばもう戻れません。こういうプロジェクトはどんなに時間に余裕を見ても最後になれば、「あと1週間欲しい」と思うものです。完全に準備して終える、ということはなかなかできないのです。覚悟を決めるしかありません。ただ…私はただの「外注さん」。いかに経営者に信頼されていたとしてもそれは平時の話。万一しくじり出荷が停止したら、莫大な損害賠償が…そんな恐怖を感じながら、それでも前に進むしかありません。私がやらなければ、その会社は永遠に変われないままです。それが変革を担う杖の重みというものです。
③独自仕様という無邪気な悪魔
日本郵便のEDIの採用を検討していた初期にエアロジ(前々回までに出ていた検討していたWMSです）の技術者から、「日本郵便は仕様書があるけど、それに受付局により独自仕様があり、それによってはカスタマイズがあるから気を付けた方がいいよ」という注意を受けていました。その後、その気配はなく、最後の10日を迎えたのですが…遅れに遅れたEDIの正式開通の時、それは起こりました。
ファイル内の顧客コードや送信URLで顧客名は分かっているはずなのですが、ファイル名を日本語の会社名と括弧のついたものに指定されていたのです。わざわざ「完全一致のこと」という注までついていました。
「（」には全角と半角があります。また、社名を入れると株式会社をつける人がいたり、いなかったりして完全一致しないわけで、どうせファイル名指定ならば、半角アルファベットの方がまだエラーは少ない。この独自仕様のため、サトーから80万円をかけて導入したシステムに付属している送信機能は使えなくなり、自社で手動で送信しなければならなくなりました。(作りこめば同様の送信機能は作れはするのですが…）
おそらくは、何かチェックに引っかかると、担当者がファイルを(多分エクセルで）開いてチェックして電話（メールでも、FAXでもなく、電話なのです）で連絡くれる仕組みになっているので、「人間がわかりやすい」仕組みにしたいというのが理由なのでしょうが、こうして日本の生産性、システム間の連携は失われていく、という典型例でした。
さらに、悪魔は襲い掛かります。そんなファイル名を人間に手動で打たせるのは間違っている、と思う私は、この固定ファイル名に変更するバッチファイルを作り、それをクリックさせれば間違いは起きない、という工程を作りました。ところが、そのバッチファイルで生成したファイルを後工程で使うプログラムファイルがエラー検出してしまいます。開いてみると最後の行に変な文字が入っています。
この辺になってくると時間が足りないことと疲労で、私もだんだん仕事が雑になってきて、この最後の文字の文字コードをバイナリエディタで開くこともせず、前後の工程のプログラム提供者に聞き、エンジニアに、「ファイルは正常にEOFで終了しています」と説明されても、「困った」で頭がいっぱいになり、そこにヒントがあることに気づきませんでした。
昔からの慣れたエンジニアならばもうお気づきでしょう。バッチコマンドで、copy系のコマンドは、アスキーモードがデフォルトで、これでワイルドカード（元のファイルにはタイムスタンプ部分があるためこれを無視して変換するため）のある処理を行うとファイル０ｘ１A（EOF）が勝手に付与されてしまうので、/bのオプションが必要なのです。ここまでは30年ほど前に経験したことがありました。そして、renコマンドでも同じ現象があり、しかもrenコマンドには、バイナリオプションがありません。copy /bとdelを組み合わせて実現する必要があります。
これに気づいてくれたのは、このシリーズでたびたび登場する、今回のシステム導入を支援してくれた副業エンジニアさん。そして、その前に、バッチファイルに不正コード生成の原因があるところまで突き止めてくれたのは、サトーのエンジニアさんでした。いや～、なんとか間に合わせることができたのは、皆さんのおかげです。
しかし、この疲労感…業務運用が仕様書通りだったら何も起きなかったはずなのです。
④手順書とチェックポイントとルール化
手順書は最後の2週間に自分で完全に操作できるまで習熟してから自分で作成しました。約40ページになりました。その過程でいろいろな間違いをしているわけで、そのポイントは、全部注記してあります。
40ページと言うとすごい分量に聞こえますが、画面遷移ごと画面やハンディターミナルの写真があるので、大した文字数ではありません。ただ、業務変更を行う際に、こうした絵入りの手順書をちゃんと作っている会社というのに、過去30年間私は出会ったことがありません。言うは易し、行うは難し。この手順書を作ってくれるというのは、実はかなり価値が高いことだと思っています。
さらに、作った後、担当者2名にそれを渡し、それを見ながら運用してもらい、詰まった個所をその場で改良しています。そのうえで、間違いを防ぐためのチェックリストも整備しています。そこまでちゃんと現場にはりついて（机を借りて）やるようにしています。それにより専門的知識がなくても「誰でも業務を遂行できる」水準を実現しています。
⑤運用シミュレーション
伝票が印刷できればそれでよいというものではありません。伝票を印刷し、現場に持って行き、実際には荷物に貼付はしないのですが、貼付したつもりで、それを今度はサイズ入力を行い、かご車に分類して配置することを一日分の全数を行うことを2度にわたり、現場責任者とシミュレーションして時間を計ってみました。結果、増加する作業時間が、減少する作業時間に対して十分少ないことを確認して、自分たちの施策が間違っていないことを責任者と確認しています。
また、その過程で、処理プログラムの中の設定情報に誤りがあることも分かり、200枚ほどの伝票を何度もめくり分類するという作業を繰り返すことになりました。
また、そうすることにより、運用面でも、システム面でも何が次の改良点なのか？を現場と共有することができます。さらに、やってみると、ハンディターミナルがすぐに省電力モードになることやビープ音が現場では小さいことなど、気になる点がでてきます。それらはメーカーが提供するハンディの説明書には一切記載がないのですが、実は簡単な操作で調整が可能であることをメールでといあわせるとサトーのエンジニアが教えてくれました。最後はそうしたことを一つ一つつぶしていくのです。
事前にここまでやってみる、というのは言われてみると当たり前なのですが、きちんとスケジュールの中で事前に責任者と計画していて自分で立ち会ってやってみないと、誰かがやってくれるものではありません。それを、当事者なのに「よくわからない」と見て見ぬふりをしているとみずほ銀行のようなことが起きてしまいます。
⑥知られざる重要事実
いままでもヤマトのシール用紙に送り状を印刷していましたが、ヤマトのシール用紙は、A4の全面がシールになっていて、A4に2面が印刷できるものでした。今回新規導入する日本郵便の「ユ00520」は左側約1/3だけがシール用紙で右側は通常のPPC用紙です。それを朝、200～1000枚印刷するのです。とすると何が起きるかというと…左側の厚みが右側の倍以上あり、通常のプリンタのトレイの紙送りローラーでは片側だけが設置して、「紙が正常にフィードできない」エラーがおきてしまうのです。しかも、手差しトレーでも起きるときにはおきます。
ユ00520に「対応済み」と書いてあるプリンターが一部にありますが、すべて「手差しトレイを使用してください」と注記があります。かといって手差しトレーでは、一度に印刷できる枚数が大きく制限されてしまい、プリンタまで何度も行き来しなければならなくなります。（プリンタを担当者の前に設置すれば済むことですが）。どうしたかというと…厚みが薄い方に下敷きをして高さを合わせるということが当面最適だという結論に至りました。
なお、もちろん、用紙をA4縦に配置することでもこの問題を軽減可能です。（が、完全ではなさそうです）
この問題は、テスト用にユ00520を一箱(500枚）ご提供いただいてから発覚したもので、その前のA4コピー用紙でのテストではわかっていませんでした。ほんと、「現場には魔物がいる」です。ただ、この点は以前から嫌な予感はしていました。
この方法も枚数が減ってくると万能ではありませんで、適宜用紙追加が必要です。この手差し運用推奨は、地味に痛打です。手差しが必要というより、高低差が一定以下になるように少しずつしか印刷できない、というのが実情で、「巨大な手差しトレイ」では解決しないのも難しいところです。
これを1000枚やろうと思うと、一日に50回も手差しに給紙することになるわけで、「手差しに給紙するトレイ」という謎なギミックの開発が必要になってしまいます。最初の50枚と後の50枚で印刷の向きを180度変えるなども試したのですが、それも設定が地味に面倒ですし、一枚でも間違うと逆向きになったものを再印刷する手間が増えることに対して、RPAで自動化できないか…などいろいろな論点がまだ残っています。ユ00520…おそるべし。
⑦「０リセット」という暴力
というわけで、弊社の昨年末からの日本郵便転換プロジェクトは、あと数日で一旦ゴールを迎えます。最初はただの相見積もり案件だったのですが、全社員の2割近くを巻き込んで業務全体を変革する中小企業にしては大プロジェクトになってしまいました。
終盤は、「あと1週間延ばせば楽になる」と耳元でささやく悪魔との闘いでした。そして、途中何度も担当者と相談していましたが、やっぱり現在の業務ではあるが、取り込み漏れしている仕様はありました。いや、きっとあるだろうと思っていました。担当者が確認してチェックしてくれるとしてもそれが完全ではないことは普通にありうることです。
しかし、慌ててプログラムに仕様追加を要望して追加費用が発生して…ということはしません。それは、業務フローの全面的な再構築が必要になることが明らかになった3月から、実は本件はただ単に、運送業者を変えるだけのプロジェクトではなく、「やらなくてもよいが、やった方が顧客のためになる」と頑張っていたことをやめ、月産2000件の時代のフローをほぼ同じ人数で月産2万件に耐えうるものに刷新するというグロース戦略の一部になっていたからです。
その中で何を重視するか、と言えばグロースのために必要なことは、1件当たりの平均コストと、平均発送所要日数の短縮であり、工程の増員を可能にする（スケーラブルな組織にする）ことであり、あまりインターネットに強くない人や、自分だけ特別対応してほしい人への対応を丁寧にすることやコスト度外視のエラー率低下、ではなかったのです。
この「間違った誠実さ」からの転換を指揮できるのは、経営者であり、その付託を受けた外部者です。いままでその「誠意」ある工程を構築してきたメンバーが既存の価値の破壊を自ら起こしてこれを0から再構築することはなかなかできないことです。そして、経営的観点からは結果として価格競争力を強め、販売量を増やし、そしてさらに設備投資や広告投資を増やしていく、という拡大思考に転換するためにこのプロジェクトを利用した、という言い方もできると思います。これが「チェンジマネジメント」なのだと弊社では考えています。
そんなことをすると反発が大変だろう、と心配される方も多いと思いますが、基本的には経営者が責任を取り、あいまいな態度を取らなければ、現場は従います。だって、新しい工程の方が楽なのですから。今回も、私が言いきれば、営業も物流も皆さん協力してくれ、そして、さらなる成長のために何かを捨てて新しいものにしていかなければならない、という考え方を手に入れることができつつあります。
先ほど「一旦」ゴールを迎える、と言いましたが、近日中に業者は切り替わります。しかし、日本企業がこの30年あまり忘れてしまった、成長のために日々新しいものを取り込み、古いものを捨て続ける、というダイナミズムはこの会社でまだ始まったばかりです。これからも、ご縁ある限り、社員メンバーを引きずるようにしながら、弊社はその先頭に立って行きたいと思っています。
