重工業/造船業界のシステム開発の完全ガイド

重工業・造船システムは、長期案件と巨大なBOM、多重の供給網をつなぐことが鍵です。設計変更と実績原価を早期に経営判断へ反映すると、効率化を超えて品質・納期・利益を守れます。

国土交通省の「DX造船所」も踏まえ、現場で使われ続ける実務を解説します。各テーマの詳細は関連記事もご覧ください。

重工業・造船業界のシステムの全体像

案件番号を中央に置き、案件原価、BOMと図面、サプライチェーン、現場端末を結んだ図解。
案件番号が異なる業務領域を結ぶ接点になります。

重工業・造船業界では、案件ごとに仕様が異なり、受注から引き渡しまで数年かかることもあります。その間に設計、資材価格、納期、顧客要望が変わるため、販売管理や工場の生産管理だけをデジタル化しても、案件全体の収益性は見えにくいままです。

超長期プロジェクト・巨大BOM・多重サプライチェーンという特殊性

船舶やプラント、発電設備を案件単位で管理するとともに、BOM・図面と複数階層の協力会社も追跡します。

  • 案件原価:発注、入荷、工数、仕掛の実績を、案件ごとの原価として積み上げる対象です。
  • BOMと図面:品目コードより細かく、E-BOM、M-BOM、交換部品の版数や承認状態まで追います。
  • サプライチェーン:元請け、一次協力会社、専門工事会社、舶用メーカーなど複数階層が一つの建造に関わります。

原価の異常を早く捉えるには、見積時の計画原価と実績、完成見込みを時系列で把握することが欠かせません。

国土交通省は、工程横断の生産性向上と造船・舶用のサプライチェーン最適化を「DX造船所」の課題としています(出典: 国土交通省「海事:造船業の国際競争力の強化」、2026年閲覧)。

基幹システムから現場端末までの対象範囲

システム全体は、ERPや会計を中心に据え、設計から製造、調達、品質、現場までのデータをつなぎます。

  • 設計・製造:PLM、PDM、CAD、MES、生産管理を連携する範囲です。
  • 調達・管理:購買と在庫、品質と検査、工事進捗、原価を扱います。
  • 社外・現場:協力会社ポータルと、スマートフォンやタブレットの現場端末です。

現場端末から作業実績、写真、検査結果、災害リスク、部品の所在を登録できる点を押さえます。

最初から全機能を導入する必要はありません。発注側は、経営指標と現場が毎日入力できる最小単位を決めて、そこから始めます。そのうえで、設計変更や原価管理など損失が大きい接点から段階的に整備すると、現場に定着しやすくなります。

ポイント

全体像で迷ったら、案件番号で原価、BOM、協力会社、現場端末がつながるかを基準に対象範囲を決めます。最初は経営指標と現場が毎日入力できる最小単位から始めると、範囲が広がりすぎずに済みます。

重工業・造船業界特有のシステム要件

重工業・造船業界では、いつ、どの設計版を使い、どの会社が部品をどの工程へ投入したかを追えるデータ連携が必要です。そのため、要件定義では機能一覧に加えて、変更・承認履歴、権限、監査証跡も確認しておきます。

工事進行基準に対応したプロジェクト別原価管理

船やプラントの原価は、完成日に一括して確定するものではありません。

  • 原価の単位:契約金額を案件、船番、工区、作業パッケージに分けた単位です。
  • 費目:材料費、外注費、直接工数、間接費を、計画と実績に分けて登録する区分です。
  • 進捗把握:出来高をもとに、見込み総原価や粗利の変動を読み取ります。

進捗率だけで追うより、投入済み原価に対する出来高も併せて確認すると、見込み総原価や粗利の変動を早期に検知できます。

原価を把握するには、会計システムへの月次集計だけでなく、現場の動きをプロジェクト番号で結ぶ必要があります。対象は、発注から検収、出庫、作業報告、手直し、設計変更までです。

担当者が予算超過の原因を掘り下げられる画面も必要です。経理と製造で原価の定義が異なる場合は、要件定義の段階で共通ルールを決めておきます。

E-BOMとM-BOMをつなぐPLM統合

E-BOMとM-BOMは、持っている情報の中身が異なります。

  • E-BOM:設計者が作る、製品の機能と構成の情報です。
  • M-BOM:加工順序、組立単位、治具、作業場所、支給品を含みます。

両者を手作業で転記すると、品目の抜けや重複、版数の取り違えが起こります。そこで、PLMと生産管理、調達を連携し、承認済みの設計情報を製造と購買へ流す形にします。

国土交通省の造船DXでは、基本設計から生産設計までの3D設計情報連携がテーマです(出典: 国土交通省「海上輸送を支える造船業のデジタル化」、2023年)。

建造中の計画変更や手直しを減らすため、バーチャルな調整も扱います。3Dモデルの表示にとどめず、変更の影響を調達、工程、原価へつなげます。

数百万点規模の設計変更を波及させる仕組み

顧客要望や現場の干渉により、建造中にも設計変更が発生します。

  • 変更記録:差分や承認者、適用開始日を変更番号で管理し、登録後に関係者へ通知します。
  • 影響範囲:変更が及ぶBOM、発注済み部品、在庫、工程、原価の範囲です。
  • 変更後の処理:未使用部品の扱いと、追加費用の負担先です。

変更管理には、版管理と変更ロック、差分比較が必要です。さらに、影響範囲の検索と旧版の参照権限も欠かせません。

巨大なCADや3Dデータは、軽量プレビュー、必要部分のキャッシュ、メタデータ検索を組み合わせて扱います。また、すべてを同じ画面で開かない設計にすると、現場の待ち時間を抑えられます。

協力会社ポータルと現場のオフライン対応

協力会社ポータルでは、図面や指示、納期、検査などの情報を案件番号で共有します。問い合わせや承認も、同じポータルで扱います。

  • アクセス制御:会社ごとに閲覧範囲を分け、契約終了時に停止する仕組みです。
  • 操作履歴:図面のダウンロードや印刷を記録する機能です。
  • 通信断対策:通信が途切れた間の入力を、復旧後に同期する形にします。

ドック、地下、船内、屋外では通信が安定しない場所があるため、端末には必要な図面や手順を一時保存しておきます。

大容量データは全件同期を避け、作業場所と担当工程に応じた差分同期を基本にします。

ローカル5Gやエッジ処理も候補になります。ただし、電波の対策だけで解決するわけではないため、停電時の運用や端末交換も含めて検証します。

ポイント

要件が機能一覧だけになっていないかを確かめます。原価、BOM、変更、協力会社の四つそれぞれについて、誰が何を見て、どう使うかが書かれているかが判断の目安です。

クラウドとオンプレミスの方式選定

方式は、図面やBOMの容量、現場通信、機密区分、既存設備との連携から検討します。

将来の拠点追加や運用担当者の体制も判断材料になります。方式に唯一の正解はないため、部分的なクラウド利用や、現場・機密データをオンプレミスに置くハイブリッドも候補になります。

データの性質で決まるクラウドとオンプレミス

利用範囲と現場で扱うデータの条件を踏まえ、両方式の特性を比べます。

  • クラウド:拠点や協力会社との共有、災害対策、初期設備の抑制で力を発揮する方式です。
  • オンプレミス:工場内LANで応答を得やすく、設備や閉域網との連携を組みやすい形です。

クラウドは利用者数の増減に対応しやすい一方で、3D図面の容量や読み込み頻度によって、性能と費用が変わります。

回線速度や転送量、保存容量、認証経路を確認します。機密の設計情報では、暗号化と持ち出し制御を中心に、アクセスログやバックアップ場所も審査します。

オンプレミスでは、サーバー更新、冗長化、バックアップ、災害復旧を自社で負担し、専門人材も確保する必要があります。

TCO(総所有コスト)は、初期費用だけでなく、5年以上の運用費に回線、ストレージ、監視、障害対応を加えて比べます。

パッケージの標準化とスクラッチの固有業務対応

方式ごとに、共通機能の整備しやすさと固有要件への対応力を比べます。

  • パッケージ:受注生産向けの生産管理やERPの共通機能を、短期間で整えやすい選択肢です。
  • フルスクラッチ:独自原価計算や特殊工程、既存設備との深い連携に応えやすい方式です。
  • 段階開発:全面刷新を避け、固有の変更管理や現場アプリから開発を始める進め方です。

ただしスクラッチでは、要件の変動と保守人材の確保が課題になります。その対策として、マスタや認証、データ連携を共通基盤にする方法もあります。

購買や在庫、工程、原価などの領域で、標準機能に業務を合わせる範囲と、アドオンで残す固有要件を決めます。

導入前のデモでは、BOM変更、分納、手直し、検収を実際に操作して確認します。

ポイント

方式はデータの性質と現場の通信条件で決めます。機密データがあればハイブリッドも候補にし、パッケージかスクラッチかは、標準機能に業務を合わせられる範囲で判断します。

重工業・造船業界のシステム開発の進め方

企画・要件定義から重要シナリオによる試作を経て、テスト・移行・定着へ進む3段階の図解。
代表案件で試してから、移行と現場への定着へ進みます。

開発では技術選定より先に、経営や設計、調達、製造などの各部門と、協力会社の代表を巻き込みます。

IPA「DX動向2025」は、日本企業が個別業務の最適化に取り組む傾向と、全社最適や成果創出の課題を整理しています(出典: IPA「DX動向2025」、2025年)。そのため、部門ごとの便利な画面を増やすだけでなく、案件データの流れを設計することが大切です。

企画・要件定義での業務とデータの境界

案件の開始から引き渡しまでを業務フローにし、情報ごとのオーナーを決めます。

  • 管理対象:品目、図面、版数、工程、取引先、作業者の範囲です。
  • 記録対象:原価と品質記録について、誰が責任を持つかを決めます。
  • マスタ責任:部品・工程マスタの登録と廃止を、社内で承認する役割です。

部品・工程マスタについては、命名や重複時の扱い、廃止手続きまで、社内の責任者が決めておく必要があります。

要件は、「画面が欲しい」ではなく業務の成果で書きます。たとえば、設計変更から影響確認までの時間や、月末の予実差異の粒度を定めておきます。さらに、入力者と承認者、例外時の代替手段を決め、保存期間や監査ログも要件に含めます。

重要シナリオによる試作と段階的な展開

全社のデータを移す前に、代表的な一案件を選び、現場で操作を試します。

  • 設計変更:変更後にどこまで影響が及ぶかを追跡する場面です。
  • 調達・作業:代替部品の発注と、協力会社の作業報告が通るかを確かめます。
  • 品質・原価:検査不合格、手直し、原価差異の扱い方です。

画面の見た目より、同じ番号で情報を追跡でき、次の担当者の作業が分かるかを見ます。

移行では旧コードと新コードの対応表を作り、重複、欠損、旧版、単位違いを洗い出します。

テストデータは、きれいなサンプルだけでなく、例外の多い実案件を使います。連携先が多い場合は、再送、重複登録、障害時の手動復旧も試します。

テスト・移行・定着で二重管理を残さない設計

リリース直後は、紙やExcelをすぐに止められない業務もあります。ただし、期限のない二重管理は形骸化するため、終わりの時期を決めておく必要があります。

  • 廃止時期:帳票の廃止日と、旧システムを参照専用にする日です。
  • 切替責任:入力を切り替える責任者を、事前に決めておきます。
  • 現場訓練:実機を使い、現場の作業者が操作に慣れるための場です。

現場訓練では、片手での操作や写真の添付、音声や選択入力、通信断からの復旧を扱います。

段階移行では、業務の境界を受注から原価まで明確にし、旧システムへ戻す手順も用意します。

切替は、在庫差異や発注漏れ、工程遅延、原価差異、問い合わせ件数で評価します。稼働したかどうかは、その一部にすぎません。

重工業・造船業界のシステム開発費用相場

小規模検証、一部導入、複数拠点連携の3段階と、それぞれのシステム開発費用の目安を示す図解。
対象範囲が広がるにつれて予算規模も大きくなります。

重工業・造船業界向けシステムに、公的機関が示す一律の標準価格はありません。

費用は機能数に加えて、BOMや図面の容量、拠点と協力会社の数によって変わります。連携本数や移行、24時間運用、セキュリティ、現場端末の台数も影響します。生産管理システムは数十万円から数千万円以上まで幅があるとされています(出典: CREX Group「生産管理システムの費用相場」、2025年)。

要件を分けて見積もる規模別の予算

予算の初期目安は、対象範囲を分けて考えます。次に示す数字は市場統計ではなく、目安として読んでください。

  • 小規模検証:現状分析と現場アプリ検証で、数百万円程度です。
  • 一部導入:パッケージ中心の場合は、1,000万円前後から数千万円です。
  • 複数拠点連携:ERP・PLM・MES等を使い、数千万円から数億円規模です。

一部導入は、受注・購買・工程・原価を対象とする案件を指します。複数拠点連携には、協力会社ポータルも含みます。

同じ要件書をもとに複数社から見積もりを取り、要求範囲に見合った予算かを確認します。

見積書は、要件定義、ライセンス、環境構築、画面・API開発の項目を分けてもらいます。さらに、移行、教育、テスト、切替支援、保守も別の項目にしてもらいます。

移行や連携テストが「別途」の場合、後から予算が膨らみやすくなります。

パッケージでは、標準機能と設定、追加開発、将来の追加費用を区別して確認します。

5年単位で見る保守・運用費とインフラ費

稼働後の費用は、システム保守と稼働環境の両面で見積もります。

  • インフラ:クラウドやデータセンター、監視、バックアップ、端末、通信の費用を指します。
  • 保守・運用:アプリやライセンス、問い合わせ、法改正への対応、追加開発に関わる費用です。

JUASの調査では、開発形態や保守内容により、パッケージ本体や追加開発を含む保守負担に差があります(出典: 一般社団法人日本情報システム・ユーザー協会「ソフトウェアメトリックス調査2020」、2020年)。

年間保守費を初期開発費の15〜20%程度と試算する例もありますが、あくまで出発点です。大量データの保存や厳格なSLA、休日対応、監視、追加開発を含めると、費用は変わります。

初期費用が安い提案ほど、5年間の総額と、保守終了後に自社で引き継げるかを確認します。

ポイント

費用は一般的な目安として扱い、予算は要件を分けて見積もった結果で決めます。初期費用だけでなく、保守やインフラを含む5年の総額で比べることが判断の目安です。

開発会社・サービスの選び方と発注のポイント

会社選びでは、個別受注生産や重工業、造船、プラントに近い案件の経験を確認します。現状分析や移行、現場教育、運用改善を担う担当者がいるかも見ておきます。

候補会社には、設計変更と原価差異のシナリオを示し、デモでの回答を求めます。

同業種実績とPLM・ERP連携の経験

質問では、同じ業界での導入社数だけでなく、実業務の処理方法まで具体的に聞くことが大切です。

  • 設計・調達:E-BOMからM-BOMへの変換と、変更の波及の扱いです。
  • 原価・権限:案件原価と会計の扱い、協力会社の権限管理の方法です。
  • 現場・移行:通信断時の報告の仕方と、旧システムからの移行件数です。

回答が製品カタログの説明にとどまる場合は、実案件での設計力を追加で確かめます。

PLM、ERP、MES、CAD、IoT、会計のすべてを一社で提供できなくても、問題はありません。大切なのは、各製品の責任範囲、API仕様、障害時の一次窓口、データ所有権を明文化できる統合パートナーかどうかです。

発注者側の責任と契約上の役割

業務知識を開発会社に任せきりにすると、マスタの重複や例外処理が仕様に残らないおそれがあります。

  • 発注者:業務の優先順位、マスタ、承認者、受入基準、データ期限を担う立場です。
  • 開発会社:実現方法、制約、リスク、テスト結果を、発注者に説明します。

発注者と開発会社は、協力して仕様を確定する関係が必要です。

契約では、要件変更、検収条件、知的財産、データ返却を定めます。さらに、再委託やセキュリティ、障害対応、終了時の移行支援も定めておきます。

要件が確定しないまま固定価格だけを求めると、変更費用や責任分界をめぐる問題が起きやすくなります。

短い企画・要件定義契約を先に置き、見積精度を高める方法も有効です。

失敗事例から学ぶ移行のフェールセーフ

基幹システムの切替では、稼働日に調達や出荷、製造が止まる事態を避ける必要があります。大規模導入では、現場機能の不具合が発注や生産へ波及したと報じられた例もあります。

  • 段階切替:拠点や工程ごとのパイロット導入です。
  • 照合・参照:在庫と発注を突き合わせ、旧系統を参照できる状態にしておきます。
  • 緊急対応:手動で発注する手順の準備です。

重工業では一社の停止が協力会社へ連鎖しやすいため、一括切替は避けます。

データ品質も対策の一部です。部品・工程マスタに責任者を置き、重複を確かめ、変更を承認し、定期的に全体を点検します。

発注前には、件数や金額、納期、仕入先、案件番号を旧システムの値と比べます。差異が残ったまま次工程へ進めない制御も組み込みます。

ポイント

会社選びでは、同業種の実績に加えて、実案件の処理方法まで具体的に答えられるかを見ます。発注側が担う役割を先に整理しておくと、判断が早まります。

よくある質問

費用や方式は、会社の規模と要件によって変わります。そのため、各質問への回答も、自社の案件条件に置き換えて検討することが大切です。

重工業・造船業界のシステム開発費用はいくらですか?

小規模検証は数百万円程度で、一部導入は1,000万円前後から数千万円です。複数拠点でPLM・ERP・MESを統合する場合は、数千万円から数億円まで広がります。

相場を見たうえで、移行や連携、教育、保守、インフラを含めた5年の総額で比べることが大切です。

造船業のシステムはクラウドとオンプレミスのどちらが良いですか?

共有対象やデータ環境に応じて、両方式の向き不向きを比べます。

  • クラウド:協力会社との共有や複数拠点の利用を重視する場合に候補です。
  • オンプレミス:閉域環境や大容量データを安定して扱うことを重視する場合の選択肢です。

機密データをオンプレミスに置き、業務ポータルをクラウドにする構成も選べます。

実際の図面データと現場通信で性能試験を行い、机上の比較だけで決めないことが重要です。

システム導入はどの業務から始めるべきですか?

経営効果と現場の利用頻度が高く、他工程への影響を測りやすい業務から始めます。候補となるのは、設計変更管理、案件別原価、購買・在庫、作業実績です。そのうえで、代表案件で試作し、データ品質と定着を確かめてから、拠点や協力会社へ展開します。

まとめ

この記事の重要ポイント

設計・製造・調達・原価を案件番号と変更番号で結び、現場と経営が同じ事実を見られる状態をつくります。

重工業・造船では、長期の個別受注と巨大なBOMや図面が前提になり、頻繁な設計変更と多重の供給網も重なります。

機能数や方式を先に決めるより、業務成果、データ責任、移行リスクを基準に優先順位を付けます。

最初に取り組む代表案件の選び方

最初に代表案件を一つ選び、現場と一緒に、BOMから原価差異までの流れを一覧にします。選ぶ案件は、業界の特徴が表れ、設計変更の波及を追える案件が適しています。選んだ案件では、次の流れで進めます。

  • 要件化:一覧にした結果を、要件書にまとめます。
  • 原価と設計:工事進行基準に対応した案件別原価管理と、E-BOM・M-BOMをつなぐPLMを組み立てます。
  • 変更と現場:変更を調達や工程へ波及させ、協力会社ポータルと通信断に強い現場機能を備えます。
  • 予算と相談:費用は目安として捉え、現状調査と要件定義で予算を確定します。複数社に同じ条件で相談し、見積もりを比べます。

国土交通省は、2025年の日本造船業について、従業員一人当たりの新造船建造量を2019年比で2割向上させ、1,800万総トンを建造する目標を掲げていました(出典: 国土交通省「海事:造船業の国際競争力の強化」、2026年閲覧)。こうした動きを踏まえ、システム投資は、設計から製造、協力会社、引き渡し後までのデータを使い、品質・納期・利益を守るために計画します。

参考情報: 国土交通省「海事:造船業の国際競争力の強化」、国土交通省「海上輸送を支える造船業のデジタル化」、IPA「DX動向2025」、JUAS「ソフトウェアメトリックス調査2020」、CREX Group「生産管理システムの費用相場」を参照しています。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。