図面管理（EDM）開発のPoC・プロトタイプ・モックアップ開発について

製造業や建設業で図面管理（EDM）システムを新規に開発・導入する際、いきなり本格開発に着手するのではなく、まずは小さく試して技術的な実現性や現場での使い勝手を検証する「PoC（概念実証）」「プロトタイプ」「モックアップ」を活用することが、失敗を避けるうえで極めて有効です。ここで本記事が扱う図面管理（EDM＝Engineering Document Management）とは、社内のあらゆるファイルを保管する汎用的なファイル・ドキュメント共有基盤ではなく、2次元・3次元のCAD図面という専門的な設計成果物に固有のメタデータとワークフローを管理する仕組みを指します。図面ごとのリビジョン（版数）管理、設計変更（ECN／ECO）の履歴追跡、図番体系と部品表（BOM）の紐付け、設計から検図・承認・出図に至る承認ワークフロー、専用CADソフトなしで閲覧できるCADビューア連携、取引先・協力会社への図面貸与と機密管理といった、ものづくり固有の高度な機能を担うのがEDMです。こうした専門機能は、大容量CADデータの扱いや複雑なBOM構造、既存の基幹システムとの連携が絡むため、事前の検証なしに本格開発へ進むと、稼働直前になって「現場で使えない」「性能が出ない」という致命的な問題が発覚しかねません。だからこそ、EDM開発ではPoC・プロトタイプによる事前検証の価値が高いのです。

本記事では、図面管理（EDM）開発のPoC・プロトタイプ・モックアップ開発に焦点を当て、本格開発前にPoCで検証すべき項目（大容量ビューアの表示性能、図番／BOM紐付けと版管理、既存システム連携）、モックアップやプロトタイプで承認ワークフローのUIや使い勝手を現場設計者に検証する意義、旧図面のスキャン・図番付与の実現性検証、PoCの期間・費用感・進め方、そしてPoCでよくある失敗と成功のポイントまでを、具体的に解説します。これから図面管理基盤の構築を検討している設計部門や情報システム部門の担当者が、本格開発への投資判断を誤らないための検証プロセスを設計する際の判断軸となる内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・図面管理（EDM）開発の完全ガイド

図面管理（EDM）におけるPoC・プロトタイプ・モックアップの位置づけ

図面管理（EDM）システムの開発において、PoC・プロトタイプ・モックアップは、いずれも「本格開発の前に不確実性を減らす」ための手段ですが、それぞれ検証の目的が異なります。EDMは、大容量の3D CADデータを扱い、図番とBOMを紐付け、承認済みの版だけを下流工程に公開するという、汎用のファイル共有システムにはない複雑な要件を持ちます。これらの要件は「作ってみないと分からない」不確実性を多く含むため、投資規模の大きい本格開発に踏み切る前に、技術的な実現性と現場での実用性を小さく検証しておくことが、手戻りと予算超過を防ぐうえで決定的に重要になります。ここでは、まず三つの手法の違いを整理し、なぜ図面管理でこうした事前検証が特に重要なのかを解説します。

三つの手法は、検証する対象と作り込みの度合いで区別されます。PoC（Proof of Concept＝概念実証）は、「そもそもこの技術的アプローチが実現可能か」を検証するもので、図面管理でいえば、大容量の3D CADデータをストレージに保管してビューアで表示できるか、既存のCADツールやERPとAPI連携が成立するか、図番とBOMの動的な紐付けが正しく機能するかといった、技術的な成立性を確かめます。プロトタイプは、実際に動く試作品を作り、業務の一連の流れ（図面のアップロードから承認、出図まで）が想定通りに回るかを検証します。モックアップは、主に画面のデザインやレイアウトを再現した見た目中心の試作で、実際のデータ処理は伴わないものの、現場の設計者に「この画面構成で操作できるか」を早期に確認してもらうために使います。EDM開発では、技術的な実現性を確かめるPoCと、現場の使い勝手を確かめるモックアップ・プロトタイプの両方を組み合わせることで、技術と業務の両面から本格開発のリスクを下げられます。

図面管理（EDM）でPoCが特に重要なのは、扱うデータと業務プロセスの両方に、汎用システムにはない固有の難しさがあるからです。まずデータ面では、ギガバイト単位の3D CADデータを扱うため、保管・プレビュー・アクセス制御の性能とセキュリティが実用に耐えるかは、実際に自社のデータで試してみないと分かりません。次に業務面では、図番の採番ルールやBOMの構造、設計変更のワークフローが企業ごとに独自であり、既存の基幹システムとの連携も一社ごとに事情が異なります。カタログスペック上は「できる」とされている機能でも、自社の実データと業務フローに載せたときに問題なく動くかは別問題です。さらに、EDMは日々の設計業務に深く組み込まれるため、現場の設計者が使いこなせなければ、どれだけ高機能でも形骸化してしまいます。こうした「技術的に動くか」と「現場で使えるか」という二つの不確実性を、投資規模の大きい本格開発の前に小さく潰しておくことが、EDM開発を成功させる前提条件となるのです。

PoCで検証すべき項目

図面管理（EDM）のPoCでは、実際の製品グループや複雑な階層構造などを模した「実業務データモデル」を用意し、図面のアップロードから承認、基幹システムへの自動転記に至るEnd-to-Endの業務シナリオを徹底して検証することが基本です。カタログ上の機能一覧を眺めるのではなく、自社の実データを使って一連の流れを通してみることで、初めて本当の課題が見えてきます。ここでは、PoCで特に重点的に確認すべき項目を、性能・セキュリティの観点と、データ構造・連携の観点に分けて解説します。

PoCで最初に確認すべきは、大容量のCADデータを扱う際の表示性能とセキュリティです。図面やCADデータは機密情報であり、ギガバイト単位にも及ぶ3D CADデータ等を保管し、専用CADソフトなしでもプレビューするための仕組みが実用に耐えるかを検証します。具体的には、自社で実際に使っている重い3Dモデルをビューアで開いたときに、待たされずに表示できるか、回転や拡大といった操作がストレスなく行えるかを確かめます。設計者が日常的に扱う図面がスムーズに閲覧できなければ、システムそのものが使われなくなってしまうため、この表示性能はPoCの重要な合否基準です。あわせて、機密情報である図面を守るための暗号化技術やアクセス制限ロジックが正しく機能するかも検証します。誰がどの図面を閲覧・ダウンロード・編集できるのかという権限制御が想定通りに動くか、承認前の図面が権限のない人に見えてしまわないかといった、セキュリティ面の成立性を実データで確認しておくことで、本格開発後に情報漏洩リスクが発覚するといった事態を防げます。

次に検証すべきが、図面管理の中核であるデータ構造と連携です。品目や図面を動的に紐づけるBOMデータ構造（親子関係、有効日、リビジョン管理）が正しく設定でき、承認を経た有効な版のみが下流工程に公開される仕組みが機能するかを、実際の製品の部品構成を使って確かめます。多階層のBOMに図面を紐付けたときに、意図通りの親子関係で表現できるか、リビジョンが更新されたときに古い版が下流に流れないかといった、EDMの根幹となる挙動をPoCで検証しておくことが重要です。さらに、CADツールやERP、MES（製造実行システム）といった外部システムと、APIを用いた双方向のデータ連携が正しいロジックで実行できるかも確認します。品目コードやマスタ項目のマッピング、データ同期のタイミングなどは、既存システム側の仕様に依存するため、実際に接続して動かしてみないと問題が見えません。この連携部分はEDM開発で最も工数がかかり、かつトラブルが起きやすい領域であるため、PoCの段階で連携の成立性を確かめておくことが、本格開発のリスクを大きく下げることにつながります。

モックアップ・プロトタイプで現場設計者に検証すること

モックアップやプロトタイプを用いてUI/UXを検証する最大の意義は、現場作業者の誤認識を防ぎ、直感的な操作性を確保することにあります。図面管理システムでは、ツリー構造のBOMや複雑なリビジョン一覧、多数の属性項目など、大量かつ密度の高い情報を取り扱います。そのため、設計から検図、承認に至るワークフローにおいて、現場の設計者が迷わず直感的に操作できる画面レイアウトであるかを事前に検証することが、システムの運用定着において極めて重要になります。ここでは、UI/UX検証の具体的なポイントと、旧図面のスキャン・図番付与の実現性検証について解説します。

モックアップ・プロトタイプの段階で現場設計者に確認してもらうべきは、日常業務で頻繁に触れる画面の使い勝手です。多階層のBOMツリーを展開・折りたたみしながら目的の部品図面へたどり着けるか、あるリビジョンの図面と過去版とを並べて比較できるか、設計変更の申請から承認までの一連のワークフローが画面上で迷わず進められるか、といった操作性を、実際の設計者に触ってもらって検証します。設計者が「この画面では、どれが最新版か一目で分からない」「承認依頼を出す手順が分かりにくい」と感じるようであれば、本格開発の前に画面設計を見直す必要があります。開発が進んでから画面の作り直しが発生すると、大幅な手戻りとコスト増につながるため、まだ変更が容易なモックアップの段階で、現場のキーマンとなる設計者を巻き込んで操作性を作り込むことが、後の定着を左右します。特に、これまで紙やファイルサーバーで図面を扱ってきた設計者にとっては、システムの操作フローが従来の業務感覚に沿っているかどうかが、受け入れられるかの分かれ目になります。

もう一つPoC・プロトタイプで検証しておきたいのが、過去に蓄積された紙図面や旧データを電子化してシステムへ取り込む部分の実現性です。長年にわたり紙や個人のフォルダに埋もれてきたレガシーな図面資産を、単に画像として取り込むだけでなく、図番や品目情報といったメタデータを付与して検索可能な状態にできるかが、電子化の成否を分けます。なお、OCR（光学文字認識）を用いた図面のスキャンや自動的な図番付与については、製品や図面の状態によって認識精度が大きく変わるため、自社の実際の図面を使って独自に技術検証を行うことが推奨されます。あわせて、この旧データの移行検証で重要な論点となるのが「データ生成ルール」の統一です。部門ごとに異なる図面番号の採番ルールや品目コード体系のままシステム化を進めると失敗を招くため、事前に図番ルールを全社で標準化・統一し、それがシステム上で運用可能かをPoCの段階で確認しておくことが求められます。電子化とデータ統一の実現性を早期に見極めておくことで、本格移行の段階で「思ったように取り込めない」という事態を回避できます。

PoCの期間・費用・進め方

図面管理（EDM）のPoC（トライアル導入評価）の期間は、一般的に1ヶ月〜6ヶ月程度、費用は200万円〜2,000万円程度が目安となります。検証する範囲や、既存システムとの連携をどこまで含めるか、自社の実データをどれだけ使うかによって、この幅の中で変動します。進め方の基本は、いきなり全社・全機能での導入を目指すのではなく、まずは「特定の製品部門」や「図面管理＋設計変更承認ワークフロー」といった限定された適用範囲でスモールスタート（PoC）を実行することです。この限定範囲で、図面検索時間の削減や手配ミスの削減といった具体的な効果を実証したうえで、他部門やBOM連携機能へと段階的に展開していく手法が、手戻りを防ぎ、結果的にプロジェクト全体の期間を短縮するために推奨されます。PoCを進める際は、あらかじめ「何をもって成功とみなすか」という評価基準（Go／No-Goの判断基準）を明確にしておくことが重要です。「3Dモデルが3秒以内に表示できる」「既存ERPと品目マスタが正しく連携する」「設計者の8割が従来より早く図面を探せると回答する」といった具体的な合否ラインを事前に設定しておくことで、PoCの結果を客観的に評価し、本格開発へ進むかどうかを冷静に判断できます。評価基準が曖昧なままPoCを始めると、「なんとなく動いた」で本格開発に突入し、後から問題が噴出するリスクが高まります。

PoCでよくある失敗と成功のポイント

図面管理（EDM）のPoCには、陥りがちな失敗パターンと、それを回避して成功に導くポイントがあります。ここでは、技術的負債を招く典型的な失敗と、Fit-to-Standardの徹底やデータ生成ルールの統一といった成功の鍵を解説します。PoCの段階でこれらを意識しておくことが、本格開発の成否を大きく左右します。

PoCや本格開発でよくある失敗が、自社の「これまでのやり方」に固執し、既存の紙ベースの複雑な手続きや承認ルートをそのままシステム上に再現しようとすることです。長年の運用で複雑化した承認フローや、部門ごとに異なる図面の扱い方を一切変えずにシステム化しようとすると、巨額のカスタマイズ費用が発生するだけでなく、将来のバージョンアップが困難になる「システムの硬直化（技術的負債）」を引き起こします。PoCの段階でこの兆候に気づかず、「現状の業務をすべて再現できること」を検証のゴールにしてしまうと、本格開発でカスタマイズが際限なく膨らみ、予算超過と納期遅延を招きます。PoCは、現状業務をそのまま再現できるかを試す場ではなく、「標準的な仕組みに業務を合わせたときに、それでも十分な効果が得られるか」を見極める場と捉えることが大切です。現状の複雑さを前提にするのではなく、この機会に業務プロセスそのものをシンプルにできないかを問い直す姿勢が、技術的負債を避ける第一歩になります。

PoCを成功に導く最大のポイントは、業務プロセスそのものをパッケージの標準機能に合わせて変革する「Fit-to-Standard」を徹底することです。標準機能に業務を合わせることで、初期開発費用および総所有コスト（TCO）を大幅に抑制でき、将来のバージョンアップも容易になります。PoCの段階から、標準機能でどこまでカバーできるか、どうしても標準では対応できず自社の競争力に直結する部分はどこかを見極め、カスタマイズを最小限に絞り込む方針を固めておくことが重要です。もう一つの成功の鍵が、グランドデザイン期において、経営層のリーダーシップのもと、品目コードや図面番号ルールといった「データ生成ルール」を全社で統一しておくことです。PoCで良い結果が出ても、全社展開の段階で部門ごとにデータのルールがバラバラだと、システムが複雑化して破綻してしまいます。PoCと並行して、あるいはそれ以前に、全社のデータ生成ルールを統一する取り組みを進めておくことで、PoCで得た成果をスムーズに全社へ広げられます。技術検証と業務標準化を両輪で進めることが、EDM開発を成功させる王道です。

まとめ

本記事では、図面管理（EDM）開発のPoC・プロトタイプ・モックアップについて、CAD図面という専門的な成果物を扱うがゆえの検証の勘所という視点から解説しました。PoCでは、実業務データモデルを用いて図面のアップロードから承認、基幹連携までのEnd-to-Endシナリオを検証し、特に大容量CADビューアの表示性能とセキュリティ、図番／BOMの紐付けと版管理、既存システムとのAPI連携の成立性を確かめることが重要です。モックアップ・プロトタイプでは、複雑なBOMツリーやリビジョン一覧、承認ワークフローの画面を現場の設計者に触ってもらい、直感的に操作できるかを検証します。旧図面のスキャン・図番付与の実現性は自社の実データで独自に検証し、あわせてデータ生成ルールの統一可否も確かめておきます。PoCの期間は1〜6ヶ月、費用は200万〜2,000万円が目安で、限定範囲でスモールスタートし、効果を実証してから段階展開するのが定石です。既存の複雑な業務をそのまま再現しようとする技術的負債の罠を避け、Fit-to-Standardの徹底とデータ生成ルールの全社統一という成功の鍵を押さえれば、本格開発への投資判断を誤らずに済みます。自社に最適な検証プロセスを具体化するためにも、まずは複数の会社に相談し、PoCの進め方を比較検討することから始めてみてください。

▼全体ガイドの記事
・図面管理（EDM）開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。