製造業のシステム開発は、現場業務の可視化、要件の凍結、RFPでの条件明記の順に進めます。暗黙知を言語化せず委託すると、現場に合わず巨額の投資が無駄になるおそれがあります。
また、協力義務や外部連携、データ移行も押さえる必要があります。全体像は製造業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・製造業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状業務の可視化とToBe設計の進め方
製造業の要件定義は、欲しい機能を並べるのではなく、現場ヒアリングと業務フローの可視化から始めます。
現状の業務フローは、受注から原価集計までの各工程を追って確認します。そのうえで、誰がどの帳票を使い、どう処理しているかを洗い出します。現状（AsIs）を理解せずに描いた要件は、現場の実態から外れます。
現場ヒアリングによる暗黙知の言語化
製造業の業務には、ベテランの判断や現場の慣行といった暗黙知が多く埋め込まれています。そのため、ヒアリングでは、判断の中身を一つずつ聞き取ります。
- 納期の優先判断：得意先ごとの対応の違い。
- 工程の判断：天候によって歩留まりが変わる工程の扱い。
- 部門ごとの業務：生産管理、現場リーダー、調達、品質、経理への聞き取り。
暗黙知の聞き取りを省くと、システムが現場の判断を再現できず、Excelや紙に戻ることがあります。
目的が曖昧なまま高機能なシステムを入れると、現場の反発を招いて定着しません。だからこそ、現場の困りごとから目的を定める必要があります。
現場課題から逆算した要件は、使われるシステムにつながります。ヒアリングには手間がかかります。しかし、後の手戻りコストを考えると、費用対効果の高い工程です。
ToBeでの業務標準化と過剰カスタマイズの回避
現状を可視化した後は、あるべき業務の姿（ToBe）を描きます。このとき、標準に合わせる業務と、自社の強みとして作り込む業務を分けることが大切です。
- 標準に合わせる業務：ムダや属人化を整理する対象。
- 作り込む業務：競争力の源泉となる固有業務を選びます。
- 段階分け：初期リリースと第2フェーズの要件の切り分け。
現状をそのまま再現すると、個別仕様が積み上がります。さらに、過剰なカスタマイズは、費用の高止まりや、バージョンアップの困難、ベンダーロックインにつながります。
パッケージを使う場合は、業務をシステムの標準に合わせることで、長期コストを抑えられます。一方、すべてを作り込むフルスクラッチは、1,000万〜数億円に膨らみます。
標準活用と作り込みを配分すれば、投資を必要な部分に集中できます。この切り分けは、RFPの要件の濃淡となり、ベンダーの工数見積もりの精度を左右します。
要件に優先順位をつけ、効果の大きい業務から段階的に作ると、初期投資を抑えながら早期に効果を出せます。また、要件定義は、機能を並べる作業であると同時に、限られた予算をどの業務に優先配分するかを決める経営判断でもあります。
協力義務を踏まえた要件凍結とプロジェクト体制
要件定義は、ベンダーに任せきりにせず、発注側も主体的に関わる必要があります。ベンダーにはプロジェクトマネジメント義務があり、一方で発注側にも協力義務という法的責任があります。
発注側の関与不足や、合意後の大量変更は、プロジェクト失敗の主因です。実際に、裁判でユーザー側が責任を問われた事例もあります。
判例に見るユーザーの協力義務と要件確定
旭川医大病院とNTT東日本の事件では、控訴審でユーザー側の協力義務違反が認定されました。要件の追加や支払いについて、次の判断が示されました。
- 追加要望：169項目中124項目が、当初の開発対象外とされました。
- 支払い：ユーザー側のみに約14億1,500万円が命じられました。
- 控訴審：札幌高裁での判断は、平成29年8月31日です。
システム開発のトラブルでは、発注側も責任を問われることがあります。要件を曖昧にしたまま進め、後から変更を大量に求めると、発注側が法的責任を負う場合があるためです。
まず、要件定義書に作る内容を明記し、発注側が責任を持って確定させます。次に、要件は早期に凍結し、その後の変更は正式な変更管理を通します。
製造業は設計変更や仕様変更が多いため、変更管理のルールをRFPの段階で決めておくことが紛争予防につながります。協力義務は、発注側の主体的な関与を裏付けるものでもあります。
社内の推進体制と意思決定者の明確化
要件の確定と変更管理には、社内のプロジェクト体制が欠かせません。RFPでは、意思決定と承認の役割を明確にしておきます。
- 最終意思決定者：要件を決める人を定めます。
- 部門窓口：各工程や部署から出す担当者。
- 承認会議：どの会議体で了承を得るかを決めます。
製造業は、現場から経営まで関係部門が多い分、意見をまとめる体制がないと要件が固まりません。現場の使いやすさと、経営層が重視する面積生産性やROIでは、評価基準が異なります。そのため、基準の違いを早期に調整して優先順位を合意しておくと、稟議にもつながります。
要件定義は技術文書であると同時に、社内の合意形成のプロセスです。そこで、riplaはフルスクラッチ受託の立場から、業務を起点にした要件整理と、部門間の調整を支援します。
プロジェクトへの現場担当者の参加
要件定義では、実際にシステムを使う現場担当者にも加わってもらう必要があります。意思決定者や管理者だけで決めると、現場の実務感覚が抜け落ちることがあります。
- 参加者：各工程のリーダーや実務担当者を加えます。
- レビュー対象：画面イメージや入力の流れ。
こうした確認によって、管理側は見たいが現場は入力できない要件を避け、実務に合う内容へ近づけられます。その結果、要件定義に関わった現場担当者は、システムを自分たちが作ったと感じ、稼働後の定着を推進します。
上から降りてきたシステムは、現場の反発を招きやすいものです。そのため、現場の納得と当事者意識が、稼働後の定着率を左右します。
外部連携・データ移行・クレンジングの要件
製造業のシステムは、単体で完結することがほとんどありません。得意先や仕入先とのEDI、設備のIoTなど、外部とのデータ連携が必要になります。CADや会計との連携に加え、既存システムからのデータ移行も避けられません。
そのため、連携や移行をRFPに明記しておかないと、開発後半に想定外の連携工数や、使えない移行データが問題になることがあります。
EDI・設備・図面データの連携要件の定義
外部連携は、相手先との事前協議が欠かせません。RFPには、どの相手と、どのフォーマットで、どの頻度で連携するかを記載します。そのうえで、連携相手との調整に必要な期間も見込んでおきます。
- EDI：相手の仕様に合わせる形になり、仕様変更には相手との調整時間がかかります。
- 図面・部品表：大容量データに合う連携方式の選定。
- 設備IoT：対象設備と取り込むデータを定めます。
物流のEDI仕様変更では、最低でも3ヶ月前から事前協議を始めるべきとされます。つまり、外部連携は自社の都合だけでは進みません。
CADの3D図面をクラウドでやり取りすると、通信速度がボトルネックになることがあります。そこで、図面の実体をオンプレミスに置き、管理情報だけを連携する構成も検討します。
連携要件では、データ量や頻度、相手先の事情まで定義しておきます。接続できることだけを条件にしないことで、後の手戻りを防げます。
データ移行とマスター整備（クレンジング）の要件
移行後の混乱を防ぐため、データの対象範囲だけでなく、マスター整備の進め方も発注時に決めておく必要があります。
- 移行対象：どのデータをどの粒度で移すかを定めます。
- 移行期間：どこまで過去にさかのぼるかを決めます。
- 整備の分担：RFPで誰が・いつ・どこまで担うかを明確にしないと、本番直前に大混乱します。
品目・取引先マスタや部品表には、重複登録、表記揺れ、廃番品の放置が残ることがあります。このまま移行すると、投資効果が損なわれます。そのため、データクレンジングを要件に含めることは、地味ですが極めて重要です。
本番前には、基幹システム上の在庫と現場が把握する在庫、実物の在庫を一致させる調整も必要です。こうした整備の工数とコストが、見積もりに含まれるかも確認します。
新システムの導入は、マスター整備を進める好機と捉えられます。重複や表記揺れを整理して命名ルールを統一すれば、導入効果が高まり、その後の運用も楽になります。
移行データは一覧にし、クレンジングの期限と判断基準も決めておきます。ここが曖昧なままだと、本番稼働でトラブルが起きやすくなります。
RFPに盛り込むSLA・保守・選定基準
RFPは、要件を伝えるだけでなく、ベンダーの比較や運用開始後の関係を決める文書です。SLAや保守の取り決め、費用内訳、選定基準を盛り込みます。
これらを記載しておくと、提案を比べやすくなり、契約後のトラブルも減らせます。生産停止が大きな損害に直結する製造業では、特に運用面の取り決めが重要です。
SLAと保守費用の要件への明記
SLAには、復旧目標時間、問い合わせの応答時間、サポート時間帯を定めます。保守費用や運用費も含めて、導入後の費用を見積もります。
- 開発費に対する保守費：一般に開発費の15〜20%が目安です。
- 3,000万円の開発：保守費は年450万〜600万円になります。
- オンプレミス運用：年500万〜1,500万円かかることもあります。
製造ラインを止められない企業ほど、復旧時間が重要です。また、保守費を想定せずに導入すると、運用段階で予算が破綻します。
初期費用だけでなく、年間コストを含む総所有コスト（TCO）の見積もりを、RFPの項目に入れます。導入後数年間の総額を比べられるよう、費用内訳を明示してもらいます。たとえば、初期費用が安くても、保守費や1件100万〜1,000万円の追加カスタマイズ費で総額が増えることがあります。
製造業のシステムには、生産実績や原価、品質記録など、失うと業務に支障が出るデータが蓄積されます。そこで、バックアップ頻度や障害時のデータ保全・復旧方法を要件に明記すると、運用段階の不安を減らせます。
つまり、SLAは契約書の付属物にとどまらず、生産を止めないための実務的な取り決めです。
選定基準としての業界理解と伴走力
ベンダーは、機能や価格だけでなく、製造業の現場やノウハウへの理解で比べます。導入後の伴走力も、選定基準になります。
- 業界理解：同業種での実績や、現場への理解の深さ。
- ヒアリング：現場の聞き取り方法の提案。
- 導入後の伴走：教育、運用定着、トラブル対応を確認します。
生産形態や工程の細かな違いを理解しないまま進めるベンダーは、要件の聞き取りで的を外し、現場と合わないシステムを作ることがあります。システムは導入後に現場へ定着して初めて成果が出るため、RFPで保守・サポート体制を問い、提案内容を比べます。
複数社に同じRFPへの提案を求めると、価格、機能、体制を同じ条件で比べられます。また、具体的な記載があれば、各社の提案の差がはっきり見えます。
RFPが曖昧だと、各社は異なる前提で見積もるため、比較が成り立たないことがあります。要件を言語化しておけば、自社の業務整理とベンダー評価の土台になります。
要件定義とRFPに手間をかけることは、大きな製造業システムへの投資を成功に導く確かな保険になります。
受け入れテストと稼働判定の基準
RFPと要件定義の段階で、受け入れテスト（UAT）と本番稼働の判定基準を決めます。確認する条件は、事前に具体化しておきます。
- 確認担当：誰がテストするかを定めます。
- 確認観点：確かめる要件の範囲。
- 合格基準：どこまで確認したら合格か明記します。
稼働条件が曖昧だと、不具合を残したまま稼働を強行し、生産や出荷が止まる事態を招くことがあります。グリコの事例も示すように、事前のリスク管理が欠かせません。
本番前に一定期間、新旧システムを並行運用し、結果を突き合わせる方法も有効です。これにより、現場が新システムに慣れ、データの整合も確認できます。
RFPには、テスト期間や並行運用の想定も盛り込みます。そのうえで、提案にそれらが含まれるかを確認します。
受け入れ基準と移行計画を要件の段階で固めておくことは、稼働後の生産停止という最悪の失敗を防ぐ、最後の歯止めになります。
まとめ
製造業の要件定義は、現場ヒアリングで現状（AsIs）を可視化し、業務を標準化したToBeを設計するところから始まります。そのうえで、ユーザーの協力義務を踏まえて要件を早期に凍結し、変更管理を定めることが、旭川医大事件のような法的リスクを避ける鍵になります。
EDI・図面・設備の外部連携や、データ移行・クレンジングを要件に明記します。加えて、SLA、保守費（開発費の15〜20%）、業界理解と伴走力を選定基準に据えることが、投資を成功に導きます。
要件定義では、ベンダーに任せきりにせず、発注側が主体的に業務を言語化して、関係部門の合意を形成することが大切です。手間はかかります。しかし、その手間が、後の巨額の手戻りや法的紛争を防ぎます。
riplaはフルスクラッチ受託と国内開発を組み合わせ、現場業務からの要件整理、合意形成、データ移行まで一貫して支援します。全体像を確認するには、製造業界のシステムの完全ガイドもご活用ください。
▼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を創業。