業務システムのUIデザイン｜使いにくい管理画面を改善する進め方と外注のチェックリスト【2026年版】

業務システムのUIデザインとは、社員や取引先が毎日使う入力・検索・承認・集計などの画面を、業務の手順に合わせて「速く・間違えずに」操作できるように設計することです。Webサイトのデザインと違い、良し悪しは見た目の印象ではなく、1件の処理にかかる操作の手数と、入力ミス・問い合わせの件数で決まります。

そのため、UIの改善を外注する前に「どの業務の、どの画面で、時間とミスが出ているか」を社内で洗い出しておくことが、見積もりと成果をぶらさない一番の近道です。この記事では、Web制作とシステム開発の両方を手がける立場から、業務システムのUIを改善するときの判断の物差し、発注前の準備、進め方、外注先の選び方を、チェックリスト形式でまとめます。UIデザインそのものの基本は「UIデザインとは？」で解説しています。

この記事で分かること

• 業務システムのUIが、ホームページやLPのUIとどこが違うのか
• 「使いにくい」を、JIS規格の7つの原則で具体的な症状に言い換える方法
• 制作会社へ依頼する前に、社内で用意しておくべき5つの材料
• 改善の進め方と、外注先を選ぶときのチェックリスト

先に結論: 業務システムのUI改善は「全画面を一新する」より、「処理件数が多く、ミスが出ている画面から順に直す」方が成果が出やすい進め方です。そのために、発注前に現場の業務と数字を集めておきましょう。

業務システムのUIが、WebサイトのUIと違う4つの点

業務システム・管理画面・基幹システムの画面は、同じ「UIデザイン」でもホームページとは前提が大きく異なります。発注者がこの違いを知っておくと、制作会社の提案が業務システムに向いているかを見分けやすくなります。

特に見落とされやすいのが「慣れた人」と「新人」の両方が使う点です。ベテランはキーボードだけで素早く入力したい一方、新人は画面を見ただけで次に何をすればいいかを知りたい。どちらか片方に寄せた設計は、もう片方の生産性を落とします。

「使いにくい」を具体的な症状に言い換える

「システムが使いにくい」という声は、そのままでは制作会社に伝わりません。改善の対象を決めるには、症状として書き出すのが有効です。現場でよく聞く症状を、チェックリストにしました。

• 同じ内容を、別の画面やExcelにもう一度入力している
• システムとは別に、Excelや紙のメモで管理している情報がある
• エラーが出ても、どの項目をどう直せばいいかが表示されない
• 入力の途中で画面を離れると、それまでの入力が消える
• 毎回同じ検索条件を入れ直している（条件を保存できない）
• 「保存」と「確定」「送信」の違いが分からず、問い合わせが来る
• 確認ダイアログが多すぎて、内容を読まずに「OK」を押す癖がついている
• 取り消し・差し戻しができず、間違えると管理者に頼むしかない
• 薄いグレーの文字や小さな文字が読みにくいと言われる
• マニュアルを見ないと操作できない画面がある

チェックが多い画面ほど、改善の効果が大きい画面です。次の節で紹介するJIS規格の原則と突き合わせると、なぜ使いにくいのかを説明できるようになります。

改善の物差し：JIS Z 8520の7つのインタラクションの原則

業務システムのUIを評価する公的な物差しとして使いやすいのが、日本産業規格の JIS Z 8520:2022「人間工学―人とシステムとのインタラクション―インタラクションの原則」 です。国際規格ISO 9241-110:2020に対応し、2022年3月22日に改正されました*1。規格は7つの原則を示し、附属書に推奨事項を適用するためのチェックリストも載せています。

7つの原則を、業務システムで確認したい具体例と対応づけると次のとおりです（原則の名称は規格の目次どおり、確認例は業務システムに当てはめた例です）。

前の節のチェックリストで当てはまった症状が、どの原則に当たるかを書き添えておくと、制作会社との打ち合わせで「なぜ直すのか」がぶれません。あわせて、Webの世界で広く使われているNielsen Norman Groupの「10のユーザビリティ・ヒューリスティクス」（1994年公開、2024年1月最終レビュー）も、専門家が画面を点検するときの観点として使われます*2。原則の考え方は「UIデザインの原則」でも紹介しています。

発注前に社内でやっておく5つの準備

制作会社に「使いやすくしてほしい」とだけ伝えると、提案は見た目の刷新に寄りがちです。次の5つを用意しておくと、見積もりの精度と提案の質が上がります。

1. 対象業務と画面の棚卸し: どの業務（受注登録、在庫確認、請求書発行など）で、どの画面を使っているかを一覧にする。画面ごとに「1日に使う回数の目安」を書く
2. ロール（権限）の一覧: 担当者・承認者・管理者など、誰がどの画面で何をするか。ロールごとに見える項目が違う場合はそれも書く
3. 現状の計測: 代表的な業務を1件処理するのにかかる時間、差し戻しや入力ミスの割合、システムに関する社内問い合わせの多い項目。改善後に同じ方法で測れば、効果を％で比べられる
4. 現場の声と、併用しているExcel・メモ: システムの外で管理している情報は、画面に足りない項目や機能の手がかりになる。実物のファイルを（個人情報を伏せて）集めておく
5. 変えられない制約: 他システムとのデータ連携、帳票のレイアウト、法令で保存が必要な項目、ブラウザやPCの環境など。UIだけを変えられる範囲を先に把握しておく

要件を文書にまとめる方法は「RFPの書き方」が参考になります。業務システムの場合は、上の5つをRFPの「現状と課題」の欄にそのまま入れられます。

UI改善の進め方：6つのステップ

業務システムのUI改善は、一般に次の順番で進めます。RINIAのUIデザインサービスでも、要件確認→情報設計→ワイヤーフレーム→ビジュアルデザイン→プロトタイプ→デザインの引き渡しという流れで進めており、業務システムでは各段階に「現場での確認」を挟むのがポイントです。

1. 現状の評価: 前の節の準備物をもとに、専門家がJIS Z 8520の原則やヒューリスティクスで画面を点検し、問題点と影響の大きさを一覧にする
2. 優先順位づけ: 「使う回数が多い × ミスや時間のロスが大きい」画面から着手する。全画面を一度に変えない
3. 情報設計とワイヤーフレーム: 業務の流れに沿って、項目の並び・画面の分け方・一覧と詳細の関係を決める。この段階で現場の担当者に見てもらう
4. プロトタイプで現場テスト: 実際に操作できる試作品で、普段の業務を数件処理してもらう。迷った場所・止まった場所を記録して直す
5. ビジュアルデザインと部品化: ボタン・入力欄・テーブル・エラー表示などを部品（コンポーネント）として整え、画面が増えても見た目と操作がそろうようにする
6. 実装・受け入れテスト・効果測定: 開発チームへ仕様を引き渡し、受け入れテスト（UAT）を経て本番へ。準備段階と同じ方法で処理時間やミスの割合を測り、改善前と比べる

システムの改修そのものも依頼する場合、RINIAのシステム開発では1〜2週間単位で機能を作り、区切りごとにデモを見てもらう進め方をとっています。UIの改善も、この単位で少しずつ現場に出していくと、使う人の抵抗が小さくなります。

アクセシビリティ：社内システムでも外せない理由

「社内でしか使わないから、アクセシビリティは関係ない」と考えがちですが、業務システムこそ配慮が必要です。

• 社員が使うシステム: 障害者雇用促進法により、2016年4月1日から、すべての事業主に、障害のある社員が働くうえでの支障を改善する「合理的配慮」の提供が義務づけられています*3。業務で使う画面が読めない・操作できないことは、この支障に当たりうる
• 取引先や顧客が使う画面（受発注ポータル、予約・会員ページなど）: 改正障害者差別解消法が2024年4月1日に施行され、事業者にも合理的配慮の提供が義務化されました*4

どちらの法律も、特定のWeb規格への準拠そのものを義務づけているわけではありません。ただ、申し出があったときに画面を直せるかどうかは、最初の設計で大きく変わります。文字の大きさを変えても崩れない、キーボードだけで操作できる、色だけで状態を伝えない、といった作りにしておくと、後から対応しやすくなります。

実際に計算してみた：よく見る配色のコントラスト比

画面の読みやすさで最も問題になりやすいのが、文字と背景のコントラストです。国際的なガイドラインWCAG 2.2では、通常の文字で4.5:1以上、大きな文字（約24px以上、太字なら約18.5px以上）で3:1以上を求めています（達成基準1.4.3・レベルAA）*5。

業務システムでよく見かける配色について、WCAGの計算式でコントラスト比を計算しました（2026年10月22日、RINIAで計算）。

注目したいのは4行目です。白い背景ではぎりぎり基準を満たすグレーでも、一覧表の1行おきに敷く薄いグレーの背景の上では基準を下回ります。テーブルが中心の業務システムでは起きやすい組み合わせなので、デザインの確認時に「背景が白以外の場所の文字」を重点的に見てもらうとよいでしょう。アクセシビリティの全体像は「Webアクセシビリティ義務化」で解説しています。

デザインシステムを使うか：デジタル庁デザインシステムという選択肢

画面数が多い業務システムでは、ボタン・入力欄・テーブルなどの部品と、その使い方のルールをまとめた「デザインシステム」を用意するかどうかが、長く使えるかの分かれ目になります。

ゼロから作る以外に、公開されているデザインシステムを土台にする方法もあります。国内の代表例がデジタル庁デザインシステムです。デザイン言語・UIコンポーネント・設計と実装のガイドラインで構成され、Figmaのデザインデータ、HTML版とReact版のコードも公開されています。想定する利用先は行政機関や公共性の高い組織のWebサイト・Webアプリケーションですが、入力フォームやエラー表示など業務システムと共通する部品が多く含まれます。2026年10月21日時点の版はv2.18.2です*6。

発注者として判断したいのは次の点です。

• 土台にするメリット: 部品と使い方のルールが最初からそろっているため、設計の議論を「自社の業務に合わせて何を変えるか」に集中できる
• 注意点: 自社ブランドの色や書体、既存システムの部品との混在をどう扱うかを先に決める。利用条件は公式サイトで最新のものを確認する
• 制作会社に聞くこと: 公開デザインシステムを使う場合と独自に作る場合で、費用・期間・将来の画面追加のしやすさがどう変わるか

外注先を選ぶときのチェックリスト

業務システムのUIは、ホームページのデザインが得意な会社と、システム開発が得意な会社のどちらか片方では足りないことがあります。次の項目を、提案や見積もりの段階で確認しましょう。

• 見積もりの単位が、画面数だけでなく「ロールの数」「画面の状態（入力中・エラー・空の一覧・権限なし）」まで考慮されているか
• 現場の担当者へのヒアリングや、業務の観察が工程に入っているか
• プロトタイプを使って、実際の担当者に操作してもらう工程があるか
• 既存システムを改修するのか、作り直すのか、それぞれの影響を説明できるか
• デザインを開発チームへ引き渡す方法（Figmaの部品・余白や色の値・仕様書）が決まっているか
• デザインデータの納品範囲と、納品後に自社や別の会社が編集してよいかが契約に書かれているか
• 改善後に効果をどう測るか（処理時間、ミスの割合、問い合わせ）を提案に含めているか
• 業務システムやWebアプリの制作実績があり、その中で担当した範囲を説明できるか

RINIAは、GA4やSearch Consoleと組み合わせて使うSEO検証ツール「Direbase」のように、データを一覧・診断する画面を持つWebアプリを自社で設計・開発しています（制作実績）。依頼先が個人か会社かで迷う場合は「フリーランスと制作会社の比較」も参考にしてください。

自社でできること／専門家に頼むべきこと

自社だけで進められるのは「何が問題か」を集めるところまでで、それを「どう直すか」に変える段階からは、設計と開発の両方を分かる専門家が入ると手戻りが減ります。

よくある失敗と防ぎ方

• 見た目だけを新しくする: 色やアイコンを変えても、入力項目や画面の順番が業務に合っていなければ処理時間は変わらない。症状のチェックリストから着手範囲を決める
• 管理職や情報システム部だけで決める: 毎日使う担当者の意見が入らないと、現場の操作に合わない画面になる。ワイヤーフレームとプロトタイプの段階で必ず現場に見てもらう
• 全画面を一度に切り替える: 慣れた操作が一斉に変わると、一時的に生産性が落ち、反発も大きい。使う回数が多い画面から段階的に出す
• 例外処理を後回しにする: 差し戻し・取り消し・権限がないときの表示など、「うまくいかなかったとき」の画面が後回しになると、問い合わせが減らない
• デザインと開発が分断される: デザインの意図が実装で失われる。部品と仕様を引き渡す方法を、発注時点で決めておく

よくある質問

業務システムのUIだけを改善することはできますか？

できる場合が多いです。画面の見た目や項目の並び、エラー表示の改善は、データの持ち方や他システムとの連携を変えずに進められることがあります。ただし、二重入力をなくす・入力項目を減らすといった改善は、データ構造の変更が必要になることもあるため、最初にUIだけで変えられる範囲を制作会社と確認しましょう。

パッケージやSaaSの業務システムでもUIを改善できますか？

製品の画面そのものは、提供元が許す範囲でしか変えられません。設定で項目の並びや表示を変える、入力ルールやマニュアルを整える、よく使う操作を別の画面にまとめるといった方法が中心になります。自社開発のシステムに比べて改善の自由度は下がるため、契約内容と設定でできることを先に確認するのがおすすめです。

UIデザインの費用は何で決まりますか？

主に、対象となる画面の数、ロール（権限）の数、画面ごとの状態の数、現場へのヒアリングやテストの有無、デザインシステムを作るかどうか、実装まで含めるかどうかで決まります。画面数だけで比べると、ヒアリングやテストを省いた見積もりが安く見えるため、工程の中身をそろえて比較しましょう。

改善の効果はどう測ればいいですか？

改善前に、代表的な業務の1件あたりの処理時間、入力ミスや差し戻しの割合、システムに関する社内問い合わせの件数を測っておき、改善後に同じ方法で測って比べます。同じ担当者・同じ種類の業務で比べ、新しい画面に慣れる期間を置いてから測ると、比較がぶれにくくなります。

社内でしか使わないシステムでも、アクセシビリティ対応は必要ですか？

必要性は高いと考えてください。障害者雇用促進法により、事業主には障害のある社員への合理的配慮の提供が義務づけられています。業務で使う画面が読めない・操作できない状態は、働くうえでの支障になりえます。文字のコントラストや大きさ、キーボード操作への対応は、高齢の社員や長時間画面を見る担当者にとっても使いやすさにつながります。

デザインはFigmaで納品してもらうべきですか？

開発チームが別の会社の場合や、将来画面を追加する予定がある場合は、Figmaなどのデザインデータで、部品や色・余白の値まで含めて受け取っておくと便利です。あわせて、納品後に自社や別の会社がデータを編集してよいかを契約で確認しておきましょう。

まとめ

業務システムのUIデザインは、見た目の新しさではなく、毎日の処理にかかる時間とミスを減らすことが目的です。

• 「使いにくい」を症状のチェックリストに書き出し、JIS Z 8520の7原則と対応づける
• 発注前に、対象業務と画面・ロール・現状の数字・現場のExcel・変えられない制約の5つを集める
• 使う回数が多く、ミスが出ている画面から段階的に直し、プロトタイプで現場に試してもらう
• 社内システムでもアクセシビリティを外さない。特に薄い背景の上の文字のコントラストに注意する
• 外注先は、業務のヒアリング・現場テスト・開発への引き渡し・効果測定まで提案に含めているかで選ぶ

RINIAでは、業務システムや管理画面のUIデザインから、改修を含むシステム開発まで一貫して対応しています。「どの画面から手をつければいいか分からない」という段階でも、お問い合わせからお気軽にご相談ください。