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

図面管理(EDM)の要件定義は、現状の図面運用(AsIs)を把握し、要件と移行範囲を整理したうえで、RFP(提案依頼書)と評価基準にまとめる順に進めます。この順で進めると、現場に定着する仕組みにつながります。全体像は図面管理(EDM)の完全ガイドもご覧ください。

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

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

現状の図面運用を担当者とCAD、保存と承認、現場展開、台帳と検索の4領域に分けた図解。
作成から出図までを、関係者への聞き取りで順にたどれます。

要件定義では、新しいシステムの機能を考える前に、いまの図面運用(AsIs)を確認します。まず、図面の作成から現場への展開までの流れを追い、運用上の困りごとも洗い出します。

AsIsの確認を省くと、現場の実態とずれたシステムになるおそれがあります。実際、図面管理プロジェクトの失敗の多くは、AsIsの把握を飛ばしたことに起因します。

図面の作成から出図までの業務フローの棚卸し

関係者へのヒアリングで、作成から出図、設計変更までの流れを一覧にします。

  • 担当者とCAD:誰が、どの作図ソフトを使うか
  • 保存と承認:どこに置き、誰が了承するか
  • 現場展開:承認が済んだ図面の届け方
  • 台帳と検索:Excel台帳の運用と、探すときに使う属性

設計者や上長、品質、調達、製造などの担当者に聞き取って文書にまとめると、システム化する範囲が見えてきます。また、人手のまま残す業務も分けておくと、要件の対象範囲を判断できます。

「最新版が分からない」といった困りごとは、発生頻度や影響金額を記録して数字にし、優先順位を付けます。

たとえば、設計者10名が1日30分ずつ図面を探す場合、年間1,200時間規模になります。時給2,500円で換算すると、年300万円相当の損失です。数字があれば、優先順位と投資対効果(ROI)を一貫して説明できます。

ToBe像とスコープ(システム化範囲)の定義

発注側が、AsIsの次に、目指す姿(ToBe)と初期導入の範囲を決めます。

  • 標準機能に寄せる:長年の慣行をそのまま独自仕様にしない
  • 第一フェーズを絞る:優先度の高い課題から対象にする
  • 後続範囲を分ける:BOM連携やPLM統合を次フェーズに回す例があります

現状の運用をそのままシステム化すると、独自仕様の作り込みが増えるおそれがあります。生産管理システムでは、初期費用800万〜1,500万円のうち、カスタマイズ費が200〜300万円に及ぶ例があります。これは全体の3〜4割に当たり、図面管理でも同じ構造で費用が膨らみます。

全機能を一度に作ろうとすると、要件が肥大化し、予算や期間を超えるおそれがあります。そのため、第一フェーズのスコープを明確に切ります。優先課題から始める判断は、RFPの精度にも直結します。

riplaは、フルスクラッチ受託の立場から、AsIsとToBeの差を踏まえた現実的な範囲設定を重視しています。

ポイント

困りごとを頻度と影響金額の数字で書き出せていれば、システム化する範囲と優先順位を説明しやすくなります。数字がないと、どこまでをシステム化するかの判断が定まりにくくなります。

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

スコープが定まったら、要件定義書に載せる機能要件と非機能要件を洗い出します。

機能要件は「何ができるか」、非機能要件は性能・信頼性・セキュリティなどの条件です。

検索や版管理に目が向きがちです。一方で、大量のCADデータを扱うため、非機能要件も欠かせません。軽視すると、使えても動作が遅く、現場で使われないシステムになります。

機能要件と非機能要件は、バランスよく整理することが肝心です。

図面管理の機能要件の必須・任意の整理

機能要件は、必須(Must)と任意(Want)に分けるのが基本です。その際は、AsIsの課題に照らして判断します。

図面管理の機能要件には、次の項目があります。

  • 登録と属性付与:図番、品名、客先、材質、改訂日の項目を持たせる
  • 検索:属性で絞り込む方法と、全文で探す方法
  • 版管理:リビジョン管理と、チェックイン/チェックアウト
  • 承認:出図と設計変更(ECN)のワークフロー
  • 履歴と閲覧:改訂の記録、トレーサビリティ、CADビューア、権限管理

すべてを必須にすると見積が膨らみ、優先したい機能が埋もれます。そこで、影響金額の大きい課題を解決する機能から必須にすると、ベンダーにも最優先の実現事項が明確に伝わります。

要件は業務の流れに沿って書きます。「検索できること」とだけ書くと、実装する範囲が曖昧になります。たとえば「図番・客先・材質の組み合わせで3秒以内に該当図面を一覧表示」と書けば、見積の前提が明確になります。

承認も「設計→課長→品質保証」の3段階とし、品質保証は条件付きで省けるように具体的に書きます。これにより、標準機能で対応できるか、カスタマイズが必要かを判定でき、認識のずれも防げます。

要件は具体的であるほど、見積の精度が上がります。

性能・セキュリティ・可用性の非機能要件の定義

図面ファイルは数十MBに及ぶことがあり、図面数が数十万件に達する企業もあります。

  • データ量:現在の図面数と、年間の増加数
  • 利用規模:想定される、同時に使う人数
  • 応答性能:検索の目標時間と、大容量CADの表示・ダウンロード速度
  • 安全性と復旧:アクセス制御、ログ、共有方法、バックアップ、RTO/RPO
  • 将来運用:拠点・CAD形式の拡張性と、管理者による設定変更

データ量や性能の目標を数値で決めておかないと、数年後にデータが増えて遅延が表面化するおそれがあります。

図面は技術ノウハウのため、安全性と復旧の条件は、要件の段階で具体的に決めておく必要があります。発注側は、案件や客先ごとのアクセス制御を定め、ダウンロードや印刷のログを残し、社外との安全な共有方法も決めておきます。バックアップとリストアの方法と、障害時の復旧目標(RTO/RPO)も、あわせて決めておきます。

クラウド型かオンプレミス型かは、保守や費用に響くため、要件の段階で決めておきます。クラウド型は導入が速い一方で、数年後の更新で追加費用が生じるとの指摘があります。そのため、長期のTCO(総保有コスト)も見据えて方式を選ぶことが大切です。

事業の成長や買収で図面数が増えたり、拠点やCAD形式が変わったりしても、破綻なく対応できるかを確かめます。BOM連携やPLM統合の構想も、初期要件の中で拡張の余地として含めておきます。

属性項目や承認ルートを管理者が変えられるか、都度ベンダーへ依頼するかで、保守コストが変わります。

非機能要件は、現在だけでなく数年後も無理なく使えるかという時間軸で定めます。

ポイント

機能要件は、AsIsの課題に照らして必須と任意を分けられているかで判断します。非機能要件は、データ量や性能の目標を数値で示せているかが目安です。

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

移行範囲、役割分担、試験移行の順に進むデータ移行要件の流れ図。
小規模な検証を挟むことで、本番移行前に不整合を見つけられます。

見落とされがちですが、データ移行はプロジェクトの成否を左右します。共有フォルダのCADデータ、Excel台帳、紙図面のスキャンデータを、どう取り込むかを決める必要があります。

移行の手順を詰めないと、過去図面がEDMに載らず、旧フォルダも使い続ける二重管理になります。移行要件は、初期構築と同じくらい重視すべき領域です。

Excel台帳のCSV取り込みと文字化け・列ズレ対策

Excel台帳には図番、品名、改訂情報などがあり、EDMの属性の初期値として取り込めます。これにより、図面の登録作業を大幅に省けます。

  • 取り込み方式:CSVを直接読み込めるか
  • データ品質:文字コードによる文字化けや、列構成のずれが起きないか
  • 移行後の運用:既存の検索軸や台帳の知恵を引き継げるか

CSVの検証手順も要件に含めておきます。文字化けや列ずれがあると手修正が増え、現場の不信も招きます。

Excelは、すぐに全面的に置き換えるより、既存台帳の知恵を活かしながら段階的に移すほうが現実的です。台帳の列を属性に対応づけると、慣れた検索軸を引き継げるため、移行後の違和感も減らせます。

riplaは、フルスクラッチ受託と製造現場への伴走の立場から、CSVの直接出力・取り込みを前提にしています。既存のマクロやVLOOKUPを活かし、Excelと共存する形も重視しています。そのため、台帳の知恵をどう引き継ぐかも、要件に明記します。

既存CADデータ・紙図面の整理と属性付与の役割分担

共有フォルダのCADデータや紙図面は、全件を移すと工数が膨大になります。

  • 移行範囲:直近の図面だけを移し、それ以前は別に管理する例
  • 優先対象:アクティブ案件の図面を先に移す例
  • 役割分担:クレンジング、属性付与、スキャン、登録のそれぞれを、誰が担当するか
  • 試験移行:本番前に、少数の図面と台帳で検証する

紙図面は、スキャンしてから属性を付けます。図面の事情を知る設計部門が主導すると、作業の質が上がります。

ベンダーにクレンジングや属性付与を任せると、人月単価で費用がかさみます。そこで、マスタ登録30〜80万円、現場教育50〜100万円の作業を自社で担えば、見積から除外できます。

内製を前提に範囲を分けると、導入費を200〜400万円規模で削減できる余地があります。誰が何を担うかまで決めることが、移行のコストを管理するうえで決め手になります。

試験移行では、代表的な数百件を使って、属性の対応、文字化け、欠落、検索の可否を確かめます。そのため、こうした手順と確認項目も要件に含めておきます。

本番前に問題を洗い出せば、大量の移行後に重大な不整合が見つかる事態を防げます。データ移行は一発勝負にしないことが、要件定義の鉄則です。

ポイント

移行範囲と役割分担を決め、本番前に少数の図面と台帳で試験移行を行えているかが判断の目安です。誰が何を担うかまで決めておくと、見積の前提もそろいます。

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

RFPの構成項目として、目的と現状、要件、移行と連携、提案条件を並べたチェックリスト図。
共通の項目をそろえると、各社の提案内容を同じ土台で確認できます。

要件をRFP(提案依頼書)にまとめ、ベンダーに共通の条件で提案と見積を出してもらいます。

記述が曖昧だと、ベンダーごとに見積の前提が異なり比べられず、別費用の追加請求につながります。つまり、記載の精度が、提案と見積の質を左右します。

RFPに必須の構成項目

図面管理(EDM)のRFPには、提案の前提と評価条件をそろえるための情報を書きます。

  • 目的と現状:背景、解決課題、定量目標、AsIs、図面数・データ量
  • 要件:必須・任意の機能、性能・セキュリティ・可用性の数値目標
  • 移行と連携:対象範囲、役割、CAD・生産管理・PLMとのつながり
  • 提案条件:想定スケジュール、予算レンジ、見積様式、評価基準

予算レンジと見積様式を指定すると、ベンダー間で比べやすくなります。

ライセンス・導入支援・カスタマイズ・ハードウェア・保守を分けて記載してもらいます。カスタマイズ費は見積全体の3〜4割に達する場合があります。

費目を明らかにすると、費用の集中や膨らみすぎるリスクを早く把握できます。RFPの記述に曖昧さを残さないことが、発注側の自衛策です。

提案評価へのPoC(実機検証)の組み込み

カタログ機能の比較表で提案を決めると、判断を誤るおそれがあります。そこで、有力候補のPoC(実機検証)をRFPに含めます。

  • 業務の適合:典型的な出図を標準機能で処理できるか
  • 性能:自社のデータ量で検索速度が落ちないか
  • 使いやすさ:設計者がマニュアルなしで操作できるか

ベンダーの環境に実際の図面データを取り込み、上記の3点を実機で確かめます。この検証は、カスタマイズが膨らむのを未然に防ぐ歯止めになります。

評価では、機能の充足度に加えて、移行や連携の理解、非機能要件への回答、製造現場への理解も見ます。

価格だけで選ぶと、後のカスタマイズや追加開発で高くつく場合があります。

riplaは、フルスクラッチ受託と国内開発の立場から、要件整理、RFP作成、PoC後の本開発を支援しています。

RFPと評価の設計に手間をかけることが、プロジェクト全体のリスクを減らすことにつながります。

既存システム連携と保守体制の要件

RFPでは抜けやすい連携要件と、運用開始後の保守体制も書き込み、見積の対象に含めます。

  • 連携先:CAD、生産管理、PLM、原価管理、調達システム
  • 連携内容:対象データ、方向、API・CSV・データベース直結などの方式
  • 保守条件:障害対応時間(SLA)、窓口、年額、更新の扱い
  • 継続性:担当交代時の引き継ぎと長期保守の体制

連携の条件を明記しないと、見積に含まれないまま、後から別費用になるおそれがあります。

図面は長く使う資産なので、5年、10年と安定して保守できるかも、選定の判断材料になります。

安さだけで保守体制の弱いベンダーを選ぶと、運用中にトラブルが多発します。連携と保守の条件を書き出しておくことが、導入後の安定運用を支えます。

ポイント

RFPの項目に、提案の前提と評価条件を書けているかが判断の目安です。PoCや連携、保守の条件まで書いてあれば、ベンダー間の見積の差を比べられます。

まとめ

AsIsの図面運用を確かめ、困りごとを数字にして優先順位を決めます。標準機能に寄せたToBeと範囲を定め、機能を必須と任意に分けたうえで、非機能要件も整理します。

既存図面とExcel台帳の移行要件は、役割分担まで決めて、RFPに曖昧さなく落とし込みます。移行と非機能要件を詰め、PoCで実機を確かめれば、カスタマイズの膨張や性能問題を防ぐことにつながります。

発注側が現状と目的を言葉にしておくと、提案や見積を比べやすくなります。riplaは、フルスクラッチ受託と国内開発を組み合わせ、要件整理からRFP・PoCまで伴走し、現場に定着する仕組みづくりを支援します。

全体像の確認には、あらためて完全ガイドをご活用ください。

会社紹介

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

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

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

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

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

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