MESのリニューアルのPoC・プロトタイプ・モックアップ開発について

MESのリニューアルにおけるPoC(概念実証)・プロトタイプ・モックアップ開発は、現場のオペレーターがその画面を迷わず、ミスなく、ストレスなく操作できるかを確かめることが主な目的です。技術の成立性や投資判断を見る他のPoCとは違い、現場での使いやすさを検証することに焦点があります。

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

▼全体ガイドの記事
・MESのリニューアルの完全ガイド

  • MESのリニューアルにおけるPoC・プロトタイプの位置づけ
  • 現場オペレーターを巻き込んだユーザビリティテストの進め方
  • 手袋操作・騒音環境・多品種少量生産の入力導線という、MES現場特有の検証観点

MESのリニューアルにおけるPoC・プロトタイプの位置づけ

MESのモダナイゼーション、刷新、更改、リニューアルにおけるPoCの検証目的を4つのパネルで示した図。
リニューアルでは現場の使いやすさが検証の中心になります。

リニューアルのPoCを設計する前に、なぜ現場での使われやすさの検証がPoCの主目的になるのかを、先に理解しておく必要があります。技術的にシステムが動くことや、経営的に投資対効果が見込めることは、他の3記事のPoCがすでに扱っているテーマです。そのうえでリニューアルでは、現場のオペレーターがストレスなく使いこなせるかという、それまで見落とされがちだった論点にPoCの重心を置きます。

技術検証・投資判断検証との違い(現場ユーザビリティが主目的)

「MESのモダナイゼーション」のPoCは技術検証で、5R(リホスト・リプラットフォーム・リファクタリング・リビルド・リプレース)のうちどのアプローチが最適かを見極めます。そこでは、正確性と堅牢性が優先されます。

一方で「MES刷新」のPoCは、生産実績データの精度や品質トレーサビリティの完全性がどれだけ改善するかを定量的に実証し、稟議を通すための説得材料を作ることが目的です。また「MES更改」のPoCは、契約満了・EOS/EOLという期限内に本開発を完了させられるという確証を得るための「保険」としての性格が強く、検証対象を絞り込むこと自体が正しい判断になります。

これに対してリニューアルのPoCは、ワイヤーフレームやプロトタイプの段階で、実際に現場のオペレーターに触ってもらう検証です。目的は、「どこで操作に迷うか」「どこでミスタップが起きるか」という体験そのものを、見えるようにすることにあります。この目的の違いを関係者間で最初に共有しておくことが、プロトタイプ検証の設計を誤らないための出発点になります。

ワイヤーフレーム・デザインカンプでの早期現場フィードバック

リニューアルのプロトタイプ検証は、実際に動作するシステムが完成してから行うのでは遅すぎます。ワイヤーフレーム(画面の骨組みだけを示した設計図)やデザインカンプ(見た目まで作り込んだデザイン案)の段階で、現場のオペレーターに実際の操作フローを見てもらい、フィードバックを得ることが重要です。

この早期のフィードバックがあれば、「この並び順だと入力しづらい」「このボタンの位置は誤タップしやすい」といった致命的な問題を、実装コストがまだかかっていない設計段階で見つけられます。そのため、開発着手後の大きな手戻りを防げます。逆に、デザインを確定してから現場へ持ち込み、初めて意見を聞く進め方は、リニューアルでは最も避けるべき進行順序です。

ポイント

リニューアルのPoCは、技術の動作や投資対効果を前提に、現場のオペレーターが迷わず使えるかを確かめる場です。判断に迷ったら、その画面を実機で現場の人に触ってもらえるかで見直すとよいでしょう。

現場オペレーターを巻き込んだユーザビリティテストの進め方

現場オペレーターのテストで、実務タスク、操作中の観察と記録、実機タブレットでの検証を確認する図。
操作中の迷いを記録すると具体的な改善につながります。

プロトタイプができたら、次は実際の現場オペレーターに使ってもらい、具体的なタスクを通じて課題を洗い出すユーザビリティテストに進みます。

タスクベースの操作フロー検証と「迷い」の観察記録

効果的なユーザビリティテストは、現場の実業務に即した具体的なタスクを設定して行います。たとえば「この製造ロットの実績を入力してください」「不良品を1件報告してください」といった形で依頼します。そのうえで、テストを実施する人は、オペレーターの手が止まった場所や、どのボタンを押そうか迷った場所、誤った画面に進んでしまった場所を注意深く観察し、記録します。

この「生の迷い」の記録は、開発後には得られない貴重な情報です。入力フォームの自動補完、エラー表示の分かりやすさ、頻出操作の簡略化といった具体的な改善策に直結します。さらに、テストの様子を録画・録音しておくと、後から複数人で見返して意見をそろえる際にも役立ちます。

実機タブレットでの操作性検証(PC画面のみのレビューの危険性)

オフィスの会議室でPC画面を見ながらデザインを承認するプロセスは、リニューアルでは大きな落とし穴になります。PC画面で「見やすい」「きれいだ」と判断されたデザインでも、現場の産業用タブレットに表示すると問題が出ることがあります。具体的には、ボタンが小さすぎて押しにくい、画面の反射で見えづらい、必要な情報が1画面に収まりきらないといった問題が、実機で初めて発覚することが少なくありません。

プロトタイプ検証は、必ず現場で使う予定の実機タブレットを用い、実際の生産ラインまたはそれに近い環境で実施することが不可欠です。また、共通のUIコンポーネントやデザインパターンを全画面で統一しておくことも、複数の画面を横断して使う現場オペレーターの学習コストを下げるうえで効果的な検証項目です。

ポイント

使いやすさは、新人からベテランまで複数名が同じ実務タスクを実機で行った結果をもとに判断すると、特定の人の好みに偏りにくくなります。

手袋操作・騒音環境・多品種少量生産の入力導線というMES現場特有の検証観点

MES現場特有の検証観点として、手袋操作、騒音環境の視覚的アラート、多品種少量生産の入力導線、バーコード/RFID連動を示す図。
現場の作業条件に合わせて画面と入力方法を確かめます。

MESの現場は、一般的なオフィス業務システムとはまったく異なる環境で使われます。そのため、生産ラインならではの検証観点を押さえておかないと、稼働後になって深刻な問題が発覚します。

手袋着用時のタッチ操作性検証と騒音環境での視覚的アラート検証

多くの製造現場では、安全のため作業中に軍手や厚手の保護手袋を着用しています。素手での操作を前提にデザインされた画面は、手袋をしたままだとタップの反応が悪くなり、誤操作が頻発する原因になります。

このため、プロトタイプ検証では、現場で実際に使っている手袋を着用したまま操作してもらうことが欠かせません。そのうえで、ボタンのサイズを通常より大きくする、ボタン同士の間隔(マージン)を十分に広く取るといった調整が必要かを、実機で確かめます。

あわせて、機械音が響く工場内ではエラー発生時の音声アラートが聞こえないことがあります。そのため、「画面全体を赤く点滅させる」「大きなアイコンでエラー箇所を強調する」といった視覚的なアラート表現が、騒音環境でも直感的に伝わるかを検証しておく必要があります。

多品種少量生産の入力導線とバーコード/RFID連動の検証

段取り替えが頻繁に発生する多品種少量生産のラインでは、品目や工程が切り替わるたびに手入力が必要な画面だと、現場の作業効率を大きく損ないます。そこでプロトタイプ検証では、バーコードリーダーやRFIDスキャンと連動して実績が自動で入力される導線が、実際の生産切り替えのタイミングでスムーズに機能するかを確かめます。

また、防爆・防塵環境が求められるラインでは、その環境基準を満たすハードウェアの画面サイズや解像度に、UIが正しく最適化されているかも実機で確認しておく必要があります。これらMES特有の検証観点を省略すると、開発自体は完了していても、現場で実際には使われないシステムになりかねません。

ポイント

画面の良し悪しは、手袋をはめた手、騒音のある現場、品種の切り替えが多い条件で操作できるかで判断します。オフィスでの見た目よりも、この条件での操作性を優先して見ます。

PoC実施体制・予算とスケジュールへの組み込み方

現場ユーザビリティを重視したPoCでも、体制と予算をあらかじめ決めておかないと、実施そのものがスケジュールを圧迫しかねません。

現場キーパーソン・保全担当を含めた実施体制

情報システム部門の担当者に加えて、実際に実績入力画面を使う現場オペレーターのキーパーソンを、新人からベテランまで幅広く選び、PoCの初期段階から巻き込んでおくことが欠かせません。さらに、PLCや現場設備との連携互換性を確かめられる保全担当者にも加わってもらいます。

特定の熟練オペレーターだけでテストを行うと、そのオペレーターには使いやすくても、新人や外国人技能実習生には分かりにくいUIになるおそれがあります。そのため、習熟度や言語背景の異なる複数名でテストを実施することが望まれます。

あわせて、複数シフトのうち特定の時間帯の担当者だけでテストを行うと、ほかのシフトに特有の課題(照明環境の違いなど)を見落とすおそれがあるため、留意が必要です。

無料トライアル・貸出端末の活用による予算圧縮

プロトタイプ検証用の産業用タブレットを、本番導入の前に台数分購入すると、想定外の予算がかかることがあります。多くのハードウェアベンダーやSaaS型MESには、検証目的の無料トライアルや貸出端末の制度が用意されているケースがあります。そこで、これらを積極的に活用すると、外部委託した場合のテスト運用費用を数十万円単位で圧縮できることがあります。

プロジェクト全体のスケジュールには、要件定義や設計工程とは別枠で、PoC・プロトタイプ検証の期間を明示的に組み込んでおきます。そのうえで、検証結果を踏まえて軌道修正できる余地を残しておくと、後戻りできない事態を避けやすくなります。

ポイント

体制は、習熟度の異なる現場の人と保全担当者を初期から加え、予算は無料トライアルや貸出端末を活用する前提で組んでおきます。

PoCを省略した場合のリスクと最低限の検証ライン

予算やスケジュールの制約から、PoC・プロトタイプ検証を省略・簡略化したくなる場面もあります。ただし、それによって後工程に持ち越されるリスクを正しく理解しておく必要があります。

本番稼働直前に発覚する「使われないシステム」リスク

プロトタイプ検証を省略・簡略化した場合に最も起こりやすい失敗は、稼働直後に現場から「使いにくい」という声が噴出し、オペレーターが独自のExcel管理や紙の記録に戻ってしまうことです。これがいわゆるシャドーIT化です。せっかく費用と期間をかけてUIを刷新しても、現場で実際に使われなければ、リニューアルの投資対効果はゼロに等しくなります。

特に、PC画面のレビューだけで承認を済ませた場合や、特定の熟練者の意見だけで全体の使い勝手を判断した場合には、稼働直前になって致命的な使いにくさが発覚しかねません。そうなると、大規模な作り直しが必要になるという最悪の事態を招くおそれがあります。

「これだけは省略できない」最低限の検証ライン

予算や期間がどれだけ限られていても、死守すべき検証ラインは3つあります。1つ目は、実際に現場で使う実機タブレットでの操作性を確認することです。PC画面のみでの承認は行わないことが前提になります。

2つ目は、手袋着用時のタッチ操作性を確認することです。現場で日常的に使われている手袋をはめた状態で、タップの精度を確かめます。3つ目は、新人から熟練者まで複数名によるタスクベースのユーザビリティテストで、特定の1人の意見だけで画面設計を確定しないことです。

これら3つを省くと、リニューアル後のMESが現場に定着せず、投資対効果そのものが実現しないおそれがあります。緊急性が高く検証期間を十分に取れない場合でも、この3つは短期間・小規模であっても必ず行ってから本番開発に進むことが、実務上の最低ラインです。

ポイント

PoCを省略するか迷ったら、稼働後に現場がExcelや紙へ戻るおそれがあるかを考えます。実機での操作性、手袋での操作、複数名のテストの3点は、期間が短くても残します。

まとめ

MESのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、位置づけや進め方を中心に、現場特有の検証観点、体制と予算、省略時のリスクまで解説しました。モダナイゼーションの技術検証、刷新の投資判断検証、更改の期限内リスク排除とは異なり、リニューアルのPoCは「現場で実際に使われる画面かどうか」を確かめることが目的です。

ワイヤーフレーム段階からの早期フィードバック、実機タブレットでの操作性確認、手袋や騒音といったMES特有の観点を押さえておくことが大切です。そのうえで、最低限の検証ラインを省かないことが、投資に見合う現場定着の要諦です。

▼全体ガイドの記事
・MESのリニューアルの完全ガイド

会社紹介

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

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

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

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

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

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