製造業システム開発の費用を左右する条件

費用の考え方

「工程管理システムはいくらか」という問いには、前提を揃えないと答えられません。同じ名前のシステムでも、対象が1ラインか全工場か、入力がPCだけかハンディ・設備込みか、基幹連携が日次CSVかリアルタイムAPIかで、必要な工数は数倍変わります。

このページでは金額のレンジを提示していません。公開できる実案件の金額を持たない状態でレンジを書けば、根拠のない数字になるためです。代わりに、見積が動く条件を明示します。自社の条件をこの表に当てはめると、どの見積が高い／安いのかを比較できる状態になります。

工数を増やす条件

見積の差が説明できないときは、この表のどの行で前提が違うのかを各社に確認すると、多くの場合は理由が特定できます。

費用の項目：初期費用と運用費を分ける

見積や社内稟議では、開発費だけでなく、その前後にかかる作業と、稼働後に毎月かかる費用を分けて並べます。開発費だけを比べると、運用が始まってから想定外の費用が出てきます。

業務別に費用が膨らみやすいところ

連携方式による違い

連携は「つなぐ」こと自体より、相手システムの仕様調査、テスト環境の確保、失敗時の復旧設計に工数がかかります。相手側ベンダーの協力が得られるかどうかが、期間に直結します。

• API：仕様が公開され、テスト環境がある場合は比較的読みやすい。認証方式と流量制限を確認する
• CSV：安価に始められるが、文字コード、締めのタイミング、失敗時の再取り込み運用を設計する必要がある
• DB直接：早いが、相手システムの保守契約に抵触する場合がある。事前確認が必須
• EDI：業界標準でも取引先ごとに個別仕様がある。対象取引先の数がそのまま工数になる
• 設備・PLC：機種と通信方式の調査、ネットワーク分離、現地作業が必要になることが多い

データ移行

移行費用は量よりも品質で決まります。同じ取引先・品番が別表記で登録されている、必須項目が空欄のまま運用されている、といった状態は、変換ルールの設計と検証に時間がかかります。

• 移行対象の年数と件数を先に決める（全件移行が必要とは限らない）
• 表記ゆれ・重複の整理を、誰がどの基準で判断するかを決める
• 移行しないデータの参照方法（旧システムの閲覧のみ残す等）を用意する
• 移行後の検証方法（件数、合計、抜き取り）を移行前に合意する

PoCと本番の費用は別物

とくにAIを含む案件では、PoCで出た結果と本番運用のコストが大きく離れることがあります。PoCは限定データ・限定条件での検証であり、本番では例外処理、権限、監視、再学習、人の確認フローが必要になります。PoCの見積を本番の見積として扱わないでください。

• PoCの目的：適用可否の判断。評価指標と合格基準を先に決める
• 本番の追加要素：例外時のフォールバック、権限とログ、監視、運用手順、教育
• PoCで判断できないこと：長期の精度変化、繁忙期の負荷、現場の定着

効果の試算と回収期間の考え方

効果は、まず「時間」で試算し、金額への換算は別の欄に分けます。削減できた時間は、ほかの仕事に回せる余力であって、そのまま現金の支出が減るとは限りません。人を減らす・残業代が減るなど、実際に支出が減る場合だけ、現金の削減として数えます。

1. 1削減できる時間を出す月の件数 × 1件あたりの削減時間（分） ÷ 60 ＝ 月に削減できる時間
2. 2増える作業を差し引く自動処理の結果を確認・修正する時間、やり直しの時間を、同じ式で出して差し引く（純削減時間）
3. 3金額に換算する（別欄）純削減時間 × 自社で使う時間単価。余力として使うのか、支出が実際に減るのかを書き分ける
4. 4運用費を差し引く月次の純便益 ＝ 換算した金額 − 毎月の運用費（保守・利用料など）
5. 5回収期間を出す（純便益が正のときだけ）回収期間（月） ＝ 初期費用 ÷ 月次の純便益。純便益が0以下なら回収期間は出さない（「回収できない」と判断する材料になる）

この表は計算の手順を示すための仮の数字で、当社の実績や特定の案件の効果ではありません。時間単価・初期費用・運用費は自社の値で計算してください。売上や粗利の増加は、受注率や単価などの前提が別に必要なため、ここでは時間の削減から自動的に換算しません。

見積を比較する方法

1. 各社へ同じ前提条件（対象業務、利用者数、連携先、移行量、非機能）を提示する
2. 見積の内訳を、要件定義・開発・移行・テスト・教育・保守で分けて出してもらう
3. 含まれていない作業（相手システム側の改修、現地作業、教育、保守）を明示してもらう
4. 仕様変更時の扱い（時間単価、最低発注量、判断者）を確認する
5. 引き渡し後に社内または他社で保守できる形か（技術構成、ドキュメント、権限）を確認する

安さを優先して後で高くつく例

• 要件定義を省いて着手し、開発中に対象範囲が膨らんで追加費用が積み上がる
• 連携を「後で」にした結果、二重入力の運用が残り、現場が使わなくなる
• データ移行を軽く見積もり、稼働直前に手入力の突貫作業が発生する
• 非機能（権限・ログ）を後回しにして、顧客監査の直前に作り直す
• 保守の条件を決めずに引き渡し、障害時に対応者がいない

概算を出すために必要な情報

• 対象業務と、その帳票・Excelでどんな項目を扱っているか（実物の添付は不要です）
• 拠点数・利用者数・利用端末
• 連携したいシステム名と、その保守ベンダーの有無
• 設備からのデータ取得の要否（対象設備の型式が分かれば併せて）
• 移行したいデータの範囲と年数
• 希望時期、決裁に必要な資料の形式

帳票や実データは、相談フォームに添付・記載しないでください。必要になった段階で、秘密保持契約と受け渡しの方法を合意してから扱います。

よくある質問

概算の金額レンジを教えてもらえますか。

このページでは金額レンジを公開していません。前提条件が違えば同じ機能名でも工数が数倍変わり、レンジだけが独り歩きするためです。対象業務、利用者数、連携先、移行量、非機能要件を共有いただければ、その条件での概算と、金額を動かす要因を提示します。

要件が固まっていない段階で見積は出せますか。

前提条件付きの概算であれば出せます。ただし、対象範囲が決まっていない段階の概算は幅が大きくなります。精度を上げるには、要件定義を分離して先に実施し、その成果物をもとに開発見積を出す進め方が確実です。

小さく始めた場合、あとで作り直しになりませんか。

データ構造と連携方針を最初に決めておけば、多くの場合は拡張で対応できます。作り直しになりやすいのは、対象業務ごとに別々のデータ定義で作り、後から統合しようとした場合です。最初の1業務でも、品番・工程・ロットなど共通で使うマスタの定義は全体を見て決めます。

補助金の対象になりますか。

制度ごとに要件と公募時期が変わるため、対象可否は必ず最新の公募要領で確認してください。当社は制度の申請代行は行っていませんが、申請に必要な見積書・システム構成・導入計画の資料作成には対応できます。

PoCはどこで終わりにしますか。

始める前に、評価する指標と合格の基準、続ける条件と止める条件を決めておき、その基準で判断します。期間や件数を延ばしても基準に届かない場合は、本番の開発へ進まずに止めることも選択肢です。