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

1. きっかけ：Xで話題になったポスト

少し前にXで「もし日本企業がGitHubを作ったら」というネタ投稿が結構回ってました。

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

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

じゃあ、なんでああなるのか。今回はそれを背景と共に、整理して考えてみましょう。

2. JTC UIとは何かを定義する

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

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

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

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

問題は「なぜこうなるのか」をちゃんと理解することだと思っています。それができれば、「見づらいからシンプルにしよう」って話も、もう少し的を射た議論になるはずです。

3. なぜ収束するのか — 四つの要因を分解する

JTC UIがあの形に落ち着くのは、単一の原因じゃありません。組織的要因・ユーザー要因・開発プロセス要因・運用要因の四つが重なってるんです。

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

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

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

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

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

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

情報を一画面にまとめておく設計は、ページを何回も行ったり来たりする手間を減らせるので、理にかなってる部分もあるんです。

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

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

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

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

業務システムでは印刷が重要な要件になることが多いです。画面のレイアウトがそのまま帳票として出力されるから、テーブル構造が基本になります。

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

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

4. 情報密度の高いUIは本当に非合理なのか？

ここからは「その密度が妥当かどうか」について考えてみます。

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

Bloomberg Terminalという例

金融のプロが使う「Bloomberg Terminal」って、画面にスパークラインや取引テーブル、ニュースが同時にびっしり表示されてます。見た目はJTC UIと似ていて「情報が詰まってる」状態です。

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

JTCのUIと比べると、Bloombergは「この密度を理解できる専門家だけを対象にした製品」であるのに対し、JTCのUIは「複数の部署の要望が一画面に集約された結果」って点が大きい違いだと思います。

認知負荷の正しい理解

「情報密度が高い＝認知負荷が高い」ってのは、初心者に対しては正しいです。でも毎日使ってるエキスパートにとっては、必ずしもそうとは限りません。

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

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

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

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

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

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

混沌のサインとしては、誰も使わない項目がずっと表示されてる、ラベルと実際の機能が一致しない、同じ情報が複数箇所に重複してる、とかですね。

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

5. UI設計で本当に判断すべきこと

UI設計で本当に大事な判断軸は、三つだけだと思っています。

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

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

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

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

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

6. まとめ

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

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

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

大事なのは「情報密度が高いか低いか」ではなく、「誰のどんな操作のために、その密度があるのか」ってことだと思っています。

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

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

その構造をちゃんと理解した上で設計するかどうか——それが「合理的な業務UI」と「ただの複雑さ」の分かれ目なんじゃないかな、って思います。