WPF初心者が挑んだタブレット用現場アプリ

はじめに

こんにちは！技術部の「さん」です

先日、工場現場で作業者が操作するタブレット向け「検査結果確認アプリ」のソースを、あらためて振り返る機会がありました。 

当時はWPFやMVVMパターンに触れた経験が浅く、手探りで開発を進めていた頃です。 

今回あらためてソースを見返してみると、10.5インチの小さなタブレット画面で、作業者が迷わず快適に使えるUIを目指して、いろいろと試行錯誤していたことが分かりました。

そこで今回は、当時どんなところで悩み、どのように対応していたのかを振り返りながら、タッチ操作の工夫やバーコードスキャナとの連携について紹介します。

そもそも、現場では何に困っていたのか

今回開発したのは、工場現場で使用する「検査結果確認アプリ」です。

現場では、検査結果を確認する際に、検査日付やロット・品番などを手掛かりに対象データを探す必要がありました。

そこで、作業者が現場で使いやすいように、検査日付から検索する方法と、ロット・品番をバーコードで読み取って検索する方法の2つを用意しました。

特にバーコード検索では、作業者が画面に文字を入力する手間を減らし、手元のハンディスキャナで読み取るだけで対象の検査結果を検索できるようにしました。

1. カレンダーが小さすぎて指で押せない問題

WPF標準の DatePicker を配置して実機タブレットで動かしてみると、ポップアップするカレンダーの日付マスが小さすぎて、指先でのタップがほぼ不可能という壁にぶち当たりました。

当時のソースを見返してみると、スタイルを調整するだけでは厳しいと判断し、XAMLのScaleTransformを使ってカレンダー全体を5倍に拡大する方法で対応していました。 

これでSurfaceの画面上でも指で日付を選択しやすくなりました。

また、主要なボタンのサイズも350×100px、DataGridの行の高さもMinRowHeight="90"に共通化し、現場での押し間違いを減らす設計にしています。

今あらためて見ると、かなり大胆な対応をしていたなと思いますが、当時は「実際に現場で指で押せること」を優先して試行錯誤していました。

2. 画面のどこにフォーカスがあってもバーコード入力を横取りする

ハンディスキャナからの入力（QRコード）を受ける際、「テキストボックスにフォーカスが当たっていないと読み取れない」状態では現場の作業効率が落ちてしまいます。

当時は、画面全体のイベント（PreviewTextInput / PreviewKeyDown）をフックし、フォーカス位置に関わらず入力を受け取ってViewModelのバッファへ渡す設計にしていました。 

今回あらためてこの部分を見返してみると、「フォーカスを意識せずにスキャンできるようにしたい」という、現場での使い勝手をかなり意識して実装していたことが分かります。

スキャナから送られてくる終端のEnterキーもe.Handled = trueで処理し、他のコントロールの誤作動を防ぎながら、スムーズに読み取れるようにしていました。

3. データ取得の工夫：非同期処理 × 正規表現でのログ判定 

スキャンしたコードを元に、無線LAN経由で検査PCの共有フォルダから該当のCSVログを取得します。

そのまま全検索を行うと通信遅延で画面が固まってしまうため、async/awaitで非同期化しつつ、データ判定のロジックにも工夫を入れていました。

このあたりも、今あらためてソースを見ると「単純にファイルを探す」だけではなく、現場の運用ルールをそのままプログラムに落とし込もうとしていた部分だと感じます。

① 正規表現による表記揺れ・連番のノイズ除去

ファイル名には20260216_W_MODELA_LOT12345(3).csvのように、再検査や追記時の連番括弧(3)が含まれる場合があります。

単純な完全一致検索ではヒットしないため、正規表現（Regex.Replace）を使って括弧部分を除去し、ベース文字列で比較する処理を挟んでいました。

今見るとシンプルな処理ですが、当時は実際のファイル名のパターンを確認しながら、「どうすれば検索条件と実ファイルをうまく紐付けられるか」を考えて実装していました。

② 条件に合致する「最新ログ」の自動抽出

 同一ロットのファイルが複数見つかった場合は、運用ルールに沿って「W検査（ダブルチェック）ログ ＞ 通常検査ログ」を優先。

さらに日付と連番の降順でソートし、「作業者が今見るべき本当の最新データ1件」をピンポイントで特定するようにしていました。

このあたりは、今の自分が見ると「こういう処理を書いていたのか」と少し懐かしく感じる部分でもあります。当時は一つひとつ手探りでしたが、現場で実際に使うことを考えながら、検索速度やログの選択ルールまで含めて実装していました。

当時を振り返って

あらためて昔のソースを見返してみると、WPFの作法に慣れていないなりに、「実際に現場で使う人がどう操作するか」をかなり意識して開発していたことに気付きました。

「デスクトップPC用の標準UI」と「現場でSurfaceタブレットを使って操作するUI」では、求められる設計が大きく違うことを、この開発を通して身をもって学びました。

当時はScaleTransformのような大胆な方法で必死に対応していましたが、現場の作業者から「画面が見やすくて押しやすい」と言ってもらえた時の達成感は、今の開発の大きなモチベーションになっています。

今あらためてソースを見返すと、「もっと別の書き方ができたかもしれない」と思う部分もあります。

それでも、当時の自分が何に悩み、何を考えて実装したのかを振り返ると、今の開発につながっている部分も多く、こうして昔のソースを見返してみるのもなかなか面白いものだと感じました。