紙の申請をウェブフォームへ移し、担当者の台帳をワークフローへ置き換えても、利用者が同じ情報を何度も入力し、 社内では画面の外で転記や照合が続くなら、サービス全体は十分に変わっていません。見た目が新しくなっても、 完了までの負担、判断の遅さ、問い合わせ、やり直しが残ることがあります。

IPAが2026年7月に公表した「DX動向2026調査のポイント」は、国内企業のDXが広がる一方、成果はデータのデジタル化や 業務効率化で高く、企業価値創出につながる内容では低い状況が続くとしています。調査対象は国内企業の経営層、 情報システム部門、DX推進部門など1,799社でした。効率化は重要ですが、それだけを終点にすると、利用者にとっての価値や 事業の変化へ届きにくくなります。

デジタル庁が2026年6月に改定した「DS-670.1 ユーザビリティガイドライン」は政府情報システム向けの基準であり、 民間企業へ直接の遵守義務を課すものではありません。ただし、プロジェクト初期から多様な利用者のニーズと利用状況を把握し、 利用時の品質目標を定め、プロトタイプと運用中の評価を通じて改善する考え方は、顧客向け・従業員向けサービスにも応用できます。 本記事では、その考え方を業務変革へつなぐ5つの手順に整理します。

具体的な課題：画面は変わったのに、利用者の仕事が軽くならない

画面単位、部署単位、システム単位で要件を集めると、「既存機能を漏れなく移す」ことが中心になりがちです。 しかし利用者は、一つの画面だけで目的を達成しているわけではありません。調査、相談、承認、支払い、受け取り、問い合わせなど、 前後の行動を含む一連の体験としてサービスを利用します。

  • 手続の前後が見えていない：入力画面だけを改善し、準備する資料、社内確認、結果待ち、再申請の負担を把握していない。
  • 例外を利用者へ押し戻す：標準ケースだけを自動化し、不明点や変更があると電話、メール、紙へ戻る。
  • 部門の境界で途切れる：顧客には一つのサービスでも、社内では受付、審査、請求、サポートが別々に管理される。
  • 操作数だけで評価する：クリック数は減っても、完了率、誤り、待ち時間、理解、不安、問い合わせを見ていない。
  • 公開後は保守だけになる：利用状況や声を継続的に集め、優先順位を決めて直す責任と予算がない。
DXの設計単位を「画面」から「利用者が目的を達成し、組織が価値を届けるまでの一連のサービス」へ広げることが出発点です。

考え方：「利用者・業務・画面・改善」を一つの循環にする

利用者中心は、要望をすべて採用することでも、見た目を整えることでもありません。誰が、どの状況で、何を達成しようとしているかを調べ、 事業目的、業務制約、安全性、アクセシビリティと照合して、よりよい方法を検証する考え方です。

  1. 利用者：対象者、目的、利用環境、能力、制約、前後の行動を理解する。
  2. 業務：社内の判断、役割、データ、受け渡し、例外、待ち時間を可視化する。
  3. 画面：必要な情報と操作だけを、誤りにくく安全で、利用可能な形へ設計する。
  4. 改善：公開後の利用データと声を集め、課題を選び、修正効果を確かめる。

デジタル庁のガイドラインは、利用者層、規模、頻度、タイミング、環境、ニーズ、目標を明らかにし、 ユーザビリティテストなど具体的な評価方法を計画するよう示しています。また、対象システムの利用前後を含む活動全体、 物理的・心理的な負担、初心者と熟達者の違い、多様な利用者のアクセシビリティを把握する観点も示しています。

実践手順1：一つの利用目的と完了条件を決める

「受注システムを刷新する」のようなシステム名から始めず、「初めての顧客が迷わず見積りを依頼し、必要な回答を受け取れる」など、 利用者の目的と完了状態を一つ選びます。経営側の狙いも、顧客離脱の低減、受注までの時間短縮、問い合わせ削減、 従業員が判断へ使える時間の確保など、同じサービスへ対応づけます。

完了率、所要時間、誤り・やり直し、問い合わせ、理解度、安心感、支援が必要な割合などから、利用時品質の目標を少数に絞ります。 売上やコストだけでなく、利用者の行動と業務の状態を途中指標として持つと、結果が変わらない原因を追いやすくなります。

実践手順2：現場観察で前後の行動と例外を描く

利用者と担当者へ聞くだけでなく、可能な範囲で実際の作業を観察します。何を準備し、どこで迷い、誰へ確認し、 どの情報を転記し、何を待ち、失敗したときどう戻るかを時系列で記録します。アクセス解析や問い合わせ履歴も組み合わせますが、 数字だけで理由を断定せず、インタビューや観察で確かめます。

多忙な人、初めて使う人、習熟した人、スマートフォンだけを使う人、支援技術を使う人など、条件の異なる利用者を含めます。 すべての声を平均化せず、目的達成を妨げる障壁と、失敗した場合の影響を整理します。個人情報や行動記録は、 調査目的、同意、閲覧範囲、保存期間を明確にして必要最小限に扱います。

実践手順3：サービス全体で「なくす・まとめる・支える」を決める

現状の画面をそのまま整える前に、各手順を「なくせるか」「一度にまとめられるか」「組織側で先回りできるか」「利用者を支援できるか」で見直します。 既に持つ情報を再入力させない、部門間の確認を裏側でつなぐ、申請前に必要条件を分かりやすく示す、途中保存や代理利用を可能にするなど、 業務とデータの変更を画面設計より先に検討します。

標準ケースだけでなく、変更、取消し、情報不足、システム停止、連絡手段が限られる場合も設計します。 例外を「利用者のミス」と決めつけず、誤りを予防する入力支援、影響を小さくする確認・取消し、有人支援へ安全に切り替える導線を用意します。

実践手順4：小さな試作品で業務と画面を同時に検証する

本番開発の前に、紙やクリック可能な試作品で代表的なタスクを実行してもらいます。説明なしで目的を理解できるか、 必要な情報を見つけられるか、誤りから戻れるか、完了と次の行動が分かるかを観察します。担当者側も同じシナリオを通し、 裏側の判断、通知、データ更新、例外処理が成立するかを確かめます。

参加人数の多さより、仮説と対象者、確認したい行動、判定条件を事前に決めることが重要です。 発言だけでなく実際の行動を記録し、一回で正解を目指さず、問題を特定して修正し、再度試します。 アクセシビリティは完成後の検査へ回さず、対象となる利用者や専門家の参加を早い段階から組み込みます。

実践手順5：公開後の声を改善の意思決定へつなぐ

公開を完了ではなく、実利用を学ぶ開始点とします。完了率、離脱箇所、処理時間、誤り、問い合わせ、利用者のフィードバック、 担当者の手戻りを定期的に確認します。デジタル庁も2026年7月、政府情報システム上で満足度と利便性のフィードバックを直接収集・分析し、 継続改善へつなぐ仕組みの整備を公表しました。

声を集めるだけで終わらせず、分類、根拠確認、優先度付け、責任者、実施期限、効果確認まで一つの改善台帳で管理します。 優先順位は声の大きさだけでなく、影響を受ける人数、目的達成への影響、安全性、アクセシビリティ、事業価値、改修の依存関係で判断します。 小さく修正できる契約、予算、技術構成も、改善できるサービスの一部です。

注意点：利用者中心を「好みの投票」にしない

  • 要望をそのまま機能化しない：発言の背後にある目的と障壁を確かめ、複数の解決方法を比較する。
  • 平均的な利用者だけを想定しない：多様な能力、端末、環境、言語、経験、代理利用を早期に検討する。
  • 画面だけを最適化しない：規程、権限、データ、部門間の受け渡し、サポート、契約も同じサービスとして扱う。
  • 満足度だけで成功を決めない：完了、時間、誤り、安全性、事業成果と組み合わせ、回答者の偏りにも注意する。
  • 調査データを集めすぎない：目的、同意、匿名化、アクセス権、保存期間を定め、必要以上に行動や属性を保持しない。
  • 公的ガイドラインを私企業へ機械的に適用しない：考え方を参考にし、自社の業種、顧客、従業員、法令、契約、リスクへ合わせる。

まとめ

利用者中心のDXは、既存手続をきれいな画面へ移すことではありません。利用者の目的と利用状況を理解し、前後の業務と例外を可視化し、 不要な手順をなくし、小さな試作品で確かめ、公開後の声と利用データから改善し続けることです。画面、業務、組織、契約を一つのサービスとして扱うと、 効率化だけでなく、利用者が価値を受け取れる状態へDXを近づけられます。

最初の一歩は、問い合わせや手戻りが多い一つの手続を選び、利用者が始める前から完了後までを一枚に描くことです。 その中から「なくせる待ち時間」「減らせる再入力」「予防できる誤り」を一つ選び、業務と画面を同時に試してください。

参考にした公式資料

本記事は公的資料をもとに、一般的なDXとサービス改善の考え方を整理したものです。 個別組織の法令適合性、アクセシビリティ適合性、契約、個人情報、人事その他の法律上・専門上の助言を行うものではありません。 公式資料は2026年8月17日時点で確認しています。実際の設計・調査・運用では、自社の利用者、業務、技術、契約、適用される法令・規格、 リスク許容度を踏まえ、必要に応じて関係部門や専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る