この記事の要点（UIXHERO視点） UIXHEROでは、テスラーの法則を「複雑性の押し付け合い、システムの献身」と捉える。 本記事では、どんなプロセスにも消せない「核となる複雑さ」が存在することを認め、それをユーザーに負わせるか、開発者（システム）が汗をかいて引き受けるかという、UX設計の哲学的な分水嶺を整理する。
テスラーの法則 / Tesler's Lawとは？
1980年代、Xerox PARCやAppleで活躍したラリー・テスラーが提唱した「複雑性保存の法則」です。 どのようなプロセスにも、取り除くことのできない「核となる複雑さ（Core Complexity）」が存在します。 重要なのは、「その複雑さを誰が処理するのか？」という点です。
UIデザインのゴールは、プログラムやデザインの工夫によって、ユーザーの肩から複雑さを取り除き、システム側に負担させることです。
テスラーの法則と関連語の違い
検索では「テスラーの法則」「Tesler's Law」「複雑性保存の法則」が混在します。UIXHEROでは、次のように整理します。
| 言葉 | 使い方 |
|---|---|
| テスラーの法則 | UX/UIの文脈でよく使われる日本語表記 |
| Tesler's Law | 英語表記。Larry Teslerに由来する呼び方 |
| 複雑性保存の法則 | 法則の意味を説明する日本語表記。複雑さは消えず、どこかに移るという考え方 |
| Law of Conservation of Complexity | 英語での説明的な呼び方 |
つまり、この法則は「シンプルに見せれば終わり」ではありません。ユーザーに見せない複雑さを、システム設計、デフォルト値、入力補助、サポート設計のどこで引き受けるかを決めるための原則です。
UXデザインでの活用事例
1. 入力自動化
- 悪い例: 住所を「都道府県」「市区町村」「番地」と全て手入力させる。（複雑さはユーザー負担）
- 良い例: 郵便番号を入れるだけで、住所の大半が自動入力される。（複雑さはシステム側のAPI連携が負担）
2. デフォルト値の活用
ほとんどのユーザーが選ぶ設定をあらかじめ選択状態にしておくことで、ユーザーの「選ぶ・考える」という負担を減らします。
3. 文脈の予測
ECサイトで「以前購入した商品」から「次に必要になりそうなもの（消耗品の詰め替えなど）」を提案する機能も、探索の複雑さをシステムが肩代わりしています。
UXで使う判断基準
テスラーの法則を使うときは、「複雑さを減らせるか」よりも「誰に複雑さを持たせるべきか」を考えます。
- ユーザーが毎回同じ情報を入力しているなら、フォーム設計や自動補完でシステム側に移す。
- ユーザーが覚えておく必要がある情報が多いなら、認知負荷を下げるために再表示・要約・確認画面を用意する。
- 多くのユーザーが同じ選択をするなら、デフォルト効果を使って安全な初期値を置く。
- 上級者だけが使う複雑な設定なら、段階的開示で必要なときだけ見せる。
一方で、複雑さをすべて隠すと、ユーザーは何が起きているか分からなくなります。重要な確認、取り消し、例外処理、権限や料金に関わる判断は、ユーザーがコントロールできる状態で残す必要があります。ここがシンプルさとのバランスです。
実装例: 複雑さの転嫁
住所入力を例に、ユーザーが全ての責任を負うパターンと、システムが複雑さを引き受けるパターンの比較デモです。
この原則を実装で見る
この原則が実装でどう形になるかを、GUNJO の部品で確かめられます。
実践ガイドライン (Practical Guidelines)
実装チェックリスト
倫理的配慮 (Ethical Considerations)
複雑さの軽減は素晴らしいことですが、「過度な抽象化」には注意が必要です。 システムがブラックボックスになりすぎて、ユーザーが「何が起きているか全く理解できない」状態になると、エラーが発生した時に誰も対処できなくなります。 また、自動化によってユーザーの選択権やコントロール感を奪いすぎないバランス感覚も重要です。
