「使われていない」は3つの症状で検出できる
現場端末が使われているかどうかは、アンケートを取る前にログで判定できます。次の3つが検出できたら、UIの設計に問題があると考えてください。
- 入力の時刻が偏っている。 実績入力の時刻分布がシフト終了前30分に集中している場合、作業のたびに入力するのではなく、紙やメモから後でまとめて転記しています。この状態では、実績データはリアルタイムの意思決定に使えません
- 既定値がそのまま確定されている割合が高い。 停止理由や不良区分で、リストの先頭または前回値がそのまま選ばれている割合が7割を超えるなら、選択肢が実態と合っていないか、選択操作が重すぎます
- 1件あたりの入力所要時間の分散が大きい。 同じ画面の入力に10秒で終わる人と2分かかる人がいる場合、画面の構造が「慣れた人だけが速く操作できる」形になっています
3つとも、稼働後すぐにログから取得できます。導入時にこの3指標を測る仕組みを組み込んでおくと、定着の議論が主観から外れます。定着そのものの進め方はチェンジマネジメントの記事で扱います。
現場端末の設計制約は、5つの物理条件で決まる
オフィス向けの画面設計をそのまま現場に持ち込むと、ほぼ確実に失敗します。理由は好みではなく、現場の物理条件です。
| 物理条件 | 生じる制約 | 設計への反映 |
|---|---|---|
| 手袋を着けている | 静電容量式タッチの精度が落ちる。細かいタップができない | タップ対象は最低でも指1本分の面積を確保。隣接ボタンの間隔を広く取る |
| 立位で、視距離が遠い | 小さい文字が読めない。スクロールに手が届きにくい | 本文の文字サイズを大きく取り、1画面で完結させる。スクロール前提の画面を作らない |
| 照度が極端（直射日光／暗所） | コントラストの低い配色が判読不能になる | 色だけで状態を区別しない。形・文字・位置を併用する |
| 手が汚れている・両手がふさがる | そもそも画面に触れられない場面がある | スキャナ・フットスイッチ・音声など、タッチ以外の入力経路を1つ用意する |
| 通信が不安定 | 送信の途中で切れる。画面が固まる | オフラインでの入力保持と、再接続時の自動再送。二重登録を防ぐ冪等性の設計 |
この5つは、画面デザインの前に確認する項目です。設置場所を実際に見ずに画面設計を始めたプロジェクトは、必ず作り直しになります。要件定義の段階で、対象工程の端末設置予定位置を全数まわり、上の5項目を現地で記録してください。
1作業あたりの操作回数に予算を設ける
現場UIの設計でもっとも効果があるのは、1作業あたりの操作回数に上限を設けることです。予算として先に決め、その中で画面を設計します。
予算を守るために削れるのは、次の3つです。
- ログイン：ICカードやNFCで1操作にする。工程ごとの再ログインは原則なくす
- 対象の特定：指図番号・品目・工程を人に選ばせず、バーコードやRFIDのスキャン1回で決める。方式の選び方はバーコード・RFID・画像認識の記事で扱います
- 確認画面：取り消し可能な操作に確認画面を挟まない。取り消せない操作にだけ確認を入れる
逆に削ってはいけないのが、入力エラー時のリカバリ操作です。誤入力の取り消しが3操作以上かかると、現場は「間違えたくないから入力しない」という行動を取ります。
「入力させない」は最終手段ではなく第一手段
操作回数を減らす最短経路は、画面を工夫することではなく、そもそも人に入力させないことです。優先順位は次のとおりです。
- 設備・測定器から自動取得する。 生産数、良品数、停止の開始終了、測定値。ここが自動化できれば、入力の大半が消えます
- スキャンで決める。 指図、品目、ロット、作業者、設備。人が選ぶのではなく読ませます
- マスタから導出する。 標準時間、工程順、検査項目は入力ではなく参照です
- どうしても人の判断が必要なものだけを入力させる。 不良の現象、停止の理由、特記事項
Rockwellが17カ国1,560名を対象に行った調査（2026年7月公表）では、43%が自社のデータを効果的に活用できていないと認識しています。データが集まらない原因の一部は分析側ではなく、現場での入力設計にあります。人に打たせる項目が多いほど、入力の欠落と精度低下が起き、その先の分析が成立しなくなります。
端末形態は、作業者の移動量で選ぶ
端末の形態は好みではなく、作業者が1シフトでどれだけ移動するかで決まります。
| 形態 | 向く条件 | 注意点 |
|---|---|---|
| 据置端末（工程横に固定） | 作業者が持ち場から動かない。連続的に入力が発生する | 台数が工程数だけ必要。設置場所の確保と配線 |
| タブレット（可搬） | 複数工程を1人が担当。図面や手順の閲覧が多い | 落下・防塵防水の等級、充電運用、置き場所の確保 |
| ハンディ端末・スキャナ | 移動が多く、入力はスキャン中心 | 画面が小さいため閲覧用途には不向き。用途を絞る |
| ウェアラブル（リング型スキャナ等） | 両手を使う作業で、スキャン頻度が高い | 対応する業務が限定的。導入前に実機での検証が必須 |
現実には複数形態の併用になります。その際に必ず決めておくのは、どの機能をどの形態で提供するかです。全機能を全端末に載せると、小さい画面に無理やり詰め込んだ画面ができあがります。据置端末には手順閲覧と例外処理、ハンディには実績とスキャンといった役割分担を、要件定義の段階で決めてください。手順の表示設計は電子作業手順書の記事、モバイル固有の実装はモバイル・ハンディ端末対応の記事で扱います。
稼働後3か月で必ず見直す前提で作る
現場UIは、一度で正解にたどり着きません。設計時点でどれだけ現場を観察しても、実際の運用でしか見つからない問題が必ず出ます。したがって、プロジェクト計画に稼働後3か月時点でのUI見直し工数をあらかじめ確保してください。
見直しの入力は、冒頭で挙げた3つの症状（入力時刻の偏り、既定値そのままの割合、所要時間の分散）と、実際の操作ログです。要望のヒアリングだけで見直すと、声の大きい人の意見に引きずられます。ログで問題箇所を特定し、その画面についてだけ現場に聞く、という順序が有効です。
この見直し工数を確保していないプロジェクトでは、「不便だが我慢して使う」状態が固定化します。そして数年後、次のシステム更新の検討時に「前のMESは現場に不評だった」という評価だけが残ります。
よくある質問
現場から「前の紙のほうが速かった」と言われます。どう対応すべきですか？
まずその主張が正しいかを実測してください。同じ作業を紙と端末の両方で行い、操作回数と所要時間を計測します。多くの場合、現場の指摘は正しく、端末のほうが遅くなっています。その場合は運用でカバーするのではなく、設計を直す対象です。逆に実測で端末のほうが速い場合、問題は速度ではなく習熟や画面の分かりにくさにあるため、対処法が変わります。いずれにせよ、実測なしに議論すると結論が出ません。
多言語対応が必要な現場では、UI設計で何を追加で考慮しますか？
文字数の増減に耐えるレイアウトが必要です。日本語で4文字のボタンラベルが、英語やポルトガル語では20文字を超えることがあります。固定幅のボタンに文字を詰め込む設計は、翻訳時に破綻します。加えて、色とアイコンの意味が文化圏で異なる場合があるため、状態表示は色だけに依存させないでください。数値と単位の表記形式（小数点、桁区切り、日付）も、言語ではなくロケール単位で切り替えられる設計にしておく必要があります。
画面設計をベンダーに任せてよいですか？
標準画面をそのまま使うこと自体は推奨されます（過度なカスタマイズは保守負担になります）。ただし、この記事で挙げた5つの物理条件と操作回数の予算は、発注側が要件として提示すべき項目です。ベンダーは自社製品の標準的な使い方は知っていますが、貴社の設置場所の照度や手袋の種類は知りません。要件定義書に「手袋着用時に操作可能であること」「定型作業の実績入力は3操作以内であること」と具体的に書いておくと、提案段階でこの制約が考慮されます。
