はじめに
先日、Xで「日本企業がGitHubを構築した場合はこう」という画像を何気なく投稿しました。
ありがたいことに、これが信じられないくらい伸びまして。
なんと数千件のリツイートに、2万を超えるいいね。インプレッションは400万回を超えました。
次々に届く通知欄と、引用リツイートで流れてくる「うわ、ありそう……」「胃が痛い」「うちの社内システムじゃん」という悲鳴を眺めながら、私は思いました。
「みんな、どれだけJTC（伝統的日本企業）に傷つけられてきたんだ……？」
JTC: Japanese Traditional Company
改めて、私が投稿した画像にちりばめられた要素を見ていきましょう。
- リポジトリ詳細画面なのに、中身が
設計書_基本設計書.xlsxや構成図.pptxといったOfficeドキュメントだらけ - Git（バージョン管理システム）のはずなのに、なぜかブラウザ上に鎮座する「アップロード」ボタンと「※一度にアップロードできるファイルサイズは100MBまでです。」との制限
- 画面下部に鎮座する、上長承認・品質保証部レビュー・セキュリティチェックなどの5段階に及ぶ「変更登録フロー（現在のステータス）」
- お知らせ欄に並ぶ「【再通知】パスワード定期変更のお願い (6月30日まで)」や「Git操作における注意事項について」といった、胃が痛くなる社内ルール
AIに生成してもらった画像ですが、冷静に考えるとこれらはすべて、JTCのどこかのシステムに実在する（あるいはかつて存在した）仕様です。
なぜ、優秀なエンジニアやデザイナーが組織の中にいるはずなのに、いざ業務システムを作ると、このような「警告と手続きの塊」のようなUIが誕生してしまうのか。
単に「デザイナーのセンスがない」で片付けるのは簡単ですが、あの使いにくいUIの裏側には、日本の伝統的な組織が抱える構造的な課題が隠されていると私は思うわけです。
ということで本記事では、なぜあのUIが生まれてしまうのかを大真面目に考察してみましょう。
なぜ「赤文字の注意書き」は無限に増殖するのか
業務システムのトップページを開くと、赤文字や太字の注意書きがこれでもかと並んでいます。
【再通知】パスワード定期変更のお願い (6月30日まで)
※一度にアップロードできるファイルサイズは100MBまでです。
Git操作における注意事項について
画面の8割が「注意」と「警告」で埋まっていますね。
なぜ、こんなことになってしまうのか。
理由は極めてシンプル。
「間違えた人」ではなく「システム」のせいにされる文化だから
JTCにおいて、ユーザーが誤操作をしてデータを消してしまったり、誤送信をしてしまったりした時、組織のリアクションはこうなります。
「なぜシステム側で誤操作を防ぐ仕組みにしなかったのか？」
「なぜ画面に注意喚起を表示していなかったのか？」
責められるのは、不注意なユーザーではなく、システム開発側や運用側なのです。
そこで、開発チームが取れる最もローコストで手軽な責任回避の手段、それが画面に注意書きを付け足すことです。
ほら、画面に赤文字で書いてありますよね？それを読まなかったユーザーの責任です
という免責のための注意書き。
トラブルが起きるたびにこの免責の赤いテキストが追加され続けた結果、画面は注意書きのゴミ箱と化します。
あれはユーザーのためのUIではなく、開発者が身を守るための"よろい"なのです。
なぜ「ハンコ」や「紙の申請」のメタファーが残るのか
件の画像のハイライトでもある「変更登録フロー（現在のステータス）」。
「Approve」ボタンでマージされるのではなく、「1. 変更登録（登録者: 山田太郎）」→「2. 上長承認（承認者: 佐藤課長）」→「3. 品質保証部レビュー」といったガチガチの承認スタンプラリーが並んでいます。
「今どきハンコなんて笑い話でしょ」と思うかもしれませんが、実際の業務システムでは「形を変えたデジタルハンコ（承認ワークフロー）」がこれでもかと寄生しています。
なぜなのか。
それは、「業務プロセス」をシステムに合わせる（BPR）のを諦め、「既存のハンコプロセス」をそのままシステム化するからではないでしょうか？
本来、GitHubのようなモダンなツールを導入する意義は、ツールそのものの機能だけでなく、その背景にある「フラットなレビュー」「非同期コミュニケーション」「開発者の自律」を導入することにあると思います。
しかし、組織側はこうです。
「我が社の規程では、リリースには部長の決裁（ハンコ）が必須となっている。そこは曲げられない」
結果として、Gitの「Approve」というシンプルな機能が、無理やり「稟議（起案・回覧・決裁）」に翻訳され、"マージするために、佐藤課長の上長承認や品質保証部のレビューをスタンプラリーのように集める変更登録フロー"が爆誕するのです。
ツールだけを最新にしても、組織の「責任の取り方」が変わらなければ、中身は昭和の稟議書のまま変わりません。
なぜ情報は1画面にギチギチに詰め込まれるのか
「XcodeManager」を見てもわかる通り、日本の業務システムはとにかく余白がないです。
「ポータル」「開発管理」「構成管理」「変更管理」「リリース管理」「品質管理」「資産管理」「共通管理」という圧倒的なタブメニュー。そこにサイドバー、お知らせ、ショートカット、ToDo一覧、課題票一覧、プルリクエスト一覧が、極小フォントで1画面にギュッと凝縮されています。
デザイナーが「もっと余白をとって、情報を整理しましょう」と提案すると、決裁者（主に偉いおじさんたち）から強烈な呪文が飛んできます。
「スクロールしないと見られないのは使いにくい」
「1画面ですべての情報を把握させろ」
彼らにとって、スクロールは「悪」であり、余白は「サボり」なのです。
情報を整理してタブに分けたり、ページを分割したりすると、今度は「情報が隠れていて見つけられない」「ワンクリックでいけない」と猛クレームが入ります。
結果、開発チームは余白を恐れるようになり、すべての情報を1画面に詰め込み、ダッシュボードという名の「情報過多の暴力」が出来上がります。
美しいUI/UXは、「情報の引き算」で決まる。
しかし、業務システムのUIは、「責任の足し算」と「クレーム回避の足し算」で画面が埋まっていきます。
要件定義における「監査・セキュリティ部門」の圧倒的権力
なぜ、こんな使いにくいUIが誰にも止められないのか。
それは、要件定義や検収のフェーズにおいて、「使いやすさ（UX）」を評価する指標（KPI）が存在しないからではないでしょうか。
「この画面、前より3倍使いやすくなりました！」と言っても、誰も評価してくれないし、予算もつきません。
一方で、「情報漏洩リスク」や「監査コンプライアンス」は、何かあったら即座に担当者の首が飛ぶレベルの強力なマイナスの評価指標です。
そうなると、力関係は一瞬で決まります。
- 開発/デザイナー: 「使い勝手を良くするために、セッション維持時間を長くしたいです」
- セキュリティ部門: 「セキュリティリスクがある。10分で自動ログアウト、毎回ワンタイムパスワード入力を必須にしろ」
UX側にはそれを覆す「大義名分（数字）」がないため、使いやすさを犠牲にした「安全という名の嫌がらせ仕様」が、無条件で通過することになります。
右クリック禁止、コピー＆ペースト禁止、20文字以上の複雑なパスワード……
これらの「使いにくいUI」は、セキュリティ部門が「仕事をしています」とアピールするための実績づくりとして生み出されている側面すらあるのではないでしょうか。
まとめ：使いやすいUI/UXは、「信頼のデザイン」から生まれる
結局のところ、警告だらけで、がんじがらめの業務システムUIは、システムがユーザーを信頼していないこと、そして組織がメンバーを信頼していないことの現れであると私は思います。
「どうせユーザーは間違える」
「どうせユーザーはルールを守らない」
「だからシステムで縛り、画面にデカデカと警告を書き、何重もの承認プロセスで監視する」
この「性悪説」に基づいた思想が、あのノイズだらけのUIを形作っています。
逆に、GitHubなどのモダンなITツールのUIがシンプルなのは、デザイナーが優秀だからだけではありません。
「開発者はプロフェッショナルであり、信頼に足る存在である」という「性善説」と「自律」を前提とした開発カルチャーがあるからこそ、あのシンプルな画面が維持できるのだと思います。
もし私たちが、社内の「使いにくい業務システム」を本当に改善したいのであれば、変えるべきはUIのCSSやフレームワークではなく、組織の「責任の取り方」であり、メンバーに対する「信頼のデザイン」そのものなのだと思います。
もし面白いとおもったらいいねとストックをお願いします！