Summary

この文書の要点

どこが設計の難所か

Accessなどのデスクトップ画面をWeb化する時、モダンなカードUIに置き換えると、現場の入力速度が落ちることがあります。旧画面の課題は見た目だけではなく、検索、入力、一覧性、ショートカットが一体になっている点にあります。

Webアプリでは画面幅、ブラウザ操作、通信遅延、権限、同時編集を考える必要があります。デスクトップアプリと同じ密度をそのまま再現すると、レスポンシブ対応や保守が難しくなる場合があります。

Accessや古い業務画面は見た目こそ古くても、入力担当者にとっては速い場合があります。タブ移動、Enter確定、前行コピー、連続登録、即時検索のような操作感を失うと、Web化したのに現場の速度が落ちます。

まず、利用者が一日の中で繰り返す操作を観察し、検索から入力、確認、保存までの最短経路を定義します。一覧、詳細、編集を完全に分けるのではなく、必要に応じて分割ペインやインライン編集を使います。

設計では、見た目の再現より入力フローを分解します。どの項目が連続入力され、どのタイミングで検証し、どのエラーなら次行へ進ませないかを決めます。ReactではテーブルUIではなく、入力状態を持つグリッドとして考える方が扱いやすくなります。

Reactでは、フォーム状態、保存済み状態、選択行、検索条件を分けます。キーボード操作、フォーカス移動、保存時の楽観更新、入力エラーの表示位置を設計します。大量データではページングだけでなく、検索条件の保持も重要です。

実装では、行ごとにdraft、validating、saving、saved、errorを持たせます。フォーカス移動、ショートカット、候補検索はUIコンポーネントに閉じず、入力コントローラとして共通化すると、画面が増えても操作感を揃えやすくなります。

検証では、マウスを使わずに主要操作ができるか、旧画面と同じ件数を処理する時間が極端に伸びないかを確認します。E2Eでは保存、検索、エラー修正、権限不足を流れで見ると実用性が分かります。

検証では、フォーム単体の正しさより、100件を連続入力した時の操作回数、フォーカス迷子、保存失敗時の復帰を見ます。Playwrightでキーボード操作をシナリオ化すると、見た目では分からない速度低下を検出できます。

高密度UIは学習済み利用者には速い一方で、初めての人には難しくなります。利用頻度の高い担当者向け画面と、たまに使う管理画面でUI密度を変える判断も必要です。

Web標準に寄せると保守しやすい一方、業務入力の速度が落ちることがあります。独自ショートカットを入れすぎると学習コストが上がります。頻度の高い操作だけを優先し、低頻度操作は標準UIに寄せる判断が必要です。

業務画面のWeb化では、古い画面をきれいにするだけでは不十分です。速さを生んでいた操作の構造を残し、Webならではの権限管理と検証を加えることが移行成功の鍵になります。

高速入力画面のWeb化は、古い画面の刷新ではなく、熟練した操作の移植です。Reactで状態を細かく分けると、速さと安全性を同時に設計できます。