図面管理（EDM）のRFP/要件定義書/提案依頼書について

図面管理（EDM）システムの導入を成功させられるかどうかは、開発が始まる前の「要件定義」と、ベンダーへ渡すRFP（提案依頼書）の精度でほぼ決まります。どれだけ優れたパッケージやベンダーを選んでも、自社が何を解決したいのか、現在の図面運用がどうなっていて、どこまでをシステム化するのかが曖昧なままでは、見積はぶれ、カスタマイズは膨らみ、出来上がったシステムは現場に使われません。だからこそ、要件定義書とRFPを発注側が主体的に整理することが、図面管理プロジェクトの土台になります。

本記事は、図面管理（EDM）のRFP・要件定義書・提案依頼書を、発注企業が自力で組み立てられるように整理する「要件定義特化」の解説です。現状（AsIs）の図面運用の可視化から、機能要件・非機能要件の洗い出し、Excel台帳・既存CADデータの移行要件、RFPに盛り込むべき項目と提案評価の観点まで、抜け漏れなく具体的に解説します。読み終えるころには、自社のRFPの骨子と、ベンダーへ何をどう問うべきかが描けるはずです。なお、図面管理（EDM）の全体像をまだ把握していない方は、まず図面管理（EDM）の完全ガイドから読むことをおすすめします。

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

現状（AsIs）の図面運用を可視化する要件整理

要件定義の出発点は、新システムの機能を並べることではなく、現在の図面運用（AsIs）を正確に可視化することです。図面がどう作られ、どこに保存され、どう承認され、どう現場に渡るのか。この一連の流れと、その中で起きている困りごとを棚卸ししないまま要件を書くと、現場の実態とズレたシステムができあがります。図面管理プロジェクトの失敗の多くは、このAsIsの可視化を飛ばしたことに起因します。

まず行うべきは、設計者・上長・品質・調達・製造といった関係者へのヒアリングを通じて、図面の作成から出図、設計変更までの業務フローを書き起こすことです。誰がどのCADで作図し、どこに保存し、誰が承認し、どう現場へ展開しているか。Excelの管理台帳をどう運用し、どの属性で検索しているか。これらを具体的に文書化することで、システム化すべき範囲と、人手のまま残すべき範囲の境界が見えてきます。

このとき重要なのは、困りごとを定量化して優先順位を付けることです。「最新版が分からない」「図面を探すのに時間がかかる」といった課題を、発生頻度や影響金額とともに整理します。設計者10名が1日30分ずつ図面を探していれば年間1,200時間規模になり、これを時給2,500円換算すれば年300万円相当の損失です。こうした数字を添えると、要件の優先順位付けと、後の投資対効果（ROI）の説明が一貫します。

AsIsを可視化したら、次に描くのが「あるべき姿（ToBe）」です。ただし、ここで現状の運用をそのままシステムに写そうとすると、独自仕様の作り込みが膨らみます。生産管理システムでは、初期費用800万〜1,500万円のうちカスタマイズ費が200〜300万円と全体の3〜4割を占める例があり、図面管理でも同じ構造でカスタマイズが膨張します。ToBeを描く際は、長年の慣行をどこまで標準機能に寄せられるかをセットで検討してください。

そのうえで、第一フェーズのスコープを明確に切ります。「まずは図面の登録・属性検索・版管理までを対象とし、BOM連携やPLM統合は次フェーズとする」といった具合に、システム化範囲を段階で定義するのです。すべてを一度に作ろうとすると要件が肥大化し、予算も期間も超過します。スコープを絞り、優先度の高い課題から解決する設計は、後述するRFPの精度にも直結します。riplaはフルスクラッチ受託の立場から、AsIsとToBeのギャップを埋める現実的なスコープの切り方を一貫して重視しています。

機能要件・非機能要件の洗い出し

スコープが定まったら、要件定義書の中身となる機能要件と非機能要件を洗い出します。機能要件は「何ができるか」、非機能要件は「どれだけの性能・信頼性・セキュリティで動くか」です。図面管理（EDM）では、検索や版管理といった機能要件に注目が集まりがちですが、大量のCADデータを扱う特性上、非機能要件を軽視すると「使えるが遅くて使われない」システムになります。両者をバランスよく整理することが肝心です。

機能要件は、必須（Must）と任意（Want）に分けて整理するのが鉄則です。図面管理の機能要件には、次のような項目が挙がります。
・図面の登録と属性（図番・品名・客先・材質・改訂日）付与
・属性検索・全文検索による即時検索
・版管理（リビジョン管理）とチェックイン/チェックアウト
・出図・設計変更（ECN）の承認ワークフロー
・改訂履歴の自動記録とトレーサビリティ
・CADビューアと権限管理（アクセス制御）

これらを自社のAsIsの困りごとに照らし、必須と任意に振り分けます。すべてを必須にすると見積が膨らみ、本当に必要な機能が埋もれます。AsIsで定量化した課題のうち、影響金額の大きいものを解決する機能から必須に位置づけてください。この優先順位こそが、ベンダーへ「何を最優先で実現してほしいか」を明確に伝えるメッセージになります。

機能要件を記述する際は、「何ができるか」を曖昧な言葉で済ませず、業務シナリオに沿って具体化することが大切です。たとえば「検索できること」ではなく「図番・客先・材質の組み合わせで3秒以内に該当図面を一覧表示できること」と書けば、ベンダーは実装イメージを持って見積でき、後の認識ズレも防げます。同様に承認ワークフローも、「自社の出図は設計→課長→品質保証の3段階で、品質保証は条件付きでスキップ可能」と具体的に書くことで、標準機能で対応できるか、カスタマイズが要るかをベンダーが正しく判断できます。要件は具体的であるほど、見積の精度が上がります。

非機能要件で特に重要なのが性能です。図面ファイルは1枚が数十MBに及ぶことも珍しくなく、図面数が数十万件に達する企業もあります。要件定義では「現在の図面数と年間増加数」「想定する同時利用者数」「検索応答は何秒以内を目標とするか」「大容量CADファイルの表示・ダウンロード速度」を具体的な数値で定めます。これらを曖昧にすると、データ量が増えた数年後に致命的な遅延が顕在化します。

セキュリティと可用性も欠かせません。図面は企業の技術ノウハウそのものであり、客先や案件ごとのアクセス制御、ダウンロード・印刷ログの取得、外部委託先との安全な共有方法を要件化します。さらに、クラウド型かオンプレミス型か、バックアップとリストアの要件、障害時の復旧目標（RTO/RPO）も定めます。クラウド型は導入が速い反面、数年後のバージョンアップで追加費用が請求される隠れコストが指摘されており、長期のTCO（総保有コスト）まで見据えて方式を選ぶことが、非機能要件の重要な論点です。

非機能要件では、拡張性と運用保守性も忘れてはいけません。事業の成長や買収で図面数が増えたとき、利用拠点が増えたとき、扱うCAD形式が変わったときに、システムが破綻なく対応できるか。将来BOM連携やPLM統合へ広げる構想があるなら、その拡張余地を初期の要件に織り込んでおく必要があります。さらに、運用開始後に管理者が自分で属性項目や承認ルートを設定変更できるか、それとも都度ベンダーへ依頼が必要かも、保守コストを大きく左右します。非機能要件は「今動くか」だけでなく「数年後も無理なく使い続けられるか」という時間軸で定義することが肝心です。

既存図面・Excel台帳のデータ移行要件

図面管理（EDM）の要件定義で、見落とされがちなのにプロジェクトの成否を左右するのがデータ移行です。長年蓄積された共有フォルダのCADデータ、Excelの管理台帳、紙図面のスキャンデータをどうEDMへ取り込むか。この移行の段取りを要件定義で詰めておかないと、「システムは入ったが過去図面が載っていないので結局フォルダも見続ける」という二重管理に陥ります。移行要件は、初期構築と同じくらい重視すべき領域です。

既存のExcel管理台帳は、図番・品名・改訂情報といったメタ情報の宝庫です。これをEDMの属性データの初期値として取り込めれば、登録作業を大幅に省けます。要件定義では、台帳のCSVをダイレクトに取り込めるか、文字コードの違いによる文字化けや、列構成のズレが起きないかを事前に検証する手順を盛り込みます。CSV変換で文字化けや列ズレが起きると、かえって手作業の修正に時間がかかり、移行が現場の不信を招きます。

ここで現実的なのが、Excel完全脱却の理想論ではなく、既存台帳の知恵を活かした段階移行です。台帳の列構成をそのまま属性マッピングに使い、現場が慣れた検索軸を引き継ぐことで、移行後の違和感を減らせます。riplaはフルスクラッチ受託と製造現場への伴走の立場から、CSVのダイレクト出力・取り込みを前提に、既存のマクロやVLOOKUPの資産を活かす現実的なExcel共存・段階移行を重視しています。移行要件には「既存台帳の知恵をどう引き継ぐか」を必ず明記してください。

共有フォルダに散在する膨大なCADデータと、倉庫に眠る紙図面をどこまで移行するかは、移行要件の核心です。すべてを移行しようとすると工数が膨大になるため、「直近◯年分のみ移行し、それ以前はアーカイブとして別管理」「アクティブ案件の図面を優先」といった移行範囲の線引きを要件で定めます。紙図面はスキャンして電子化し、属性を付けて登録しますが、この作業は図面の事情を知る自社の設計部門が主導したほうが質が上がります。

そこで要件定義では、移行作業の役割分担を明確にします。データのクレンジングや属性付与をベンダーに任せると人月単価で費用がかさみますが、マスタ登録30〜80万円、現場教育50〜100万円といった作業を自社で巻き取れば、見積から除外できます。内製化を前提にスコープを切り分けることで、導入費を200〜400万円規模で削減できる余地があります。移行要件は「誰が何をやるか」の役割分担まで踏み込んで定義することが、コスト管理の決め手です。

移行の進め方として有効なのが、本番移行の前に小規模な試験移行を挟むことです。代表的な数百件の図面と台帳データを先にEDMへ取り込み、属性が正しくマッピングされるか、文字化けや欠落がないか、移行後に検索できるかを検証します。ここで問題を洗い出しておけば、本番移行で大量データを流し込んだ後に致命的な不整合が発覚する事態を防げます。試験移行の手順とチェック項目も要件定義に盛り込むことで、移行リスクを段階的につぶせます。データ移行は「一発勝負にしない」ことが、要件定義での鉄則です。

RFP（提案依頼書）に盛り込む項目と評価の観点

要件が固まったら、それをベンダーへ伝えるRFP（提案依頼書）に落とし込みます。RFPは、各ベンダーから同じ土俵で提案と見積を集め、公平に比較するための共通仕様書です。RFPの記述が曖昧だと、ベンダーごとに前提がバラバラの見積が返ってきて比較できず、後から「それは別費用」と追加請求される温床になります。RFPの質が、提案の質と見積の精度を決めます。

図面管理（EDM）のRFPには、次の項目を盛り込みます。
・プロジェクトの背景と目的（解決したい課題と定量目標）
・現状（AsIs）の図面運用と図面数・データ量
・機能要件（必須/任意の区別付き）
・非機能要件（性能・セキュリティ・可用性の数値目標）
・データ移行の範囲と役割分担
・既存システム（CAD・生産管理・PLM）との連携要件
・想定スケジュールと予算レンジ
・提案・見積の様式と評価基準

特に「予算レンジ」と「見積の様式」を指定することが、後の比較を楽にします。ライセンス・導入支援・カスタマイズ・ハードウェア・保守といった内訳を分けて記載するよう求めれば、どこに費用が集中しているかが見えます。カスタマイズ費は見積全体の3〜4割に達することもあるため、内訳を明示させることで膨張のリスクを早期に察知できます。RFPは「曖昧さを残さない」ことが何よりの自衛策です。

提案を評価する際、カタログ機能の比較表だけで決めるのは危険です。RFPの段階で、有力候補にはPoC（実機検証）を求めることを盛り込みます。PoCでは、ベンダーの環境に自社の実際の図面データを生のまま流し込み、「自社の典型的な出図パターンが標準機能で流れるか」「自社のデータ量で検索速度が落ちないか」「マニュアルなしで設計者が触れるか」を実機で確認します。この実機検証が、カスタマイズ膨張を未然に防ぐ最大の防波堤になります。

提案の評価基準は、機能の充足度だけでなく、移行・連携への理解、非機能要件への回答、そして自社業界・製造現場への理解度を重視します。価格の安さだけで選ぶと、後のカスタマイズや追加開発で結局高くつくことが少なくありません。riplaはフルスクラッチ受託と国内開発の立場から、要件定義とRFP作成の段階から発注側に伴走し、PoCで要件を見極めてから本開発に進む進め方を支援しています。RFPと評価設計に手間をかけることが、図面管理プロジェクト全体のリスクを下げる最も効果的な投資です。

RFPで意外と抜けやすいのが、既存システムとの連携要件と、運用開始後の保守体制です。図面管理（EDM）は、CADソフト、生産管理システム、PLM、ときに原価管理や調達システムとデータをやり取りします。どのシステムと、どの方向に、どんなデータを連携するのかをRFPに明記しないと、ベンダーは連携を見積に含めず、後から「それは別費用」となります。連携対象と連携方式（API・CSV・データベース直結など）を具体的に書き込むことが、見積のぶれを防ぎます。

保守体制も、RFPで問うべき重要項目です。障害時の対応時間（SLA）、問い合わせ窓口、保守費の年額、バージョンアップの扱い、担当者が変わっても引き継げる体制かを確認します。図面は長期に使い続ける資産なので、5年・10年と安定して保守してもらえるかが、ベンダー選定の決め手になります。安いだけで保守体制が脆弱なベンダーを選ぶと、運用段階でトラブルが多発します。連携と保守をRFPで言語化しておくことが、導入後の安定運用を担保します。

まとめ

図面管理（EDM）の要件定義とRFPは、現状（AsIs）の図面運用を可視化して困りごとを定量化し、標準機能に寄せたToBeとスコープを定め、機能要件と非機能要件を必須・任意で整理し、既存図面とExcel台帳の移行要件を役割分担まで詰め、それらをRFPへ曖昧さなく落とし込む、という流れで組み立てます。特にデータ移行と非機能要件、そしてPoCを評価に組み込むことが、カスタマイズ膨張と性能トラブルという二大リスクを未然に防ぎます。

要件定義で大切なのは、「ベンダーに任せる」のではなく「発注側が主体的に現状と目的を言語化する」ことです。AsIsの可視化と優先順位付けに時間をかければ、RFPは精度を増し、提案も見積も比較しやすくなります。riplaはフルスクラッチ受託と国内開発を組み合わせ、要件整理・RFP作成・PoCによる検証まで発注側に伴走し、現場に定着する図面管理システムづくりを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。