【実績】水産加工会社の在庫・受発注をDX化｜課題の洗い出しから見積もり・スケジュール・開発・納品・保守までの全工程を公開

「在庫はホワイトボードと勘、受注はFAXと電話とLINE」。水産加工の現場では、いまだにこの状態で年商数億円を回している会社が珍しくありません。動いてはいるものの、担当者が一人休むと止まる。棚卸しのたびに帳簿と現物が合わない。取引先から「あの注文どうなってる？」と聞かれて即答できない。

この記事では、当社が実際に担当した水産加工会社の在庫管理・受発注のDX化案件について、課題の洗い出し→見積もり→スケジュール→開発→納品→保守という流れを、工程ごとに具体的に公開します。「システム会社に相談すると何をどこまでやってくれて、いくらかかって、どれくらいの期間で終わるのか」が見えないまま止まっている事業者の方に向けて、判断材料になるように書きました。

読み終えると、次のことが分かります。

• 水産加工という業種で、在庫・受発注のどこが具体的につまずくのか
• 見積もりが何を根拠に組まれているのか（内訳と人日の考え方）
• 着手から本稼働まで、どんなスケジュールで何が起きるのか
• 納品して終わりではなく、保守で何をどこまで見るのか

※ 本事例はクライアントの掲載許諾を得たうえで、社名・商品名など特定につながる情報を伏せ、数値の一部を丸めて掲載しています。金額・工数は同種案件の実績レンジであり、要件によって上下します。

案件概要：どんな会社の、どんな相談だったか

相談元は、地方で40年以上続く水産加工会社です。生鮮の仕入れから、切り身・干物・味付け加工、冷凍保管、出荷までを自社で行っています。

最初のお問い合わせ内容は「在庫管理システムを入れたい。いくらかかるか」でした。ただ、ヒアリングを進めると、本当に困っていたのは在庫そのものではなく「受注から出荷までの情報が一箇所にまとまっていないこと」だと分かります。ここを取り違えたまま在庫システムだけ導入すると、高い確率で使われずに終わります。

【工程1】課題の洗い出し：水産加工特有の「つまずきポイント」

最初の3週間は、システムの話を一切せずに業務の棚卸しに使いました。事務所と加工場に計5日間入り、受注担当・工場長・出荷担当・経理にそれぞれヒアリングし、伝票の実物を全部見せてもらっています。そこで出てきた課題は、大きく5つでした。

課題1：在庫が「重量」と「箱数」の二重単位で管理されている

水産加工でほぼ必ず出てくるのがこれです。仕入れはkg（重量）、加工後の製品は箱・パック（数量）、取引先への販売単位はまた別、という三段構えになっています。さらに、原魚10kgから製品が何パック取れるかは、その日のサイズや歩留まりで変動します。

市販の在庫管理ソフトは「1商品＝1単位」を前提にしているものが多く、この二重単位を扱えません。結果、現場は「システムには箱数だけ入れて、重量はExcelで別管理」という運用になり、二重入力が発生していました。

課題2：受注チャネルがFAX・電話・メール・LINEに分散

量販店からはFAX、外食チェーンからはEDIに近い専用フォーマットのExcel、地元小売からは電話とLINE、ふるさと納税と自社ECはそれぞれの管理画面。受注担当は毎朝これを全部開いて、紙の受注伝票に手書きで転記していました。

この転記作業だけで1日あたり約3.5時間。しかも転記した紙が加工場に回るまでのタイムラグがあり、「もう作り始めちゃったのに、その後キャンセルが入っていた」という事故が月に数回起きていました。

課題3：ロット・賞味期限・産地の追跡ができない

食品なので、万が一のときにロット単位で追跡できる必要があります。しかし実態は、加工日と原魚の仕入れロットの紐づけが手書きの作業日報にしか残っておらず、遡ろうとすると倉庫からファイルを引っ張り出して人力で照合するしかありませんでした。取引先の品質監査でも指摘を受けていた項目です。

課題4：欠品と過剰在庫が同時に起きている

冷凍庫にはいつ入れたか分からない在庫が積み上がる一方で、定番品が急な注文で欠品する。これは在庫数が見えていないというより、「引当済み（もう出荷が決まっている分）」と「フリー在庫」が区別されていないことが原因でした。ホワイトボードの数字は現物の総数なので、そこから何が売約済みか分からない。

課題5：すべてがベテラン1人の頭の中にある

「A社は木曜納品だけど祝日前は水曜にずらす」「B社は箱に必ず産地シールを貼る」といったルールが、どこにも書かれていませんでした。これは在庫管理の課題というより事業継続の課題で、今回のプロジェクトが動いた最大の理由でもあります。

なお、こうした「現場が回らない」タイプの課題は業種を問わず共通する部分もあります。EC・小売寄りの整理はEC サイト運営の課題をどう解決する？業務効率化・広告改善・制作体制まで整理する完全ガイドでもまとめています。

【工程2】見積もり：何を根拠に、どう金額を出したか

「システム開発の見積もりはブラックボックス」と言われがちなので、この案件でどう算出したかを開示します。当社は画面数×単価ではなく、機能単位で人日を積み上げ、最後にプロジェクト管理費を乗せる方式を取っています。

ステップ1：要件を「必須／推奨／将来」の3階層に仕分ける

ヒアリングで出た要望は全部で60項目以上ありました。これを全部作ると予算が跳ね上がるので、必ず3つに仕分けます。

• 必須（Must）：これがないと業務が回らない。今回は受注取込・在庫の二重単位・引当・出荷伝票・ロット記録の5領域
• 推奨（Should）：あると効果が大きいが、初回リリース後でもよい。売上分析・原価計算・発注点アラートなど
• 将来（Could）：構想としては聞いておくが、今回は作らない。ハンディ端末での棚卸し、取引先向けWeb発注画面など

この仕分けをお客様と一緒にその場でやるのが重要です。こちらが勝手に削ると「言ったのに入っていない」になり、全部入れると予算が通らない。第1回の見積もり提示時点で、必須のみ・必須＋推奨の2パターンを出しました。

ステップ2：機能ごとに人日を積み上げる

実際に提示した見積もりの内訳がこちらです（必須要件のみ・単価3万円／人日で計算）。

これに加えて、クラウド利用料などのランニングが月額約1.8万円（サーバー・バックアップ・SSL・メール配信）。推奨要件まで含めたパターンBは約560万円で提示し、最終的には必須のみで着手し、推奨は稼働後に保守枠の中で順次追加するという判断になりました。

ステップ3：見積もりに「含まないもの」を必ず明記する

トラブルの9割はここです。当社の見積書には、必ず「本見積もりに含まれないもの」を列挙します。この案件では以下を明記しました。

• ハンディターミナル・ラベルプリンタなどのハードウェア購入費
• 取引先側のシステム改修が必要になるEDI接続
• 既存Excelのデータそのものの内容精査（誤りの修正はお客様側で実施）
• 稼働後の新規機能追加（保守契約または別途見積もり）
• ネットワーク工事・PC入替

受注管理まわりのコスト感を一般論として押さえておきたい場合は、受注管理システムの料金相場は？月額費用の内訳と失敗しない比較ポイント完全ガイドもあわせてご覧ください。パッケージを使う場合と作る場合の分岐点が見えやすくなります。

ステップ4：補助金の使えるルートを確認する

この規模の設備投資は、補助金の対象になることがあります。今回はIT導入補助金の枠を検討し、要件・スケジュールの整合を取ったうえで申請を並行して進めました。補助金は申請から交付決定までに時間がかかり、交付決定前に契約・発注すると対象外になるケースがあるため、スケジュールの引き方に直結します。見積もり段階で必ず確認する項目です。

※ 補助金の要件・公募時期は年度ごとに変わります。実際の申請可否は最新の公募要領および認定支援機関にご確認ください。

【工程3】スケジュール：着手から本稼働まで5.5ヶ月

提示・合意したスケジュールは全22週です。水産加工は繁忙期（年末・お盆前）に現場を止められないため、本稼働を閑散期に置くことから逆算して組んでいます。

ポイントは「お客様側の作業時間もスケジュールに明記する」ことです。システム開発が遅れる原因の多くは開発側ではなく、レビューや意思決定が止まることにあります。最初に「御社側で合計おおよそ50時間必要です」と伝えておくと、社内の体制を確保してもらいやすくなります。

また、W9〜W16の開発期間は2週間ごとに動くものを見てもらう進め方にしました。一括で作って最後に見せると「思っていたのと違う」が高確率で起きます。特に現場が使う画面は、実際に触ってもらわないと分かりません。

【工程4】開発：どう作ったか

技術構成は「あとで引き継げること」を優先

クラウド（一般的なWebアプリケーション構成）で構築し、事務所のPCからも加工場のタブレットからもブラウザで使えるようにしました。特殊なフレームワークや独自言語は避け、後任のベンダーでも保守できる標準的な構成にしています。数百万円をかけて作ったものが、担当者が変わった瞬間に誰も触れなくなるのは最悪のパターンだからです。

在庫は「二重単位」と「引当」を最初から設計に入れる

課題1・課題4への対応です。1つの商品に対して重量（kg）と数量（箱・パック）の両方を持たせ、換算係数を商品マスタで管理する設計にしました。歩留まりが変動する加工工程は、投入した原魚ロットと産出した製品ロットを紐づける「加工実績」として記録します。

在庫数は「総在庫」「引当済み」「フリー在庫」の3つを常に分けて表示。受注が入った時点で自動的に引当がかかるため、ホワイトボード時代の「あると思ったらもう売れていた」がなくなりました。

受注取込は「全自動」を狙わない

FAXの完全自動読み取りは、精度と費用の両面で現実的ではないと判断しました。代わりに、チャネルごとに取込方法を変える設計にしています。

• Excel／CSVで来る取引先：取引先ごとの取込フォーマットを定義し、ドラッグ＆ドロップで取込
• 自社EC・ふるさと納税：CSVエクスポート→取込（将来的にAPI連携も可能な設計）
• FAX・電話：受注入力画面で手入力。ただし得意先を選ぶと、その取引先の定番商品・入り数・納品曜日が自動で候補表示されるようにして、入力を1件あたり数十秒まで短縮

「全部自動化」を目指して破綻するより、件数の多いところから自動化し、残りは入力を速くするほうが確実に効果が出ます。複数チャネルのデータをどう揃えるかという論点は、複数モールの商品情報（JANコード・SKU・中古区分）をどう一元管理する？仕様差異と同期エラー防止ガイドでも扱っています。

現場が使う画面は「文字を大きく、押す場所を少なく」

加工場は手袋をしたまま、濡れた手で、明るい場所でタブレットを触ります。事務用のUIをそのまま持ち込むと使われません。出荷担当の画面は、ボタンを大きくし、1画面あたりの操作を2〜3タップに絞りました。研修で「これなら使える」と言われるかどうかが、稼働後の定着を決めます。

データ移行はクレンジングが本番

移行作業そのものは数日ですが、その前段のデータクレンジングに一番時間がかかります。取引先台帳には廃業済みの会社が残り、商品マスタには同じ商品が表記違いで3件登録されている、といった状態が普通です。ここはお客様側にしか判断できないため、「重複候補リスト」「未使用マスタリスト」を出して、社内で仕分けしてもらう形で進めました。

【工程5】納品：検収とカットオーバー

納品は「システムを渡して終わり」ではありません。この案件では次の順序で進めました。

1. 受入テスト（W17〜18）：実際の受注データで、お客様自身にテストシナリオを実施してもらう。ここで出た不具合・仕様調整は開発側で対応
2. 並行稼働（W19〜20）：2週間、旧来の紙運用と新システムを同時に回す。手間はかかるが、これをやらないと本番当日に止まるリスクがある
3. 操作研修（W20）：事務所向け・加工場向けの2回に分けて実施。録画してあとから見返せるようにする
4. カットオーバー（W21）：旧運用を停止。初週は担当者が現地に常駐し、その場で質問に答える
5. 検収・引き渡し（W22）：検収書に加え、ソースコード・設計書・運用マニュアル・アカウント情報の一式を引き渡す

納品物の引き渡しは特に重要です。「ソースコードはベンダーが持ったまま」という契約だと、将来ベンダーを変えられなくなります。当社は原則、納品物一式をお客様側の資産として渡す形にしています。

また、繁忙期を避けたとはいえカットオーバー週は必ず何かが起きます。「初週は現地に人がいる」ことを前提にスケジュールと見積もりを組んでおくと、現場の不安が大きく下がります。

【工程6】保守：納品後に何をどこまで見るか

システムは作った瞬間から古くなっていきます。この案件では、稼働と同時に保守契約を開始しました。提示した3プランは以下のとおりです。

この会社が選んだのはスタンダード（月4.8万円）です。理由は、見積もり段階で「推奨」に仕分けした機能を、稼働後に月5時間の改修枠で少しずつ足していく計画だったためです。実際、稼働から1年で以下が追加されました。

• 発注点を下回った商品のアラート表示（3ヶ月目）
• 得意先別の売上・粗利サマリー画面（5ヶ月目）
• ふるさと納税ポータルのCSV自動取込対応（8ヶ月目）
• ロット追跡の逆引き検索（品質監査対応・11ヶ月目）

保守で当社が実際にやっていることは、大きく4つです。

1. 止めない：稼働監視、日次バックアップ、ミドルウェア・ライブラリのセキュリティ更新。ここは表に出ませんが、事故が起きたときの損害が最も大きい部分です
2. 直す：不具合の受付と修正。受付窓口を1本化し、チャットで受けてチケット管理する運用にしています
3. 足す：月次定例で現場から出た要望を拾い、優先度をつけて改修枠の中で実装
4. 見る：月次で在庫差異・出荷ミス件数・入力件数などの数値を一緒に確認し、「システムを入れて実際に良くなっているか」を検証

4つ目を保守に含めているのが当社の特徴です。導入したシステムは、使われて初めて価値が出ます。ログを見ると「この画面は誰も使っていない」「この機能だけ毎日使われている」がはっきり分かるので、それを次の改修の優先順位に反映させます。

導入後に何が変わったか

稼働から6ヶ月後、同社の社内計測値として共有いただいた数値です。

ただ、この会社にとって最大の成果は数字ではありませんでした。当初のきっかけだった「ベテラン社員の退職」に対して、業務を引き継げる状態になったことです。得意先ごとの納品ルールも、商品ごとの入り数も、すべてマスタとして残っている。退職された方には、稼働後にマスタ整備を手伝っていただき、そのまま引き継ぎが完了しました。

同じような会社が失敗しないための5つのポイント

ここまでの工程を踏まえて、これから在庫・受発注のDX化を考える事業者の方に、特に伝えたいことをまとめます。

1. 「システムを入れる」前に「業務を書き出す」

いまの業務が紙の上に書き出せていない状態でシステムを選ぶと、必ずミスマッチが起きます。最低限、受注から出荷までの流れと、そこで使っている帳票を全部並べるところから始めてください。これは自社だけでもできます。

2. パッケージで足りるかを先に検証する

今回は二重単位・ロット・得意先別ルールという要件からスクラッチ開発を選びましたが、要件が標準的なら市販パッケージやSaaSのほうが速く安く済みます。「作る」判断は、パッケージで無理だと確認してからで十分です。ツール選定の観点はEC自動化ツールの選び方｜忙しいネットショップ運営を救う比較ポイントと導入順序が参考になります。

3. 全部を一度に作らない

要件を必須／推奨／将来に分けて、必須だけで一度動かす。これが結果的に一番早く、一番安く、一番使われます。動き始めてからのほうが「本当に必要なもの」がはっきり見えます。

4. 現場の一人を巻き込む

社長と情シスだけで決めたシステムは、現場で使われません。設計レビューとテストには、必ず毎日その業務をやっている人に入ってもらってください。今回は出荷担当の方に4回のスプリントレビュー全部に出ていただきました。

5. 保守の予算を最初から見込む

初期費用だけを見て予算を組むと、稼働後に「直したいけど予算がない」状態になります。目安として初期費用の15〜20%程度を年間の保守費として見込んでおくと、稼働後の改善が止まりません。物流・倉庫まわりの体制を含めて考えたい場合は、mimosaとWMSの違いは？EC物流を整えるための基礎知識と導入判断もあわせてどうぞ。

よくある質問

Q. 同じような規模だと、いくらくらいかかりますか？

要件次第ですが、在庫・受発注を対象にしたスクラッチ開発でおおむね250万〜600万円（税別）がひとつのレンジです。パッケージやSaaSの導入・設定支援であれば、初期50万〜150万円＋月額数万円で収まるケースもあります。まずはヒアリングのうえ、両方のパターンで概算をお出しします。

Q. 期間はどれくらい見ておけばよいですか？

本記事の案件で5.5ヶ月です。要件を絞れば3ヶ月程度、基幹システムまで含む場合は8ヶ月〜1年になることもあります。繁忙期を避けて本稼働日を決め、そこから逆算するのが現実的な組み方です。

Q. 現場がパソコンに慣れていなくても大丈夫ですか？

今回の加工場でも、日常的にPCを使うのは工場長のみでした。現場が触る画面はタブレット前提で操作を最小限にし、研修を分けて実施することで対応しています。むしろ、現場が慣れていない前提で設計するほうがうまくいきます。

Q. 既存の会計ソフトや販売管理ソフトは入れ替えが必要ですか？

必須ではありません。今回も会計ソフトはそのまま残し、仕訳用のCSVを出力する連携にしました。全部を入れ替えようとすると費用も期間も跳ね上がるため、今困っているところだけを切り出すのが基本方針です。

Q. 補助金は使えますか？

年度・要件によりますが、IT導入補助金などの対象になる可能性があります。ただし交付決定前の契約・発注は対象外になることがあるため、検討している場合は必ず着手前にご相談ください。スケジュールの組み方が変わります。

Q. 途中でベンダーを変えられますか？

当社の場合、ソースコード・設計書一式を納品時にお渡ししているため、技術的には可能です。契約時に「納品物の権利がどちらに帰属するか」を必ず確認してください。ここが曖昧な契約は、長期的にリスクになります。

まとめ

水産加工会社の在庫・受発注DX化を、6つの工程に分けて公開しました。要点を整理します。

• 課題：重量と数量の二重単位、受注チャネルの分散、ロット追跡の不可、引当が見えない在庫、そして属人化
• 見積もり：要件を必須／推奨／将来に3分割し、機能単位で人日を積み上げる。必須のみ118人日・407万円で提示
• スケジュール：全22週（5.5ヶ月）。繁忙期を避けた本稼働日から逆算し、お客様側の作業時間も明記
• 開発：引き継げる標準構成、二重単位と引当を設計に内包、全自動を狙わない受注取込、現場向けUI
• 納品：受入テスト→2週間の並行稼働→研修→カットオーバー→検収。納品物一式をお客様資産として引き渡し
• 保守：月4.8万円のスタンダードプランで、止めない・直す・足す・見るの4つを継続

「うちの場合はどこから手をつけるべきか」「そもそも作るべきか、パッケージで足りるのか」といった段階のご相談も歓迎です。現状のヒアリングから整理してご提案します。ご相談・お見積もりは無料です。

制作・支援実績の一覧はこちら／無料でEC・業務システムの相談をする