業務UIで改行や全角半角にこだわりすぎると共通化のメリットが薄れる

はじめに

業務システムのUIレビューをしていると、改行位置や全角・半角といった細かな見た目について、かなり厳密な指摘が入ることがあります。

もちろん、表記の統一や読みやすさは重要です。

ただ、実際にその画面を毎日使う利用者は特に気にしておらず、日常的に操作しない関係者だけが細かな表示差を気にしている場合、本当にそこへ開発工数を使うべきなのかは考えた方がよいと思っています。

全角・半角は、表示上の統一だけの話とは限りません。検索、照合、外部システム連携、帳票ではデータ値として意味を持つことがあります。この記事では、そうしたデータ上の要件ではなく、表示上の個別調整を主な対象にします。

特に気になるのは、画面ごとの細かな見た目を優先することで、コンポーネント化やCSSの共通化によって得られるはずのメリットまで失われてしまうことです。

この記事では、業務UIにおいて「見た目の細かな調整」と「共通化・操作効率」のどちらを優先すべきかについて考えます。

「気になる」と「業務で困る」は別

UIレビューでは、次のような指摘が出ることがあります。

• この括弧は全角にしてほしい
• この文言はここで改行してほしい
• この項目だけ1行に収めてほしい
• この画面では余白を少し広げてほしい

こうした指摘自体が悪いわけではありません。

問題は、それが実際の利用者の課題なのか、それともレビューする側の好みなのかが曖昧なまま修正対象になることです。

業務システムであれば、まず確認したいのは次の点です。

• 利用者が読みにくいと感じているか
• 操作ミスにつながっているか
• 業務時間に影響しているか
• 表示上の誤解が発生しているか
• 社内ルールや法令などで表記が決まっているか

これらに該当するなら、修正する意味があります。

一方で「なんとなくこちらの方がきれい」という理由だけなら、他の改善より優先するべきかは考える余地があります。

共通コンポーネントを作る意味

VueやReactで業務画面を作る場合、ボタン、入力欄、テーブル、ラベル、メッセージなどを共通コンポーネントとして実装することがあります。

例えば、次のようなコンポーネントです。

<AppLabel>
  顧客情報
</AppLabel>

共通コンポーネントを使う理由は、単に同じコードを書きたくないからではありません。

主なメリットは次のようなものです。

• 見た目を統一できる
• 修正箇所を集約できる
• 画面ごとの差分を減らせる
• 重複した表示ルールのテストを集約しやすい
• 実装者ごとのばらつきを減らせる

つまり、共通化は、共通ルールを決めたうえで必要な例外を少数のバリアントとして扱い、全体をシンプルにするための仕組みでもあります。

画面ごとの微調整が増えると共通化が崩れる

ところが、レビューのたびに次のような要望が追加されるとどうなるでしょうか。

• A画面だけ文字を少し小さくする
• B画面だけ強制的にこの位置で改行する
• C画面だけ括弧の前後に余白を追加する
• D画面だけ単語の途中でも折り返す
• E画面だけ折り返さない

最初は共通コンポーネントだったものが、次第にpropsだらけになっていきます。

<AppLabel
  :no-wrap="true"
  :break-all="false"
  :compact="true"
  :force-line-break="true"
/>

さらに条件が増えると、今度は利用側からTailwind CSSのクラスを直接渡したくなります。

<AppLabel class="break-all whitespace-normal text-sm">
  顧客情報
</AppLabel>

これ自体が必ず悪いわけではありません。

ただ、各画面が好きなようにCSSを上書きするようになると、共通コンポーネントを使っているにもかかわらず、見た目や挙動は結局画面ごとに異なる状態になります。

こうなると、共通化によって得たかったメリットが徐々に薄れていきます。

Tailwind CSSを使っていても同じ

Tailwind CSSは、CSSを書かなくてよくなる仕組みというより、デザイン上の制約をある程度共通の単位で扱いやすくする仕組みだと考えています。

以下のクラス名はTailwind CSS v4を前提にします。

例えば、

<p class="wrap-break-word">
  ...
</p>

という共通ルールを採用しているのに、画面ごとに

<p class="break-all">
  ...
</p>

<p class="whitespace-nowrap">
  ...
</p>

<p class="break-keep">
  ...
</p>

それぞれが変える表示ルールは次のとおりです。

• wrap-break-wordは、長い英単語やURLが収まらないときに単語の途中で折り返せるようにします。
• break-allは、単語の区切りを保たず必要な位置で折り返します。
• whitespace-nowrapは、内容を折り返さないため、幅が足りない場合は横方向にはみ出します。
• break-keepは、日本語・中国語・韓国語（CJK）の文字列で、文字間の改行を抑制します。whitespace-nowrapとは異なり、すべての折り返しを禁止する指定ではありません。

と例外を増やしていけば、最終的には「Tailwindを使っているだけで、設計としては各画面が個別CSSを持っている」のと近い状態になります。

重要なのはTailwindを使っているかどうかではなく、どこまで共通ルールとして扱い、どこからを本当に必要な例外とするかだと思います。

Web UIで改行位置を固定するのは意外と難しい

改行位置を細かく指定する要求は、Web UIと相性がよくない場合があります。

一方で、内容が固定された短い見出し、帳票に近い表示、法令上の定型文、語句を分断すると読み違えにつながる表示では、明示的な改行が合理的な場合もあります。画面幅やデータに応じて変わる本文と、固定の表示要件を分けて考える必要があります。

表示結果は次の条件でも変わります。

• 画面幅
• ブラウザ倍率
• フォント
• OS
• 入力されるデータ
• 全角・半角
• 日本語と英数字の混在

例えば、

口座情報（本人確認済み）

と

口座情報(本人確認済み)

では文字幅が変わります。

あるPCでちょうどよく見えるように改行を調整しても、別の解像度やブラウザ倍率では崩れることがあります。

そのため、特定のスクリーンショットを基準に「ここで折り返す」という調整を続けるより、

• コンテナ幅
• min-width
• max-width
• white-space
• overflow-wrap
• word-break

などのルールを決め、さまざまな文字列でも破綻しない状態を作る方が保守しやすいと感じます。

特にoverflow-wrapは、通常の改行位置に収まらない長い文字列だけを分割できます。word-break: break-allのように常に単語の途中で分割する指定とは挙動が異なるため、URL、英単語、日本語を含むデータで確認して選びます。

実際の利用者が求めるのは作業完了の速さと正確さではないか

業務画面では、1回の操作を数秒短縮できることや、操作ミスを防げることの方が、見た目の微調整より大きな価値を持つことがあります。

例えば、利用者が1日に100回使う操作を1秒短縮できれば、1人あたり1日100秒です。

10人が使えば1日1,000秒になります。

そのため、自分なら次のような改善を優先したいです。

• 画面遷移を減らす
• APIレスポンスを速くする
• 不要な再取得を減らす
• 検索条件を保持する
• キーボードだけでも操作できるようにする
• 初期フォーカスを適切にする
• Enterキーで検索できるようにする
• よく使う項目を上に置く
• ローディング時間を短くする
• 同じ情報を何度も入力させない

こうした改善は、実際に画面を何度も操作する人ほど効果を感じやすいです。

業務UIでは「1回見たときに美しいこと」より、「1日に100回使っても邪魔にならないこと」の方が重要な場合があります。

UIレビューでは「誰のための修正か」を確認したい

改行や全角・半角の修正依頼が来たとき、自分なら次のように整理します。

1. 利用者からの要望か

実際の利用者から「読みにくい」「間違えやすい」と声が出ているなら、優先度は高いです。

2. 共通ルールか

デザインガイドラインや社内ルールとして決まっているなら、画面単位ではなく共通ルールとして実装した方がよいです。

3. 共通化の前提を共有できているか

利用者や要件を提示する人が、その画面で共通コンポーネントや共通の表示ルールを使っていることを把握しているとは限りません。画面上の見た目だけを見れば、個別に直せるように見えるからです。

これは要件を出す側の理解不足として扱う話ではありません。実装する側が、個別の修正が共通コンポーネントのバリアント追加や全画面への影響確認につながることを説明し、変更範囲と優先度を一緒に判断できる状態にする必要があります。

4. データ上の要件か

外部システム連携、CSV、固定長データ、検索、帳票などで全角・半角に意味があるなら、単なるUIの話ではありません。

5. BFFやAPIの変更が必要か

BFFを採用している構成では、バックエンドのレスポンスに含まれる文字列を全角から半角へ変換したり、画面用の表記に変えたりするために、BFFの変換処理を追加することがあります。

この変更は表示だけに見えても、BFFがフロントエンドへ返す値の表現ルールを変えることになります。変換漏れ、画面ごとの差異、検索条件との不整合などが入り込む余地も増えます。

そのため要件担当者には、元データ自体を変えるのか、画面表示だけを変えるのかを確認したうえで、BFFの実装と検証が必要になることを伝えた方がよいです。

6. 単なる見た目の好みか

特定の人だけが気にしていて、業務上の問題も共通ルールもないなら、本当に個別実装を増やす価値があるのかを考えたいです。

例外を追加するコストはその画面だけでは終わらない

「この画面だけだから」と例外対応を追加するのは簡単です。

しかし、その例外は将来の保守対象になります。

例えば、共通コンポーネントへbreakModeのようなpropsを追加すれば、

• propsの意味を理解する必要がある
• Storybookやテストのパターンが増える
• 他画面でも利用され始める
• どの値を使うべきか判断が必要になる
• 新しい例外との組み合わせが増える

といったコストが発生します。

局所的には数行の変更でも、設計全体では分岐を一つ増やしていることになります。

表記の例外が増えると、BFFの変換処理の単体テスト、API契約の確認、画面での表示確認も増えます。テスト自体は必要ですが、要件の根拠が曖昧な例外まで増やすと、障害を防ぐための重要なテストに割ける工数を圧迫する可能性があります。

だからこそ、UI上の例外を追加するときは、

「実装できるか」

だけではなく、

「共通ルールを崩してまで対応する価値があるか」

まで確認したいです。

まとめ

業務UIで全角・半角や改行を気にすること自体は悪くありません。

ただ、それが実際の利用者の課題ではなく、レビューする人の見た目の好みだけになっているなら、優先順位は考えた方がよいと思います。

画面単位の細かな指定が増えるほど、コンポーネント化やTailwind CSSによる共通化のメリットは小さくなります。

一方で、実際の利用者にとっては、

• 速く表示される
• 少ない操作で終わる
• 入力を繰り返さなくてよい
• キーボードで素早く操作できる
• 操作ミスをしにくい

といった改善の方が、日々の業務へ直接効くことがあります。

UIレビューで細かな表示差を直す前に、

「誰が困っているのか」

「この変更で業務がどう改善するのか」

「共通化を崩すコストに見合うのか」

を確認する。

業務システムでは、この視点を持っていたいです。