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

結論、JTC業務UIの収束は単なる怠慢でも純粋な偶然でもありません。 組織的要因・ユーザー要因・開発プロセス要因・運用要因の四つが重なった結果です。 ただし、「収束の構造を理解した上で設計しているか」と「設計根拠が明示されないまま慣例で固定されているか」では、合理的な密度と単なる混沌を分けます。

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

少し前、Xで「〇〇がGitHubを構築したら」という一連のポストが話題になっていました。 さまざまな企業や国のスタイルに当てはめてGitHubを想像する、というネタ投稿の流れです。

その中に「もし日本企業がGitHubを構築したら」という投稿がありました（@shiro_shihi）。

内容は、びっしりと並んだ項目、横に伸びるタブ群、Excelライクな一覧表、小さなフォントで詰め込まれた情報、大量のボタン。 見た瞬間、業務システムで何度も見たレイアウトと一致しました。

リプ欄は賛同が多かったです。 エンジニアもデザイナーも、業種を問わず「見たことある」「これこれ」という反応です。 このポストへの反応を見ると、JTC業務UIへの「あるある認識」がすでに広く共有されていると読み取れます。

では、なぜああなるのか。以下では四つの要因に分解して整理します。

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

まず用語を整理します。

JTC（Japanese Traditional Company）は、日本の伝統的な大企業を指すネットスラングです。大手メーカー・金融機関・通信会社・商社など、いわゆる「日本型企業」を指す場合が多く、2019年頃からXで用例が広まった言葉です。

「JTC UI」と呼ぶ場合、具体的には以下の特徴を指します。

• 画面上部に横並びのタブが大量にある
• ボタンの種類と数が多い（登録・更新・削除・確認・戻る・キャンセル・一覧・印刷…）
• 情報密度が高く、フォントが小さい
• テーブルが中心で、Excelとほぼ同じレイアウト
• 検索条件エリアが画面上部を占拠している
• 入力フォームの項目数が多い
• 色使いはくすんでいて、階層構造が深い

問題は「なぜそうなるのか」を構造として理解することです。 それができると、「見づらいからシンプルにしよう」の議論が、もう少し精度の高いものになります。

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

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

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

大企業の業務システムは、複数の部署が同じ画面を使います。 営業・経理・管理・法務・物流など、部署ごとに必要な情報が違います。 その結果、各部署の要望が一つの画面に集約されます。

承認は多段階になりがちで、それがまた画面上に積み上がります。 申請→確認→承認→差し戻し→再申請といった流れに対応するため、ボタンとステータス表示が並びます。 権限によって見えるボタンを変える設計も可能ですが、出し分けロジックが複雑になるため、「全部表示して非活性にする」判断がなされやすいです。 これは怠慢というより、承認の複雑さをUIで処理するときのコスト最小化の帰結と見るほうが正確です。

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

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

Nielsen Norman Group の「Novice vs. Expert Users」では、ミッションクリティカルな業務においてはHCIの中心的な目標が操作速度（transaction throughput）と熟練者の複雑タスク支援に移ることを、電話会社のディレクトリUIや打ち上げ管制の事例から論じています。 私の読みでは、業務UIの「一画面に詰め込む」設計思想とも、これは一本の線でつながります。

定常オペレーターが多い環境では、学習コストが高いことはさほど問題になりません。 研修期間があり、マニュアルがあり、そのシステムを何年も使い続けることが前提だからです。 実務上は、操作を1秒速くこなせるかどうかが年単位で積み上がると、大きなコスト差になります。 情報をまとめて一画面に出す設計は、ページ遷移を減らし、操作ステップを短縮する合理的な選択です。

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

固定価格・一括リリース型の案件では、要件定義段階で全機能を確定させる必要があります。 将来使う可能性が低い項目も先行実装される構造になりやすく、不要な項目が蓄積しやすいです。 各部署の要望を全部拾おうとした結果、「どこかの部署にとっては必要」という理由で項目が削れなくなります。 つまり、「帳票の形そのまま」に見えるUIは、利害調整の結果が画面に堆積したものと考えるとよく説明できます。

日本では帳票文化が強いと言われています。 「帳」（帳簿）と「票」（伝票）で記録と証拠を細かく管理する慣行が、コンピュータ化の際にも引き継がれた傾向があります。 罫線・矩形・桁区切りだらけの帳票形式が、そのまま画面レイアウトに移植されたケースは珍しくありません。

メインフレーム時代（1970〜90年代）に確立されたUIパターンが、オープン化の際にも踏襲された企業は多いです。 ただしこれは傾向の話であり、企業・業界によって差はあります。

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

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

既存システムとの連携要件も設計を制約します。 レガシーシステムのデータ構造に合わせる必要があるため、UIの最適化より連携の安定性が優先されます。 具体的には、画面の項目順が変えられない、コード値に欠番が使えない、ラベルを変更するとマスタ連携が崩れる、といった制約がレイアウトに直接影響します。

「マニュアル文化」も重要な要因です。 操作手順書・研修資料を前提にした設計では、画面に全項目・全ボタンを出しておく方が「説明しやすい」という判断が働きます。 ラベルを省略するより「画面にそのまま名前が書いてある」状態が、マニュアル作成・教育コストを下げるからです。

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

§3では「なぜその形になるか」を分解しました。ここからは「その密度が妥当かどうか」の問いに移ります。

「JTC UIは非合理だ」という批判は、ある前提で見れば当たります。 ただしその前提が「Consumer向けサービスのユーザー像」であった場合、批判の方向がずれています。

Bloomberg Terminalという対比

Bloomberg Terminal は、金融のプロフェッショナル向けツールです。 画面には、主要市場指数のスパークライン・取引量の詳細テーブル・ニュースフィード・キーボードショートカットが同時に表示されます。 見た目だけで言えば「情報が詰め込まれている」——JTC UIと同様です。

Bloomberg Terminal は35万人以上の金融意思決定者が毎日使うプロダクトです（参照: How Bloomberg Terminal UX designers conceal complexity）。 Bloomberg CTO の Shawn Edwards は「複雑さを隠す。数千の機能にまたがって、ユーザーがシームレスに使えるようにする」という設計哲学を語っています。 ここで「隠す」のは「情報を減らす」という意味ではなく、判断に不要な複雑さを背後に下げることです。

Bloomberg の UX Manager である Fahd Arshad は「デザインの議論はほぼ desirability（好み）の話にならない。ユーザーがどんな価値を得るかだけを議論する」と述べています。 35万人のトレーダーはこの密度を日常的に使いこなしています。JTCのUIと見た目は似ていても、設計プロセスの出発点が違います。

いっぽう、JTCの業務UIとBloomberg Terminalは同じ文脈ではありません。 違いをひとことで言えば、Bloombergは「この密度を理解できる専門家だけを対象にした製品」であり、JTCのUIは「複数の利害関係者の要望が一画面に集約された結果」です。 ここで Bloomberg を引用する目的は「高密度 = 常に合理的」を主張するためではなく、「密度そのものが悪ではない」という例として見ることです。

認知負荷の正しい理解

「情報密度が高い = 認知負荷が高い」というのは、ノービスユーザーに対しては正しいです。 エキスパートユーザーに対しては、必ずしも正しくありません。

NNGの「Testing Expert Users」でも、熟練ユーザーの行動は自動化されると述べられています。 複雑な操作パターンでも、使い込めば「頭を使わずに」動かせる状態になります。 その前提で画面を細かく刻むほうが往復コストが増えてかえって遅く感じられる——これは§3の「一画面集約で操作ステップを短縮する」という設計選択とも対応しています。

NNGのcontent dispersion（コンテンツの分散）に関する研究でも、スカスカな画面はモバイルファーストのデザインをPCで表示した結果として生まれやすく、同一ページ内で関連コンテンツが散在しスクロールが増えることで使いやすさが低下すると指摘されています（参照: Scaling User Interfaces）。

高密度が免罪符になるわけでもない。 操作結果のフィードバックが遅い・エラー理由が画面に出ない・入力後の変化がわかりにくい、といった問題は「密度」とは別軸のUX課題です。 情報が多くても、feedback と error prevention が機能しなければミス率は上がります。 同様に、密度が高くても affordance（操作可能性の視覚的手がかり）が弱ければ誤操作を誘発します。「情報が詰まっている」と「使える情報が整理されている」は別物です。

Consumer向けUIと業務向けUIの比較

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

「合理的な密度」と「単なる混沌」は別物です。

エキスパート前提の高密度設計は合理的な賭けとして筋が通ります。 要件の積み上げだけで作られた「誰も整理していない密度」は、エキスパートにとっても扱いにくいです。 混沌の兆候としては、誰も使わない項目が常時表示されている・ラベルと実機能が一致しない・同一情報が複数箇所に重複している、といったシグナルが目安になります。

「誰のどんな操作のために、何を画面に出すか」——設計者がそれを言えるかどうかが分かれ目です。 後の衝突を減らすためにも、実務ではまずこの一文を言語化できるかどうかから始めたほうがいいです。

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

UI設計の判断軸は三つです。

誰が使うか（ユーザー像）

ノービスとエキスパートでは、最適な設計が変わります。 「エキスパートになる前のユーザー体験」をどこまで設計に含めるかは、ユーザー集団の固定度によります。 NNGの「Testing Expert Users」では、人員の入替や新規ユーザーが継続的に現れる組織では「ノービス体験を無視するのはリスクがある」と指摘しています。 実際に判断するなら、離職率・人員の回転速度・立ち上がりに何週間かかるかを確認してから決める、というのが現実的です。

どんなタスクか（タスク性質）

反復作業と探索的操作では、最適な設計が違います。 毎日同じ伝票を叩き込む業務なら、まず削るべきは操作ステップの総量です。 データを分析して意思決定する業務なら、情報の見通しやすさと比較のしやすさが優先されます。 同じシステムでも、タスクが混在する場合はモード分けか導線の優先度設計が必要です。

どれくらいの頻度か（使用頻度）

年に一度しか使わない機能と、毎日100回操作する機能を同じ優先度で扱うべきではありません。 触る回数が多い機能なら、ショートカット・キーボード操作・一画面集約が効いてきます。 年に数回しか使わない機能なら、導線を長めにしてガイドや補足説明を厚くするほうが合います。

これら三つを明確にしないまま「この画面、見づらいよね」「もっとシンプルにしよう」と議論しても、判断基準がありません。

現代の業務SaaSの一部には「Consumer寄りすぎ」の問題があります。 たとえば申請一覧と詳細が別画面に分かれており、週に何十件もの承認作業をするエキスパートが確認のたびに行き来が必要になるケース。見た目はきれいでも、エキスパートからは「前のシステムのほうが速かった」と言われます。 会議で「見づらい」が出る前に、Consumer前提の延長か業務前提かを合意しておかないと、比較対象すらそろわない状態になります。

6. まとめ

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

• 組織的要因：多部署対応・承認フロー・権限の複雑さ
• ユーザー要因：エキスパートユーザー前提・学習コストより操作速度を優先
• 開発プロセス要因：要件の積み上げ・帳票文化・メインフレーム時代からの踏襲
• 運用要因：印刷要件・レガシー連携・マニュアル文化

そのUIが一見非合理に見えても、使われる場所・使う人・タスクの性質によっては最適解になります。 Bloomberg Terminalが40年以上にわたって高い情報密度を維持しながら使われ続けているのが、設計の文脈は異なるものの、その一例です。

争点は「情報密度が高いか低いか」ではありません。 「誰のどんな操作のために、その密度があるか」——そこが問われています。

「見づらいからシンプルに」だけで削ると、熟練者の手が遅くなる画面が出ます。 一方で「業務だから詰め込みは当然」で止まると、誰のための整理かが曖昧なまま残ります。

JTC UIが「あるある」として広く認識されているのは、設計根拠が明示されないまま積み上がったUIへの再現度の高い経験が、業界を問わず共有されているからです。 その構造を理解した上で設計するかどうかが、合理的な業務UIと単なる複雑さの分かれ目です。