画面の更新を、業務の言葉で評価する
「画面がすっきりした」「一度に見える情報が増えた」。UIの更新を見たとき、こうした第一印象は大切です。しかし、本番への適用を決めるには、もう少し具体的な判断が必要になります。
例えば、営業担当者が対象の商談を探し、内容を確認し、必要な項目を修正して保存する。この一連の作業が、普段使っている端末でも無理なく行えるでしょうか。使い慣れた操作の位置が変わった場合、説明なしでもたどり着けるでしょうか。
本稿では、2026年9月に発表されたモデル駆動型アプリのUI更新を取り上げます。主張はシンプルです。UI更新の受入基準は、画面が表示されることに加え、利用者が業務を完了できることまで含めるべきです。
1. GAとPreviewを分けて把握する
Microsoftの2026年9月17日付の公式ブログでは、バージョン2609.1に関する更新として、次の状態が示されています。[1]
| 対象 | 発表上の状態 |
|---|---|
| ヘッダーとナビゲーションの刷新 | 一般提供（GA）。採用はオプトイン |
| 表示密度の調整 | パブリックプレビュー |
表示密度にはcomfortable、cozy、compactの3段階があり、ヘッダーとナビゲーションの刷新を前提とします。公式発表では、刷新を有効にすると表示密度の機能も既定で有効になり、アプリ側で既定値や機能の無効化を設定できると説明されています。[1]
したがって、「GAのUI更新を採用する」という判断と、「Previewの表示密度を利用させる」という判断は、分けて記録したほうがよいでしょう。
以下の受入テストや展開手順は、この更新を踏まえた筆者の提案です。Microsoftが指定する必須手順ではありません。実際の設定可否は、対象環境で確認する前提とします。
2. スクロール後の操作までテストする
Microsoft Learnでは、刷新後のフォームについて、コマンドバーは上部に固定され、フォームヘッダーが画面外へスクロールすると、縮小された固定ヘッダーが表示されると説明されています。また、初期プレビューにあったcompact commandsの動作は、全幅のコマンドバーに置き換えられています。[2]
このような変更は、画面を開いた直後のスクリーンショットだけでは評価しきれません。
例えば、長いフォームの下部で入力した後、利用者は「いま、どのレコードを編集しているか」を確認できるでしょうか。そのまま保存や次の操作へ進めるでしょうか。過去のプレビューで確認済みであっても、現在の挙動をもう一度見る意味があります。
テストケースは、部品の名前よりも行動で書くと、業務担当者と認識を合わせやすくなります。
| 業務シナリオ | 確認したいこと | 合格条件の例 |
|---|---|---|
| 一覧から対象レコードを探して開く | 識別に必要な情報と操作の分かりやすさ | 名前が似た別レコードと取り違えずに開ける |
| 長いフォームの下部を編集する | スクロール後のレコード識別と保存操作 | 対象を確認し、入力を保存して結果を確かめられる |
| 入力エラーを修正する | エラーに気付き、該当箇所へ戻れるか | 原因を把握し、修正後に作業を完了できる |
| 別の業務画面へ移動する | ナビゲーションの理解 | 日常的に使う画面へ迷わず移動できる |
これはサンプルであり、全案件で同じシナリオを採用する必要はありません。問い合わせ件数が多い操作、毎日繰り返す操作、誤操作の影響が大きい操作から選ぶと、限られた検証時間を使いやすくなります。
3. 表示密度は「最も多く表示できる設定」で決めない
表示密度を評価するとき、一覧の表示行数だけを比べると判断が偏ります。
例えば、一覧を見比べる時間が長い担当者と、フォームに文章を入力する時間が長い担当者では、使いやすさの基準が異なるはずです。小さなノートPCと大きな外部ディスプレイでも、同じ設定の印象は変わります。
そこで、比較時には次の条件を記録することを勧めます。
- 使用端末と画面サイズ
- ブラウザーのズーム倍率
- 評価した表示密度
- 実施した業務シナリオ
- 読みにくかった箇所、押し間違えた箇所、迷った操作
目的は、すべての組み合わせを網羅することではありません。主な利用環境を再現し、不具合報告や評価結果を比較できるようにすることです。
「compactのほうが速かった」という感想も、画面サイズや作業内容が分からなければ、全員に適用する根拠にはなりません。初期値を一つ決める場合でも、誰のどの作業を基準にしたかを残しておくと、展開後の見直しがしやすくなります。
4. UATでは、慣れの問題と作業を妨げる問題を分ける
新しいUIを見せると、「前と違うので使いにくい」という反応が出ることがあります。ここで、すべてを不具合として扱うと評価が進みません。一方で、すべてを慣れの問題として片付けると、実際の支障を見落とします。
筆者なら、指摘を次のように整理します。
| 指摘の種類 | 例 | 対応の考え方 |
|---|---|---|
| 操作の理解に関するもの | メニューの場所が分からなかった | 短い案内で解消するかを再確認する |
| 表示条件に左右されるもの | 特定の端末では文字を読みづらい | ズームや表示設定を含めて比較する |
| 業務完了を妨げるもの | 必要な操作に到達できず作業が止まる | 再現条件を整理し、展開可否の判断材料にする |
| 好みの違い | 以前の余白や色のほうが好き | 業務への影響と分けて記録する |
判断には、説明前と説明後の両方を見る方法が役立ちます。短い説明で解消するなら、周知の課題かもしれません。説明後も同じ箇所で作業が止まるなら、追加調査が必要です。
操作時間を測る場合も、初回だけで結論を出さず、同じ条件で数回試してから比較したいところです。ただし、測定そのものを目的にせず、日常業務に支障がないかという問いに戻ることが大切です。
5. 展開判断を一枚にまとめる
検証結果を多く集めても、「結局、何を有効にするのか」が曖昧なままでは展開できません。
最終的には、次の項目を一枚の判断メモにまとめることを提案します。
| 項目 | 記録内容 |
|---|---|
| 適用範囲 | 対象アプリと利用者 |
| 設定方針 | ヘッダー刷新と表示密度を、それぞれどう扱うか |
| 検証結果 | 主要シナリオの結果と未解決事項 |
| 周知内容 | 操作位置の変更など、利用者に伝える点 |
| 展開条件 | どの課題が残る場合に見送るか |
| 問題発生時の対応 | 問い合わせ先、再現に必要な情報、設定見直しの担当者 |
特に、以前の状態へ戻せる範囲は事前に確認しておきます。「画面の設定だから簡単に戻せるはず」と想定するだけでは、問題が起きたときに対応できません。対象環境で選択できる設定と、その変更による影響を確認してから手順に落とし込みます。
周知資料も、画面全体のマニュアルを作り直す前に、利用者が迷いそうな変更点に絞った短い案内から始めるとよいでしょう。
UI更新を、業務を見直す機会にする
今回の更新を評価する際は、新しい見た目を説明するだけでなく、日常業務のどこが楽になり、どこで迷うかを確認したいところです。
そのための第一歩は、代表的な業務シナリオをいくつか選び、実際の利用条件で試すことです。合格条件を「画面が正常に表示される」から「対象を見つけ、判断し、入力し、作業を完了できる」へ具体化すると、UIの評価が業務の評価につながります。
新UIの価値を判断する基準は、利用者が安心して仕事を進められるかどうかです。
参考情報と日付の確認
情報確認日：2026年10月2日。採用期間：2025年10月2日～2026年10月2日。
[1] Microsoft Power Platform Blog What’s new in Power Platform: September 2026 feature update
- 著者：Tiffany Treacy。
- 公開日：2026年9月17日。ページ本文の日付と、HTMLのdatePublished／article:published_time（2026-09-17T15:00:00+00:00）を確認。日付は発行元の表記に合わせています。
- 使用箇所：モデル駆動型アプリのUI更新、GA／Previewの区別、表示密度の前提と設定。
- 状態：ヘッダー・ナビゲーション刷新はGA、表示密度はPublic Previewとして記載。個別環境への適用状況を保証するものではありません。
[2] Microsoft Learn Modern, refreshed look for model-driven apps
- ページ表示の最終更新日：2026年9月15日。初版公開日は未確認。
- 使用箇所：「Wave 2: Header and navigation refresh」のスクロール時のヘッダー挙動とコマンドバーの変更。
- 更新の関連性：9月17日付の公式発表[1]がこのページへ直接リンクしており、同発表で紹介されたフォームヘッダーの挙動が当該節に記載されていることを照合。ページ全体の更新日だけで旧来の全記述を新情報とは扱っていません。
- 本稿では、クラシック表示への復帰に関するページ内記述を根拠にした手順は掲載していません。
コメント