ブログトップ

公開日:

更新日:

9 min read

技術革新

「画面」という言葉の誤用を考える - ビューポートとページの使い分け

「画面」という言葉の誤用を考える - ビューポートとページの使い分けのイメージ

前回の記事で「画面」と「ページ」の違いについて考えました。 今回は、言葉の使い分けについて考えます。

正しい使い方の具体例

「画面」と「ページ」の違いを理解すると、以下のような使い分けが自然にできるようになります:

✅ 「ページのデザイン」:正しい

  • 文書全体の構造とレイアウトを考える対象として適切

❌ 「画面の設計」:誤り

  • 表示領域だけを設計することはあり得ない
  • 正しくは「ページの設計」

✅ 「画面に表示する」:正しい

  • 現在見えている部分について言及するときに適切

❌ 「画面をスクロール」:誤り

  • 画面(ビューポート)自体は固定の表示領域であり、スクロールの対象にはならない。

✅ 「ページをスクロール」:正しい

  • 文書全体を上下に動かす動作を正確に表現

このような区別は、単なる言葉の使い方の問題ではありません。 レスポンシブデザインやスクロール関連の実装で、予期せぬ問題を防ぐことにもつながります。

なぜ、この区別は重要なのか

これらの言葉の使い分けは、単なる言葉の揚げ足取りではありません。

例えば、「画面の設計」と言ってしまうと、スクロールで見えない部分の考慮が抜け落ちてしまう可能性があります。 「画面」という言葉は、現在表示されている部分について言及するときにのみ使います。

  • 画面に表示されている項目
  • 画面からはみ出している部分

正確な用語を使うことで次に効果が期待できます。

  • チーム内のコミュニケーションが明確になる
  • 設計の意図が正確に伝わる
  • 実装時の誤解を防ぐことができる

設計ドキュメントにおける影響

この「画面」と「ページ」の概念の混同は、設計ドキュメントの作成方法にも大きく影響しています。 典型的な例が「画面遷移図」と「ワイヤーフレーム」の違いです。

従来の「画面遷移図」アプローチ

  • 各画面を独立した単位として捉える
  • 画面間の遷移を矢印で表現
  • 紙での出力や印刷を前提とした設計
  • 静的な状態のみを表現

現代の「ワイヤーフレーム」アプローチ

  • ページ全体としての構造を重視
  • スクロールやインタラクションを含めた動的な表現
  • モックアップによる実際の挙動の表現
  • 印刷では表現しきれない動的な要素を含む

この違いは単なるツールの進化ではありません。設計思想の根本的な変化を反映しています。 従来の「画面」単位での思考から、「ページ」全体としての体験設計への移行を示しています。

ただし、この変化は時として組織内での軋轢を生むこともあります。

  • 紙の資料を重視する従来の開発プロセスとの衝突
  • レビューや承認プロセスの変更の必要性
  • 設計ドキュメントの保管や共有方法の見直し

昭和の頃、システム開発の価格とは、1千万円当たり1メートルの高さの書類である、と言われました。 実際、それだけの書類を納品していました。しかも手書きで1ページずつページ番号を書くんです。 検品でページが飛んでいたら再納品です。 納品前のチェックでページが飛んでいて、何千枚の紙のページ番号を消しゴムで消して書き直した、つらい作業を思い出しました。

写経かよ!!!!!

そんな価値観を色濃く残す人たちや組織が、日本ではまだまだ幅を利かせています。

解決への糸口

重要なのは、双方の価値観を理解し、歩み寄ることです:

  • ワイヤーフレームやモックアップに加えて、重要な遷移だけを図示した補助資料を用意する
  • 設計意図の伝達に重点を置き、表現方法は柔軟に選択する

つまり、「画面」か「ページ」かという二項対立ではなく、 それぞれの長所を活かした効果的なコミュニケーション方法を模索することが重要です。

形式主義の実情

しかし、現実はもっと複雑です。形式的な手続きを重視する組織では、 「画面遷移図でなければならない」という硬直的な要求に直面することもあります。

興味深いことに、このような要求の多くは、実はITをよく理解していない担当者から来ることが 少なくありません。皮肉なことに、そのような場合、ワイヤーフレームを単に印刷して 「画面遷移図」として提出すれば、要件を満たせることが少なくありません。

この状況は、日本の組織における根深い問題を示唆しています:

  • 形式的な手続きが実質的な内容より重視される
  • 実務担当者の知識と承認プロセスの要件の乖離
  • 新しい手法や考え方の導入を妨げる形骸化した制度

私たちは技術者として、このような状況に直面したとき、単に従来の形式に従うのではなく、 より良いコミュニケーション方法を模索し続ける必要があるでしょう。 同時に、組織の現実的な制約の中で、賢明な妥協点を見出す柔軟性も求められます。

たかが単語、されど単語

私たちエンジニアは、コードの品質にはとても気を使います。 でも、それと同じくらい、使う言葉の品質にも気を配る必要があるのではないでしょうか。

今日から、チームメイトと話すとき、ドキュメントを書くとき、これらの単語の使い方を意識してみてください。 きっと、より正確で分かりやすいコミュニケーションにつながるはずです。

そして何より、このような「なんとなく違和感がある」という感覚を大切にしてください。 その違和感の先には、必ず新しい発見が待っていると思いますよ。

こんな記事を書いておいてなんですが、それでもついつい「管理画面」とか言ってる自分がいます。 「管理ページ」がしっくりこないのは、きっと私がオールドタイプだからでしょうか…。