結論から書きます。
エクセルでの受注管理は「注文件数」だけでは壊れません。
壊れるのは、件数と同時に販売チャネルの数、作業する人の数、出荷後の変更対応という要素が重なったときです。
この記事では、その分岐点を4つに分けて、どの条件を超えたら手作業では持たなくなるのかを整理します。
逆に言えば、この条件に達していないなら、まだエクセルで十分に回せます。
いま、こういう状態になっていませんか。
朝いちばんに各モールの管理画面から注文CSV（表計算ソフトで開ける形式のデータファイル）をダウンロードして、1枚のシートに貼り付ける。
項目名がチャネルごとに違うので、並び替えて整える。
在庫を引き当てて、出荷指示のシートを作る。
ここまでで午前中が終わる。
夕方、キャンセルと住所変更の連絡が入って、もう出荷指示を出したぶんを手で戻す。
この作業自体は、ひとつずつ見れば難しくありません。
難しくないからこそ、限界が見えにくい。
「まだいける」と思っているうちに、ある日ミスが出て、そこで初めて手作業の限界に気づく、という順番になりがちです。
判断材料として、どこで何が起きるのかを先に知っておく意味はあります。
私たちも、自社ECの受注管理を長らくスプレッドシート（表計算ソフト。
エクセルと同じ形式で、複数人が同時に開けるもの）で回していました。
破綻したのは、月間の注文が500件を超えたあたりです。
同時に編集できるぶんエクセルより耐えましたが、限界が来る構造は同じでした。
起きたことは4つです。
出荷済みの注文にもう一度送り状を作ってしまう二重出荷と、逆に出荷そのものが漏れること。
キャンセルや返品の反映が抜けて、売上と在庫の数字が実態と合わなくなること。
在庫がズレて売り越しや欠品が起きること。
そして複数人で開いている最中に、誰かの編集が上書きされて消えること。
どれも一度きりではなく、繰り返し起きました。
目次
なぜエクセル管理は「件数」ではなく「掛け算」で壊れるのか
受注管理の作業量は、注文件数に比例して増えるわけではありません。
増え方は掛け算に近くなります。
ひとつの注文を処理するために必要な判断は、おおよそ「どのチャネルの注文か」「在庫はあるか」「同梱するものはあるか」「送り先に特殊な指定はあるか」に分かれます。
チャネルが1つなら判断は単純ですが、2つ、3つと増えると、チャネルごとに送料の扱いも、ギフト対応の有無も、キャンセル可能な期限も違います。
つまりルールの組み合わせが増えるのであって、行数が増えるだけではありません。
もうひとつの構造的な問題は、エクセルが「今の状態」しか持たないことです。
受注データは本来、受付・入金確認・引当・出荷指示・出荷済み・完了という状態を持ちます。
ところが表計算ソフトのシート上では、これをステータス列に手で書き込むことで表現します。
書き換えた瞬間に前の状態は消えます。
誰がいつ書き換えたかも残りません。
これが致命的になるのは、トラブルが起きたときです。
「この注文、なぜ出荷済みになっているのか」を追いかけようとしても、追いかける材料がありません。
結果として、記憶と推測で原因を探すことになります。
放置するとどうなるか
手作業のままで件数が増えていくと、次の順番で問題が出てくることが多いです。
最初に出るのは作業時間の膨張です。
これは自覚しやすい。
次に出るのが属人化です。
シートの構造とルールを理解している人が1人しかいない状態になり、その人が休むと出荷が止まります。
これは自覚しにくい。
困っていないからです。
困るのは、その人が休んだ日だけです。
その次に出るのが出荷ミスです。
誤配送、二重出荷、欠品出荷。
これらは単発では起きますが、手作業が限界に近いときは、同じ週に複数回起きるという形で表れます。
最後に出るのが数字が信用できなくなることです。
在庫数が実地棚卸と合わない。
売上集計が会計と合わない。
この段階になると、改善しようにも現状を測る手段がなくなります。
判断の土台が崩れるので、影響がいちばん大きいのはここです。
分岐点1：販売チャネルが2つを超えたとき
自社サイトのみ、あるいはモール1つのみであれば、エクセルはかなり長く持ちます。
管理画面のCSVをそのまま使えて、項目の並び替えも1パターンで済むからです。
チャネルが3つ目に入ると、状況が変わります。
CSVの項目名と並び順がそれぞれ違うため、貼り付けのたびに整形が必要になります。
さらに在庫の引き当てが問題になります。
同じ商品を複数チャネルで売っている場合、どこか1つが売り切ったことを他のチャネルに反映する作業が発生します。
この反映が手作業だと、反映までの時間差がそのまま売り越し（在庫がないのに注文を受けてしまうこと）のリスクになります。
対処の選択肢としては、まずチャネルごとに在庫を分けて割り当ててしまう方法があります。
売り越しは防げますが、機会損失は増えます。
もうひとつは、在庫連携を自動化するツールを入れる方法です。
分岐点2：受注作業に触る人が2人以上になったとき
1人で回している間は、シートがどれだけ独自ルールでも問題は起きません。
作業者の頭の中にルールがあるからです。
2人目が入った瞬間に、いくつかのことが起きます。
同時編集による上書き、ステータスの解釈違い（「確認済み」が入金確認なのか出荷準備完了なのかが人によって違う）、そして「誰が変更したか分からない」という状態です。
クラウド上の表計算ツールを使えば同時編集の問題は減りますが、解釈違いと変更履歴の問題は残ります。
この段階での選択肢は、シートの列に入力規則を設定してステータスの表記を統一する、変更ログ用の別シートを作って手で記録する、あるいは受注管理システムに移す、のいずれかです。
前の2つは運用の負担が増えるので、続けられるかどうかで判断が分かれます。
分岐点3：出荷後の変更対応が週に何度も発生するようになったとき
受注管理で最も手作業が効かないのが、出荷指示を出した後の変更です。
キャンセル、住所変更、商品の追加、返品。
これらは注文データだけでなく、在庫、売上、配送業者への連絡と、複数の場所を同時に直す必要があります。
エクセルではこの「同時に直す」が保証できません。
1か所だけ直して他を直し忘れる、という事故が起きます。
しかも直し忘れは、その場では気づけません。
月末の集計や棚卸のタイミングで、ずれとして発覚します。
変更対応が月に数件であれば、チェックリストを作って手で潰す運用で持ちます。
週に何度も発生する規模になると、チェックリスト運用そのものが作業として重くなります。
分岐点4：シートの行数が増えて動作が重くなったとき
これは分かりやすい限界です。
数式や条件付き書式を多用したシートは、行数が数千を超えたあたりから開くだけで時間がかかるようになります。
ファイルが壊れる、保存に失敗する、といったことも起きます。
対処としては、月ごとにファイルを分割する方法があります。
ただしこれをやると、期間をまたいだ検索や集計ができなくなります。
「先月注文したお客様の再注文かどうか」を確認するのに、複数ファイルを開くことになります。
分割は延命策としては有効ですが、検索性を犠牲にしている、という理解の上でやるかどうかの判断になります。
分岐点5：顧客が誰なのか見えなくなったとき
これは作業ミスとは別の、もっと静かな限界です。
シートに並んでいるのは「注文」であって「顧客」ではありません。
同じ人が何回買っているのか、これまでいくら使っているのか（LTV。
顧客生涯価値。
1人の顧客が取引期間全体でもたらす売上）は、集計しない限り見えません。
私たちの場合、受注処理が回っているうちは問題として認識していませんでした。
ところが、リピート施策を考えようとした段階で、そもそも誰がリピーターなのかを答えられないことに気づきました。
注文の履歴は残っているのに、顧客軸の情報が無い。
これは行を増やしても解決せず、データの持ち方そのものを変えるしかありませんでした。
手作業でどこまでやれるか
正直に書くと、手作業でやれる範囲は思っているより広いです。
以下の条件が揃っているなら、システムに移さなくても回ります。
- 販売チャネルが1〜2つ
- 受注作業に触る人が1人（もしくは、完全に担当時間が分かれている2人）
- 出荷後の変更対応が月数件程度
- 取扱商品の点数が少なく、在庫の引き当てが単純
- 同梱物やギフト対応などの例外処理がルール化されている
この範囲であれば、エクセルのほうが速いことすらあります。
システムは決められた形にデータを入れる必要がありますが、エクセルは例外的な処理をその場で書き足せるからです。
柔軟性という点では手作業に分があります。
逆に、限界が来るのは上の条件が崩れたときです。
特に「人が増える」と「例外が増える」の2つが重なると、急速に苦しくなります。
人が増えると認識の統一が必要になり、例外が増えるとルール化できない判断が増えるからです。
この2つは、エクセルというツールの性質上、どうやっても解決できません。
表計算ソフトは計算のための道具であって、業務の状態を管理するための道具ではないためです。
なお、移行すれば全部が楽になるわけではありません。
受注管理システムを入れると、初期設定に時間がかかり、例外処理は逆にやりにくくなることがあります。
月々の費用も発生します。
移行の判断は「エクセルが辛いかどうか」ではなく、「辛さの原因が、上の分岐点のどれに当たるか」で見たほうが精度が上がります。
分岐点3だけが問題なら、システム全体を入れ替えなくても、変更対応の手順を整えるだけで済む場合もあります。
まとめ
- エクセル管理が壊れるのは件数の増加ではなく、チャネル数・作業人数・例外処理の掛け算による
- 限界の兆候は、作業時間の膨張 → 属人化 → 出荷ミス → 数字が合わない、の順で表れることが多い
- 分岐点は4つ。チャネルが3つ目に入る、作業者が2人以上になる、出荷後の変更が週に複数回になる、シートが重くなる
- チャネル1〜2つ・作業者1人・例外が月数件までなら、手作業のほうが柔軟で速い場合もある
- 「人が増える」と「例外が増える」が重なったときは、エクセルの構造上、運用の工夫では解決しにくい
- 移行にも初期設定の手間・費用・柔軟性の低下というコストがあるため、どの分岐点で詰まっているかを特定してから判断する選択肢もある