気づいたら社内ツールが20個超えていた — 中小ECが「全部内製」に行き着いた話

ふと社内のツール棚卸しをしてみたら、自社で作って自社で回しているWebアプリ・自動化Botが20個を超えていました。 楽天・Yahoo・Amazon・Shopify・ZOZO・SHOPLIST・auPAY・Qoo10といったモールを横断する在庫・価格・受注の管理から、倉庫のピッキング支援、納前検品、お客様問い合わせの一元管理、商品画像の生成、SNS投稿の自動化まで。 気がついたら、業務のかなりの部分が「うちの中で作って、うちの中で直している」状態になっていました。

最初から「全部内製でいくぞ」と決めていたわけでは、まったくありません。 むしろ、できるだけ外のサービスや外注パートナーに任せて、自分たちはブランドと商品づくりに集中したかった、というのが本音です。 ではなぜ、こうなったのか。 本記事では、岐阜の中小EC事業者である私たちが、「結局、社内で作るのが一番早かった」という結論に何度も辿り着いた、その裏側を書いてみたいと思います。

はじまりは「外注したら、噛み合わなかった」の連続だった

EC運営を続けていると、業務の細部はどんどん固有化していきます。 扱う商品、出荷の波、モールごとのルール、現場スタッフのオペレーション。 パッケージのSaaSや外注パートナーに任せようとすると、たいていどこかで「うちのやり方とは違う」「ここだけは譲れない」という小さなズレが出てきます。 そのズレは、最初は些細でも、毎日積み重なるとオペレーション全体の足を引っ張ります。

たとえば、ある時期、倉庫オペレーションを外部の仕組みに乗せようと検討したことがあります。 ところが、私たちの取り扱う商品は色・サイズのバリエーションが多く、棚の構成も独自のロジックで組まれていました。 標準のピッキング動線に当てはめようとするほど、現場の動きはむしろ遅くなる。 「うちの倉庫」に最適化しないと意味がないことが、運用してみて初めて分かりました。

似たような体験を、価格管理・在庫同期・問い合わせ対応・商品画像の制作と、領域を変えながら何度も繰り返しました。 そのたびに「自分たちで作ったほうが早いし、間違いがない」となり、社内の引き出しに小さなツールが一つずつ増えていきました。

エピソード1：8モールの価格を毎日見るのが、人間には無理だった

私たちは現在、楽天・Yahoo・Amazon・Shopify・ZOZO・SHOPLIST・auPAY・Qoo10 と、8つのモール／自社ECで商品を販売しています。 モールごとに価格改定のルールも、セール時の値引き計算も、競合の動きも違います。 これを人間が毎日「目で見て」「Excelで突き合わせて」「一件ずつ更新する」のは、現実的に不可能でした。 担当者を一人つけても回らない。二人にしても、ミスは増えこそすれ減らない。

最終的に、社内で8モール横断の価格管理ツールを作りました。 全モールの現在価格・税抜換算・粗利・競合最安を1画面に並べ、変更したいものを選んでカートに入れる感覚で一括反映する。 楽天はAPI、Shopifyはタグ越し、SHOPLISTはFTP、Qoo10はCSV+メール送信と、モールごとに「届け方」もバラバラなので、その違いを全部ツール側に閉じ込めました。

このツールができてから、価格改定は週に一度の意思決定の場になりました。 担当者が「どのモールでいくらにする」を入力するだけで、配信は全自動。 「価格を変える」という仕事が、「値づけを考える」仕事だけに戻ってきた感覚があります。

エピソード2：倉庫ピッキングは、スマホ片手のスタッフがいちばん速い

倉庫オペレーションも、当初はパッケージや汎用ハンディ端末を検討していました。 けれど、現場のスタッフが一番効率よく動けるのは、結局のところ「いつも使っている自分のスマホ」だったんです。 ハンディ端末を導入しても、立ち上げが遅い・操作系が独特・現場の声が反映されにくいといった摩擦が必ず出る。

そこで、社内でスマホ向けの倉庫ピッキング支援アプリを作りました。 音声でピッキング指示を読み上げ、JANコードはスマホのカメラでスキャン、途中で中断してもブラウザのストレージから状態が復帰する。 ベテランも新人も、同じスマホ画面を見ながら、自分のペースで進められる作りです。 「ハンディ端末を導入する代わりに、スタッフのスマホを賢くする」という発想でした。

このアプリの良いところは、現場の不満や要望をその週のうちにアプリ側に反映できることです。 「読み上げが速すぎる」「棚番だけ読み上げてほしい」「撮影モードの位置がずれる」—— こうした現場の声は、外注した仕組みに反映するには稟議も見積もりも必要ですが、社内で作っていれば、現場の声がそのまま開発タスクになります。

エピソード3：4モールに散らばる問い合わせを、ひとつの受信箱にまとめた

お客様からの問い合わせは、楽天・Amazon・Yahoo・メルカリShops の管理画面にそれぞれ届きます。 モールごとにログインして、対応して、また別のモールにログインして……というのは、件数が増えてくると現実的に回りません。 担当の割り振りミスも、二重対応も、対応漏れも起きやすい。

社内で作った問い合わせ統合アプリは、4モールの問い合わせを1時間ごとに自動で集めてきて、ひとつの受信箱に並べます。 未割当→担当割当→対応中→完了、というステータスを管理しながら、過去のお客様メッセージ・店舗側の返信を時系列で並べて表示。 AIが過去の対応文脈を踏まえた返信ドラフトを書いてくれるので、担当者はそれを読み、自分の言葉に直して送る。 「考える時間」だけを残して、「探す時間」「ログインする時間」「思い出す時間」を削っていったイメージです。

内製化のいちばんのリターンは「業務とツールが並走して進化すること」

ここまで具体例を3つ書きましたが、ほかにも、納前検品アプリ・商品画像の自動生成ツール・モールごとのDLBot群・ブログ自動投稿・SNS自動投稿など、数えていくとキリがありません。 ただ、一つひとつは派手でもなく、SaaSとして売れるような完成度のものでもない。 「うちの業務にフィットしていて、毎日確実に時間を作ってくれる」という、それだけのツールたちです。

内製化を続けてきて感じる、いちばんのリターンは何かといえば、業務とツールが同じスピードで進化していくことだと思います。 モールの仕様が変わった、現場のオペが変わった、新しいブランドを立ち上げた—— そのたびに「ツール側を変える」が当たり前になっているので、業務が止まりません。 これは、外部サービスや外注に依存していると、なかなか得られない種類の機動力です。

もちろん、内製化が万能だとは思っていません。 作る体力・直し続ける体力がない領域では、素直にSaaSや外部パートナーに頼るほうがずっと健全です。 ただ、「業務のど真ん中」だけは、自分たちで触れる状態にしておきたい。 私たちが7年やってきて辿り着いた、いまのところの結論はそんなところです。

同じ悩みを抱えている事業者さまへ

「外注したけど噛み合わなかった」「SaaSが自社のオペに合わない」「でも社内に開発リソースがない」—— 私たちも、ずっとそうでした。

もし、同じような壁にぶつかっているEC事業者さま・物流の現場の方がいらっしゃれば、 私たちが内製化の過程で得たノウハウや、社内で動かしているツールの一部を、 EC運営コンサルティング や 物流DX支援 のかたちでお渡しできるかもしれません。

「うちの場合はどうしたらいいだろう」というご相談は、お問い合わせフォーム よりお気軽にどうぞ。 無理に内製化をおすすめすることはありません。御社にとって一番健全なやり方を、一緒に考えるところから始めさせてください。