メーカー向けシステムの要件定義は、現場ヒアリングから製造要件の整理、RFP（提案依頼書）の作成へと進めると、実務に合う仕様になります。
現場の整理、製造要件、社内稟議の3点を、発注企業の視点から順に見ていきます。全体像は完全ガイドをご覧ください。
▼全体ガイドの記事
・メーカー向けのシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングとToBeモデルから始める進め方
要件定義は、機能一覧を埋める前に、現場がどう作業し、どこに無駄や手戻りがあるかを徹底的に聞き取ることから始めます。生産管理者、作業者、調達、原価管理、品質保証など、多くの関係者の業務と判断がかかわります。特に、実態を把握しないまま要件を固めると、現場と噛み合わないシステムになるおそれがあります。
AsIs/ToBeと目的の明確化（AX）
要件定義では、現状の業務フロー（AsIs）を書き出し、あるべき姿（ToBe）を描いて、そのあいだのギャップをシステムで埋めます。
「DXが流行りだから」といった曖昧な目的で多機能なシステムを入れると、現場の反発を招くことがあります。さらに、目的が曖昧なままだと、現場が従来のやり方を選び、システムを使わなくなるおそれもあります。そこで、導入を今の業務の電子化だけで終わらせず、業務変革（AX）として捉えます。
- 目的を定める：何のために、どの業務をどう変えるかをはっきりさせる
- ToBeを描く：無駄な工程や二重管理をなくすかどうかを判断する
- 適用範囲を決める：標準機能に合わせる部分と、固有の要件を分けて考える
自社固有で譲れない部分だけをカスタマイズすれば、過剰開発による費用の高止まりを避けられます。また、AsIs/ToBeの整理は、機能要件を書く前に取り組む工程です。
関係者ヒアリングと暗黙知の言語化
現場の声と、文書になっていない暗黙知は、要件に反映する前に確認しておきます。
- 関係者：生産管理者、作業者、部材調達、原価管理の経理、品質保証の検査担当
- 暗黙知：製品ごとの段取りや取引先への特急対応
暗黙知を言語化して要件に反映しないと、実際の運用に合わなくなります。ヒアリングの質は、後工程の手戻りを左右します。
時間をかけて現場を巻き込み、実態を見える形にしてから要件を組み立てることが、要件定義の核心になります。この姿勢は、手戻りや生産ラインの混乱を避けることにもつながります。
業務標準化とカスタマイズの線引き
標準化とカスタマイズの線引きは、要件定義で担う意思決定です。線引きが曖昧なまま開発を進めると、従来のやり方を残す要望を受け入れ続けることになり、費用が膨らむおそれがあります。
カスタマイズの追加は、1件あたり100万〜1,000万円に達することもあります（出典：ripla）。だからこそ、その要件が競争力の源泉なのか、慣れたやり方への固執なのかを見極めます。
- 標準で吸収する：標準機能で足りる要望を取り出して整理する
- 業務側を見直す：標準に合わせて変えられる業務を選び出す
- 必要箇所を作り込む：競争力につながる固有の工程を対象にする
一般的な事務処理は作り込まず、強みを生む固有の工程に絞ると、費用とベンダーロックインを抑えられます。
この仕分けには、現場との対話が欠かせません。標準に合わせる理由を丁寧に説明すると、導入後の定着にもつながります。
製造特有の商習慣の要件化
メーカーの要件定義では、他業種と違って、製造特有の業務を要件に落とし込むことが欠かせません。生産計画や部品表（BOM）、所要量計算と原価計算を、自社の実態に合わせて仕様にします。ただし、汎用パッケージの標準機能に無理に合わせると、現場が回らなくなるおそれがあります。
生産計画・BOM・原価の要件の仕様化
製造固有の論点を一つずつ仕様にしていくことが、要件定義書の中核です。
- BOM・原価：製品構成や設計変更の扱い、原価の把握単位を定める
- 生産計画：生産方式と自動化、特急対応の範囲を決める
- インフラ：重い図面や部品表データを踏まえて、方式を選ぶ
- 原価の粒度：経営の要求と、現場が入力できる範囲をすり合わせる
原価の単位には製品別、工程別、ロット別があり、顧客別まで見るかも検討の対象になります。
曖昧なまま開発を進めると、BOMが製品構成と合わなくなり、原価も希望する粒度で出ないといったトラブルにつながります。
生産計画は、受注生産か見込生産か、またはその両者が混在するかによって、必要な要件が変わります。そのうえで、負荷平準化や納期回答をどこまで自動化するか、特急対応をどう扱うかを決めると、手戻りを防げます。
重いデータを扱う場合は、通信速度の面でオンプレミスが有利な場面もあります。方式を後回しにすると、性能要件で意見が分かれることがあります。
原価を細かく見るほど、現場の実績入力も細かくなります。そのため、経営と現場の折り合いが、使われる原価機能の前提になります。特に、理想だけで細かな原価管理を要件にすると、現場が入力しきれず、データが埋まらないおそれがあります。
データ移行・マスター整備(クレンジング)の要件
データ移行とマスター整備（クレンジング）では、データの状態と整備の分担を決めておきます。
- 既存データ：品目・取引先マスタ、BOM、在庫の重複や表記揺れを確認する
- 在庫の照合：基幹データ、現場データ、実物在庫を一致させる
- 整備の分担：担当者、期限、整備する粒度をはっきりさせる
- 移行計画：範囲・責任・スケジュールを要件定義書に記載する
マスター整備は地味で時間がかかりますが、システムの精度を支える土台です。
古い情報をそのまま移せば、新しいシステムに問題を持ち込むことになります。また、担当が曖昧なままだと、開発の終盤になってマスタの未整理が分かり、稼働が大幅に遅れることがあります。
社内稟議で使うROIの算出ロジック
要件定義と並行して、システム投資を社内で承認してもらう準備も進めます。メーカーのシステム投資は数百万円から数億円に及ぶため、要件定義の段階でROI（投資対効果）の算出ロジックを組み立てておきます。
要件定義書を作っても、経営層の承認がなければ始まりません。ROIの算出は多くの解説で手薄な領域です。だからこそ、丁寧な準備ほど差がつきます。
現場・経営の階層別評価基準の要件への織り込み
投資の評価基準は社内の階層によって異なるため、相手に合わせて価値を説明します。
- 現場：使いやすさや負担の軽減
- 生産管理：面積生産性や稼働率
- 経営：ROIや利益率など、金額に換算した効果
階層別の評価基準を要件定義の段階で押さえておくと、現場と経営の双方を納得させやすくなります。稟議資料の説得力も増します。
効果は、特急外注の年間削減額や、集計工数の削減時間を人件費に換算した額、原価の見える化による利益改善の見込みを、自社の実数値で積み上げます。
一次データでは、特急外注を年最大20%、集計を月100時間以上削減し、2〜3年で投資を回収した事例があります（出典：ripla）。そこで、この効果率を自社の外注費や工数に当てはめれば、回収年数を概算できます。
非財務価値の数値化と投資効果の示し方
金額効果を補う非財務価値と、投資の回収を示す期間や算出方法を整理します。
- 技術継承：ベテランの暗黙知をシステムに残す
- 顧客・品質：納期遵守率の向上による顧客満足と、追跡によるリコールリスクの低減
- 環境価値：CO2削減量など、数値で示せる効果
- 回収計画：DCF法による5年・10年の効果
非財務価値は直接の金額になりにくいものの、経営判断で考慮されます。また、将来のキャッシュフローを現在価値に割り引くDCF法（割引キャッシュフロー法）も活用できます。
単年度の数字だけでなく、5年・10年の効果を示すと、初期投資への抵抗を和らげられます。算出の根拠になる現状の数値は、ヒアリングで集めておきます。
ROIを準備しておけば、稟議の停滞によるプロジェクトの宙づりを抑えられ、円滑な意思決定にもつながります。
RFPの項目と発注側の協力義務
整理した要件は、RFP（提案依頼書）にまとめてベンダーへ渡します。RFPの質は、ベンダーの提案の質と見積りの精度を左右します。
発注側にも、ユーザーとしての協力義務があります。この点を理解しておくことが、トラブル回避につながります。
RFPに盛り込むべき項目とSLA
RFPには、提案と見積りの前提になる情報を記載します。
- プロジェクト：目的・背景、対象業務、予算、納期
- システム：機能要件、性能・可用性・セキュリティ
- 運用：データ移行の範囲、保守・運用条件
メーカーの場合は、重いデータを扱う性能や、基幹システムとの連携、保守サポートのSLA（サービス品質保証）を明記します。
保守費は一般に、開発費の15〜20%が目安です。たとえば、開発費が3,000万円なら、年450万〜600万円になります（出典：ripla）。
また、オンプレミス運用では、保守費が年500万〜1,500万円規模になることもあります（出典：ripla）。そのため、保守条件をRFPに明記しなければ、稼働後の運用コストを把握しにくくなります。
RFPでは、製造業の現場感を理解しているベンダーかどうかも見極めたいところです。業界の理解が乏しいベンダーに任せると、標準パッケージに業務を無理に合わせる提案になりがちです。あわせて、ヘルプデスクや伴走型サポート、導入後の定着支援まで含めて比べられるようにします。
見積りは、安さだけでなく、自社の製造業務をどこまで理解しているかも見て判断します。内訳の粒度を見ると、見積りの妥当性も分かります。一式いくらという大括りな見積りでは、後から別費用を請求される余地が残ります。
見積りは、要件定義から保守まで工程ごとに費用を分け、前提条件も明記してもらいます。特に、データ移行費、教育費、稼働後の保守費が含まれているかを確かめます。これが抜けた見積りは、安く見えても後から総額が膨らむことがあります。
RFPで見積り様式を指定すると、複数のベンダーを同じ条件で比べられます。
発注側のユーザー協力義務という法的論点
システム開発では、ベンダーだけでなく発注側にもユーザーとしての協力が求められます。
- 要件提示：必要な要件を適時に伝えること
- 意思決定：発注側として判断を下すこと
- 仕様凍結：決めた内容と変更の扱いを定めること
協力を怠ると、ベンダーのプロジェクトマネジメント義務だけでなく、発注側の責任も問われることがあります。要件が曖昧なまま開発終盤に追加要望を重ねるのは、トラブルの原因になります。
実際の判例でも、協力義務は重く扱われています。旭川医大病院とNTT東日本の事件では、控訴審（札幌高裁・平成29年8月31日）で、ユーザー側の協力義務違反が認定されました。この事件では、169項目中124項目が開発対象外とされ、ユーザー側のみに約14億1500万円の支払いが命じられました（出典：ripla）。
医療機関の事例ですが、要件を固めないまま追加要望を繰り返す場合に、発注側がどんなリスクを負うかを示しています。仕様を固め、凍結のルールを決めておくことが、メーカー自身を守る手立てになります。
まとめ
メーカー向けシステムの要件定義では、現場ヒアリングを起点に、AsIs/ToBeと目的を整理します。要件定義は、生産ラインの混乱を避けるうえで最も大事な工程です。
生産計画・BOM・原価・データ移行を仕様にし、RFPには性能・連携・保守SLAも記載します。現場感を理解するベンダーかどうかの見極めも欠かせません。
旭川医大の約14億1500万円の判決は、発注側にも協力義務があり、要件を固めきれないまま進むリスクが小さくないことを示しています。
要件定義に時間をかけるほど、後の開発・導入の手戻りが減り、総コストを抑えられます。現場の暗黙知を言語化し、製造固有の要件やデータ移行まで詰めることが、現場に使われるシステムにつながります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、製造現場の業務から逆算した要件整理とRFP・要件定義書の作成を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼全体ガイドの記事
・メーカー向けのシステムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。