ガラス/セメント業界のシステム開発の発注/外注/依頼/委託方法について

ガラス・セメント業界のシステム開発を発注するときは、業務の整理、要件の確定、小規模な導入の順に進めるのが基本です。段階的に導入すれば、プラントを止めずに投資効果を確かめやすくなります。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

ガラス・セメント業界のシステム開発を外注する全体像

発注の基本は、現場業務を整理して必要な成果物を定めたうえで、複数の候補会社に同じ条件で提案と見積を依頼することです。

ガラス・セメント工場は、受注生産の組立工場と違い、原料が製造工程の中で変化するプロセス型製造業です。そのため、販売管理をデジタル化するだけでは足りず、生産実績や原価とつなげてこそ経営判断に使えるシステムになります。

組立加工業向け要件との違い

たとえばガラスでは、原料の配合、溶解炉の状態、成形条件、検査結果、端材の扱いが品質と原価に影響します。セメントでは、石灰石などの原料受入から粉砕、調合、焼成、粉体の保管、出荷までを一連の流れとして管理します。

BOM（部品表）を中心にした仕組みだけでは、レシピの変更履歴、投入量と出来高の差、同時に複数製品が生じる連産品の原価を表しにくい場合があります。

発注要件の中心は「工程・物流・設備」の三領域

候補会社が業務への対応範囲を示せるよう、RFPでは要件を工程・物流・設備の三領域に分けて整理します。

• 工程管理：レシピ、歩留まり、品質、原価。
• 物流管理：サイロやタンクの容量、専用船、バラ車の配車。
• 設備管理：炉やキルンなどの設備保全とエネルギー。

これらを業務フローとデータ項目に分けてRFPに記載すると、候補会社の提案を同じ軸で比べられます。

経済産業省は2025年、レガシーシステムのモダン化に関する総括レポートを公表しています。古い仕組みを置き換えるだけでなく、変化に追随できる構造への見直しが求められています（出典: 経済産業省「レガシーシステムモダン化委員会総括レポート」、2025年）。

発注前に整理すべき業務とRFPの作り方

RFPは、開発会社に要望を伝えるための資料であると同時に、社内の意思決定をそろえるための資料です。

最初から細かな画面仕様まで書く必要はありません。ただし、対象拠点、利用者、対象業務、現行システム、解決したい経営課題、予算と希望時期、納品物、評価基準は明記します。なかでも「何をもって成功とするか」を数値で決めておくことが、提案の質を左右します。

現状業務と目標業務の分け方

まず、現場ごとに、今どの帳票、Excel、ホワイトボード、電話、FAXを使っているかを洗い出します。そのうえで、将来どの担当者がいつどのデータを入力し、誰が承認し、どの帳票を出すのかを定めます。

たとえば「在庫をリアルタイム化する」といった書き方では不十分です。「サイロごとの理論在庫と実在庫を毎日何時までに照合し、出荷指示と配車計画へ連携する」のように、業務ルールとデータの責任者まで書く必要があります。

RFPに入れる業界固有のデータ項目

ガラスとセメントでは管理対象が異なるため、RFPのデータ項目は業種ごとに整理します。

• ガラス：配合比率、溶解炉の温度、成形条件、ロット、検査結果、規格外品と再利用品。
• セメント：原料の含水率、粉体のロット、キルンの稼働情報、サイロ容量、積込実績、車両の到着予定と納入先。
• 共通の確認事項：レシピの変更権限と履歴、単位・換算方法、連産品の原価配賦。

これらが抜けると、完成後に追加開発として請求されるリスクが高まります。

効果測定の指標の設定

効果指標には、棚卸し差異、歩留まり、設備停止時間、配車待機時間、入力工数、月次締め日数などがあります。たとえば、棚卸し差異を現状比30％削減する、配車確定を前日17時までに行う、設備異常の一次記録を10分以内に残す、といった数値を目標にします。

数値は発注先に提案してもらうより、発注者が現場と合意して先に決めておくと、納品判定と投資対効果の確認に使えます。

発注形態の比較（パッケージ・クラウド・スクラッチ）

発注形態に正解はありません。標準業務に合わせられる範囲が広ければ、パッケージやSaaSが候補になります。一方で、既存設備や独自の配合・原価計算が競争力なら、パッケージを核にした追加開発やスクラッチ開発が候補になります。

比較では、初期費用だけでなく、5年から10年のTCO、通信障害時の業務継続、データの持ち出しやすさも見ます。

パッケージ・SaaSで標準化できる範囲

パッケージやSaaSは、短期間で導入しやすく、アップデートやセキュリティ対応を委託しやすい点が魅力です。

ただし、標準機能に業務を合わせる際に現場の例外処理を無理に残すと、カスタマイズが増えて利点が薄れてしまいます。そこで、デモでは受注画面よりも、配合変更、連産品の原価、サイロの在庫引当、車両の積載制約、炉の異常記録といった自社の難しい業務を再現してもらいます。

スクラッチ開発の管理責任と独自性

スクラッチ開発は、現場の業務や既存設備との連携を細かく設計できる一方、要件定義、テスト、保守、セキュリティ、将来の人材確保まで発注者が管理する必要があります。

全部を一度に作るより、まず原料・生産実績・在庫・出荷の最小範囲でPoCを行い、次に設備保全やGXデータへ広げる段階方式が現実的です。

クラウドとオンプレミスの業務継続性

クラウドは、拠点間のデータ共有やバックアップ、拡張を計画しやすい方式です。一方で、通信が不安定、または制御系と業務系の分離が必要な工場では、オンプレミスや工場内エッジサーバーを併用します。

発注前に、回線が断たれたとき業務を何時間続けられるかを確かめておきます。また、再接続後の二重登録をどう防ぐか、クラウド料金が増える条件、データを全量エクスポートできるかも、契約前に見ておきます。

システム開発を発注する進め方

候補会社が決まったら、要件定義、設計・開発、テスト・移行、運用定着の順に進みます。各段階の終了条件を決めておき、次の工程へ進む前に未決事項を一覧にします。

発注者は、業務責任者、現場代表、情報システム担当、経理・品質・設備保全の責任者を、最初からプロジェクトに入れておくことが大切です。

要件定義で決めることと決めないこと

要件定義では、対象範囲と業務ルール、権限を決めます。そのうえで、後から変えにくい要件も、この段階で文書にしておきます。

• データ項目：現場で扱う情報の種類と、その定義。
• 外部連携：既存システムや外部サービスと、どこでつなぐか。
• 性能：処理の速さや、同時に使う人数などの条件。
• 障害時の復旧と監査ログ：止まったときの戻し方と、操作の記録の残し方。
• セキュリティ：情報を守るために、どこまで対策するか。

将来検討する機能は、対象外として明記します。

計画には、発注者側でマスタデータを整備する期限と、現場がレビューする回数も入れておきます。要件を凍結する日を設けないまま開発を始めると、追加要望と納期・費用の関係が曖昧になります。

設計・開発での判断記録とデモ

設計では、業務フローと画面、帳票を確認します。そのうえで、要件を実装へ移すための判断も、設計の段階で書き残しておきます。

• データモデル：情報をどんな単位と関係で持つかの設計。
• 連携方式：他のシステムとのデータのやり取りの方法。
• 権限：誰がどの画面とデータを扱えるかの割り当て。
• エラー処理：入力ミスや連携の失敗時に、どう止まり、どう知らせるか。

毎週の定例会議では、課題、決定事項、担当者、期限を記録しておき、画面の試作は工場の利用者に実際に触ってもらいます。

現場の反発は、機能が足りないことより、入力のタイミングや責任分担が現実と合っていないことから起こりやすいものです。そのため、入力項目を最小限にし、紙のチェックリストを段階的に置き換えるなど、運用も同時に設計します。

テストと移行の段取り

テストでは、機能確認だけでなく、実際のレシピや過去ロット、通信断の状況も再現して、本番に近い条件で動くかを見ます。

• 異常値：測定値や入力値が、想定の範囲を外れたときの動き。
• 返品：出荷後に戻ってきた製品の扱い。
• 計画変更：生産計画が直前に変わったときの動き。
• 設備停止：炉やキルンが止まったときの記録と対応。
• 夜間の担当者交代：夜間に担当が替わったとき、引き継ぎと記録がつながるか。

移行では、旧システムから新システムへ一度に切り替える方式に加えて、拠点別、業務別、製品群別の段階移行、並行稼働、切り戻しを比べます。

24時間稼働の炉やキルンに直接つながる場合は、業務系システムが止まっても安全側へ倒れる構成を用意します。あわせて、手書きの記録から後追いで登録する手順も決めておきます。

業務の不確実性に合わせた契約形態の選び方

契約形態は、請負契約、準委任契約、保守・運用契約を組み合わせるのが一般的です。ただし、契約名だけで判断せず、成果物と完成責任、検収を具体的に確認します。さらに、作業の進め方と成果の受け渡しを、契約書の中で項目ごとに決めておきます。

• 作業時間：発注者と開発会社が、どれだけの時間を作業に充てるか。
• 変更管理：要望が出たとき、費用と納期への影響をどう判断するか。
• 知的財産権：成果物の権利を、発注者と開発会社のどちらが持つか。
• 再委託：開発会社が別の会社に作業を任せるときの条件。
• 障害対応：稼働後に不具合が出たとき、誰がどこまで対応するか。

要件が固まらないまま全工程を固定価格の請負にすると、発注側と開発会社の双方が無理な前提を抱えやすくなります。

請負契約の成果物と検収条件

請負契約は、要件と成果物が明確な機能開発に向いています。そのうえで、画面一覧、帳票一覧、連携仕様を、契約書や仕様書にひも付けます。検収の場では、このひも付けを照合の基準にします。

• テスト項目：どの機能を、どんな手順で確かめるか。
• 性能条件：処理の速さや同時利用など、満たすべき条件。
• 納品物：成果物として渡すものの一覧。
• 検収期限：確認と受け入れを終える期限。
• 不具合の扱い：検収後に見つかった不具合を、どちらが直すか。

「使える状態」のような抽象的な条件を避け、「指定したロットを検索できる」「配合変更履歴を権限者が参照できる」といった受入条件に置き換えます。仕様変更は、費用と納期の影響を承認してから行う変更管理票で扱います。

準委任契約の使いどころ（要件整理や伴走支援）

準委任契約は、要件定義、現状調査、プロジェクト管理、専門人材の支援など、成果を事前に固定しにくい業務に適しています。

発注者は、作業範囲、体制、稼働時間、報告方法、責任分界、成果物の扱いを明記し、丸投げにならないようにします。

発注者側の担当者が意思決定を行い、委託先は調査と選択肢の整理を支援する関係にすると、要件の最終責任が曖昧になりにくいです。

保守契約のSLAと費用上限

保守契約では、受付時間、重大度ごとの一次回答時間、復旧目標を定めます。そのうえで、保守の範囲と費用の上限も、契約の中で具体的に決めておきます。

• 定期点検：稼働中のシステムを定期的に確認する作業の範囲。
• バックアップ：データの複製を、どの頻度でどこに残すか。
• セキュリティ更新：OSや部品の更新を、保守の範囲に含めるかどうか。
• 問い合わせ回数：対応を受ける回数に上限を設けるかどうか。
• 追加開発の単価：保守の範囲を超える改修を、どの単価で請け負うか。

保守費は開発費の年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データは後付けせずに設計へ含めること

GXの初期要件では、排出量の算定、制度の適用、顧客への説明に必要なデータを、あらかじめ整理しておきます。

• 排出量算定：燃料、電力、原料、輸送データ。
• 制度適用：対象範囲と算定義務の確認に必要な情報。
• 顧客説明への備え：必要な情報を追跡できる状態にしておく。

生産量と結びつけて、製品・拠点ごとのCO2排出量を把握します。

GX推進法に基づく排出量取引制度は2026年度に開始します。直近3年度のCO2直接排出量の平均が10万トン以上の事業者は、対象判定、計測、算定が必要です（出典: 経済産業省「2026年度版 GX推進法に基づく排出量取引制度」、2026年）。

対象外の企業であっても、顧客から排出量データを求められる可能性があります。そのため、計量データ、換算係数、証跡、承認履歴を管理できる構造を、初期要件に含めます。

稼働後90日間の改善期間

稼働後は毎週、問い合わせ件数や入力漏れ、処理時間を確認します。マスタ変更や障害、手作業への戻りも、同じ場で見ておきます。

特にレシピや原料マスタは、現場が勝手に変更すると原価や品質の追跡性が失われます。そのため、変更申請と承認の手順を運用に組み込みます。

3か月程度の改善期間を契約上の支援範囲に含めると、保守会社と発注者の双方が改善課題を消化できるようになり、導入効果が定着しやすくなります。

よくある質問

発注担当者が迷いやすい費用や契約は、会社の規模、対象範囲、設備連携によって変わります。最終的には、RFPと現場調査を通じて個別に確認します。

ガラス・セメント業界のシステム開発費用はいくらですか？

費用は、小規模な業務システムで500万円程度から、大規模な基幹システムで3億円以上です。対象拠点、設備連携、移行データ、現場端末、保守によって変わるため、初期費用だけでなく5年TCOと工程別の内訳も比べます。

契約は請負と準委任のどちらがよいですか？

要件と成果物が固まった開発には請負契約が、不確実性が高い現状調査や要件定義には準委任契約が向いています。たとえば、要件定義を準委任、開発を請負、稼働後を保守とする組み合わせが使いやすいです。

委託先は何社から見積を取るべきですか？

RFPは、同じ条件で2〜4社に渡すのが現実的です。社数が多すぎると、質問への対応や評価が浅くなります。そのため、実績、現場理解、移行・保守体制で絞り込み、金額、前提、除外項目、リスクへの回答を同じ基準で比べます。

24時間稼働の工場を止めずに移行できますか？

段階移行、並行稼働、業務系と制御系の分離、通信断時の手順、切り戻し条件によって、停止リスクを抑えます。そのうえで、完全に無停止だとは約束せず、許容停止時間や手作業からの後追い登録をRFPとテスト計画に落とし込みます。

まとめ

発注で押さえる三つの要点

業界固有のデータ項目を要件に含め、契約と見積の前提をそろえ、移行と保守まで含めて委託先を評価します。レシピや設備データの責任者を発注者が決めておくと、開発会社任せによる要件漏れを防ぎやすくなります。

最初に着手すること

最初に着手するのは一工場の現状整理です。その後は次の順に進めます。

1. 現状を整理：一工場の現状業務、帳票、マスタ、設備連携、費用課題を一覧にし、成功指標を三つ程度に絞る。
2. 業界特性を整理：プロセス型製造業としての業務特性を洗い出す。
3. RFPへ具体化：レシピ・配合、歩留まり、連産品原価、サイロ・タンク在庫、バルク物流、炉・キルンの保全、CO2排出量を業務要件とデータ項目に記す。
4. RFPを作成：整理した資料をもとにRFPを作り、複数社から現場調査と提案を受ける。
5. 方式を比較：パッケージ、クラウド、スクラッチを5年TCOと業務継続性で比べる。
6. 契約を使い分け：要件定義は準委任、確定後の開発は請負、稼働後はSLA付き保守とする。
7. 見積を比較：金額に加えて、現場調査、移行、教育、テスト、除外項目、成果物、ロックイン対策を同条件で比べる。
8. 小さく始める：効果を測り、現場と合意してから拠点を広げます。段階導入は、プラントを止めずに投資効果を得る近道です。

参考情報・出典

本記事の最新動向に関する補強情報は、以下の公的資料を参照しています。

レガシーシステムのモダン化

経済産業省「レガシーシステムモダン化委員会総括レポート」（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です。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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