重工業・造船業界のシステム発注は、対象業務とデータを定め、要件を整理してから、契約と段階導入の順に進めます。この流れをそろえると、原価や設計変更、協力会社との連携を一体で管理できます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
重工業・造船業界のシステム発注で押さえる全体像
重工業・造船業界では、超長期の個別受注、多数の部品と図面、多層の協力会社が重なります。このため、外注範囲を決める前に、経営管理から会計までのどの業務を同じデータでつなぐかを明らかにします。
超長期プロジェクトの原価を追える状態
船舶やプラントは、受注から設計、調達、建造、試運転、引き渡しまで数年に及ぶ場合があります。そのため、案件ごとの予算や出来高は、月次の支出とは別に追う必要があります。
利益のずれは完成間際に判明しやすいため、進捗と予実差異も途中で確認します。発注時には、案件番号を共通のキーにして各データを結び付けておきます。
- 原価と進捗：プロジェクト別原価と工事進行基準の進捗
- 予算と発注：予実差異、発注残、仕掛の状況
- 変更費用：設計変更に伴う追加費用
E-BOMからM-BOM、調達までの連動
E-BOMとM-BOMが分断されると、部品名や版数が複数存在し、調達や在庫の判断が遅れます。そこで、PLMをERPや生産管理、購買と連携させ、情報を変更履歴付きで扱える構造にします。
- 設計情報：図面の版、承認状態、代替部品
- 製造・調達情報：所要量、納期、原価
国土交通省は、工程横断の生産性向上と供給網最適化を進める「DX造船所」を示しています（出典：国土交通省「造船業の国際競争力の強化」、2026年確認）。
重工業・造船業界のシステム発注形態の選び方
業務が固まった部分にはパッケージや標準機能を使い、競争力に直結する領域は個別に開発する方法が現実的です。一方で、全社一括のフルスクラッチは要件の揺れとデータ移行の負担が大きいため、段階導入を前提に比べます。
パッケージ・SaaS・フルスクラッチの役割分担
標準化しやすい領域はパッケージを検討し、個別性の高い領域は適合度を順に確かめます。
- 標準化領域：会計、購買、在庫、ワークフロー
- 個別性の確認：受注生産、製番、図面版管理、工程別原価
- 適合度の順：標準機能、拡張機能、連携開発
フルスクラッチは、将来の受注や製造で差別化に必要な機能に絞ります。機能を限るほど、投資効果を説明しやすくなります。
データ量と現場条件によるクラウドとオンプレミスの選び分け
拠点間共有や大容量データの扱い、設備との接続条件を並べて、構成ごとの向き不向きを比べます。
- クラウド：拠点間共有、拡張性、災害対策を重視する場合に候補
- 大容量データ：巨大なCAD図面や数百万点のBOMでは表示速度、転送量、通信断対策を検証
- オンプレミス：工場内LANの応答や既存設備との接続に強く、設備更新などは自社負担
- 運用負担：オンプレミスではバックアップや拠点間冗長化も自社で負担
- ハイブリッド：基幹データはクラウド、図面キャッシュやエッジ処理は現場に配置
RFPと要件整理で発注者が担う範囲
RFPは、解決したい業務課題や対象範囲、制約、評価方法を同じ条件で示すための文書です。「高機能なシステムを作ってください」という依頼書とは、性格が異なります。
発注者は業務の目的と優先順位を決め、ベンダーが方式と工数を提案します。
IPAは、要件定義をユーザー企業とベンダーの認識合わせと位置づけ、成果物への責任はユーザー企業にあると説明しています。この説明は、IPAの資料「要件定義とは？」で、2026年に確認しています。
RFPに記す業務・データ・非機能の三層
RFPには、業務の流れと関係者の責任、データの実態、システムの運用条件を記します。
- 業務：受注、設計、調達、製造、検査、出荷、保守の流れと責任
- データ：品目、製番、図面、BOM、工程、仕入先、原価、承認履歴
- 品質・運用：検索応答時間、図面容量、バックアップ、権限、監査ログ
- 例外時の条件：通信断時の動作と復旧目標
既存データは、件数や欠損、重複の状況を示します。さらに、表記ゆれや同時利用者数も提示します。
設計変更が原価と調達に波及する条件
造船では、建造開始後も顧客要望や現場事情、部材供給の状況で設計変更が発生します。そのため、変更要求の手順と変更対象への対応を、RFPの中で定義しておきます。
- 承認手順：起票者、影響分析の対象、承認者、適用開始日
- 部材対応：旧版部品と発注済み部材の扱い
- 原価処理：追加原価の計上方法
変更前後のBOMや工程、原価を追えないと、予算増加の理由を説明できません。
協力会社ポータルの利便性と分離管理
数百社規模の協力会社と図面、工程、検査記録を共有する場合は、全員に同じ情報を見せません。閲覧・登録・承認の権限は、案件や会社の単位で分けて設定します。
- 権限管理：案件、工程、会社、役割ごとに閲覧・登録・承認を設定
- 図面保護：有効期限、透かし、ダウンロード制限、操作ログ
- アカウント：退場した会社の利用を即時停止
現場では、片手操作やオフライン入力を含めて実機で検証します。写真圧縮や同期失敗時の再送も、同じ方法で確かめます。さらに、紙とExcelの二重管理を残さない運用も、RFPに記します。
システム開発の契約形態の組み合わせ
不確実性の高い上流工程と、成果物を確定しやすい開発工程は分けて契約します。たとえば、要件定義は準委任または支援契約、設計・製造・テストは請負が候補になります。
移行支援や保守は準委任とし、工程に応じて責任と対価を分けます。
準委任は探索と伴走、請負は確定した成果物の使い分け
準委任では、専門人材と作業時間を活用し、要件が定まらない作業を進めます。
- 準委任：現行調査、業務整理、試作、移行計画
- 請負：画面、API、帳票、テスト条件が確定した開発
未確定の要件に完成責任を求めると、想定外の追加変更を双方が抱えることになります。一方で、請負では成果物や納期を契約書と別紙に具体化します。検査方法と瑕疵対応も、同じ形で定めます。
契約書に明記する前提条件と変更管理
発注者が提供する情報や意思決定の期限は、契約上の前提として明記します。
- 提供物：マスタ、図面、インターフェース仕様、担当者
- 変更管理：受付期限、影響分析、見積承認、納期再設定
- 優先順位：変更管理票で決定方法を統一
未整備の品目・工程マスタを委託先へ任せると、意味や業務ルールの責任が曖昧になります。あわせて、口頭の依頼を正式な追加作業へ変換する手順も、あらかじめ決めておきます。
IPAのモデル契約解説でも、入力文書の不備に関する責任と発注者の関与が重視されています（出典：IPA「情報システム開発のモデル契約書に目を向けよう」、2026年確認）。
重工業・造船業界のシステム開発費用相場と内訳
費用は、拠点や利用者の数、BOM・図面の規模によって変わります。連携先や移行データの品質も関わります。現場端末、セキュリティ、保守範囲も影響するため、範囲と前提をそろえて概算を取ります。
ここに示す金額は、2026年時点の国内受託開発の相場観による予算の目安で、ベンダーの定価ではありません。見積もりの精度は、要件定義が終わったあとに上げていきます。
企画・小規模連携は数百万円、基幹刷新は数千万円から億円の幅
規模別の初期費用は、対象範囲に応じて次の幅が目安です。
- 企画・調査：現行調査、業務整理、RFP作成、試作まで数百万円から1,000万円程度
- 単一拠点：生産・購買・在庫連携や現場アプリの最小構成は1,000万円から5,000万円程度
- 複数拠点：ERP・PLM・生産管理・原価管理の基幹刷新は5,000万円から数億円規模
数百万点のBOMや大容量3D図面、複数工場、多数の協力会社が重なると、費用を押し上げます。さらに、旧システムからの複雑な移行では、移行、教育、並行稼働の費用も加算します。
初期費用以外の移行・教育・保守・インフラ費用
見積書では工程別の費用と、運用後に発生する費用を分けて確認します。
- 開発工程：要件定義、設計、製造、テスト、プロジェクト管理
- 導入作業：移行、教育、現場展開
- 運用費：クラウド、ストレージ、バックアップ、監視、セキュリティ、ライセンス
- 支援費：問い合わせ対応、機能改善
保守費は、開発費の15〜20％程度と置く場合もあります。ただし、率だけで判断するのは難しく、中身を分けて見る必要があります。
保守費の中身は、24時間監視や現場への出張を含むかどうかで変わります。図面容量の増加、SLA、機器保守の扱いも、金額を左右します。
IPAの見積り支援では、過去実績や開発規模、工数を使い、変動要因を示します（出典：IPA「CoBRA法に基づく見積り支援ツール」、2026年確認）。
委託先選定と見積比較で見るべきポイント
価格だけで選ぶと、要件漏れや移行費の追加が起こり得ます。さらに、現場展開が止まったり、保守が特定の人に偏ったりすることもあります。提案は、業務理解やデータ統合の深さで比べます。移行や現場定着、協力会社の安全も含めて見ます。
同業種実績は導入社数よりデータと業務の深さを見る観点
「製造業の実績」だけでなく、個別受注生産やデータ連携などの担当範囲を確認します。
- 業務実績：製番、BOM、工程別原価、設計変更
- システム実績：PLM・ERP連携、協力会社ポータル
- 導入実績：規模、拠点、連携先、移行件数、稼働後の定着
実績案件については、規模や稼働後の定着状況を具体的に聞いておきます。匿名化して説明できる会社を選び、デモには関係部門の担当者に参加してもらいます。設計や購買、現場の担当者は、特に欠かせません。
自社の受注案件を最初から最後まで通せるかを確認します。
見積比較で前提・成果物・除外範囲をそろえる方法
見積を作業や導入項目に分け、同じ条件で各社を比較します。
- 開発費：要件定義、ライセンス、カスタマイズ、インフラ、連携
- 移行・検証：データクレンジング、移行、テスト、教育、保守
- 前提条件：帳票、API、データ量、同時利用者、拠点
- 支援範囲：協力会社アカウント、テストケース、稼働後の日数
画面数や人月の合計だけでなく、含まれる成果物と対象範囲を照合します。移行や教育が抜けた安価な提案は、比較表の空欄を追加費用のリスクとして扱います。
サプライチェーンを止めない移行計画
一斉切り替えを避け、対象業務と拠点を分けた移行計画を提案してもらいます。
- 段階導入：パイロットと並行稼働
- 障害時の備え：切り戻し条件と代替手順
- 移行判定：現場の業務責任者も確認に参加
購買や部品供給が止まる事態に備えて、代替手順を流れごとに決めておきます。対象は受注から検収までの各段階です。たとえば、クボタのSAP導入時に工場生産管理機能が不全となり、部品調達へ影響したとされる事例を教訓にします。
移行判定は、経営会議に加えて、現場の業務責任者とも確認します。
重工業・造船業界のシステム発注でよくある質問
費用や契約の正解は、会社の規模と対象範囲で変わります。先に判断軸を決めると、異なる提案も比較しやすくなります。
重工業・造船業界のシステム開発は何社に相見積もりを取ればよいですか？
候補を3〜5社程度に絞り、同じRFPと質疑回答を渡して比較する方法が実務的です。候補が多すぎると評価に時間がかかり、各社との対話も浅くなります。
一次評価では業界実績や連携の体制を見ます。そのうえで、移行や定着、保守体制も含めて、最終的に2社程度を詳しく比べます。
要件定義からベンダーへ外注しても問題ありませんか？
外注はできますが、目的や優先順位の決定は自社で担います。現場の受入条件やマスタの正しさも、自社の責任です。
業務責任者を社内に置いたうえで、委託先から現行調査や論点整理、画面案の支援を受けます。要件定義書の作成も、支援の対象になります。最終的な要件の承認や、データの意味、運用ルールの決定は自社で行います。
クラウドとオンプレミスのどちらを発注すべきですか？
導入方式を決める際は、共有の利点と現場での検証条件を確認します。
- クラウドの利点：拠点間共有、災害対策、協力会社連携
- 構成の判断：大量の図面やBOMがあっても、全てをオンプレミスにする必要はない
- 事前検証：現場回線、データ量、既存設備、セキュリティ、通信断時の継続性
- 検証環境：図面表示、BOM検索、変更同期、オフライン復旧を数値で比較
費用を抑えるために最初に削るべき機能は何ですか？
初期費用を調整するときは、必須機能を保ち、後回しにできる範囲を見極めます。
- 初期範囲から外す候補：安全や原価精度に直結しない装飾機能
- 削らない機能：マスタ整備、変更履歴、権限、バックアップ
- 後段へ回す機能：利用頻度の低い帳票や高度な分析
- 段階導入：受注から製造、調達、原価までの最小業務を稼働させる
- 契約時の確認：APIやデータモデルを後から拡張できるか
まとめ
発注前には、プロジェクト原価やE-BOMとM-BOMの連携、設計変更の扱いを要件に含めておきます。協力会社との共有や現場操作も、要件として定めます。
要件定義は準委任、確定した開発は請負とします。そのうえで、段階移行と変更管理を契約に含めます。
費用は企画・検証の数百万円から、複数拠点の基幹刷新では数千万円から数億円まで幅があります。
参考情報は、国土交通省「造船業の国際競争力の強化」です（2026年8月確認）。関連URLはこちらです（https://www.mlit.go.jp/maritime/maritime_tk5_000014.html）。
同省の資料「造船業・舶用工業における技術開発の促進」も参考になります。関連URLはこちらです（https://www.mlit.go.jp/maritime/maritime_tk5_000067.html）。
IPAの参考資料には「DX動向2025」があります。関連URLはこちらです（https://www.ipa.go.jp/pressrelease/2025/press20250626.html）。
同機構の要件定義の資料も参考になります（https://dx.ipa.go.jp/youken-teigi）。
契約に関する参考資料は、IPA「情報システム開発のモデル契約書に目を向けよう」です。関連URLはこちらです（https://www.ipa.go.jp/archive/digital/iot-en-ci/vol18_column.html）。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。