製造業向けシステム開発

相談できる課題

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

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

提供するサービスの範囲

パッケージで十分な場合

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

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

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

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

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

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

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

開発の進め方と、無償・有償の範囲

依頼は次の段階で進みます。各段階の終わりに、次へ進むかどうかを判断する材料をそろえます。途中の段階で止めることもできます。

無償で対応するのは、初回の30分診断と、追加ヒアリング1回程度の簡易な要件整理までです。業務・データ調査や要件定義の成果物づくり以降は有償のご依頼として、範囲と成果物を見積に明記します。初回の相談で契約を迫ることはありません。

判断に使える根拠と、その読み方

製造業の顧客名を出せる事例は公開していません。公開できる案件が出た時点で掲載します。いま示せる根拠は次の3種類で、それぞれ読み取れることが違うため、混ぜて扱いません。

• 株式会社Cloverse様｜アパレル向けAIクリエイティブ基盤の開発（アパレル／生成AI SaaS） — 業務の聞き取りから要件を起こす進め方と、失敗した処理だけを再実行できる非同期ジョブの設計
• 株式会社Atsumell様｜サービスを止めずにデータ基盤を刷新した事例（BtoBプラットフォーム） — 稼働中のまま段階的に移行する手順と、応募した時点のデータを残す設計。並行稼働・データ移行・履歴保全の考え方の参考
• オンプレミスからのAWS移行アセスメント（金融） — 移行する前提で論点を洗い出し、「現時点では移行しない」と判断した例。開発ありきにしない判断の参考
• 技術デモ：見積生成（架空のデータで動作） — 案件文から見積を作り、受注・工程・原価へ引き渡す仕組みを試せます

上の実案件はいずれも製造業以外です。進め方と設計判断の参考として示すもので、製造業で同じ成果を約束するものではありません。

• 製造業のAI活用事例をどう読むか（解説記事） — 報道された成果を、自社の判断材料にするときの読み方
• 製造業AIが「入れたのに使われない」に終わる理由（解説記事） — 公開された成功・失敗事例から、定着しない条件を整理
• 製造業のAI導入は「モデル選び」で決まらない（解説記事） — 他社の公開事例から、データと業務の土台を整える順番を読む

体制・契約・品質管理

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

相談の窓口と設計の責任は、次の担当者が持ちます。経歴と執筆記事は著者ページで確認できます。

• 徐 聖博（代表取締役） — AI・生成AIの実装、プロダクト開発、経営としての投資判断
• 高畑 拓海（開発支援事業部 部長） — 要件定義、PM、顧客折衝、開発組織の運営

相談した後の流れ

1. 相談フォームの受付後、担当者が内容を確認し、2営業日以内にメールで連絡する
2. 追加で確認したい点（対象業務、現在の管理方法、既存システムの構成）があれば、そのメールで伺う
3. 30分診断で、最初に着手する業務1つ、先に確認すべきデータ、次に判断することを整理する
4. 有償の段階へ進む場合は、範囲と成果物を明記した見積を提示し、合意してから着手する

調査をしないまま、提案の内容や金額を断定することはしません。その場で答えられない点は、何を確認すれば答えられるかをお伝えします。

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

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

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

対象外の案件

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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