製造業向けシステム開発

相談できる課題

• 生産管理パッケージを入れたが、現場の実態と合わず結局Excelに戻っている
• 基幹システムと現場の作業実績が分断され、進捗を人に聞かないと分からない
• 図面・仕様・見積の履歴が個人のフォルダに散在し、最新版が特定できない
• FAX・メール受注を人が転記しており、繁忙期に納期回答が遅れる
• 検査記録が紙で、顧客監査やクレーム時にロットから履歴を追えない
• 設備の停止・故障の記録が残らず、保全の優先順位を数字で説明できない
• AIを使いたいが、自社のデータで何がどこまでできるのか判断できない

いずれも「システムが無いから起きている」とは限りません。運用の変更で解決できる場合もあるため、開発ありきではなく、業務・データ・体制の3点から原因を切り分けたうえで提案します。

提供するサービスの範囲

パッケージで十分な場合

次の条件がそろう場合は、個別開発よりもパッケージ導入を勧めます。開発を受注することよりも、投資が回収できる構成を選ぶほうが重要です。

• 業務を標準に合わせて変更する意思決定ができる
• 必要な機能の大半が標準機能で満たせる
• 連携が一般的なCSV・APIの範囲で足りる
• 法改正や制度対応など、継続的なメンテナンスが必要な領域
• 社内に運用を維持できる担当者がいる

個別開発が必要になる場合

• 製品や顧客ごとに工程・入力項目・帳票が変わり、標準機能では表現できない
• 見積・原価のロジックが自社固有で、そこが競争力になっている
• 既存の基幹や設備との連携が個別要件になる
• パッケージの改修費が積み上がり、総額で個別開発と変わらなくなっている
• 現場の運用を止められず、段階的に移行する必要がある

パッケージ＋不足部分だけの個別開発（周辺システム）という選択肢もあります。全面的な個別開発が唯一の解ではありません。

既存システム・設備との連携

連携で問題になるのは、方式そのものより「どちらを正とするか」「失敗したときにどう戻すか」を決めていないことです。設計時に次を確定させます。

開発の進め方

1. 相談・現状把握（30分〜）：対象業務、現在の管理方法、関係者、困っている事象を確認する
2. 業務整理・Fit/Gap：システム化する範囲としない範囲を決め、パッケージ／個別開発／運用改善に振り分ける
3. 要件定義：データ項目、画面、権限、連携、非機能、移行、運用を文書化し、見積の前提を確定させる
4. 小規模検証または先行開発：1ライン・1製品群・1帳票など、影響範囲を限定して現場で試す
5. 開発・テスト：本番相当のデータで、現場が実際に入力できるかを確認する
6. 移行・並行稼働・切替：旧運用と並行させ、戻せる状態を確保したうえで切り替える
7. 運用・改善：使われていない機能と入力項目を定期的に見直す

体制・契約・品質管理

• 要件定義と開発を分けて契約でき、要件定義のみの依頼にも対応する
• 発注者側にも、業務を説明できる担当者を1名置いてもらう前提で進める
• 仕様変更は、影響範囲と工数を提示したうえで合意してから着手する
• テスト・レビューの記録を残し、引き渡し後に社内で保守できる形にする
• 守秘義務、データの取り扱い範囲、再委託の有無は契約前に合意する

費用・期間を左右する条件

• 対象業務の数と、業務ルールの例外の多さ
• 拠点・工場数、利用者数、利用する端末の種類
• 連携先システムの数と、その連携方式（API有無、CSV、DB直接、EDI）
• 設備・PLCからのデータ取得の有無と、現地調査の要否
• データ移行の量と品質（表記ゆれ、重複、欠損）
• 権限・承認・操作ログ・改ざん防止など、非機能の要求水準
• 稼働中の業務を止められる時間と、並行稼働の期間

同じ機能名でも、これらの条件で工数は大きく変わります。金額を1点で示すより、前提条件を明示した見積のほうが比較に使えます。

対象外の案件

• 安全機能や人命に直結する制御そのものの開発
• 既存設備の制御ロジック（PLCプログラム）の改変
• 24時間365日の常駐運用保守を単独で担う契約
• 発注者側に業務を説明できる担当者を置けない案件
• 目的と評価指標を定義しないままの「とりあえずAI」の実装

対象外に該当する場合でも、要件整理・連携方式の検討・ベンダー選定の判断材料づくりだけを支援することは可能です。

よくある質問

要件定義だけを依頼できますか。

できます。要件定義と開発は分けて契約でき、要件定義の成果物（業務フロー、データ項目、対象範囲、非機能要件、移行方針）は他社への見積依頼にも使える形で納品します。

製造業の導入実績を見せてもらえますか。

製造業の顧客名を出せる事例は公開していません。公開できる案件が出た時点で掲載します。代わりに、見積生成の技術デモを実際に動かせる形で公開しており、相談の場では近い構成の設計方針、想定する構成図、想定される難所を具体的に説明します。

既存のパッケージを使い続けたまま相談できますか。

できます。不足している部分だけを周辺システムとして個別開発し、パッケージとはAPIやCSVで接続する構成は一般的な選択肢です。パッケージの改修費と比較して判断します。

開発後の保守はどうなりますか。

不具合対応と改善開発を分けて条件を決めます。24時間365日の常駐運用保守は対象外ですが、障害時の連絡方法、対応時間帯、優先度の基準は契約時に合意します。社内で保守できるよう、設計書と運用手順を引き渡します。

相談から着手までどのくらいかかりますか。

案件規模と、発注者側の意思決定の速さによります。目安として、初回相談から業務整理の開始までは、対象業務と関係者が決まっていれば数週間程度です。正確な期間は、対象範囲と体制を確認したうえで回答します。