2026年度新卒エンジニアとして入社した花です。
突然ですが、まず以下の画像をご覧ください。

（自作図）

いかがでしょうか？
順番通りに読んでしまっていた方が多いのではないでしょうか。

どんなに自分の意思で自由に読もうとしても、脳は文字の大きさ・コントラスト・余白といった視覚情報から無意識に優先順位（視覚的階層構造）を判断し、作り手の意図通りに動かされてしまいます。
大学時代に情報デザインやヒューマンインタフェースを学んでいた私は、入社して開発オンボーディングを行う中でふと気づきました。

「直感的なUIデザイン」も「可読性の高いコード」も、目指している本質は全く同じなのではないか？

どちらも「人間の脳の仕様」を理解し、認知負荷をいかに減らすかという最適化問題です。
今回は、大学で学んだ認知心理学やゲシュタルトの法則をベースに、「ユーザーの脳」と「コードを読む開発者の脳」に優しいUI実装とJavaコード設計の共通点を3つの視点から整理してみました。

1. 【視覚と構造】ゲシュタルトの法則 ✕ 空行・インデント

人間には「目から入ってきたバラバラの視覚情報を、自動的にグループやパターンとして構造化して認識する」という心理的特性があります（ゲシュタルトの法則）。
エンジニアがコードを読むときも同様で、ロジックを解釈する前に、まずは周辺視野で「コードの見た目の形」を無意識に捉えています。

〇近接の法則：空行は思考のグループ化

これは「近い位置にあるもの同士は同じグループに見える」というもの。

UI：関連するフォームの入力欄とラベルを近づけ、次の項目との間には広い余白をとる。
コード：処理と処理の間に「意図的な空行」を入れることで、「ここがひとまとまりの処理単位である」と脳へ直感的に伝えられる。

public class OrderService {
    // マジックナンバーを回避
    private static final double TAX_RATE = 0.1;

    // ✖ 処理が凝縮されていて、どこからどこまでがひとまとまりか脳が一瞬で捉えられない
    public void processOrderBad(User user, Order order) {
        if (!user.isActive()) return;
        double tax = order.getAmount() * TAX_RATE;
        double total = order.getAmount() + tax;
        order.setFinalPrice(total);
        notificationService.sendOrderConfirmation(user, order);
    }

    // ◎ 近接の法則を活用し、役割ごとに空行でグループ化
    public void processOrderGood(User user, Order order) {
        // 1. バリデーション
        if (!user.isActive()) return;

        // 2. 金額計算と設定
        double tax = order.getAmount() * TAX_RATE;
        double total = order.getAmount() + tax;
        order.setFinalPrice(total);

        // 3. 事後処理
        notificationService.sendOrderConfirmation(user, order);
    }
}

〇閉鎖の法則：ネストの深さは「脳のコンテキスト維持」を疲弊させる

これは「閉じられた領域を一つの塊として認識する」というもの。
if 文や for 文のネストが深くなると、脳は「いま自分はどの枠組みの中にいるのか」というコンテキストを常に保持しなければならず、急激に認知負荷が高まります。ガード節（関数の上部で単純な条件を先に処理するもの）を使ってネストを浅くすることは、脳が保持し続けるべき枠組み（閉じた領域）を早期に破棄し、脳のメモリを解放するための非常に効果的なリファクタリング手法です。

// ✖ ネストが深く、脳のメモリ（コンテキスト）を消費してしまう
public String processUser(User user) {
    if (user != null) {
        if (user.isActive()) {
            if (user.hasPermission()) {
                // ここに到達したとき、脳は3つのif条件をすべて保持していないと理解できない
                return doSomething(user);
            }
        }
    }
    return null;
}

// ◎ ガード節で枠組み（コンテキスト）をすぐに破棄する
public String processUser(User user) {
    if (user == null) return null;
    if (!user.isActive()) return null;
    if (!user.hasPermission()) return null;

    // 思考のスコープ（枠組み）がリセットされ、ここだけに集中できる
    return doSomething(user);
}

2. 【記憶の限界】ワーキングメモリ ✕ メソッド分割

認知心理学において、人間が短期的に頭の中で保持・操作できる記憶領域（ワーキングメモリ）は「同時に4±1項目（3〜5個）程度」と言われています（ネルソン・コーワンによる「マジックナンバー4」）。PCのメモリと比べて、人間の脳のメモリは非常に小さく、すぐにオーバーフローを起こします。

UI：一度に大量の入力項目やボタンを見せられると、お客様（ユーザー）のワーキングメモリがパンクしてしまいます。そのため、アコーディオンUI（クリックやタップにより隠れている文章やメニューを表示する）やステップ分けフォームのように必要な時に必要な情報だけを見せる段階的開示が用いられます。
コード：Javaのメソッド内で追うべきローカル変数や状態が5個以上になると、脳のメモリがオーバーフローし、バグの見落としに直結します。長大なメソッドから関数の抽出を行い、変数のスコープを局所化することは、読者のワーキングメモリに載せる状態を常に3〜4個以下に抑える手段です。

// ✖ 追うべき変数や状態が多すぎて脳のメモリ（4±1個）を使い果たす
public void processUserPurchase(User user, Item item) {
    // 100行に及ぶ処理の中で user, item, price, tax, discount, points, stock...
    // 多数の変数が入り乱れ、脳のワーキングメモリが破綻する
    
    double price = item.getPrice();
    double tax = price * 0.1;
    double discount = user.getDiscountRate() * price;
    double finalPrice = price + tax - discount;
    
    // ...決済処理、ポイント付与、在庫更新などが長々と続く
}

// ◎ 単一責任のメソッドに分割（関数の抽出）。1つのメソッドで追う変数は常に2〜3個
public void processUserPurchase(User user, Item item) {
    // 追う変数：user, item, finalPrice（3つだけ）
    double finalPrice = calculateFinalPrice(user, item);
    executePayment(user, finalPrice);
    updateInventoryAndPoints(user, item);
}

「1つのメソッドを短くする」「カプセル化する」というクリーンコードの原則は、単なる見た目の問題ではありません。その本質は「読み手のワーキングメモリ容量に対する人間工学的な配慮」です。

3. 【記憶の省力化】想起（Recall）vs 認識（Recognition） ✕ Javaの型システム（Enum）

人間の脳にとって、ゼロから記憶を呼び出す「想起」は非常に負荷のかかる作業です。一方で、提示された選択肢から選ぶ「認識」は一瞬で行うことができます。

UI：検索窓に自由入力させる（想起）よりも、ドロップダウンで選択肢を表示したり（認識）、入力補完を出す方がユーザーは迷わず操作することができます。
コード：Enumの活用
静的型付け言語であるJavaにおいて、この「認識」を活用した設計は非常に強力です。メソッドの引数に String や int等を使うと、呼び出し側は「どんな文字列を渡せばいいんだっけ？」とドキュメントを遡って「想起」しなければなりません。

// ✖ 何でも書けてしまうので、間違えた文字が入る危険がある
String today = "月曜日"; 
String today2 = "Monday"; 
String today3 = "月ようび"; 
String today4 = "はな"; // 曜日ですらない意味不明な文字も入れてしまえる


// ◎ 選択肢のリスト（Enum）を定義する
public enum DayOfWeek {
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY
}

// 使うときは、この中から選ぶしかない
DayOfWeek today = DayOfWeek.MONDAY; // OK
DayOfWeek today2 = DayOfWeek.HANA; // コンパイルエラー（そんな曜日はない）

型を厳格に定義することは、安全性を高めるだけでなく、他の開発者の記憶力に依存しない確実なインターフェースの提供につながります。

おわりに：脳の仕様を意識できるエンジニアを目指して

開発オンボーディングを通して、「読みやすいコードとは何か」「良いUI実装とは何か」を日々試行錯誤しています。
大学で学んだ情報デザインや認知心理学の知見を振り返ってみると、すべては「CPUにとどまらず、人間の脳の処理負荷をいかに下げるか」という点に集約されていると感じます。

画面の向こうにいるユーザーの脳に配慮したUI実装
コードを読むチームメンバーの脳に配慮したJavaのコード設計

未熟な身ではありますが、今後は単に仕様を満たすコードを書くだけでなく、心理学的な根拠を持って脳に優しいプロダクトコードを書くことのできるエンジニアを目指していきたいと思います。
ぜひ先輩方の「可読性を上げるために意識している工夫」などがあれば、教えていただけると嬉しいです。

参考文献

Dustin Boswell, Trevor Foucher 著、角征典訳 (2012) 『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』オライリー・ジャパン
Cowan, N. (2001). The magical number 4 in short-term memory （ネルソン・コーワンによるワーキングメモリに関する研究）
- ※大学の情報デザイン関連の講義スライドおよび配布資料を参照