JTCの業務UIはなぜ"あのレイアウト"に収束するのか — 情報密度と最適解の話

少し前にXで「もし日本企業がGitHubを作ったら」というネタ投稿が結構回ってました。きっかけになったのは、@Shiro_Shihi さんの投稿です。

画面を見た瞬間に「うわ、これ業務システムで何回も見たやつじゃん」ってなりました。横にタブがズラッと並んでいて、ボタンも山ほどあります。Excelみたいに情報が詰め込まれていて、フォントも小さめです。あるあるですよね。

リプライ欄も「これこれこれ」「まじで見たことあるわ」と続いていました。エンジニアもデザイナーも「業種関係なくあるあるすぎる」と反応していて、なんかJTCの業務UIには共通認識があるんだなって思いました。

じゃあ、なんでああなるのか。背景とあわせて、少し考えてみます。

まず用語を整理しておきます。

JTC（Japanese Traditional Company / 日本の伝統的な大企業を指すネットスラング）は、大手メーカーや金融、通信、商社をイメージする人が多いんですよね。2019年頃から、Xでよく見るようになりました。

「JTC UI」と呼ぶときの特徴は、だいたいこんな感じです。

• 画面の上の方にタブが横にたくさん並んでる
• ボタンの種類と数が異常に多い（登録、更新、削除、確認、戻る、キャンセル、印刷など）
• 情報がめっちゃ詰まっててフォントが小さい
• テーブルがメインで、Excelとほぼ同じ見た目
• 検索条件のエリアが画面上部をガッツリ占領してる
• 入力項目がとにかく多い
• 色味はくすんでて、階層が深め

特徴が揃っているので、このままAIの画像生成に渡せそうです。なぜこうなるのかが分かれば、「見づらいからシンプルにしよう」も、もう少し的を射た話になります。

JTC UIがあの形に落ち着くのは「これ！」みたいな一つの原因じゃなくて、組織的要因・ユーザー要因・開発プロセス要因・運用要因の四つが重なってると思っています。

組織的要因：多部署対応と承認フローの複雑さ

大企業の業務システムって、営業、経理、管理、法務、物流など、いろんな部署が同じ画面を使うことが多いんですよね。それぞれ必要な情報が違うので、要望が全部、一つの画面に集まってきます。

承認も何段階にもなり、ボタンやステータス表示が増えます。権限で出し分けることもできます。ただし、ロジックが複雑になるので、「全部表示して非活性にしとく」という選択になりやすいんですよね。これは怠慢というより、承認の複雑さを最小限のコストで処理しようとした結果だと思います。

ユーザー要因：エキスパートユーザー前提の設計

業務システムを使う人は、毎日同じ操作を何度も繰り返すエキスパート（熟練したユーザー）です。一般の消費者向けサービスとは、前提が全然違います。

Nielsen Norman Group（以下、NNG）の研究でも、業務システムでは「操作速度」と「熟練者が複雑なタスクを早くこなせること」が重視される、って言われてます。学習コストが高いことは、そこまで問題視されないんですよね。研修もマニュアルもあり、何年も同じシステムを使う前提だからです。

情報を一画面にまとめておく設計は、ページを何度も往復する手間を減らせます。つまり、理にかなっている部分もあるんですよね。

開発プロセス要因：要件の積み上げと帳票文化

固定価格・一括リリースの案件だと、要件定義の段階で全部の機能を決めておかないといけないんですよね。将来使うかもしれない項目も先に出してしまうから、不要なものがどんどん溜まっていきます。「どこかの部署にとっては必要だから」って理由で、項目が削れなくなるんですよね。

あと、日本特有の帳票文化も影響してると思います。細かく記録と証拠を残す習慣が、画面のレイアウトにもそのまま引き継がれやすいんですよね。メインフレーム時代のパターンが今も残ってる企業は結構あります。

運用要因：印刷・既存システム連携・マニュアル文化

業務システムでは、印刷が要件に入ることが多いんですよね。画面レイアウトがそのまま帳票になるので、テーブル構造が基本になります。

それから、既存システムとの連携も大きな制約です。レガシーシステムのデータ構造に合わせなきゃいけないので、UIをきれいに最適化するより、連携の安定性を優先せざるを得ないんですよね。

あと「マニュアル文化」も見逃せないポイントです。操作手順書や研修資料を作る前提だと、画面に全部の項目とボタンを出しておいた方が説明しやすいんですよね。ラベルを省略するより「画面に書いてある」状態の方が、教育コストが下がるからです。

「JTC UIは非合理だ」という声はよく聞きます。ただ、それは消費者向けサービスの目線だと思います。業務システムの文脈では、少し話が変わってきます。

Bloomberg Terminalという例

金融のプロが使う「Bloomberg Terminal」には、スパークライン（数値の推移を小さな折れ線で示すグラフ）が並びます。取引テーブルやニュースも、同時に表示されます。見た目はJTC UIと似ていて、情報が詰まっています。

でも、35万人以上の金融のプロが毎日使っているんですよね。BloombergのUXチームは「複雑さを隠す」と言っていますが、実際には判断に不要な複雑さを背後に下げているそうです。情報を減らすんじゃなくて、必要なものを整理して出す感じです。

Bloombergは、この密度を理解できる専門家だけを対象にした製品です。一方でJTCのUIは、複数部署の要望が一画面に集まった結果です。

認知負荷の正しい理解

「情報密度が高い＝認知負荷（情報を処理するときにかかる頭の負担）が高い」は、初心者には当てはまります。ただし、毎日使っているエキスパートには、必ずしも当てはまりません。

熟練してくると操作が自動化されるので、画面を細かく分けると、かえって往復が増えて遅く感じます。NNGの研究でも、スカスカな画面の方が使いにくくなるケースがあると指摘されています。

ただ、高密度が常に正しいわけではありません。フィードバックが遅い、エラー理由がわかりにくい、操作のヒントが弱い。こうした問題は、密度とは別の話です。「情報が多い」ことと、「使える情報が整理されている」ことは、別物なんですよね。

Consumer向けと業務向けの違い（ざっくり）

ノービス（そのシステムを使い始めたばかりの人）と、毎日使う人では、画面の前提が違います。

ただし、すべてのJTC UIを擁護する話ではない

「合理的な高密度」と「ただの混沌」は全く別物です。

エキスパート前提で詰め込む設計は、筋が通ります。ただし、要件をただ積み上げただけの「誰も整理していない密度」は、エキスパートにとっても扱いにくくなります。

混沌のサインは、誰も使わない項目が残っていること、ラベルと機能の不一致、同じ情報の重複です。

「誰のどんな操作のために、何を画面に出すか」。これを設計者が答えられるかどうかが、分かれ目だと思います。

UI設計で見る軸は、三つです。

1. 誰が使うか（ユーザー像） ノービスとエキスパートでは、最適な設計が全然違います。離職率が高くて人がよく入れ替わる組織なら、初心者向けの配慮も必要になります。

2. どんなタスクか（タスクの性質） 毎日同じ伝票を入力する作業と、データを分析して判断する作業では、求められる画面の形が違います。同じシステムでもタスクが混在する場合は、モード分けや優先順位の設計が必要になります。

3. どれくらいの頻度か（使用頻度） 年に1回しか使わない機能と、毎日100回触る機能を同じ扱いにするのはナンセンスです。触る回数が多いものは、ショートカットや一画面集約を優先します。稀にしか使わないものは、ガイドを厚めにします。

この三つを明確にしないまま「見づらいからシンプルにしよう」って議論しても話が噛み合わないんですよね。

最近の業務SaaSの中には「Consumer寄りすぎて逆に使いにくい」って声も結構聞きます。見た目はきれいでも、エキスパートからは「前のシステムの方が速かった」って言われるパターンです。

JTCの業務UIがあのレイアウトに収束するのは、以下の四つの要因が重なった結果です。

• 組織的要因：多部署対応と承認フローの複雑さ
• ユーザー要因：エキスパート前提で操作速度を最優先
• 開発プロセス要因：要件の積み上げと帳票文化
• 運用要因：印刷要件・レガシー連携・マニュアル文化

その密度が一見非合理に見えても、使う人やタスク、頻度によっては理にかなっているケースは少なくありません。Bloomberg Terminalが40年以上にわたって高い情報密度を保ち続けているのも、その一例だと思います。

JTC UIが「あるある」として広く認識されているのは、設計根拠が曖昧なまま積み上がってきたUIへの、業界を超えた共通体験があるからだと思います。

「見づらいからシンプルに」だけで削ると、熟練者の手を遅くします。一方で「業務だから詰め込みは当然」と放置すると、誰のための整理かわからないまま残ります。

情報密度は、高いか低いかではなく、誰のどんな操作のためにあるかで判断します。

関連：画面が詰まったまま失敗したときの立て直しも重要です。そちらの観点はエラー処理を立て直し設計として整理した記事にまとめています。