ガラス・セメント業界のシステム開発を外注するなら、一般的な製造業向けERPをそのまま導入するのではなく、レシピ管理、歩留まり、連産品、サイロ在庫、24時間稼働設備までを発注条件に落とし込むことが重要です。
本記事では、ガラス・セメント業界のシステム開発を発注・外注・委託する方法を、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、移行と運用まで順番に解説します。プロセス型製造業の現場で起こりやすい失敗を避け、プラントを止めずに段階導入するための判断材料としてご活用ください。
ガラス・セメント業界のシステム開発を外注する全体像

発注の基本は、現場業務を整理して必要な成果物を定義し、複数の候補会社へ同じ条件で提案と見積を依頼することです。ガラス・セメント工場は、受注生産の組立工場とは異なり、原料が製造工程のなかで変化するプロセス型製造業です。そのため、販売管理だけをデジタル化しても、生産実績や原価がつながらなければ経営判断には使えません。
組立加工業向けの要件だけでは足りません
たとえばガラスでは原料の配合、溶解炉の状態、成形条件、検査結果、端材の扱いが品質と原価に影響します。セメントでは石灰石などの原料受入、粉砕、調合、焼成、粉体の保管、出荷までを連続して管理します。BOM(部品表)を中心とした仕組みだけでは、レシピの変更履歴、投入量と出来高の差、複数製品が同時に生じる連産品の原価を表現しにくい場合があります。
発注要件の中心は「工程・物流・設備」の三つです
要件は、第一にレシピ、歩留まり、品質、原価を扱う工程管理、第二にサイロやタンクの容量、専用船、バラ車の配車を扱う物流管理、第三に炉やキルンなどの設備保全とエネルギー管理です。これらを業務フローとデータ項目に分けてRFPへ記載すると、候補会社の提案を比較しやすくなります。経済産業省は2025年にもレガシーシステムのモダン化に関する総括レポートを公表しており、古い仕組みを単に置き換えるだけでなく、変化に追随できる構造へ見直すことが求められています(出典: 経済産業省「レガシーシステムモダン化委員会総括レポート」、2025年)。
発注前に整理すべき業務とRFPの作り方

RFPは、開発会社に要望を伝える資料であると同時に、自社の意思決定をそろえる資料です。最初から細かな画面仕様を書く必要はありませんが、対象拠点、利用者、対象業務、現行システム、解決したい経営課題、予算と希望時期、納品物、評価基準は明記します。特に「何をもって成功とするか」を数値で置くことが、提案の質を左右します。
現状業務と目標業務を分けて書きます
現場ごとに、現在どの帳票、Excel、ホワイトボード、電話、FAXを使っているかを洗い出します。そのうえで、将来はどの担当者が、いつ、どのデータを入力し、誰が承認し、どの帳票を出すのかを定義します。たとえば「在庫をリアルタイム化する」では不十分です。「サイロごとの理論在庫と実在庫を毎日何時までに照合し、出荷指示と配車計画へ連携する」のように、業務ルールとデータの責任者まで書く必要があります。
RFPには業界固有のデータ項目を入れます
ガラスなら配合比率、溶解炉の温度、成形条件、ロット、検査結果、規格外品と再利用品を記載します。セメントなら原料の含水率、粉体のロット、キルンの稼働情報、サイロ容量、積込実績、車両の到着予定と納入先を記載します。どちらも「レシピを誰が変更できるか」「変更前後を追跡できるか」「単位と換算方法は何か」「連産品の原価をどう配賦するか」を確認項目にします。ここが抜けると、完成後に追加開発として請求されるリスクが高まります。
効果測定の指標を先に決めます
効果指標には、棚卸し差異、歩留まり、設備停止時間、配車の待機時間、入力工数、月次締め日数などを使えます。例として「棚卸し差異を現状比30%削減」「配車確定を前日17時までに完了」「設備異常の一次記録を10分以内に登録」のようにします。数値は発注先から提案してもらうのではなく、発注者が現場と合意しておくと、納品判定と投資対効果の確認に使えます。
発注形態はパッケージ・クラウド・スクラッチを比較します

発注形態に正解はありません。標準業務へ合わせられる範囲が広い会社はパッケージやSaaSが候補になり、既存設備や独自の配合・原価計算が競争力そのものである会社は、パッケージを核にした追加開発やスクラッチ開発が候補になります。比較では初期費用だけでなく、5年から10年のTCO、通信障害時の業務継続、データの持ち出しやすさを見ます。
パッケージ・SaaSは標準化できる範囲を確認します
パッケージやSaaSは、短期間で導入しやすく、アップデートやセキュリティ対応を委託しやすい点が魅力です。ただし、標準機能に業務を合わせる過程で、現場の例外処理を無理に残すと、カスタマイズが増えて利点が薄れます。デモでは受注画面ではなく、配合変更、連産品の原価、サイロの在庫引当、車両の積載制約、炉の異常記録といった自社の難しい業務を再現してもらいます。
スクラッチ開発は独自性と引き換えに管理責任が増えます
スクラッチ開発は、現場の業務や既存設備との連携を細かく設計できる一方、要件定義、テスト、保守、セキュリティ、将来の人材確保まで発注者が管理する必要があります。全部を一度に作るのではなく、まず原料・生産実績・在庫・出荷の最小範囲でPoCを実施し、次に設備保全やGXデータへ広げる段階方式が現実的です。
クラウドとオンプレミスは業務継続性で選びます
クラウドは拠点間で同じデータを扱いやすく、バックアップや拡張を計画しやすい選択肢です。一方、工場内の通信が不安定な場合や、制御系と業務系を厳格に分離する必要がある場合は、オンプレミスや工場内エッジサーバーを組み合わせます。発注時には「回線断のとき何時間業務を継続できるか」「再接続後に二重登録をどう防ぐか」「クラウド料金の増加条件」「データを全量エクスポートできるか」を契約前に確認します。
システム開発を発注する進め方

候補会社が決まった後は、要件定義、設計・開発、テスト・移行、運用定着の順に進めます。各段階の終了条件を決め、次の工程へ進む前に未決事項を一覧化します。発注者の業務責任者、現場代表、情報システム担当、経理・品質・設備保全の責任者を最初からプロジェクトに入れることが大切です。
要件定義では決めることと決めないことを分けます
要件定義では、対象範囲、業務ルール、権限、データ項目、外部連携、性能、障害時の復旧、監査ログ、セキュリティを決めます。反対に、将来検討する機能は対象外として明記します。発注者側でマスタデータを整備する期限や、現場がレビューする回数も計画に入れます。要件を凍結する日を設けないまま開発を始めると、追加要望と納期・費用の関係が曖昧になります。
設計・開発では判断記録とデモを残します
設計では、業務フロー、画面、帳票、データモデル、連携方式、権限、エラー処理を確認します。毎週の定例会議では、課題、決定事項、担当者、期限を記録し、画面の試作を工場の利用者に触ってもらいます。現場の反発は、システムの機能不足よりも、入力のタイミングや責任分担が現実と合っていないことから起こりやすいです。入力項目を最小化し、紙のチェックリストを段階的に置き換えるなど、運用も同時に設計します。
テストと移行はプラント停止を前提にしません
テストでは、機能確認だけでなく、実際のレシピ、過去ロット、異常値、返品、計画変更、通信断、設備停止、夜間の担当者交代を再現します。移行は、旧システムから新システムへ一度に切り替える方式だけでなく、拠点別、業務別、製品群別の段階移行、並行稼働、切り戻しを比較します。24時間稼働の炉やキルンに直接つながる場合は、業務系システムが停止しても安全側へ倒れる構成と、手書き記録から後追い登録する手順を用意します。
契約形態は業務の不確実性に合わせて選びます

契約形態は、請負契約、準委任契約、保守・運用契約を組み合わせることが一般的です。契約名だけで判断せず、成果物、完成責任、作業時間、検収、変更管理、知的財産権、再委託、障害対応を具体的に確認します。要件が固まっていない段階で全工程を固定価格の請負にすると、双方が無理な前提を抱えやすくなります。
請負契約は成果物と検収条件を明確にします
請負契約は、要件と成果物が明確な機能開発に向いています。画面一覧、帳票一覧、連携仕様、テスト項目、性能条件、納品物、検収期限、不具合の扱いを契約書や仕様書にひも付けます。「使える状態」などの抽象的な条件ではなく、「指定したロットを検索できる」「配合変更履歴を権限者が参照できる」といった受入条件にします。仕様変更は、費用と納期の影響を承認してから実施する変更管理票で扱います。
準委任契約は要件整理や伴走支援に向きます
準委任契約は、要件定義、現状調査、プロジェクト管理、専門人材の支援など、成果を事前に固定しにくい業務に向いています。作業範囲、体制、稼働時間、報告方法、責任分界、成果物の扱いを明記し、丸投げにならないようにします。発注者側の担当者が意思決定を行い、委託先は調査と選択肢の整理を支援する関係にすると、要件の最終責任が曖昧になりにくいです。
保守契約はSLAと費用上限を定義します
保守では、受付時間、重大度ごとの一次回答時間、復旧目標、定期点検、バックアップ、セキュリティ更新、問い合わせ回数、追加開発の単価を定義します。保守費用は一般に開発費の年15〜20%が目安とされ、開発費3,000万円なら年間450万〜600万円の範囲です。ただし、現場端末、IoT、24時間監視、現地駆け付けを含むかで大きく変わるため、数字だけで高い・安いと判断せず、サービス範囲とSLAを比較します。
ガラス・セメント業界のシステム開発費用相場

費用は対象拠点数、利用者数、既存システムとの連携、設備データの取得、移行データ量、可用性、カスタマイズ範囲で変わります。一般的な製造業の目安では、小規模な業務システムで500万円程度から、大規模な基幹システムで3億円以上まで幅があります。ガラス・セメント工場では、現場端末やセンサー、制御系との境界、拠点間連携が加わるため、見積の前提をそろえなければ比較できません。
費用は工程別の比率で妥当性を確認します
見積の工程別配分は、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%、開発30〜40%、テスト15〜20%が一つの目安です。たとえば総額5,000万円なら、要件定義だけで500万〜750万円程度になる計算です。現場調査、設備連携、データクレンジング、移行リハーサルが別枠になっていない場合は、後から追加請求される可能性を確認します。
初期費用と5年TCOを分けて見ます
初期費用のほかに、ライセンス、クラウド利用料、端末交換、通信費、監視、バックアップ、教育、保守、法改正対応を5年分で試算します。センサーやタブレットを高温、粉塵、振動のある場所へ設置する場合は、防塵防水性能、交換周期、予備機の数量も費用に含めます。SaaSの月額が低くても、ユーザー数やデータ容量、API、長期保存で費用が増えることがあります。
予算超過を防ぐには予備費と変更ルールが必要です
予算には、要件の不確実性、データ品質、設備との接続、拠点展開の差異を吸収する予備費を持たせます。予備費を隠して一律に低価格を掲げる提案より、前提条件とリスクを明示する提案のほうが信頼できます。追加要望を無制限に受け入れず、変更の目的、優先度、費用、納期、代替案を記録し、経営会議で承認する仕組みを置きます。
委託先の選び方と見積比較のポイント

委託先は知名度や単価だけで選ばず、同規模のプロセス型製造業での実績、現場調査の姿勢、設備・物流・原価への理解、移行と保守の体制を確認します。候補会社には同じRFPを渡し、提案書の構成、見積の粒度、質問の内容、リスクの指摘、デモの再現度を比較します。候補を2〜4社程度に絞ると、発注側の評価負荷と比較のしやすさのバランスを取りやすいです。
同業種実績は機能名ではなく業務の深さを見ます
「製造業の実績あり」という説明だけでは足りません。レシピや配合の版管理、連産品の原価計算、粉体の単位換算、サイロの容量制約、バラ車の配車、設備異常の記録など、自社と近い業務を確認します。守秘義務の範囲で、導入前の課題、担当した範囲、利用拠点数、移行方法、導入後の効果、保守体制を質問します。営業担当だけでなく、実際のプロジェクト責任者と技術者が説明できる会社を評価します。
見積は金額ではなく前提と除外項目をそろえます
見積比較では、要件定義、設計、開発、テスト、移行、教育、保守、プロジェクト管理がそれぞれ計上されているかを確認します。データ移行、現場での端末設置、ネットワーク工事、帳票変更、外部API、休日対応、旅費、ライセンスを「別途」としている場合は、上限や算定方法を聞きます。安い提案が現場検証や移行を含んでいないだけの可能性もあるため、同じ作業範囲へ補正して比較することが大切です。
ベンダーロックインを契約と設計で防ぎます
発注前に、設計書、データモデル、API仕様、テスト結果、運用手順、ソースコード、設定情報の納品範囲と権利関係を確認します。データを標準形式で定期的に取り出せるか、別会社が保守を引き継げるか、再委託先を把握できるかも重要です。特定会社に依存すること自体が悪いのではなく、依存する範囲と、将来移行する場合の費用・手順を把握しておくことがリスク管理になります。
移行後に現場へ定着させる方法

システム開発は稼働開始で終わりません。現場が紙やExcelへ戻らないためには、使う人が業務ルールの変更に納得し、入力の負担を理解できる状態を作ります。導入前に全業務をデジタル化するのではなく、まず入力時刻、担当者、承認者、異常時の連絡先を標準化するAX(アナログ・トランスフォーメーション)を進めることも有効です。
最初は一拠点・一工程で効果を確認します
最初から全拠点を対象にせず、代表的な一工場の一工程で始めます。原料受入から生産実績、在庫、出荷までのデータがつながる範囲を選び、現場の入力時間、在庫差異、配車待機、設備停止の記録が改善したかを検証します。成功条件を満たしてから他拠点へ横展開すると、拠点ごとの例外を整理しながら投資を分割できます。
GXデータは後付けせずに設計へ含めます
ガラス・セメント業界では、燃料、電力、原料、輸送と生産量をひも付け、製品単位や拠点単位のCO2排出量を把握する要件が重要です。経済産業省の資料では、2026年度から排出量取引制度が開始され、直近3年度のCO2直接排出量の平均が10万トン以上の事業者は対象判定と計測・算定が必要です(出典: 経済産業省「2026年度版 GX推進法に基づく排出量取引制度」、2026年)。対象外の企業でも、顧客から排出量データを求められる可能性があるため、計量データ、換算係数、証跡、承認履歴を管理できる構造を初期要件に含めます。
稼働後90日間は改善期間として扱います
稼働後は、問い合わせ件数、入力漏れ、マスタ変更、処理時間、障害、手作業への戻りを毎週確認します。特にレシピや原料マスタは、現場が勝手に変更すると原価や品質の追跡性が失われるため、変更申請と承認を運用へ組み込みます。3か月程度の改善期間を契約上の支援範囲へ含め、保守会社と発注者の双方が改善課題を消化できるようにすると、導入効果が定着しやすくなります。
よくある質問

ここでは、発注担当者が特に迷いやすい点をまとめます。費用や契約は会社の規模、対象範囲、設備連携によって変わるため、最終的にはRFPと現場調査を通じて個別に確認します。
ガラス・セメント業界のシステム開発費用はいくらですか?
小規模な業務システムは500万円程度から、大規模な基幹システムは3億円以上まで幅があります。対象拠点、設備連携、移行データ、現場端末、保守を含む範囲で変わるため、初期費用だけでなく5年TCOと工程別内訳を比較することが大切です。
契約は請負と準委任のどちらがよいですか?
要件と成果物が固まった開発は請負契約、現状調査や要件定義など不確実性が高い業務は準委任契約が向いています。実際には、要件定義を準委任、確定した開発を請負、稼働後を保守契約とする組み合わせが使いやすいです。
委託先は何社から見積を取るべきですか?
RFPを同じ条件で2〜4社へ渡し、提案と見積を比較する方法が現実的です。会社数を増やしすぎると質問対応と評価が浅くなるため、業界実績、現場理解、移行・保守体制で候補を絞り、金額、前提、除外項目、リスクへの回答を同じ土俵で確認します。
24時間稼働の工場を止めずに移行できますか?
段階移行、並行稼働、業務系と制御系の分離、通信断時の手順、切り戻し条件を組み合わせれば、停止リスクを抑えられます。完全な無停止を約束するのではなく、どの業務を何分止められるか、手作業へ切り替えた場合にどう後追い登録するかをRFPとテスト計画へ落とし込むことが重要です。
まとめ

発注で押さえる三つの要点
要件を業界固有のデータ項目へ落とし込み、契約と見積の前提をそろえ、移行と保守まで含めて委託先を評価することが要点です。特に、レシピや設備データの責任者を発注者側で決めると、開発会社任せの要件漏れを防ぎやすくなります。
最初に着手すること
まずは一工場の現状業務、帳票、マスタ、設備連携、費用の課題を一覧化し、成功指標を三つ程度に絞ります。その資料をもとにRFPを作成し、複数社の現場調査と提案を受けることから始めてください。
ガラス・セメント業界のシステム開発を外注するときは、まずプロセス型製造業としての業務特性を整理します。レシピ・配合、歩留まり、連産品原価、サイロ・タンク在庫、バルク物流、炉・キルンの保全、CO2排出量を、RFPの業務要件とデータ項目へ具体化してください。
そのうえで、パッケージ、クラウド、スクラッチを5年TCOと業務継続性で比較し、要件定義は準委任、確定した開発は請負、稼働後はSLA付き保守というように契約を使い分けます。見積は金額だけで決めず、現場調査、移行、教育、テスト、除外項目、成果物、ロックイン対策まで同じ条件で比べます。小さく始めて効果を測り、現場と合意しながら拠点展開することが、プラントを止めずに投資効果を出す近道です。
参考情報・出典

本記事の最新動向に関する補強情報は、以下の公的資料を参照しています。
レガシーシステムのモダン化
経済産業省「レガシーシステムモダン化委員会総括レポート」(2025年) https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html
企業のDX推進と人材動向
独立行政法人情報処理推進機構「DX動向2025」(2025年) https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html
2026年度の排出量取引制度
経済産業省「2026年度版 GX推進法に基づく排出量取引制度が開始します」(2026年) https://www.meti.go.jp/policy/energy_environment/global_warming/ets_leaflet.pdf
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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