設備保全管理システム（CMMS）開発のPoC・プロトタイプ・モックアップ開発について

設備保全管理システム（CMMS：Computerized Maintenance Management System）の開発では、いきなり本開発に着手する前に、PoC（実現可能性検証）やプロトタイプ、モックアップといった小さな試作・検証を挟むことの価値が、他の業務システム以上に大きくなります。理由は、CMMSが「現場・設備・データ」という三つの不確実な現物と向き合うシステムだからです。会計処理を扱う資産管理システムや、生産計画を組む生産管理システムであれば、業務ルールを机上で詰めれば実装の見通しはおおむね立ちます。ところがCMMSは、油や粉塵にまみれた現場で保全員が本当に入力を続けられるのか、古い設備からセンサーで意味のあるデータが取れるのか、といった問いに、実際に現場で試してみるまで答えが出ません。ここを検証しないまま本開発へ突き進むと、完成してから「現場で使われない」「予知保全のデータが取れない」という致命的な誤算に直面します。

本記事では、設備保全管理システム（CMMS）開発におけるPoC・プロトタイプ・モックアップに焦点を当て、三つの用語の違いと使い分け、予知保全の実現可能性を確かめるPoCの進め方、現場の保全員が本当に使えるかを確かめるUIモックアップの検証、業務フローを動かして確かめるプロトタイプの活用、そしてPoCの結果を本開発へと橋渡しする進め方までを、CMMS特有の観点から解説します。とりわけ、ボトルネック設備1台に絞った実証、既存設備やPLC・センサーからのデータ取得可否の検証、軍手や汚れた手でも操作できるワークオーダー入力UIの検証といった、CMMSならではの現場受容性・データ取得可能性の見極めを軸に整理します。設備を止めないための投資を無駄にしないために、本開発の前に何をどう確かめておくべきか――その判断軸を、失敗例も交えながらお伝えします。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・設備保全管理システム（CMMS）開発の完全ガイド

CMMSにおけるPoC・プロトタイプ・モックアップの位置づけ

PoC・プロトタイプ・モックアップは似た文脈で使われますが、検証する対象が異なります。これらを混同すると「何を確かめたいのか」が曖昧なまま試作だけが独り歩きし、時間と費用を浪費します。CMMS開発では、どの不確実性を潰したいのかに応じて、三つを適切に使い分けることが重要です。まずはそれぞれが何を検証する手段なのかを整理し、そのうえでCMMSにおいて事前検証の価値がなぜ特に高いのかを押さえておきましょう。

三つの用語は、検証の深さと対象で区別できます。モックアップは、画面のデザインや項目配置を実際の見た目に近い形で作った「静止画に近い試作」で、主に画面のわかりやすさや操作の流れをイメージ共有するために使います。プロトタイプは、実際に画面が動き、データを入力して次の画面に進めるといった「動く試作」で、業務の一連の流れを触って確かめるために使います。そしてPoC（Proof of Concept＝概念実証）は、そもそも技術的に実現可能かどうかを確かめる検証で、CMMSの場合は「このセンサーで狙った故障の予兆が本当に捉えられるか」「古い設備からデータを取り出せるか」といった、実現できるか否かが読めない部分を対象とします。CMMS開発では、画面の使い勝手はモックアップ、業務フローはプロトタイプ、予知保全やデータ連携の実現性はPoC、というように、不確実性の性質に応じて手段を選ぶことが、無駄のない検証につながります。

CMMSで事前検証の価値が高いのは、成否を分ける要因の多くが「やってみないとわからない」領域にあるからです。第一に、現場の受容性です。保全員が慣れ親しんだ紙と口頭のやり方から、モバイル端末での入力に移ってくれるかは、実際に現場で使ってもらうまで確信が持てません。第二に、設備からのデータ取得可能性です。予知保全を目指す場合、対象設備からセンサーで必要な精度のデータが取れるか、既存の制御装置と接続できるかは、現地で試すまで断言できません。第三に、故障予測の実現性です。センサーデータから故障の予兆を捉えられるかは、実際にデータを集めて分析してみて初めて評価できます。これらはいずれも、要件定義書をどれだけ丁寧に書いても机上では確かめられない不確実性であり、本開発に数千万円を投じる前に、小さな検証で潰しておく価値が非常に大きいのです。逆に、この検証を省くと、完成後に現場で使われない、データが取れない、という取り返しのつかない失敗につながります。

PoC：予知保全の実現可能性を確かめる

CMMSのPoCで最も重要になるのが、予知保全（CBM）の実現可能性検証です。振動や温度といったセンサーデータから設備の故障予兆を捉えるという構想は魅力的ですが、実際にそれが自社の設備で成り立つのかは、検証してみないとわかりません。ここでは、対象を絞った実証、データ取得の可否、そして予知保全PoC特有の落とし穴という三つの観点から、失敗しないPoCの進め方を見ていきます。

予知保全のPoCは、いきなり工場全体や複数設備で始めるのではなく、対象を1台に絞ることが鉄則です。選ぶべきは、止まると生産全体に大きな影響が出るボトルネック設備や、故障頻度が高くて損失の大きい設備です。こうした「効果が最も見込める1台」に的を絞ることで、限られた期間と費用で意味のある検証ができ、成功すれば横展開の説得材料にもなります。逆に、最初から欲張って多数の設備を対象にすると、センサー設置やデータ収集の手間が膨らみ、どの設備の検証も中途半端になりがちです。1台での実証を通じて、センサーの取り付け方、データの取り方、分析の勘所を掴み、そこで得た型を他設備へ広げていくのが、費用対効果の高い進め方です。PoCの段階では、成果を急がず「この設備で予知保全が成り立つかを見極める」という一点に集中することが、後の本開発の成否を左右します。

予知保全PoCの前半の山は、対象設備から必要な精度のデータを実際に取得できるかの検証です。新しくセンサーを後付けする場合は、振動や温度を狙った箇所に正しく取り付けられるか、必要なサンプリング頻度でデータを拾えるかを確かめます。既存の制御装置（PLC）やSCADAからデータを取り出す場合は、通信プロトコルが対応しているか、外部にデータを出す口があるかという「接続の壁」に直面することが少なくありません。古い設備ほど外部連携を想定しておらず、データを取り出すために追加のハードウェアや改造が必要になるケースもあります。この検証を怠ると、本開発の途中で「肝心のデータが取れない」という事態に陥り、計画全体が崩れます。PoCの初期段階で、対象設備から狙ったデータが、狙った精度と頻度で、無理なく取得できることを実機で確認しておくことが、予知保全を現実のものにする土台になります。

予知保全PoCで見落とされがちな、しかし極めて重要な落とし穴が「故障データが集まらない」という問題です。故障の予兆を学習で捉えるには、正常時のデータだけでなく、異常時・故障時のデータが十分に必要です。ところが、よく整備された優良な設備ほど滅多に壊れないため、PoC期間中に肝心の異常データがまったく集まらず、予測モデルを構築できないまま数ヶ月と数百万円を費やして終わる、という失敗が現実に起きています。これを避けるには、いくつかの工夫が要ります。過去の故障記録や振動データが残っていれば活用する、意図的に負荷をかけた試験で異常状態を再現する、あるいは同型設備の他社事例やメーカー提供の故障パターンを参照する、といった方法です。また、そもそも予兆が出やすい故障モードなのか（徐々に劣化する軸受けなどは予知に向くが、突発的に壊れる部品は向かない）を見極めることも大切です。予知保全は万能ではなく、対象と故障モードを選んで初めて成り立つことを、PoCの設計段階から意識しておく必要があります。

モックアップ：現場が本当に使えるUIを確かめる

予知保全の実現性と並んで、CMMSの成否を左右するのが現場の保全員が使うUIの受容性です。どれだけ機能が充実していても、現場で入力が続かなければデータは溜まらず、システムは形骸化します。だからこそ、本開発の前にモックアップで画面を現場に見せ、実際に触ってもらって「使えるか」を確かめることが欠かせません。ここでは、現場受容性の検証と、情報システム部門と現場の感覚のギャップという二つの論点を見ていきます。

CMMSのUIモックアップ検証は、事務所の快適な環境ではなく、実際の現場条件で行うことが肝心です。保全員は、軍手をはめたまま、あるいは油で汚れた手で、明るさや騒音が一定でない現場でタブレットを操作します。この条件下で、点検結果の入力や使用部品の登録、ワークオーダーの完了報告が、迷わず数タップで行えるかを確かめる必要があります。ボタンは手袋でも押せる大きさか、入力項目は最小限に絞られているか、片手で持って操作できるか、屋外や暗所でも画面が見えるか――こうした細部が現場での定着を決めます。モックアップの段階で実際の保全員に触ってもらい、「どこで迷ったか」「何が面倒か」を率直に聞き出すことで、本開発前にUIを現場基準へ作り込めます。ここで得たフィードバックは、机上の設計では決して得られない、CMMSを使われるシステムにするための最も貴重な情報になります。

UIモックアップ検証で必ず意識すべきなのが、システムを選ぶ側と使う側の感覚のずれです。よくある失敗に、情報システム部門がPCの画面上で「見やすくて使いやすい」と判断して選んだUIが、現場のタブレット端末ではボタンが小さすぎて手袋では押せず、結局現場が紙のメモに戻ってしまう、というものがあります。PCの大きな画面と、現場の小さなタブレット、しかも手袋越しの操作とでは、使いやすさの基準がまったく異なります。このギャップを埋めるには、UIの評価を情報システム部門だけで完結させず、必ず実際に使う現場の保全員を検証に巻き込むことが不可欠です。モックアップを現場に持ち込み、普段の作業の流れのなかで試してもらえば、机上では気づけない問題が次々と見えてきます。CMMSは「導入を決める人」と「毎日使う人」が異なるシステムだからこそ、使う人の視点でUIを検証し、現場が納得して使える形に仕上げてから本開発へ進むことが、投資を無駄にしないための要となります。

プロトタイプ：業務フローを動かして確かめる

モックアップが個々の画面を確かめる手段なら、プロトタイプは業務の一連の流れを動かして確かめる手段です。CMMSは、点検の計画からワークオーダーの発行、現場での作業、実績の記録、そして次の計画への反映という一連のサイクルで回るため、画面単体では問題なくても、つないで動かすと業務が回らないことがあります。動くプロトタイプで一連のフローを試すことで、こうした流れの詰まりを本開発前に発見できます。

プロトタイプで確かめたいのは、予防保全の計画からワークオーダーの発行、作業員へのアサイン、現場での実施、実績（使用部品・作業時間・停止時間）の記録、そしてそのデータが次の計画やKPIに反映されるまでの一連のサイクルが、実際の保全業務の実態に沿って自然に流れるかどうかです。たとえば、点検スケジュールから自動でワークオーダーが起票され、適切なスキルの作業員に割り振られ、完了報告が上がって履歴に残る、という流れを動くプロトタイプで一通り回してみます。ここで、現場の実際の段取りと画面の流れが合わない、入力項目が多すぎて作業の妨げになる、承認のステップが現場の指揮系統と噛み合わない、といった問題が見えてきます。こうした業務フロー上の詰まりは、静止画のモックアップでは気づきにくく、実際に動かして初めて表面化します。本開発の前にプロトタイプでサイクルを回し、現場の運用に馴染む形へ整えておくことが、稼働後の手戻りを大きく減らします。

プロトタイプやPoCの段階で、既存システムや設備との連携を技術的に検証しておくことも重要です。CMMSは単独で完結するより、生産管理システムやMES、あるいは在庫・購買システムと連携することで価値が高まります。たとえば、設備の稼働・停止信号を制御装置から取得できれば、保全員が手入力しなくてもMTBFやMTTRを自動で算出でき、生産計画と連携すればライン停止の少ないタイミングで予防保全を組めます。しかし、これらの連携は現場の実機やシステムの仕様に依存するため、机上の想定どおりにいくとは限りません。連携の要となる部分は、プロトタイプで実際にデータをつないでみて、想定した形で取得・連携できるかを早めに確認しておくべきです。連携先が多岐にわたる場合は、まず効果の大きい一つに絞って技術検証を行い、成立を確認してから範囲を広げるのが堅実です。ここでの検証結果が、本開発の連携スコープと見積もりの精度を大きく左右します。

PoCを成功させ本開発へつなげる進め方

PoCやプロトタイプは、実施すること自体が目的ではなく、本開発の判断材料を得るための手段です。ところが、目的や評価基準を決めないまま始めてしまい、「なんとなくやってみた」で終わって次につながらないケースが後を絶ちません。ここでは、PoCを確実に成果へつなげるための進め方を、事前の設計と本開発への橋渡しという二つの観点から整理します。

PoCを始める前に、「何を確かめたら成功とするか」という評価基準と、「どこまでで見切りをつけるか」という撤退基準を明確に定めておくことが、最も大切な準備です。たとえば予知保全のPoCなら、「対象設備から必要精度のデータが取得でき、過去または試験で得た異常データから一定以上の精度で予兆を検知できること」を成功基準に据えます。同時に、「一定期間データを集めても異常が発生せず、外部データでも代替できない場合は予知保全の対象から外す」といった撤退基準も決めておきます。この基準がないと、成果が出ないPoCをずるずると続けて費用を浪費したり、逆に曖昧な手応えだけで本開発に進んで後で行き詰まったりします。期間・予算・体制も含めて、PoCを小さく区切って設計し、終了時に明確な判断ができる形にしておくことが、限られた投資で最大の学びを得るための鍵です。

PoCやプロトタイプで得た学びは、本開発の要件と見積もりの精度を高める形で活かしてこそ意味があります。1台の設備で予知保全が成り立つと確認できたなら、その型を何台に広げるとどれだけのセンサー・通信・分析のコストがかかるかを試算でき、投資対効果の見通しが立ちます。現場でUIを検証して改善点を洗い出せたなら、本開発ではそれを反映した画面仕様から着手でき、手戻りを減らせます。業務フローや連携をプロトタイプで確認できたなら、本開発のスコープと難所が明確になり、より確度の高い見積もりが可能になります。逆に、PoCの結果を報告書に残すだけで本開発の要件に反映しなければ、せっかくの検証が無駄になります。PoCの終了時には、得られた事実と数値を整理し、本開発の対象範囲・優先順位・概算費用へと具体的に落とし込むところまでを一続きの活動として設計することが、CMMS導入を成功に導く進め方です。

まとめ

本記事では、設備保全管理システム（CMMS）開発におけるPoC・プロトタイプ・モックアップを、用語の使い分けから予知保全の実現性検証、現場UIの受容性検証、業務フローの試行、そして本開発への橋渡しまで、CMMS特有の観点で整理しました。CMMSは「現場・設備・データ」という机上では確かめられない不確実性を抱えるため、本開発に大きな投資をする前に、小さな検証でこれらを潰しておく価値がとりわけ大きいシステムです。予知保全はボトルネック設備1台に絞って実現性とデータ取得可否を確かめ、故障データが集まらない落とし穴に備える。UIは実際の現場条件で保全員に触ってもらい、情シスと現場の感覚のギャップを埋める。業務フローと連携はプロトタイプで動かして詰まりを見つける。そして、目的と撤退基準を先に決め、得られた学びを本開発の要件と見積もりに橋渡しする――この一連の流れを踏むことで、CMMSは「作ったが使われない」失敗を避け、確実に現場で機能するシステムへと近づきます。導入を検討される際は、まず小さなPoCから始めることを、経験ある開発パートナーとともに検討することをお勧めします。

▼全体ガイドの記事
・設備保全管理システム（CMMS）開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。