業務システムの使いにくさを減らすUI/UX改善：現場定着を左右する設計原則

UIは、利用者が画面の表示・入力・操作・処理の状態を認識し、操作する接点です。UXは、利用者が業務の目的を達成するまでの過程で生じる体験です。業務システムでは、見た目の美しさに加えて、利用者が必要な入力と操作を終え、結果を正しく理解し、次の業務へ渡せるかを改善の対象にします。

ユーザビリティは、利用者にとっての有効性・効率性・満足度などの観点から評価されます（デジタル庁：ユーザビリティ導入ガイドブック PDF p.11、確認日：2026年10月21日）。業務の言葉に置き換えると、「申請を正しく完了できたか」「余計な手間や時間がかからなかったか」「不安や不満なく使えたか」です。

同じシステムでも、申請者・承認者・管理者では、目的、使う頻度、権限が異なります。使いにくさの原因が画面にあるとは限らず、承認の段階や社内ルールの分かりにくさ、権限の設定、処理の遅さが原因のこともあります。入力画面の改修で直すこと、業務手順を見直すこと、権限や性能を直すことを切り分け、全面的な作り直しを前提にせずに対象を決めます。業務フロー全体の見直しは、POA（プロセス指向アプローチ）の記事で扱っています。

「使いにくい」という声は、困っている場面ごとに分け、何を確かめるかを決めてから改善案を考えます。次の表は、症状から原因の仮説を立てるための確認票の例です。原因を断定するものではなく、担当は役割の例です。

表は横にスクロールできます →

差し戻しのように、画面ではなく業務のルールや承認の条件が原因の場合は、画面の改修だけでは解決しません。確かめた結果は、事実と仮説を分けて記録します。

フォームでは、必要な項目と入力の条件を先に伝え、誤りがあれば場所と直し方を示し、操作の結果が分かるようにします。次の3つは、業務システムで起きやすい困りごとと、改善案・確認方法の例です。

入力中に誤りを示す方法は役立つ場合もありますが、日付のように入力途中の値が常に誤りに見える項目では、入力後に確認する方が合うことがあります（WAI：User Notifications）。全角・半角などの形式をそのまま受け付けるかは、項目の意味と保存の条件から決め、識別子やパスワードまで一律に変換しません。画面での確認とは別に、サーバー側でも入力を検証します（WAI：Validating Input、いずれも確認日：2026年10月21日）。

ボタンの連打を防ぐだけでは、二重の登録を防げたことになりません。サーバー側での二重処理の対策と再試行の条件は、APIファースト開発の記事で扱っています。また、WCAG 2.2の3.3.4（レベルAA）は、法的な約束や金銭の取引、利用者のデータの変更・削除を伴う操作について、取り消し、入力の確認と修正、送信前の確認のいずれかを用意することを求めています（WCAG 2.2：Error Prevention）。

アクセシビリティでは、障害のある人や支援技術を使う人を含め、対象の利用者が使う端末と操作方法で、入力・操作・結果の確認ができるかを確かめます。業務システムでよく確認する観点は次のとおりです（WCAG 2.2の該当項目、確認日：2026年10月21日）。

• 文字のコントラスト：1.4.3（レベルAA）では、通常の文字は背景との比を4.5:1以上、大きな文字は3:1以上とし、操作できない状態の部品の文字やロゴなどは対象外です（WCAG 2.2：Contrast (Minimum)）。すべての要素に一律に4.5:1が求められるわけではありません。
• 押す対象の大きさ：2.5.8（レベルAA）は原則24×24 CSS px以上で、周囲に十分な間隔がある場合などの例外があります（WCAG 2.2：Target Size (Minimum)）。44×44 CSS pxは2.5.5（レベルAAA）の基準です（WCAG 2.2：Target Size (Enhanced)）。対象の端末で押し間違えないかも確かめます。
• キーボード操作とフォーカス：Tabキーで移動できるだけでなく、すべての機能をキーボードで実行・選択できるか（2.1.1、Keyboard）、フォーカスの位置が見えるか（2.4.7、Focus Visible）、固定表示のヘッダーなどでフォーカスが完全に隠れないか（2.4.11、Focus Not Obscured (Minimum)）を確認します。2.4.11（レベルAA）は一部が隠れることを許していますが、見やすさのためには隠れない設計が望ましいとされています。
• ラベル・説明・エラーの関連付け：ラベルと入力欄を関連付け、色だけに頼らずに必須やエラーを伝えます（WAI：Labeling Controls）。
• 処理の状態の通知：保存の完了やエラーの件数などの状態の変化は、画面に読み込み中の表示や短い通知が見えるだけでなく、スクリーンリーダーなどの支援技術にも伝わるようにします（4.1.3、Status Messages）。

これらは確認の観点の一部です。WCAGへの適合はページ全体と一連の手続き全体で判断されるため（WCAG 2.2：Conformance Requirements）、この記事の確認項目を満たしただけで、WCAGやJISに適合しているとはいえません。

改善を確かめる指標は、何を開始・完了とするかを決め、同じ条件で比べます。次の表は、この記事で使う数え方の例です。すべてのシステムに共通する標準の式ではないため、自社の業務に合わせて定義を決めます。

表は横にスクロールできます →

比べるときは、利用者の役割と習熟度、課題、端末、データ、システムの版、開始・完了・中断の条件、助言の有無、上限時間、記録の漏れをそろえます。完了したと思ったのに実際は完了していない場合も記録し、数字に加えて、難しさや自信など利用者の声も確認します（GOV.UK：Usability benchmarking、確認日：2026年10月21日）。少人数の観察は問題と原因の手がかりを見つけるためのもので、全利用者での改善率を示すには、条件をそろえた量的な比較が別に必要です（デジタル庁のガイドブック PDF p.43）。指標の定義と集計の条件をそろえる考え方は、データ分析基盤の記事でも扱っています。

ユーザビリティテストでは、対象の業務と完了の条件を決め、実際の利用者や利用が見込まれる人に、答えを示さない課題で操作してもらい、観察した事実と原因の仮説を分けて記録します。進め方の例は次のとおりです（GOV.UK：Moderated usability testing、確認日：2026年10月21日）。

1. 対象の業務、利用者、完了の条件を決める。
2. 参加の同意、記録する範囲、試験の条件（端末・データ・版・上限時間）を決める。
3. 答えを示さない課題を出し、操作を観察する。
4. 観察した事実と、原因の仮説を分けて記録する。
5. 業務への影響、頻度、元に戻せるか、改修の工数から、暫定の優先度を決める。
6. 試作と受入の条件、担当を記録し、同じ条件で再確認する。

人数は固定せず、対象の役割と目的から決めます。少人数のテストを繰り返す考え方が知られていますが、その数値には前提となるモデルと条件があり、申請者と承認者、初めての人と慣れた人、支援技術を使う人など、利用者のグループごとに分けて確かめる必要があります（NN/g：Why You Only Need to Test with 5 Users、デジタル庁のガイドブック PDF p.44）。

以下は数え方を説明する仮の記録です。備品購入申請の画面を、申請者6名が同じPC・同じ版・同じ仮の入力内容で各1回操作した想定です。開始は課題の説明を終えて操作を始めた時点、完了は「申請を送信し、受付番号と承認待ちの状態を確認したこと」とし、助言はせず、上限は600秒としました。下書きの保存だけで終えた場合は未完了とし、承認されたかどうかは別の業務段階として扱います。

表は横にスクロールできます →

この記録では、完了率は4/6（約66.7%）、修正・助言なしの完了率は2/6（約33.3%、AとD）、入力エラーがあった試行は3/6（50%、B・C・F）です。完了した4件の時間は、平均が(180+240+300+360)÷4＝270秒、中央値も270秒です。未完了のCとEは、それぞれ600秒・210秒として別に残し、0秒にしたり完了した人の時間に混ぜたりしません。承認側の確認と問い合わせは記録していないため、差し戻し率と問い合わせは未確認とし、0件とは書きません。6名はこの例の件数で、推奨する人数や全利用者を代表する根拠ではありません。

観察から、改善案と次回の確認条件を次のように整理します。

表は横にスクロールできます →

出現回数が少ない段階で順位を固定せず、業務への影響と元に戻せるかを含めた暫定の優先度とします。改善後の数値は、次回に同じ条件で確認してから記録します。改善の記録として残すのは、対象の業務と完了の条件、観察の記録、原因の仮説と優先度、試作の案、受入の条件・担当・再確認の予定です。

改善を始める前に、分かる範囲で次の点を確認します。すべてに当てはまっても、使いやすさが保証されるわけではありません。未確認の項目は、担当と確認の時期を決めて残します。

社内や外部に相談するときは、困っている操作、使う人、今の手順、変えられる範囲を分かる範囲でまとめておくと、整理を進めやすくなります。資料や要件がそろっていなくても、ご相談いただけます。非公開の画面、個人情報、パスワードを相談フォームに書いていただく必要はありません。