設計変更管理システム開発の発注/外注/依頼/委託方法について

設計変更管理システムの発注は、業務とデータの整理、RFPと契約の確定、段階導入の順に進めます。この順で進めると、設計変更を製造の現場まで反映しやすくなります。

具体的には、発注形態と要件を整えたうえで費用と委託先を見極め、導入後は運用を含めて段階的に広げていきます。

▼全体ガイドの記事
・設計変更管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

設計変更管理システムを発注する前に知るべき全体像

設計変更管理システムには、図面やCADデータを保存する以上の役割があります。変更の理由と承認者、適用日を記録し、対象部品や製番・ロット、実施結果まで残します。

システムは、関係部門が同じ正式版を参照するための業務基盤です。範囲が曖昧なままだと、申請機能だけを作る受託会社と、製造まで反映する仕組みを期待する発注者との間で認識がずれます。

ECR・ECO・ECNの管理範囲

発注する範囲を決めるには、用語、状態、承認の設計を先にそろえておく必要があります。整理の際は、次の3つの観点を押さえます。

• 用語：ECRは設計変更要求、ECOは変更を実施する設計変更オーダー、ECNは承認された変更を関係者へ通知する設計変更通知
• 状態遷移：起票者・影響評価者・承認条件・製造への配布時期を決める。用語の境界は会社によって違う
• 承認ルート：軽微な寸法修正は設計内で完結し、安全・法規・原価に関わる変更は品質保証や生産技術も審査に加わる

NECの設計変更管理ソリューションも、ECRの属性、ECOの仕掛かり・承認待ち・正式などの状態、実施・確認・配布の記録を管理する構成を示しています（出典: NEC「設計変更管理ソリューション」、2026年確認）。

発注範囲は、画面や入力フォームの数ではなく、変更を正式版としてリリースできる統制の範囲で決めます。

PDM・PLM・ワークフロー製品の役割分担

設計部門でCADデータや文書の版管理が中心なら、PDMが候補になります。

設計BOMを製造BOMへ展開し、品質・購買・在庫・工程・サプライヤーへ伝える場合は、PLMが適しています。

PLMは、必要に応じて基幹システムと連携させます。ただし、申請と承認だけが目的なら、ローコードやワークフロー製品でも始められます。

BOM差分や版の不変性、監査証跡は、後から足すと限界が出やすい項目です。製番・ロット単位の有効性も、後付けでは限界が出やすくなります。特に、発注相談では製品名より業務の成果を先に伝えます。

• 製造へ影響を反映：設計変更を製造まで届けること
• 正式版を共有：設計と製造が同じ有効版を参照できる状態

発注先が製品販売に偏らず、現行プロセスの棚卸しから支援できるかも確認します。

設計変更管理システムの発注形態の選び方

短期間で標準的な変更管理を始めたい場合は、クラウド型パッケージが候補になります。

既存のCAD・ERP・MESや独自の有効性ルールとつなぐ必要があれば、パッケージ導入と連携開発を検討します。

競争力に直結する特殊な業務があるなら、個別開発が候補です。

導入スピード、保守、データ移行、製品更新への追随まで含めて選びます。価格だけで発注形態を決めないことが大切です。

クラウド型・パッケージ型での始め方

形態を選ぶときは、導入しやすさと運用条件、標準機能の範囲を比べます。

• クラウド型：サーバー・初期インフラの負担を抑え、1拠点・1製品群や複数拠点で始めやすい
• RFPの運用条件：ユーザー、保存先、バックアップ、認証、外部共有、終了時のデータ返却の条件
• SaaSの範囲：設計変更情報・文書・製品構成を扱える製品もある。CAD・ERP連携、移行、教育は別作業の場合がある
• パッケージ型：ECR・ECO・ECN、版管理、承認、監査ログなどを標準機能で整えやすい
• 標準機能の活用：Fit to Standardを基本に、法規制や製品固有の有効性管理など、差別化に直結する部分だけを設定・拡張する

外部の協力会社も同じ環境を使いやすくなります。一方で、アドオンを増やすほど、更新のたびに改修費がかさみ、委託先を変えることも難しくなります。

個別開発・ローコードの使い分け

個別開発とローコードは、独自要件への適合性と保守の負担を比べて使い分けます。

• 個別開発：独自構成、複雑な製番・ロット、特殊承認、レガシー連携が競争力に関わる場合
• ローコード：申請・承認・通知・期限管理のPoCを小さく試す場合
• 役割分担：業務の核をパッケージ、周辺の入力や通知をローコードで担う方法もある

個別開発は柔軟に作れる一方で、OS・DBの更新、脆弱性対応、担当者の退職後の保守、連携先の仕様変更も、発注者の負担になります。

初期費用だけで選ばず、設計書、テスト仕様書、ソースコード、運用手順書の納品と、障害時の責任の分け方を契約に含めます。

BOM差分やCAD参照、設計BOMから製造BOMへの反映まで広げる場合は、PLMとの連携方針を先に決めておきます。

RFPと要件整理の進め方

RFPは、製品名や画面一覧ではなく、現行業務と目指す状態を基準に各社の提案を比べるための資料です。

データ、連携、非機能、納品物、評価方法も同じ条件でそろえます。

現場の変更票を数件たどり、例外処理や旧版の回収を確認してから要件を書きます。業務が分からないままRFPを作ると、後工程で追加開発が重なり、費用も膨らみます。

変更プロセスと対象データの棚卸し

要件の漏れを防ぐには、現行の変更業務を洗い出し、どこに何が残っているかを確かめておく必要があります。

• 変更理由：顧客クレーム、品質不具合、原価低減、部品廃止、法規制対応。優先度と承認者も合わせて確かめる
• 対象データ：図面、CAD、仕様書、検査規格、設計・製造BOM、工程表、在庫、仕掛品、設備、購買先
• 現状記録：変更票、メール、共有フォルダ、ERP・MESの登録内容を照合する
• RFP条件：差分、上下位部品の影響、代替部品、適用日、型式、製番、ロット、シリアル
• 現場運用：製造・品質保証・購買・保守・サプライヤーの確認時期と旧版の検知・差止め・回収を定める

RFPに必ず書く機能要件・非機能要件

各社が同じ前提で回答できるよう、機能・連携・非機能の条件を分けて書きます。

• 機能：ECR・ECO・ECNの登録項目、変更種別ごとの承認ルート、差戻し、期限通知、電子署名、版・リビジョン、関連文書、BOM差分、影響範囲、配布記録、監査ログ
• 連携：CAD・ERP・MES・品質管理・購買・文書管理・サプライヤーポータルとの連携方式、正データ、同期頻度、再送・手動復旧
• 非機能：利用者数・拠点数・同時利用、検索性能・稼働時間、バックアップ・復旧目標、可用性、認証・権限、暗号化、ログ保存期間、データ所在、外部接続、サポート時間

現場でスマートフォンやタブレットを使う場合は、入力項目と、通信が途切れたときの扱いも確認します。

経済産業省の2025年4月更新資料は、工場システムの対策に加えて、委託やサプライチェーンの観点も示しています（出典: 経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策」、2025年）。

設計変更管理システムの発注から導入までの進め方

発注後は、要件定義、プロトタイプまたはPoC、設定・開発と進み、データ移行を経て、連携テストと受入テストで確かめます。その後、教育を行ってから段階リリースに入ります。

設計、製造、品質、購買、情報システムの代表者が意思決定できる体制を作ります。1工場か1製品群に絞り、KPIを測ってから横展開します。

PTCの「設計変更管理とは？」で2026年に確認した公式事例では、Vaillant Groupが設計変更通知の反映期間を150日から90日に短縮しています。

ただし、同じ効果が自社で出るとは限りません。そのため、発注時に現状のリードタイムを測り、改善目標を決めておきます。

委託先の体制と要件定義の進め方

委託体制と要件定義では、誰にどこまで任せるかを明らかにしておく必要があります。

• 委託先の経験：製造業コンサル、PLM・PDM、移行、CAD・ERP・MES連携を確認する
• 責任分担：製品仕様、要件定義、移行、稼働後の各責任者を特定し、発注者側にも業務責任者を置く
• 要件の分類：現状・将来フローを並べ、標準機能、設定、開発、廃止に分ける

現場の例外を、すべてカスタマイズで解決する必要はありません。承認者、有効日、実施確認者を決めておくと、見積と受入条件が明確になります。

移行・連携・テスト・定着の管理

移行から定着まで、各工程の確認事項と完了条件を順に決めていきます。

1. 正式版・旧版・廃止版、欠落属性、重複品番、関連BOM、アクセス権を判定し、移行対象とアーカイブを分ける。古い図面や重複部品は取り込まない。
2. 移行サンプルで件数を確かめるだけでなく、図面から部品、部品から上位製品、変更票から承認記録へたどれるかも確かめる。
3. BOM差分の不一致、品番未登録、承認取消、通信失敗、二重送信、旧版参照、権限不足を想定して連携テストする。
4. 正しい版が正しい部門へ届き、エラーを検知して再送か切り戻しができることを完了条件にする。

稼働後は、操作ログや承認滞留、差戻し理由、旧版の使用件数、変更リードタイムを月次で確かめます。あわせて、使われていない入力項目も見直します。

契約形態の使い分け（請負・準委任・SaaS）

契約形態は、成果物と要件の確定度で選びます。納品する機能、期限、検収条件を合意できる部分は請負になります。

業務整理や調査、PoC、アジャイルで仕様を検証しながら進める部分は、準委任が基本です。

クラウド製品は利用契約のほか、導入設定、連携、移行、教育、保守が別契約になる場合があります。そこで、総額と、どこまでを誰が受け持つかを一枚の表にまとめます。

請負契約と準委任契約の分担

成果物と要件の確定度に応じて、どの工程をどの契約にするかを決め、引継ぎ事項も残しておきます。

• 請負：納品物、完成判定、検収、瑕疵や不具合の対応、変更管理の手順を明確にする
• 準委任：調査、業務整理、仕様検証、稼働後改善に使う。成果や費用上限の管理に注意する
• 工程分割：調査・整理は準委任、合意後の設定・開発は請負、稼働後改善は準委任とする方法がある
• 引継ぎ：前提、未決事項、追加費用の条件、再見積の時期を文書に残す

要件が不足したまま全工程を請負にすると、最低限の機能で完成扱いとなり、現場の期待とずれる場合があります。

反対に、要件が明確な設定や連携アダプターを準委任にすると、成果と費用の上限を管理しにくくなります。

契約書で確認するデータ・知的財産・保守範囲

契約では、データ、アクセス、保守、費用の範囲をそれぞれ定めておきます。

• 権利と利用範囲：図面、BOM、変更履歴、ログ、設定、ソース、API仕様、テストデータ
• クラウド終了時：データ出力形式、削除証明、バックアップ保持、サブコンポーネント・再委託先のアクセス
• 秘密情報の管理：秘密保持に加え、閲覧・ダウンロード・印刷・外部共有の許可者を定める
• 保守内容：障害切り分け、復旧目標、問い合わせ時間、パッチ、製品更新、連携変更、追加ユーザー、帳票・ワークフロー改修

障害の原因が受託会社、製品ベンダー、クラウド基盤、社内ネットワークのどこにあるかを判定する手順も定めます。

保守費を初期開発費の年15〜25％程度で計画する例もあります。

この数値は、製品や契約、対象範囲によって変わるため、固定値ではなく見積条件として確認します。

設計変更管理システムの費用相場と見積の内訳

専用システムは公開定価が少なく、費用はユーザー数、拠点数、CAD・ERP・MES連携によって変わります。移行の手間と導入形態も、見積の金額を左右します。

• 移行量：図面・BOMの件数だけでなく、関連付けや属性変換、重複品番の整理で工数が変わる
• 導入形態：クラウドかオンプレミスかで、費用が変わる

独自の有効性管理も費用に影響します。

次に示す金額は製品価格の確定値ではなく、2026年時点の開発相場とPDM・PLM導入情報による計画用の推定です。

正式な予算は、同じ条件のRFPで見積を取り、作業範囲を確かめてから決めます。

導入パターン別の費用レンジ

金額と期間は、対象範囲に応じて次のように推定されています。いずれも計画用の目安です。

• 小規模クラウドPDM・PLM：1拠点で文書・BOM・変更ワークフローから始め、初期費用100万〜600万円程度、期間1〜3か月
• 連携付きパッケージ：CAD・ERP・品質システムとの連携を含み、500万〜2,000万円程度、3〜9か月程度
• 中規模PLM導入：複数工場の製造BOM・承認・権限・データ移行を統合し、2,000万〜5,000万円程度、6〜12か月程度
• 大規模な個別開発：独自の有効性管理、複数のレガシー連携、全社展開を含み、5,000万円から1億円超、期間12〜24か月以上となる可能性

一般的なシステム開発の人月単価は60万〜200万円程度とする相場情報もあります（出典: SIA「システム開発の費用・相場 2026年版」）。

設計変更管理では、業務コンサル、PLM導入SE、連携、移行、テストのそれぞれの専門性が総額に影響します。

ライセンス以外に発生する費用

見積では、ライセンスやSaaS利用料とは別に、次の作業を分けて確認します。

• 導入準備：現状調査、要件定義、業務フロー設計
• 構築と連携：環境、画面・権限・ワークフロー設定、追加開発、CAD・ERP・MES連携
• 移行と検証：データクレンジングと移行、テスト
• 稼働支援：教育、マニュアル、稼働後支援

移行工数は件数だけでは決まらず、図面とBOMの関連付けや属性変換、重複品番の整理、旧版の扱いも影響します。

費用を抑えるなら、変更要求・承認、図面・BOMの版管理、製造通知というMVPに絞り、標準機能を優先します。

導入後は、1製品群で実データを使い、変更リードタイム、承認滞留、旧版参照、手戻りを測定してから、品質やサプライヤー連携を加えます。

見積金額だけでなく、対象外の作業と将来拡張時の単価・前提も確認します。

委託先の選定と見積比較で見るべきポイント

委託先は製品の知名度だけで選ばず、同じ規模・業種・拠点数での導入経験や、ECR・ECO・ECNの実装経験を確認します。

BOM差分や影響分析、CAD・ERP・MES連携も選定の材料になります。そのほかに、次の項目も選定の材料です。

• 移行：件数だけでは決まらない工数を、属性変換や重複品番の整理まで含めて確認する
• 現場教育：操作方法に加えて、正式版の定義や旧版を使ってはいけない理由まで伝えられるかを確認する
• 国内保守：国内での保守対応の体制と範囲を確認する

自社の変更票を使った実機デモをすると、提案機能と運用の差が見えてきます。

委託先に確認する実績とデモの内容

導入社数の多さよりも、変更前後をどう管理し、製造・購買・品質へどう配布したかを聞くことが大切です。デモでは、次の一連の操作を確認します。

• 変更の処理：起票、影響分析、承認、差戻し、版のリリース
• 現場への反映：製造側の確認と監査ログの追跡
• 例外の確認：権限不足、連携エラー、検索結果に混ざる旧版の識別

可能であれば、匿名化した画面や業務フローを使うとよいでしょう。

提案体制では、PM、業務コンサル、製品・設定の各担当に加えて、連携、移行、テストの担当と稼働時期も確認します。

提案責任者が稼働後にいない場合は、引継ぎ先とエスカレーション先を決めておきます。再委託の範囲やアクセス権、秘密保持、事故時の報告責任も、契約に反映させます。

見積を同じ条件で比べる方法

総額を比べる前に、各社の見積項目と前提条件をそろえておきます。比べる区分も、各社で同じにします。

• 導入作業：要件定義、設定、個別開発、連携
• 稼働準備：移行、テスト、教育、保守
• 前提条件：連携本数、移行件数、ユーザー・拠点数、テスト数、教育回数

「一式」とだけ書かれた項目は、作業内容、工数、担当者、前提データ、除外事項を質問します。条件がそろわないままだと、安く見えた見積に後から追加費用が発生することがあります。

比較表には、標準機能、設定、追加開発、発注者の準備範囲を書き込みます。あわせて、納期の起点が契約、要件確定、移行完了のどれなのかも確かめます。

費用・期間・機能がすべて有利に見える提案でも、対象外の作業や将来費用が隠れていないかを確認して評価します。

設計図面・BOMを守るセキュリティと運用の要件

設計図面やBOMには、製品ノウハウや営業秘密が含まれることがあります。そのため、安全性はクラウドかオンプレミスかだけでは判断しません。

RFPには、最小権限、MFA、通信・保存時の暗号化を含めます。ほかに、次の項目も入れます。

• 操作・変更ログ：閲覧・変更・承認・配布の実行者と日時を追跡できるようにする
• バックアップ：復旧目標に合わせて設計する
• 復旧訓練：復旧の手順を、実際に試しておく

外部協力会社の権限には期限を付け、退職者の権限は即時に無効にすることも定めます。

製造現場のOTネットワークとITシステムをどう分離し、どう接続するかは、情報システム部門と工場側で合意しておきます。

RFPで確認する認証・権限・ログ

認証と権限では、担当者や業務に応じてアクセスを制御できるように定義します。加えて、次の運用も実際に試しておきます。

• 認証：社内ID連携、MFA、外部本人確認、共有アカウント禁止
• 権限：設計・製造・品質・購買・保守・サプライヤーごとに、閲覧・登録・編集・承認・ダウンロード・配布を分け、製品・拠点・プロジェクト単位で制御する
• 例外対応：代理承認、緊急変更、期限切れ、異動、退職時の停止

ログでは、閲覧・変更・承認・配布の実行者と日時を追跡します。そのうえで、改ざん防止や保存期間、検索・出力、監査提出、異常アクセス通知も確認します。

委託先の開発環境やサポート環境へ本番データを持ち出す場合は、匿名化、持ち出し承認、保管期限、削除確認を必須にします。

工場システムでは、サイバー攻撃が操業停止につながるおそれがあります。そのため、脆弱性対応と復旧訓練も稼働後の委託範囲に含めます。

現場が使い続ける運用ルールの設計

現場に正式版の運用を根づかせるには、画面と教育、定期確認を一緒に設計する必要があります。

• 入力設計：必要項目に絞り、メールや紙での連絡から正式版管理へ移す
• 現場画面：CADを使わない担当者も対象製品・変更理由・適用時期・確認事項を理解できるようにする
• 教育：操作方法だけでなく、正式版の定義、旧版を使ってはいけない理由、変更を見つけたときの起票方法を伝える
• 定期確認：変更リードタイム、承認滞留、差戻し、未配布、旧版参照、不具合、手戻りを追う

変更管理を導入しても、現場がメールや紙での連絡を続けていれば、正式版をまとめて管理することはできません。KPIが改善しないときは、機能を足す前に、承認者、入力項目、責任部門を見直します。

設計変更管理は、納品後も製品や組織、工場の変化に合わせてルールを更新し続けるものです。

よくある質問（FAQ）

設計変更管理システムの発注では、まず自社の変更業務をどこから整理するかが出発点になります。費用や製品は、その整理をもとに比べていきます。

設計変更管理システムの開発費用はどのくらいですか？

小規模なクラウドPDM・PLMは初期費用100万〜600万円程度、連携付きパッケージは500万〜2,000万円程度が、計画用の推定になります。

複数拠点のPLM統合は2,000万〜5,000万円程度、個別開発は5,000万円から1億円超となる可能性があります。

専用システムに公開定価は少なく、費用はライセンス、設定、連携、移行、教育、保守の範囲で変わります。そのため、RFPで同じ条件の見積を取って比べます。

設計変更管理はスクラッチ開発とパッケージ導入のどちらがよいですか？

標準的なECR・ECO・ECN、版管理、承認、監査ログを早く整えるなら、パッケージが候補です。

独自の製品構成や有効性、レガシー連携が競争力に直結し、標準機能で業務を変えられない場合は、個別開発を検討します。

最初から全社でスクラッチ開発に進めず、標準機能のPoCで業務を検証してから追加開発を判断するのが安全です。

委託先を選ぶときに最も重視するポイントは何ですか？

同規模・同業種の実績、BOM差分と影響分析を確認します。ほかに次の項目も確認します。

• CAD・ERP・MES連携：既存システムとのつなぎ込みの実績を確認する
• 移行：既存データの移し替えを、どこまで担うかを確認する
• 現場教育：現場の担当者への教育の範囲を確認する
• 稼働後保守：稼働後の保守をどこまで担うかを確認する

実機デモでは変更要求から承認、差戻し、版のリリース、製造配布、権限不足や連携エラーを自社に近い形で試します。

製品ベンダーと実装SIerが別なら、要件定義、移行、障害対応の責任者を契約前に明確にします。

小さく始める場合は何から着手すればよいですか？

1工場または1製品群に絞り、変更要求・承認、図面・BOMの版管理、製造通知から始めます。実データを使って、移行と連携を試します。

変更リードタイム、承認滞留、旧版参照、手戻りをKPIとして測定します。効果を確かめてから品質、購買、サプライヤー、複数拠点へ広げれば、過剰な投資と現場の混乱を抑えられます。

まとめ

発注前にそろえるべき判断材料

申請画面の開発費だけで判断せず、変更要求から影響分析、審査、承認までの流れを整理します。あわせて、次の段階も範囲に含めます。

• 実施
• 製造・購買・品質への配布
• 効果確認

設計部門中心ならPDM、製造・品質まで含めるならPLM連携、特殊な有効性やレガシー連携が必要なら個別開発を検討します。

段階導入で失敗を防ぐ進め方

発注前にそろえる条件と導入時の判断は、RFP、見積、導入の3点に分けて考えます。

• RFP：ECR・ECO・ECN、BOM差分、適用日・製番・ロット、権限、監査ログ、連携、移行、教育、復旧、保守を含める
• 見積：小規模の100万〜600万円程度から大規模の5,000万円〜1億円超まで幅があるため、根拠と除外事項を確認する
• 導入：1工場・1製品群で実データを使い、定着を確かめてから段階的に広げる

▼全体ガイドの記事
・設計変更管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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