Webシステムの画面を検証するとき、パソコンで一度開いて問題がなければ完了、としたくなることがある。しかし、利用者がスマートフォンを使うシステムでは、それだけでは足りない。画面幅が変わると、パソコンでは見えなかった問題が表面化する。
「DX経営ゲーム」の参加者画面は、ホーム、意思決定入力、結果、AI相談、ルールなど複数のタブで構成されている。結果画面には損益計算書、貸借対照表、製造原価報告書、キャッシュフロー計算書、推移表など、情報量の多い表示がある。
会計数値を表形式で並べると、列数や項目名が増える。パソコンでは十分な横幅があるため整って見えても、スマートフォンでは表だけが画面の外へはみ出すことがある。ページ全体が横に動いてしまうと、操作ボタンや他の文章まで読みづらくなる。
今回の監査では、比較表を示すcomp-tableと、ホーム画面の推移表であるhome-trend-tableが確認対象になりた。単にスクリーンショットを眺めるのではなく、表示領域より幅の広い要素を検出し、横方向にはみ出している要素がないかを調べた。
修正前には残件がありたが、最新版を仮想マシンへ反映して再監査した結果、広すぎる要素の検出は全タブで0件になりた。これにより、対象としていた表のスマートフォン幅での崩れが解消されたと判断した。
ここで重要なのは、「スマートフォン対応」という一言を、具体的な検査条件に変えることだ。対応しているつもり、見た感じでは使える、という表現では判定できない。どの幅で、どの画面を開き、何を異常とするかを決める必要がある。
今回作成した個人編のテスト計画では、パソコンだけでなく複数のモバイル幅を確認対象にしている。また、ログイン画面だけではなく、ホーム、入力、結果、ルール、AI相談まで主要タブを確認する。最初の画面が収まっていても、後から読み込まれる表やカードが崩れる可能性があるからだ。
画面監査では、コンソールエラーも同時に確認した。以前は静的ファイルの読み込みで404が残っていた。404は画面全体を停止させるとは限らず、利用者からは一見正常に見える場合がある。しかし、不要な参照が残っていることは、配信内容と設定が一致していない証拠だ。
原因候補として、Webアプリのアイコン情報を持つmanifest.jsonやapple-touch-iconの参照も確認した。修正版ではマニフェストのアイコン設定が空になり、HTMLから不要な参照が除かれていた。再検証ではコンソールエラーが全実行で0件となり、404が解消したことを確認した。
画面の品質は、見た目だけで判断できない。要素のはみ出し、読み込み失敗、コンソールエラー、操作対象の表示、タブ切り替え後の状態など、複数の観点がある。特にスマートフォンでは、表示領域が狭いため、小さな設計上の無理が使い勝手に直結する。
また、レスポンシブ対応は「表を小さくする」だけではない。文字を縮めすぎれば読めなくなる。必要な場合は表の領域だけを横スクロールさせ、ページ全体は固定するなど、情報の性質に合わせた設計が必要だ。
検証時にも、横スクロールがあること自体を機械的に不具合とはしない。表の内部で意図的にスクロールできるなら正常だ。問題なのは、一つの要素が原因でページ全体の幅が広がり、利用者が現在位置を見失う状態だ。仕様と実際の操作感を合わせて判断する。
今回のテスト計画では、表示崩れの観点を独立した項目にした。確認対象は横方向のはみ出しだけではない。カード同士の重なり、ボタン文字の欠け、入力部品の操作不能、固定表示による内容の隠れ、グラフや表の見切れなども対象だ。画面幅を変えたときに、見た目だけでなく操作が維持されるかを確認する。
特に意思決定画面では、スライダーや切り替えボタンを操作できることが重要だ。結果画面が多少読みにくい問題と、入力ボタンが押せずゲームを進められない問題では優先度が違いる。そこで、リリース判定では主要な操作経路を優先し、その後に個別の表示品質を詰めるようにした。
また、画面監査の結果は、修正前後で同じ形式のレポートとして残した。担当者の印象だけで「良くなった」とせず、コンソールエラーと幅超過要素の件数を比較できる。自動検出で候補を絞り、最後は実画面で意味を判断するという進め方だ。
今回、404、比較表、推移表という具体的な残件を一つずつ再確認し、最終的にコンソールエラー0件、幅超過要素0件まで確認した。「修正した」という報告だけではなく、修正版を配信した環境で同じ監査を再実行したことで、解消を根拠付きで示せた。
パソコンで正常に見えることは、検証の始まりにすぎない。利用者が実際に使う画面幅と操作経路で確かめること。その積み重ねによって、動くだけの画面から、現場で使える画面へ近づけられる。