ExcelとAccessの継ぎ接ぎから卒業。受注受付と配車を、自社専用システムに載せ替えた話

相談をいただいた時点の状況

年商6億円、従業員38名。九州を拠点に、完成車を全国へ運ぶ自動車陸送の会社です。ディーラーやオークション会場からの依頼を受け、キャリアカーとドライバーを手配して運びます。取引先からのご紹介で、社長から直接ご連絡をいただきました。

最初の打ち合わせで出てきた言葉が、この案件のすべてを表していました。「うちの受注受付、寺田（仮名）が休むと止まるんです。去年インフルエンザで3日休んだとき、会社が半分止まりました」。

受注の入口は4つありました。電話、FAX、メール、そして一部の大口取引先が使うWebフォーム。それぞれ形式がばらばらで、車種の書き方も納期の表現も統一されていません。「本日中」と書かれていても、それが何時までなのかは相手によって違う。

入ってきた依頼は、まずExcelの受付台帳に手で転記されます。そこから、20年ほど前に前任者が作ったAccessの配車台帳へ、もう一度入力される。同じ情報を2回打ち込む運用が、長年そのまま続いていました。

配車の割り当ては、完全に寺田さんの頭の中にありました。どのドライバーがどのルートに慣れているか、どの車両が何台積みか、どの取引先が何時までの納車を求めるか。20年分の判断が、1人に集約されていたわけです。

最初にやったこと ── 受注の全パターンを紙に書き出す

1か月目は、システムの話を一切しませんでした。まず受注が入ってから配車が確定するまでの流れを、1枚の図にすることから始めました。

寺田さんに横についていただき、実際の依頼を1件ずつ追いかけます。「この依頼が来たら、次に何を見ますか」「なぜこのドライバーを選んだんですか」。判断の理由を、その場で言葉にしてもらう作業です。

2週間で、受注のパターンが11通りあることが分かりました。取引先の種類と、依頼の緊急度と、車両の特殊性の組み合わせです。本人は「毎回違う」と言っていましたが、並べてみれば11通りに収まりました。

配車の判断基準も、8つのルールとして書き出せました。優先順位まで含めて明文化したのは、これが初めてだったそうです。

この図と一覧を社長にお見せしたとき、「これが出てきただけで、だいぶ気が楽になりました」と言われました。属人化の恐ろしさは、失われるまで中身が見えないことにあります。

打ち手① 受注の入口を1つに揃えた

最初に手を付けたのは、4つに分かれていた受注の入口です。

取引先に「今日からWebフォームだけにしてください」とは言えません。相手にも都合があります。そこで、入口はそのまま4つ残し、受け取ったあとの形を1つに揃える方針にしました。

• Webフォーム：そのまま受注データになる
• メール：本文から必要項目を抜き出して受注データにする
• FAX：電子FAXに切り替え、画像から項目を読み取る
• 電話：受付画面に直接入力する。項目は7つだけ

電話の受付画面は、入力項目を7つに絞りました。依頼元、車種、台数、積地、卸地、希望納期、備考。それ以上は聞きません。追加情報は、必要になった時点で確認すればいい。受付の段階で完璧を目指すと、電話が長くなります。

FAXの読み取りは、精度を100%にしようとしませんでした。読み取り結果を人が確認する画面を挟み、間違っていたら直す。全自動を狙うより、確認の手間を最小にするほうが現実的です。

打ち手② ExcelとAccessのデータを移行した

次が、20年分のデータ移行です。ここがこの案件でいちばん神経を使った部分でした。

Accessの台帳には、過去12万件を超える配車履歴が入っていました。取引先ごとの単価、ドライバーの稼働履歴、ルートの所要時間。この履歴こそが、この会社の資産です。移行に失敗すれば、20年分が消えます。

手順は慎重に組みました。

1. まず読み取り専用でコピーを取り、元のAccessには一切触らない
2. コピーからデータ構造を解析し、新システムの設計に反映する
3. 移行スクリプトを書き、テスト環境で3回移行を試す
4. 件数・金額の合計・取引先数の3点で、移行前後の照合を行う
5. 本番移行後も、旧Accessは1年間そのまま残す

最後の「旧システムを残す」は必ずやります。移行後に「あのデータが見当たらない」という事態は、どれだけ検証しても起こり得ます。捨てるのは、1年間問題が出なかったあとで構いません。

既存の帳票も、そのまま出力できるようにしました。取引先に提出する運送指示書や請求書の様式が変わると、相手側の事務が混乱します。社内は変えても、社外に出るものは変えない。これが移行の鉄則です。

打ち手③ 配車の割り当てを半自動にした

3つ目が、寺田さんの頭の中にあった8つのルールを、システムに移す作業です。

重要なのは、最終判断は人が行う設計にしたことです。システムがやるのは、条件に合う候補を3つまで提示するところまで。決めるのは寺田さん、あるいはその日の担当者です。

下の2つを意図的に自動化から外しています。天候や取引先との関係は、数値化できません。数値化できないものを無理に自動化すると、判断の質が落ちます。

この設計にしたことで、寺田さん以外の3名も配車を組めるようになりました。ベテランの判断を奪ったのではなく、判断に必要な情報を全員が見られるようにした、という形です。

つまずいた点 ── ベテランの抵抗ではなく、若手の遠慮

導入前、いちばん心配していたのは寺田さんの抵抗でした。20年やってきた仕事の一部が仕組みに置き換わるわけですから、面白くないはずだと。

実際は逆でした。寺田さんは初日から協力的で、「これで休めます」と笑っておられました。詰まったのは、別のところです。

「システムがこう出してますけど、寺田さんならどうするかなと思って、結局聞いちゃうんです」

若手が、システムの提示した候補を信用しきれず、結局寺田さんに確認していました。属人化が形を変えて残ってしまったわけです。

対策として、候補ごとに「なぜこの組み合わせなのか」を1行で表示するようにしました。「拘束時間に余裕あり／このルートの走行実績12回」といった具合です。理由が見えると、人は判断できるようになります。

この修正を入れてから2か月で、寺田さんへの確認は目に見えて減りました。ブラックボックスは、たとえ精度が高くても使われません。

結果 ── 受注処理が月120時間減り、配車ミスが8割減った

稼働開始から6か月後の実測値です。

受注受付から配車確定までの事務時間が、月120時間削減されました。二重入力がなくなったことが最大の要因です。

配車ミス（車両の積載超過、ドライバーの拘束時間超過、納車時間の取り違え）は8割減りました。とくに拘束時間の超過は、システムが候補から自動で除外するため、ゼロになっています。これはコンプライアンス上も大きい。

そして受注受付ができる人が1名から4名になりました。社長が最初におっしゃっていた「寺田さんが休むと止まる」状態は、解消されています。

支援の進め方とスケジュール

要件定義から稼働まで7か月、そこから月額保守に移行しています。

開発中は2週間ごとに動くものをお見せする進め方にしました。仕様書だけで進めると、出来上がってから「思っていたのと違う」となります。実物を見ながら直すほうが、結果的に速い。

7か月目は、旧システムと新システムを並行で動かしました。片方が止まっても業務が続く状態を1か月つくってから、旧システムを止めています。

費用と、作らなかったもの

開発費280万円、月額保守8万円（いずれも税別）です。

見積もりの段階で、作らないものを先に決めました。これが費用を抑えるいちばんの方法です。

• 会計連携：既存の会計ソフトにCSVで渡す形にした。連携機能は作らない
• 請求書発行：既存の様式をそのまま使う。システム側では作らない
• ドライバー向けアプリ：現時点では不要と判断。将来の拡張余地だけ残す
• 取引先向けの進捗照会：要望はあったが、第2フェーズへ送った

最後の進捗照会は、社長が最も欲しがっていた機能でした。ですが受注と配車が安定する前に外向けの機能を作ると、不安定なものを取引先に見せることになります。順番を守ることを優先しました。

削減効果は月120時間、人件費換算で年間280万円程度です。開発費と保守費を合わせても、2年目には回収できている計算になります。

作らなかったものと、その理由

開発費を抑えるうえで、いちばん効いたのは作らない範囲を先に決めたことです。この案件で見送った機能と、その理由を挙げます。

最後の分析ダッシュボードは、社長からのご要望でした。お断りした理由は、「見る習慣がないところに、見る道具を作っても使われない」からです。まずCSVを出して手元で集計してもらい、実際に見る習慣がついてから作るほうが確実です。

結果として、1年後に社長ご自身が「この数字が毎月見たい」と具体的に言えるようになりました。いま第2フェーズで、その部分だけを作っています。

開発を外注するときの注意点

この案件は私たちが開発まで手がけましたが、他社に発注される場合の注意点もお伝えしておきます。

1. 業務フローを描いてから見積を取る──描けていない状態で見積を取ると、必ず高くつきます。作る範囲が決まっていないためです
2. 2週間ごとに動くものを見せてもらう──仕様書だけで進む契約は避けてください。出来上がってから違うと分かると、手戻りが大きすぎます
3. データ移行の検証方法を先に決める──件数・合計金額・マスタ件数の3点照合を、契約書に書いておくくらいで構いません
4. 旧システムを1年残す条件を入れる──移行後に問題が出ないとは限りません
5. 保守費用を最初に確認する──開発費が安くても、保守が高いと総額で逆転します

とくに1番目が重要です。業務フローは、発注側が描くべきものです。システム会社に描いてもらうと、その会社が作りやすい形になります。それは必ずしも自社に合う形ではありません。

描き方が分からない場合は、実際の依頼を10件、紙に追いかけてみてください。「この情報が、次にどこへ行くか」を矢印で結ぶだけで、かなりのことが見えます。

よくいただく質問

「既製のパッケージでは駄目ですか」──まず既製品を検討すべきです。この会社でも3製品を比較しました。合わなかったのは、配車の判断ルールが特殊だったためです。8割合う製品があるなら、業務のほうを寄せるほうが安く済みます。

「開発期間が長くないですか」──7か月は、この規模では標準的です。逆に3か月で作れると言われたら、要件定義を省いている可能性があります。作り直しになるほうが高くつきます。

「ベテランが辞めたらどうしますか」──この案件の目的が、まさにそこでした。判断ルールを8つに明文化した時点で、リスクはかなり下がっています。完全にはなくなりませんが、20年分が一度に消えることはありません。

「保守は必要ですか」──必要です。業務は変わり続けるので、システムも変え続ける必要があります。保守を切ると、3年後には「使いにくいから」と新しいものを作り直すことになります。

いま、どうなっているか

月額保守で毎月改善を続けています。現場から出た要望を月1〜2件ずつ反映する形です。大きく作り直すのではなく、少しずつ足していく。

第2フェーズとして、取引先向けの進捗照会の準備を進めています。受注と配車が安定したので、そろそろ外向けに出せる段階になりました。

寺田さんは、いまは配車の実務よりも若手の育成に時間を使っておられます。判断のルールが文書になったことで、教えやすくなったそうです。

同じ状況の会社へ

「ExcelとAccessの継ぎ接ぎで限界」という会社は、たくさんあります。共通しているのは、その継ぎ接ぎが「動いてしまっている」ことです。動いているから、止めて作り直す踏ん切りがつかない。

判断の目安は、「その仕組みを理解している人が何人いるか」です。1人なら、それは仕組みではなく属人化です。2人でも危うい。3人以上が触れるなら、まだ猶予があります。

作り直すと決めたら、最初にやるのは業務フローの可視化です。システム会社に相談するのは、そのあとで構いません。フローが描けていない状態で見積を取ると、必ず高くつきます。作る範囲が決まっていないためです。

システムの画面構成

どんな画面を作ったのかを、簡単に書いておきます。画面数は全部で7つです。多く作りませんでした。

最も時間をかけたのは受注受付の画面でした。電話を受けながら打ち込むので、マウスを使わずキーボードだけで完結する必要があります。タブキーの移動順を、実際の会話の順番に合わせました。

配車ボードは、それまでホワイトボードで管理していたものを画面に移した形です。紙やホワイトボードでうまく回っている部分は、見た目をなるべく変えないのが定着のコツです。

導入後に出てきた、想定外の効果

稼働から半年で、当初想定していなかった変化が3つ出ました。

1. 取引先からの問い合わせが減った。「あの車、いま どこですか」という電話が、月40件から12件に。受注一覧で状態が見えるので、事務が即答できるようになったため
2. ドライバーの日報提出率が上がった。紙の日報は提出率が7割程度だったが、スマホから5項目に絞ったところ98%に。入力の手間が下がると、提出率は素直に上がる
3. 単価の交渉材料ができた。ルートごとの実際の所要時間と燃料費が見えるようになり、採算の合わないルートについて取引先と条件を話せるようになった

3つ目は、経営に直接効きました。それまで「なんとなく儲かっていない気がする」だった路線が、はっきり数字で出た。結果、2つのルートで単価改定に応じてもらえています。

業務システムの価値は、効率化だけではありません。それまで見えなかった数字が見えるようになることのほうが、経営には効くことがあります。

保守で毎月やっていること

月8万円の保守で何をしているのか、具体的に書いておきます。

• 現場から出た要望のヒアリング（月1回・30分のオンライン）
• 軽微な改修（月1〜2件。画面の並び替え、項目追加など）
• データのバックアップ確認と復旧テスト（四半期に1回）
• サーバーとライブラリの更新（セキュリティ対応）
• 利用状況のレポート（どの画面がよく使われているか）

最も価値が出ているのは1つ目と2つ目です。業務は変わり続けるので、システムも変え続ける必要があります。ここを止めると、3年後には「使いにくいから」と作り直すことになります。

実際、稼働から1年半で反映した改修は28件。うち大きめのものは4件で、残りは画面の細かい調整です。この積み重ねが、現場の「使いやすい」を作ります。

最後のレポートも効いています。使われていない画面が見つかれば、なくす判断ができる。機能を足すだけでなく、減らすことも保守の仕事だと考えています。

経営者からよくいただく反論と、それへの答え

「いま動いているものを、わざわざ壊す必要があるのか」──最も本質的な問いです。判断の目安は「その仕組みを理解している人が何人いるか」。1人なら、それは仕組みではなく属人化です。動いているうちに手を打つほうが、止まってから慌てるより安く済みます。

「開発費280万円は高い」──比較対象によります。パッケージなら初期費用は抑えられますが、業務を製品に合わせる必要が出ます。この会社では配車の判断ルールが特殊で、それができませんでした。8割合う製品があるなら、迷わずそちらをお勧めします。

「作ったあと、頼み続けないといけないのでは」──保守は必要です。ただし、他社に引き継げる形で作ります。この案件でも、設計書とデータ構造の資料を納品しています。囲い込む作り方はしません。

「7か月は長い」──この規模では標準的です。3か月で作れると言われたら、要件定義を省いている可能性を疑ってください。作り直しになるほうが、結果的に高くつきます。

「うちの業務は特殊すぎる」──特殊なのは全体の2割程度で、残り8割はどの会社も似ています。特殊な2割だけを作り、8割は既存の考え方を使う。この切り分けができれば、費用は大きく下がります。

この支援の、次にあるもの

この事例では受注と配車を作り直しました。次のフェーズは取引先向けの進捗照会です。ここまで来ると、システムは社内の効率化の道具から、取引先との関係を作る道具に変わります。

業務システムは、作って終わりではありません。会社の成長に合わせて、役割そのものが変わっていきます。

私たちが月次顧問という形をとっているのは、この「次」に付き合うためです。プロジェクト型で一度きりの支援にすると、仕組みは残っても、次の判断のときに相談先がなくなります。

逆に、社内で回るようになった領域からは、こちらの関与を意図的に減らしていきます。ずっと同じ量で入り続ける支援は、依存を作るだけだと考えています。

この会社でも、システムの領域についてはすでに関与を大きく減らしました。月次会議に同席する程度で、実務はすべて社内で回っています。

最後に ── この支援を振り返って

稼働から1年半、システムは止まっていません。当たり前のようですが、業務システムでは決して当たり前ではありません。止まらない理由は、機能を欲張らなかったことに尽きると考えています。

社長からは「作る前に、作らないものを決める打ち合わせが一番よかった」と言われました。要望を全部聞いてくれる会社より、断る理由を説明してくれる会社のほうが信用できる、というお話でした。

最後に、この案件で最も難しかった判断を書いておきます。取引先向けの進捗照会機能を、社長のご要望がありながら第2フェーズへ送ったことです。目の前の要望に応えるほうが喜ばれます。ですが、受注と配車が安定する前に外向けの機能を出せば、不安定なものを取引先に見せることになる。順番を守ることを選びました。1年後、その判断は正しかったと社長からも言っていただいています。

受注受付ができる人が1名から4名になったこと。数字としては地味ですが、経営上のリスクという意味では、この案件で最も大きな成果でした。属人化は、失われるまで金額に表れません。だからこそ、失われる前に手を打つ必要があります。

なお、この事例で使ったExcelとAccessの分析データは、いまも社内に残してあります。移行の判断が正しかったかを、あとから検証できるようにするためです。

この事例に関するご質問

この事例について詳しく聞きたい、自社の場合はどうかを知りたい、という方は、無料相談でお受けしています。30分、オンラインです。

事例の会社と業種や規模が違っても構いません。むしろ、違う条件での話のほうが、お互いに得るものが多いと思っています。

よくお受けするのは「うちの規模でも同じことができるか」というご質問です。答えは、たいてい「できるが、やり方は変わる」です。年商1億円の会社と10億円の会社では、同じ課題でも打ち手が変わります。そこをその場でお話しします。

支援に入る前に、必ず確認していること

どの案件でも、契約の前に4つのことを確認します。ここが揃っていない状態で始めると、途中で止まるからです。

1. 経営者が、この件に時間を使う気があるか。現場に任せきりにする前提の依頼は、お断りすることがあります。数字と方針に関わる話は、経営者が入らないと決まりません
2. 社内に、一緒に動く人が1人いるか。外部だけでは動きません。窓口になる方が1名いれば十分です。専任である必要はありません
3. いま何が起きているかを、数字で測れる状態か。測れないなら、測るところから始めます。ここに1か月かかることもあります
4. 半年から1年、続ける覚悟があるか。3か月で結果を求められる場合は、この支援は向きません。正直にそうお伝えします

4つ目でお断りしたことも、実際にあります。急いでいる会社に「時間がかかります」と言うのは気が引けますが、合わない支援を始めるほうが、お互いに損をします。

逆に、この4つが揃っていれば、業種や規模はあまり関係ありません。年商1億円の会社でも、10億円の会社でも、やることの本質は変わらないからです。

他のコンサルティング会社との違い

「他社と何が違うのか」とよく聞かれます。正直にお答えすると、やっていること自体は、そこまで変わりません。分析して、設計して、実行して、定着させる。手順は業界の標準です。

違いがあるとすれば、3つだと考えています。

2つ目が、実務では最も効きます。「こういう仕組みがあるといい」で終わらず、その仕組みを実際に作れる。ここでベンダーを挟むと、要件の翻訳に時間がかかり、意図もずれます。

3つ目は、当たり前のようで実行されていないことが多い項目です。着手前に測っていなければ、効果は比較できません。「体感で楽になった」は成果ではない、というのが基本姿勢です。

この事例をご覧になった方へ

ここまで読んでいただいて、「うちも同じかもしれない」と思われたなら、まず実際の依頼を10件、紙に追いかけてみてください。情報がどこへ流れるかを矢印で結ぶだけです。

それをやったうえで、判断がつかなければご相談ください。30分の無料相談では、売り込みをしません。状況を伺って、何が効きそうかだけをお伝えします。その場で契約をお願いすることはありません。

合わないと判断したときは、そう申し上げます。「いまはシステムを作り直すの段階ではない」とお伝えして終わったご相談も、実際にあります。無理に契約しても、お互いに時間を失うだけだからです。