水産加工の在庫・受発注をDX化する進め方｜課題整理から見積もり・スケジュール・納品・保守まで

水産加工業の在庫管理と受発注は、市販の在庫管理ソフトに乗せようとすると、たいてい途中で止まります。原料が天然物で入荷量が読めず、数量は個数ではなく重量で、加工すれば在庫そのものが別の品目に変わるからです。「Excelと手書きの伝票で回してきたが、そろそろ限界」という相談は、この業種でとくに多く寄せられます。

この記事では、水産加工会社の在庫・受発注をシステム化するとき、課題の洗い出しから見積もり、スケジュール、開発、納品、そして稼働後の保守までを、おこじょデザインシステムが実際に案件で踏んでいる順番どおりに整理します。費用は幅（レンジ）で示し、何によって上下するのかまで書きます。

なお本記事は、特定の取引先の案件内容をそのまま公開したものではありません。水産加工業に共通して現れる業務要件をもとに構成したモデルケースです。金額・期間は目安であり、実際の見積もりは要件によって変わります。

なぜ水産加工の在庫は市販ソフトで止まるのか

最初に、この業種特有の「引っかかりどころ」を押さえます。ここを理解しないまま汎用パッケージを導入すると、結局は現場がExcelを併用し、二重入力が増えて前より遅くなる、という結末になりがちです。

1. 数量が個数ではなく重量で、1ケースごとに重さが違う

「サバフィレ 10ケース」は在庫として成立しません。同じ品名でも1ケースの正味重量がばらつくため、ケース単位の員数管理と、実重量（バラ重量）の記録を両方持つ必要があります。出荷時の請求も重量建てになることが多く、ここを個数管理で近似すると、請求金額が合わなくなります。

2. 加工すると在庫が別の品目に変わる

原料100kgを三枚おろしにすれば、製品が60kg、副産物が20kg、廃棄が20kg、といった形で在庫が姿を変えます。この工程変換と歩留まりを記録できないと、在庫は必ず理論値と合わなくなります。逆に言えば、歩留まりを品目別・仕入先別・時期別に蓄積できるようになるだけで、原価と仕入判断の精度が変わります。

3. ロットが漁獲海域・漁獲日・凍結日に紐づく

2021年6月に食品衛生法上のHACCPに沿った衛生管理が完全義務化されて以降、記録の保存は「やっておいたほうがよいこと」ではなくなりました。加えて量販店や生協は独自のトレーサビリティ要求を持ち、輸出が絡めばさらに要件が増えます。回収が発生したときに、どのロットがどの得意先のどの店舗まで行ったかを追えるかどうかが、この仕組みの実質的な合格ラインです。

4. 原料の仕入単価が毎日動く

浜値は日々変動し、同じ品目でも入荷ロットごとに単価が違います。移動平均で丸めるのか、ロット別の実際原価で持つのかは、経理・税務の方針と現場の入力負荷のバランスで決める設計上の分岐点です。ここは見積もり前に必ず握っておく項目です。

5. 受注がFAX・電話・メール・EDIに散らばっている

量販店は流通BMSなどのEDI、地場の飲食店や小売は電話とFAX、というように受注チャネルが混在しているのが普通です。全部を一気に電子化しようとすると失敗します。件数ベースで内訳を数え、上位に効くチャネルから順に取り込むのが定石です。

6. 現場は低温で、手が濡れていて、手袋をしている

事務所のPCで動くきれいな画面を作っても、加工場では使われません。冷凍庫内は電波が届かないことも多く、そもそもキーボード入力ができません。この制約は、あとから直すのが最も高くつく部分です。

着手前にやる業務の棚卸し（2〜4週間）

見積もりを出す前に、必ず現地に入って業務を見ます。ヒアリングだけで作った見積もりは、ほぼ確実に外れます。このフェーズで確認するのは次の項目です。

• 登録上のSKU数と、直近12ヶ月で実際に動いた品目数（この2つは大きく違うことが多い）
• ロットをどの粒度で持つか（漁獲日単位か、入荷ロット単位か、製造日単位か）
• 拠点の内訳（自社冷凍庫、外部の営業倉庫、協力工場への外注加工）
• 受注チャネルごとの月間件数と、締め時間・出荷リードタイム
• 既存の会計・販売管理システムと、そこへ渡すべきデータ
• いま誰が、何に、1日何分使っているか（棚卸し、伝票起票、在庫の電話確認など）
• 繁忙期がいつか（年末年始、お盆、季節魚の最盛期）

この段階で「今回はシステムを作らないほうがよい」と判断することもあります。たとえば在庫のズレの原因が入力ルールの不統一だけなら、まず運用ルールと帳票を整えるほうが安く速く効きます。棚卸しの成果物は、業務フロー図、課題の一覧、優先順位をつけた機能候補リスト、そして概算見積もりです。

見積もりは何で決まるか

「在庫管理システムはいくらですか」という質問には、単独では答えられません。金額を動かしている変数は、実務上はほぼ次の4つに集約されます。

1. 在庫の粒度／重量管理の有無、ロットをどこまで細かく追うか、工程変換を記録するか
2. 拠点数と外部倉庫／自社1拠点で完結するか、営業倉庫や協力工場の在庫まで見るか
3. 外部連携の本数／EDI、会計ソフト、計量器、ラベルプリンタ、既存の販売管理。連携1本ごとに仕様確認と試験の工数が積み上がる
4. 現場端末／事務所PCだけか、防水タブレットやハンディターミナルを使うか、オフライン動作が要るか

逆に言えば、金額を下げる最も効く手段は「今回は作らない範囲を決めること」です。全機能を一度に見積もると高額かつ長期になり、経営判断が止まります。

フェーズ別の費用レンジ

1拠点、実稼働SKU数百点、現場端末10台前後を想定したモデルケースです。

上振れする典型は、多拠点・外部倉庫連携あり、対米や対EUの輸出対応あり、既存基幹システムとの双方向連携あり、というケースです。逆に、まず1拠点の在庫だけを対象にフェーズ0と1に絞れば、200〜400万円・3ヶ月程度から着手できます。

ハードウェア（防水タブレット、ハンディターミナル、ラベルプリンタ、計量器との接続機器）は実費で別計上します。台数と機種で変わるため、開発費に含めず透明にしておくほうが、あとの追加購入も判断しやすくなります。

補助金については、IT導入補助金やものづくり補助金が候補になることがあります。ただし対象経費や要件は年度ごとの公募要領で変わるため、2026年8月7日時点の情報として鵜呑みにせず、申請時点の最新要領と、必要なら認定支援機関への確認を前提にしてください。採択前提でスケジュールを組むのは避けます。

スケジュールの組み方（6ヶ月モデル）

フェーズ0から本稼働までを6ヶ月に置いた場合の標準的な進み方です。実際には各月の終わりに、動くものを現場で触ってもらう時間を必ず挟みます。

スケジュールで最も遅れる原因は、開発側ではなくマスタ整備です。商品マスタの名寄せ、取引先ごとの単価表、得意先の届け先コードといった作業は現場の知識がないと進まず、しかも通常業務の合間に行われます。ここを見積もり時点で「クライアント側の作業」として工数と担当者名まで明記しておかないと、2〜3ヶ月は平気でずれます。

もう1つ、本稼働日は繁忙期を外します。水産加工なら年末年始とお盆前は避けるのが鉄則です。切り替え直後は必ず想定外が出るため、現場に余力のある時期を選びます。

どう作るか

段階リリースを前提に組む

在庫と受発注を同時に切り替えると、問題が起きたときに原因の切り分けができません。先に在庫だけを稼働させ、在庫数が信用できる状態を作ってから受発注を乗せます。在庫が合っていないシステムの上に受注を載せても、欠品判定が機能しないためです。

現場の画面は制約から逆算する

• 手袋のまま押せるサイズのボタン、テンキー中心の入力、1画面1作業
• 冷凍庫内で電波が切れても入力を続けられるオフライン動作と、復帰時の同期
• 計量器やハンディターミナルから読んだ値を人が打ち直さない（二重入力は必ず事故になる）
• 「間違えた」をその場で取り消せる導線。実運用で最も使われる機能は訂正です
• マスタの表示名は正式名称ではなく、現場が普段使っている呼び名に合わせる
• パート従業員・社員・管理者で権限を分け、原価情報は限られた人だけに見せる

技術構成

おこじょデザインシステムでは、Next.js（React）を中心に、認証・データベース・ホスティングをクラウドマネージドサービスで構成することが多く、自社でサーバーを持たない形にしています。専用端末を用意せず、既存のタブレットやスマートフォンのブラウザで動くようにするため、初期のハードウェア投資と、稼働後のサーバー保守の手間を抑えられます。既存の基幹システムがオンプレミスにある場合は、連携方式を含めてフェーズ0で設計します。

2週間ごとに現場に見せる

仕様書の文面で合意しても、現場が実際に触ると必ず違和感が出ます。2週間ごとに検証環境を触ってもらい、その場で直す前提で進めます。完成してから見せる進め方は、この業種では特に失敗します。

納品時に何を渡すか

「システムが動くこと」は納品物の一部にすぎません。稼働後に発注側が自走でき、かつ別の会社に引き継げる状態にして初めて納品です。渡すものは次のとおりです。

• 本番環境一式と、すべての管理者アカウント。クラウドサービスの契約名義とドメインはクライアント名義にする
• 移行済みデータと、移行前後の突合結果（件数と金額が一致していることの証跡）
• 操作マニュアル。紙のマニュアルは現場で読まれないため、作業単位の短い画面録画を主にする
• 受入テストの仕様書と実施結果
• 障害発生時の連絡フローと、社内でできる一次対応の手順
• ソースコードの扱い（著作権の譲渡か使用許諾か）を明記した書面
• 利用している外部サービス、ドメイン、SSL証明書の契約・更新日一覧

そして納品日と本稼働日は分けます。従来のやり方と並行して動かす期間を2週間から1ヶ月ほど設け、数字が一致することを確認してから旧運用を止めます。並行運用は現場に負担がかかるため、期間と終了条件を最初に決めておきます。

保守で毎月やること

在庫と受発注は業務が止まると出荷が止まる領域です。保守は「壊れたら直す」ではなく、壊れる前に見る作業が中心になります。

• バックアップの取得確認と、月1回の復元テスト（取れているかではなく、戻せるかを確認する）
• エラーログと処理の遅い箇所の確認、データ量の増加傾向のチェック
• 理論在庫と実棚の差異レビュー。差異が出る品目には運用側の原因があることが多い
• 繁忙期前の負荷確認と、想定件数での事前テスト
• ライブラリ・実行環境の更新と、セキュリティ修正の適用
• 制度・取引先都合の変更対応（電子帳簿保存法、インボイス、取引先のEDI仕様やセンター納品ルールの変更）
• 月次レポートの提出と、改善提案の棚卸し

契約時に線引きを明文化しておくと、あとで揉めません。

連絡手段と応答時間の目安も決めておきます。出荷が止まる障害は当日中の一次対応、それ以外は翌営業日、といった形で、現実に守れる水準を約束するのが実務的です。

よくある失敗

• 全部いっぺんに作る／金額が跳ね上がり、稼働までの期間が長くなり、途中で熱量が切れる
• マスタ整備を後回しにする／開発が終わっているのにデータがなくて動かせない、という状態になる
• 現場に見せるのが遅い／完成後に「これでは使えない」が出て、作り直しになる
• 紙とExcelを完全に消そうとする／残すべき紙もある。一次記録だけをシステムに寄せ、印刷物は帳票として出す割り切りが要る
• 特定の一人しか使えない状態で終わる／必ず2名以上が操作できる状態を納品条件に入れる
• アカウントがベンダー名義のまま／保守会社を替えられなくなる。契約名義は最初からクライアントにする

よくある質問

既存の販売管理ソフトは捨てる必要がありますか

多くの場合、必要ありません。会計や請求まわりが既存ソフトで問題なく回っているなら、そこは残し、パッケージが苦手とする現場の在庫とロット管理だけを作って連携するほうが、費用も期間も抑えられます。どこで切るかをフェーズ0で決めます。

パッケージとスクラッチのどちらがよいですか

業務をパッケージに合わせられる部分はパッケージが有利です。合わせられないのは、この業種では重量管理、歩留まり、ロットの持ち方、そして自社特有の受注ルールに集中します。全部をスクラッチにするのではなく、合わない部分だけを作る前提で比較してください。

社内で内製できませんか

可能なケースもあります。ただし内製で難しくなりやすいのは、作ることより、担当者が異動・退職したあとに誰も触れなくなる点です。内製する場合でも、設計とデータ構造だけ外部でレビューしておくと、あとの選択肢が残ります。

途中で要件が増えたらどうなりますか

増えます。前提として増えるものと考え、フェーズごとに契約を区切り、追加要望は次フェーズの候補として一覧に積む運用にしています。進行中のフェーズに割り込ませないことが、期日を守る唯一の方法です。

稼働後に開発会社と連絡が取れなくなるのが不安です

そのリスクは契約と納品物で下げられます。クラウドサービスの契約名義をクライアントにする、ソースコードの扱いを書面で決める、環境構築手順を残す。この3点が揃っていれば、保守を他社に引き継ぐことができます。

まとめ

• 水産加工の在庫は、重量・歩留まり・ロットの3点で汎用パッケージから外れる。ここを設計の起点にする
• 見積もりは、在庫の粒度・拠点数・連携本数・現場端末の4変数で決まる。金額を下げる最短手は作らない範囲を決めること
• 初期構築はモデルケースで400〜900万円・4〜9ヶ月、保守は月5〜20万円。1拠点の在庫だけなら200〜400万円・3ヶ月から着手できる
• スケジュールの遅延要因はマスタ整備。クライアント側の作業として工数と担当者を最初に決める
• 在庫を先に稼働させ、数字が信用できる状態を作ってから受発注を乗せる
• 納品物にはアカウント名義、移行の突合結果、引き継ぎ可能な状態までを含める
• 保守の中心は復元テストと差異レビュー、そして制度・取引先要求の変更への追随

おこじょデザインシステムでは、現地に入って業務を見るところから、要件定義、開発、納品、稼働後の運用保守までを一貫して担当しています。まだ「何を作ればいいか分からない」段階のご相談でも、業務の棚卸しから一緒に始めます。システム受託開発・運用保守のページもあわせてご覧ください。

※本記事は特定の取引先の実案件を記述したものではなく、水産加工業に共通する業務要件をもとに構成したモデルケースです。記載の金額・期間は2026年8月7日時点の目安であり、実際のお見積もりは要件により変動します。補助金・法制度に関する記述は、必ず申請時点の最新の公募要領・法令をご確認ください。