工程管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

工程管理システム開発は、現場の要件定義、設計・開発とテスト、段階的な導入の順に進めます。

この順に進め、各段階で現場担当者がレビューとサインオフを行うと、認識のずれや現場への影響を抑えられます。

▼全体ガイドの記事
・工程管理システム開発の完全ガイド

工程管理システム開発の全体像

発注側は、生産形態や工程の複雑さ、IT予算、将来の拡張計画を確認します。方式ごとに、開発期間、費用、柔軟性、保守運用の負担が大きく異なります。適切な方式を選ばないと、機能不足や使い勝手の悪さで現場に定着せず、Excel管理に逆戻りするケースも少なくありません。

開発アプローチは大きく3つに分かれ、自社の業務内容や予算によって選ぶ方式が変わります。

  • スクラッチ開発:独自業務への適合性を優先する企業向け。
  • パッケージ:標準機能を使って費用を抑えたい企業向け。
  • クラウドSaaS:初期費用と運用負担を抑えたい企業向け。

スクラッチ開発・パッケージカスタマイズ・クラウドSaaSの違い

自社に合う方式を選ぶ際は、独自業務への適合性、標準機能の範囲、運用負担の3点を比べます。

  • スクラッチ開発:独自の生産方式や工程ルールを反映したい場合。
  • パッケージ:標準機能を活用して費用を抑えたい場合。
  • クラウドSaaS:初期費用を抑えて素早く使い始めたい場合。

スクラッチ開発は、既存製品に頼らず、自社業務に合わせてゼロから構築する方式です。セル生産やライン生産、プロジェクト型生産といった独自の生産方式も、システムに反映できます。

開発コストは3方式のなかで最も高く、中規模でも3,000万〜1億円程度かかります。期間も6ヶ月〜2年程度かかりやすい方式です。スクラッチ開発では、プロジェクト管理と要件定義の品質が、システム品質に直結します。

パッケージでは、自社業務に合わせてカスタマイズします。製品には、SPRINGPRO、Asprova、PLANNER8などがあります。

標準機能で対応できる業務が多ければ、スクラッチ開発より費用を50〜70%削減できることがあります。ただし、バージョンアップ対応やカスタマイズ部分の保守には、継続的な費用がかかります。

クラウドSaaSには、SmartMat CloudやKAIZEN Cloudなどがあり、月額数万〜数十万円で利用できます。初期費用を抑えて素早く導入でき、運用・保守の負担も少なく済みます。一方で、機能のカスタマイズには限界があり、既存の生産管理システム(PMS)やERPと連携しにくい場合もあります。

クラウドSaaSは、製品や工程が標準的な中小製造業が、工程管理のデジタル化を始める際に適しています。

一般的な開発期間とスケジュール感

開発期間は、システムの規模や複雑さによって変わります。規模は小・中・大の3段階に分けて考えます。

  • 小規模:単一工場、5工程以内、利用者50名以下。
  • 中規模:複数ライン、20工程前後、利用者100〜300名、ERP連携あり。
  • 大規模:複数工場、IoT連携、グローバル展開を含む。

小規模の場合、スクラッチは4〜6ヶ月、パッケージは2〜4ヶ月が目安です。中規模では、スクラッチが8〜12ヶ月、パッケージが4〜8ヶ月程度かかります。

大規模では12〜24ヶ月以上を見込みます。また、スケジュールの配分も工程ごとに確認しておく必要があります。

期間の配分は、要件定義が20〜30%、設計が15〜20%、開発が35〜40%です。テストが15〜20%、リリース・導入が5〜10%を占めます。

現場への影響を抑えるには、一部ラインから試験導入する段階リリースが有効です。安定稼働を確認してから全体へ展開すれば、障害が起きたときの影響を小さくでき、現場定着も計画できます。

ポイント

方式は、独自業務への適合性、標準機能の範囲、運用負担を比べて選びます。開発期間や費用の差が大きいため、現場に定着するかどうかも含めて判断するとよいでしょう。

工程管理システム開発の進め方(要件定義〜運用)

工程管理システム開発の要件定義、設計、開発・テスト・リリースの3段階を横並びで示した図。
段階ごとの確認を経て、導入へ進む構成です。

各段階で作業結果をまとめ、承認を得てから次へ進むフェーズゲート方式が有効です。現場と開発側の認識はずれやすいため、各段階で現場担当者のレビューとサインオフを行います。後工程での手戻りを防ぐうえで、最も大切にしたい確認です。

要件定義フェーズ(工程フロー・担当者・進捗管理要件のヒアリング)

要件定義では、開発会社が現場の工程フロー、担当者の役割、進捗管理の方法を徹底的に聞き取ります。

  • 参加者:現場責任者やライン担当者、品質管理担当やIT担当の4者を必ず含める。
  • 聞く内容:それぞれの視点から見た「現状の課題」「理想の状態」「譲れない要件」。

工程ルートは、標準的なルートだけでなく、工程の迂回や先行後行ルールの例外、作業者のスキルによる依存関係も確認しておきます。これを見落とすと、稼働後に登録できない工程パターンが頻発します。

ヒアリングの結果は、現行業務フロー図(As-Is)と新業務フロー図(To-Be)にまとめます。現場担当者の承認を得てから、内容を要件定義書に落とし込みます。

要件定義書には、機能要件として工程登録とスケジュール作成を記し、進捗入力やアラート設定も加えます。非機能要件としては、画面表示速度や同時接続数を明記し、データ保持期間やバックアップ方式、セキュリティ要件も書き添えます。

外部システムとの連携仕様も決めておきます。対象は、生産管理システムやERP、品質管理システム、IoTセンサーなどです。連携の概要を先に決めておくと、設計以降の工数見積もりの精度が上がります。

要件定義書は、開発の基準となる文書です。開発会社と発注者、現場責任者の三者が内容を理解し、正式に承認してから次へ進みます。

設計・UI/UXデザインフェーズ

設計では、全体の構成や画面を、作業環境と将来の運用を見据えて決めます。データベースやAPIも、同じ前提で設計します。

  • リアルタイム性:進捗を管理画面に即時反映できること。
  • 拡張性:ラインや工場が増えたときに広げられる構成。
  • 現場UI:手袋でも使える最小44×44pxのボタン。
  • 操作性:工程完了報告を3タップ以内で行えること。

工程、製品、作業者の各マスタと実績データの関係を正規化します。頻繁に参照するクエリの性能を確保するため、インデックスも設計します。

入力端末には、タブレット、タッチスクリーン、産業用ハンディターミナルなどを想定します。騒音環境で見やすいコントラスト比も、製造現場向けのUI要件に含めます。また、工程の状況は、ガントチャートやカンバン方式の進捗ボードで直感的に示します。

FigmaやAdobe XDで作った試作品を現場担当者に試してもらい、出てきた意見を設計に反映します。設計段階でユーザーテストを行えば、開発中の大きな手戻りを防げます。

開発・テスト・リリースフェーズ

実装から運用開始までは、開発、テスト、段階リリースの順に進みます。

  1. 設計書に基づき、画面やサーバー、データベース、外部APIを並行して実装する。
  2. 2週間スプリントのアジャイル開発で優先機能を作り、現場レビューの意見を取り入れる。
  3. 単体・結合・システムの各テストを経て、ユーザー受入テスト(UAT)まで順に実施する。
  4. 一斉には切り替えず、一部ラインや工場から段階導入して、リリース後は集中支援を行う。

優先機能には、工程登録や進捗入力、ガントチャート表示などがあります。動くデモをレビューに出せば、完成形への認識のずれを抑えられます。

テストでは、工程が並行する場合の進捗表示と、遅延アラートの出る時期を確かめます。IoTデータの遅延や欠損も重点項目です。特にUATでは、実際の製造データを使い、現場担当者が業務の流れに沿って問題なく操作できるかを見ます。

リリース後2〜4週間は集中サポートを設け、問い合わせに素早く対応します。

ポイント

各段階で現場担当者の承認を得てから次へ進むかどうかを、判断の目安にします。承認を省くと、後工程での手戻りを防ぎにくくなります。

工程管理システムの主要機能と技術選定

工程管理システムの必須機能として、スケジュール、進捗可視化、リソース管理、アラートを配置したハブ図。
計画から異常の通知まで、機能が役割を分担します。

必要な機能は生産形態によって異なるため、必須機能、連携機能、技術基盤の3つの面から検討します。

必須機能(工程スケジュール管理・進捗可視化・リソース管理・アラート)

必須機能は、計画作成から現場の進捗把握、異常の通知までを支えます。

  • スケジュール:工程ルートと標準作業時間を登録し、計画を組む。
  • 進捗可視化:開始、完了、中断を現場から入力し、進み具合を追う。
  • リソース管理:設備、作業者、材料を工程計画に結びつける。
  • アラート:遅延や異常、納期リスクを知らせる。

製品やロットごとに、工程ルートや標準時間などを登録します。使用設備や必要スキルも登録しておくと、ガントチャートやネットワーク図でスケジュールを自動生成できます。

納期から着手日と完了日を逆算する機能を、逆スケジューリングと呼びます。また、有限能力スケジューリングは、複数のオーダーを組み直して生産効率を高める仕組みです。

進捗可視化の画面には、進捗を色分けしたガントチャートや、全体を見渡すカンバンビューがあります。フロービューでボトルネックを検出すれば、状況に応じた判断を早められます。

高度な機能では、設備の負荷が集中したときや、特定スキルの作業者が不足したときを自動で検知します。検知後に代替案を示すシステムもあります。

通知は、メールやSMS、社内チャットツール(Slack/Teamsなど)に届けます。標準時間の110%超で警告し、120%超でエスカレーションする設定例もあります。しきい値は現場の実態に合わせて調整し、設備異常や品質逸脱も通知の対象に含めます。

連携機能(生産管理システム・ERP・IoTセンサーとの連携)

基幹システムと連携すると、情報をひとつにまとめられ、工程管理に伴う業務を自動化できます。

  • 生産管理(PMS):受注や製造指示を工程計画に結びつける。
  • ERP:工程実績を原価、在庫、会計に反映させる。
  • IoTセンサー:設備データから稼働状況や工程の完了を判定する。

生産計画と工程スケジュールを揃えるために、PMSから受注情報、製造指示、材料所要量計算(MRP)の結果を連携します。

連携方式は、CSVの定期バッチ、REST API/WebAPI、データベース直接連携です。リアルタイム連携には、Apache Kafka、AWS SQS、RabbitMQなどのメッセージキューが有効です。

SAP、Oracle ERP、Dynamics 365との連携で、工程実績を原価、在庫、会計に反映します。SAP BAPIやOData APIなど公式APIを使うと、ERP更新時の影響を抑えられます。

温度、振動、電流センサーの情報から、設備の状態や異常の兆候を判定できます。工程の完了も自動で判定でき、実績の入力につながります。

IoTデータ収集にはMQTTを使い、AWS IoT GreengrassやAzure IoT Edgeを基盤にできます。大量センサーデータの蓄積や分析には、Time Series Database(InfluxDB・TimescaleDB)を使います。

技術スタックと選定ポイント

工程管理では、画面操作からセンサーデータの保存までを支える技術を組み合わせます。

  • 画面:React.js、Vue.js、Angular.js。
  • サーバー:Node.js、Python、Java、PHP、Go。
  • データベース:工程実績はPostgreSQL・MySQL、時系列データはInfluxDB・TimescaleDB、スケジューリングの中間データはRedis。
  • インフラ:AWS、Azure、Google Cloud、Kubernetes、ECS。

ガントチャートやリアルタイム画面には高い操作性が求められます。こうした画面には、React.js、Vue.js、Angular.jsといったモダンJavaScriptフレームワークが主流です。

ガントチャートライブラリには、DHTMLX Gantt、Frappe Gantt、Bryntum Ganttがあります。サーバーの候補は、Node.js(Express/Fastify)、Python(FastAPI/Django)です。

Java(Spring Boot)やPHP(Laravel)も有力です。一方で、IoTや大量データ処理では、Node.js(非同期I/Oが得意)やGoの採用が増えています。

用途ごとにデータベースを分けるマルチデータベース構成が一般的です。KubernetesやECS(AWS Elastic Container Service)でコンテナ化し、拡張性と可用性を確保します。オンプレミス要件があれば、クラウドとのハイブリッド構成を検討します。

最終的な判断では、開発会社の習熟度や将来の内製化計画、同種システムの運用実績を重視します。

ポイント

必須機能、連携機能、技術基盤の順に検討すると、考えを整理できます。連携先のERPやIoTセンサーを先に決めておくと、技術選定の根拠が明確になります。

工程管理システム開発の注意点

現場向け画面の設計要件として、操作、視認性、誤操作防止、多言語の4項目を示した図。
4つの観点を画面設計時に並べて確認できます。

現場に定着させるには、UI/UXとリアルタイム連携の信頼性を早い段階から検討します。

現場作業員が使いやすいUI/UX設計

現場に合わない画面では入力が省かれたり、後からまとめて入力されたりします。その結果、画面と実際の進捗がずれて信頼が失われ、「結局Excelに戻した」という失敗につながります。

現場向けの画面では、操作しやすさと視認性を中心に、誤操作防止や多言語対応も検討します。

  • 操作:工程選択から確認まで3ステップ以内。
  • 視認性:照明や防護メガネを踏まえた高コントラスト。
  • 誤操作防止:完了ボタンを大きくし、取り消しを容易にする。
  • 多言語:日本語・英語・ベトナム語・タガログ語の切り替え機能。

外国人技能実習生が多い現場では、必要な言語を切り替えられるようにします。スマートフォンやタブレットで操作しやすいよう、タッチ操作の設計も必要です。バーコードやQRコードで指示書や部品を読み取れば、手入力を減らせます。

管理者画面と作業員画面は分け、役割ごとに情報量と操作を設計します。現場に合った画面は、利用者全体の満足度の向上につながります。

リアルタイムデータ連携の設計

リアルタイムで共有するには技術上の課題があるため、接続方式と障害時の動きをあらかじめ決めておきます。

  • 画面更新:WebSocketでサーバーから進捗を配信する。
  • センサー障害:途絶時の通知と手動入力への切り替えを定義する。
  • 外部連携:遅延、API制限、重複処理への対処を決める。

WebSocketは、管理画面に工程進捗をすぐ反映するサーバープッシュ型通信です。タブレットが100台以上常時接続する場合は、WebSocketサーバーの負荷が増えます。Sticky Session対応のロードバランサーとRedisでセッションを共有し、スケールアウトします。

センサーの通信障害や電源断、データ欠損が起きたときの挙動も、設計の段階で決めておきます。たとえば、データが5分途絶したら設備異常を通知し、連携が切れた場合は手動入力へ自動で切り替えます。

バッチ連携では、最大1時間の遅延が生じる場合があります。そのため、データの整合性を保つ工夫が必要です。

API同期では、呼び出し制限(Rate Limiting)への対応が必要です。冪等性とは、同じ要求を複数回送っても結果が変わらない性質です。API連携では、この性質を実装して、データの重複処理を防ぎます。

ポイント

UI/UXとリアルタイム連携は、現場が入力を続けられるかどうかで判断します。入力が省かれると画面と進捗がずれ、Excelに戻る失敗につながります。

開発を成功させるためのポイント

失敗の主な原因は、現場と要件のずれや、導入後の定着支援が足りないことです。高機能でも現場で使われなければ、投資は活きません。

現場担当者を巻き込んだ要件定義

関係者は立場ごとに期待が異なるため、要件定義に各視点を反映させます。

  • 経営層:KPIを追えることと、コスト削減効果。
  • IT部門:セキュリティと保守性。
  • 現場管理者:工程全体の把握と迅速な判断。
  • 現場作業員:簡単な操作と日常業務への影響抑制。

管理側の意見だけで作ると、現場で使いにくくなり、定着が妨げられます。現場観察(バリューストリームマッピング)は、見えにくい課題を発見する方法です。

現場の担当者代表をプロジェクトに加える「現場ユーザー代表制度」も有効です。各スプリントレビューには現場担当者が参加し、継続して意見を伝えます。

初期の段階では、すべての要望を盛り込まず、MVP(最小限の価値を持つプロダクト)を定めます。機能を絞って段階的に追加すれば、スコープクリープ(要件の際限ない拡大)を防げます。

段階的な導入と定着支援

全社一斉に導入すると、混乱を招くおそれがあります。そのため、小さく試してから展開します。

  1. 製品ライン、工程グループ、工場棟から試験対象を選ぶ。
  2. 2〜3ヶ月運用して、動作確認や課題の洗い出し、改善を行う。
  3. スーパーユーザーを選び、集中トレーニングを実施する。
  4. 導入後3〜6ヶ月は、KPIを監視しながら改善を続ける。

試験導入の対象には、ITツールへの親和性が高い担当者がいるラインや、例外の少ない標準的なラインが候補になります。初期の試験で成功体験を作れば、以降の導入を進めやすくなります。

マニュアルの配布や研修だけでなく、現場スーパーユーザー制度も設けます。担当者は、同僚の質問に答えつつ、開発会社と現場をつなぎます。さらに、運用で出た課題を集め、改善要望として開発側に伝えます。

KPIには、システム稼働率や実績入力率のほか、工程遅延発生件数、納期遵守率などがあります。目標に届かなかった指標は、原因を分析し、改善策を実行するPDCAを回します。継続的な改善によって、システムへの投資対効果を高められます。

ポイント

要件定義と段階導入の両方に現場の担当者を関わらせられるかが、定着の成否を分けます。最初から全要望を盛り込まず、MVPから段階的に広げるかどうかも判断の目安になります。

▼全体ガイドの記事
・工程管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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