人生はもっとシンプルであったほうがよい。しかし、選択肢や能力を犠牲にしたくもないのです。テスラーの複雑性保存の法則は、設計からのルールであり、私たちが両方を手に入れることができない理由を説明しています。この法則が、シンプルさを見直すことで、より良いプロダクトやサービスを生み出すのにどのように役立つかを紹介しましょう。
「なぜ人生はシンプルであってはいけないのか？」
誰もが一度はそう自問したことがあるでしょう。結局のところ、人生は複雑です。私たちは毎日、ほとんど無限に繰り返されるように見えるプロセスに直面しています。各ステップは、それを可能にするために別のタスクを完了する必要があり、それ自体が別のタスクを必要とします。道具を使いこなすためには、膨大な知識を暗記し、新たなスキルを身につけなければならないのです。新しい家で光熱費をつなぐとか、冷蔵庫の制御を理解するとか、簡単そうに見える努力も、結局は多くの不可解なステップを踏むことになります。
私たちが物事をよりシンプルにしたいと願うとき、それは通常、プロダクトやサービスに少ないステップ、少ないコントロール、少ないオプション、覚えることの少なさを望むことを意味します。しかし同時に、私たちは同じ機能や性能のすべてを求めています。この2つの願望はしばしば対立し、複雑なものを理解する方法を歪めてしまいます。
概念モデル
"複雑さとともに生きる"の中で、ドナルド・A・ノーマンは、複雑さはすべて心の中にあると説明しています。私たちがプロダクトやサービスを単純または複雑と認識するのは、その概念モデルに根拠があるからです。ノーマンは次のように書いています。「概念モデルとは、何かがどのように機能するかについて、人が持つ根本的な信念構造のことです。概念モデルは、そうでなければ複雑なものを組織化し理解するための非常に重要なツールです」。
例えば、多くのコンピュータでは、ファイルをフォルダにドラッグ・アンド・ドロップすることができます。ファイルとフォルダの両方には、現実世界の名前を表すアイコンが付いていることが多いのです。ユーザーにとって、このプロセスは単純であり、明確な概念モデルを提供します。グラフィカル・インターフェースを使い始めたころは、実世界の用語やアイコンのおかげで、何をしているのか簡単に理解できました。しかし、このプロセスが単純に見えるのは、この効果的な概念モデルのおかげに過ぎないのです。ファイルやフォルダーが存在しないコンピューター上で起こっていることを表しているわけではないのです。コンピューターは都合の良い場所にデータを保存し、複数の場所にファイルを分割することもあります。
一度使い方を知ってしまえば、複雑なツールは結局、私たちの生活をよりシンプルにしてくれます。コンピュータのファイルは、物理的なファイルとフォルダという、人々がすでに理解しているものを乗っ取ったからこそ、優れた概念モデルなのです。コンピュータが実際にどのようにファイルを保存しているかを反映した全く新しい概念モデルを開発するのは、はるかに難しかったでしょう。重要なのは、このシンプルな概念モデルをユーザーに与えたからといって、物事が裏でどのように動いているのかが変わるわけではないということです。
機能を削除しても、選択肢がなくなるので、何かがシンプルになるわけではないのです。シンプルなツールは、プロセスを単純化する能力に限界があります。単純なツールで複雑なことをしようとすると、より複雑なツールで同じことをするよりも複雑になります。
ここで役に立つ例えは、職人が使う手工具、例えば銀細工師のプレーニッシングハンマー（金属の表面を削り、滑らかにするための道具）です。ノーマンは、これらの道具は素人目には単純に見えると強調します。しかし、それを使いこなすには高度な技術と練習が必要なのです。職人は、自分が持っている専門的な道具の数々から、どのようにそれらを選ぶかを知っている必要があります。
カンナをかけるハンマーは、それ自体、例えばデジタル写真編集プログラムよりもずっとずっと単純に見えるかもしれません。ノーマンは言います。写真編集ツールと銀細工師の作業台全体を比較しなければならないのです。どちらも使いこなすには多くの時間と練習が必要です。どちらも、ひとつひとつはシンプルな多くの道具で構成されています。それらをいつ、どのように使うかを学ぶことが複雑な部分なのです。
ノーマンはこうも書いています。「道具が並んだ作業台やデジタル写真編集プログラムを見て、初心者は複雑さを感じます。」プロはさまざまなツールを見て、それぞれが簡単に使えると思います。彼らはプロセスを簡単にするために、それぞれをいつ使うべきかを知っています。選択肢が少なければ、やるべきことをひとつひとつシンプルなステップに分解することができないため、彼らの生活はシンプルになるどころか、より複雑になってしまいます。プロフェッショナルは、経験で磨かれた概念モデルによって、さまざまなツールを使いこなすことができるのです。
複雑性の保存
難しいことを最もシンプルな方法で行うには、多くの選択肢が必要です。
複雑さが必要なのは、それが必要な機能を与えてくれるからです。これを理解するのに有用なフレームワークが、テスラーの複雑性保存の法則です：
システムの複雑さの総和は一定である。ユーザーとシステムとのインタラクションをよりシンプルにすると、舞台裏の複雑さは増大する。
この法則は、ゼロックス、アップル、アマゾン、ヤフーで働いた人間とコンピュータのインタラクションを専門とするコンピュータ科学者、ローレンス・テスラー（1945-2020）に由来します。 テスラーは初期のグラフィカル・インターフェースの開発に影響を与え、コピー＆ペースト機能の共同開発者でもあります。
複雑さはエネルギーのようなもので、創造することも破壊することもできないのです。プロダクトやサービスがユーザーにとってよりシンプルになれば、エンジニアやデザイナーはより懸命に働かなければならないのです。ノーマンは次のように書いています。「テクノロジーでは、使用レベルで単純化すると、必ず根本的なメカニズムが複雑化する。」例えば、コンピュータのインターフェースにおけるファイルとフォルダの概念モデルは、ファイルがどのように保存されるかを変えるものではないが、そのプロセスを認識可能なものに変換するために余分な作業を行うことで、デザイナーはユーザーにとってナビゲーションを容易にします。
見た目がシンプルかどうか、使い方がシンプルかどうかは、その全体的な複雑さについてはほとんど語らないのです。表面的には単純なものでも、内部はとてつもなく複雑です。では、誰の視点から複雑さを測るのか？"
制御不能
すべての機能にはコントロールが必要です。何かが複雑であればあるほど、ユーザーから見えるか見えないかにかかわらず、より多くのコントロールが必要になります。コントロールは、iPhoneのホームボタンのようにユーザーが直接アクセスできる場合もあれば、自動サーモスタットのように舞台裏にある場合もあります。
ユーザーの立場からすれば、最もシンプルなプロダクトやサービスとは、完全に自動化され、（何か問題が起きない限り）介入を必要としないものです。
あなたが料金を支払っている限り、あなたの家への水道供給はおそらく完全に自動化されています。水道の蛇口をひねったとき、最初にパイプに水があることを要求する必要はないのです。水道を管理する会社が複雑な手続きを行っているのです。
あるいは、高価なホテルに泊まれば、部屋はいつもあなたの希望通りになっているかもしれません。ミニ冷蔵庫には、あなたのお気に入りが十分にストックされ、アメニティグッズも用意され忘れているかもしれません。あなたがリクエストするまでもなく、スタッフは舞台裏でこれを実現するために働いているのです。
一方、ユーザーが最後の一歩までコントロールしなければならないプロダクトやサービスもあります。
プロの写真家は、ホワイトバランスからシャッタースピードまで、あらゆる設定を手動で行う必要があるカメラを使っている可能性が高いでしょう。つまり、カメラ自体は自動化を必要としないが、ユーザーはすべてのコントロールを操作する必要があり、結果を完全にコントロールすることができます。アマチュア写真家は、これらの設定を自動的に選択するカメラを使うかもしれません。この場合、複雑さはカメラの内部構造に移ります。
イケアストア内のレストランでは、飲み物を入れたり、食器を片付けたりといった作業は通常、客が自分で行います。つまり、スタッフがこれらの作業を行うレストランに比べ、スタッフの複雑さが軽減され、価格もずっと安くなります。
複雑性の保存からの教訓
複雑性保存のテスラーの法則から得られる最初の教訓は、見た目がいかにシンプルであるかは、それがいかにシンプルに使えるかを反映するものではないということです。複雑さの動きを概念化する一つの方法は、トレードオフという概念です。複雑さが一定であれば、その複雑さをどこに移動させるかによってトレードオフが生じます。
複雑さのトレードオフの非常に基本的な例は、算数の歴史に見ることができます。何世紀もの間、世界中の多くの計数システムは、数の足し算や引き算を容易にするために、タブラ（ローマ人）やそろばん（日本人）のような石やビーズを使った道具を採用していました。これらは使いやすかったが、持ち運びは容易ではなかったのです。その後、ヒンドゥー・アラビア・システム（今日私たちが使っているシステム）が登場し、柱を使うことで可動部分を必要とせず、より携帯性に優れた計数システムを提供するようになりました。しかし、可搬性には代償が伴います。
ポール・ロックハートは算術の中で次のように説明しています。 「ヒンドゥー・アラビック・システムでは、書くことと計算することが表裏一体となっています。石を動かしたり、ビーズをスライドさせたりする代わりに、私たちの操作はシンボルそのものの変換になります。つまり、私たちは物事を知る必要があります。例えば、3は2より1多いということを知る必要があります。言い換えれば、私たちが（移植性のために）支払う代償は、大量の暗記です。より単純な算数システムは、ユーザーに要求される暗記という点で、より複雑さを要求します。私たちは皆、人生の初期に数学記号を覚えるという難しいプロセスを経験しました。今となっては単純に思えるかもしれないが、それは慣れ親しんだからにほかならないのです。
最初は単純であることに魅力を感じるかもしれないが、それが操作の複雑さを意味するのであれば、ユーザーはすぐに不満を感じるようになります。ノーマンはこう書いています：
知覚されるシンプルさは、使い方のシンプルさ、つまり操作のシンプルさとはまったく違います。知覚されるシンプルさは、目に見えるコントロールやディスプレイの数が増えるにつれて減少します。目に見える選択肢の数を増やすと、知覚されるシンプルさは低下します。問題は、操作や表示の数を増やすことによって、操作のシンプルさが劇的に改善される可能性があることです。何かを習得しやすくし、使いやすくするものそのものが、それをより難しいと認識させることもあります。
たとえ使用前に否定的な反応を受けたとしても、操作のシンプルさの方がより重要な目標なのです。例えば、企業において、プロジェクトごとに直接の責任者を明示することは、プロジェクトをチームワークで進め、それぞれのパートに最適な人に任せるよりも複雑に見えるかもしれません。しかし実際には、誰かがそれを進めようとするときや、問題についてのフィードバックを誰が聞くべきかを知る必要があるときに、複雑さが増す。
第二の教訓は、ユーザーにとって物事は常に驚くほどシンプルである必要はないということです。プロダクトやサービスがシンプルすぎると、ユーザーは不審に思ったり、コントロールを奪われたように感じたりします。ユーザーは、舞台裏でもっと多くのことが行われていることを知っているが、それが何なのか知らないだけなのです。ユーザーが実際の参加者のように感じられるよう、最低限の複雑さを保つ必要がある場合もあります。伝説によると、ケーキミックスには新鮮な卵を加える必要があるが、これは初期のユーザーが、乾燥卵はちょっと手抜きで手間がかからないと感じたからだといいます。
最小限の複雑さが望ましい例として、宿題の手伝いがあります。多くの親にとって、子供の宿題を手伝うことは不必要な複雑さのように感じられることが多いでしょう。それはたいてい、何年も考えたこともないような題材や事実であり、子供を助けるためにそれらを学び直さなければならないことに気づくのです。教師が授業ですべてをカバーし、子どもたちが追加の練習を必要としない程度にできれば、はるかに単純なことです。しかし、宿題のプロセスに親を参加させることで、複雑さが生まれります。さらに、苦手な分野や興味のある分野についての洞察を得たり、子どもとのよりよい関係を築く方法を見つけたり、より幅広いライフスキルを子どもに教えるにはどうしたらよいかを学んだりすることができます。
他人のために物事を単純化しようとするとき、それ以上単純化するとより悪い経験につながるという、負のリターンが逓減するポイントがあることを認識すべきです。単純化すること自体が目的なのではなく、スピード、使いやすさ、時間の節約といった他のことが目的なのです。私たちは、ユーザーの立場から、単純化そのもののために物事を単純化すべきではないのです。
もし変更がユーザーにとってより良いものにならないのであれば、舞台裏で不必要な複雑さを作り出しているだけです。特に重要なことに関しては、人はコントロールされていると感じたいものです。何が起きているのか少しは知りたいもので、単純すぎるプロセスは何も教えてくれないのです。
第3の教訓は、プロダクトやサービスの品質は、それらがうまく機能しなかったときに何が起こるかにかかっているということです。ユーザー側で多くのコントロールがあるもので問題を処理することは、ユーザーにとって簡単かもしれません。
ユーザー側に多くのコントロールがあるものでの問題処理は、ユーザーにとって簡単かもしれません。しかし、何かが壊れる時点まで完全に自動化されていた場合、ユーザーはどう反応していいかわからないのです。その変化は衝撃的で、固まったり過剰に反応したりするかもしれません。完全に自動化されたものが背景に消えていくのを見ると、これはプロダクトやサービスとの最も顕著で記憶に残るインタラクションかもしれません。問題の対処がユーザーにとって困難な場合、例えば迅速なサポートや指示が得られなかったり、そもそも何が問題だったのかを確認するのが難しい場合、たとえ何年も前からすべてがうまくいっていたとしても、全体的にネガティブな印象を持ってしまうかもしれません。
自動運転車の開発における大きな課題は、クルマに問題が発生した場合にドライバーが運転を引き継ぐ必要があることです。しかし、しばらく手動で車を操作したことがない人がいると、パニックになったり、何をすべきか忘れてしまうかもしれません。だから、車が自分で運転する時間を制限するのはいい考えです。飛行機のパイロットも同じだと言われています。飛行機が仕事をしすぎると、パイロットは緊急時にうまく対処できないのです。
第四の教訓は、顧客やユーザーに与えるコントロールのレベルが、あなたの仕事量にどのような影響を与えるかを考えることの重要性です。しかし、クライアントにとっては大変な作業かもしれません。クライアントが何を望んでいるのかわからなかったり、選択を誤ったりするかもしれません。経験豊富なデザイナーであれば、クライアントに求める情報はもっと少なくなり、その代わりにブランド全体を理解し、微妙な手がかりからニーズを推測し、自分たちで詳細を把握することに労力を割くかもしれません。マネジャーがチームに与える自主性が高ければ高いほど、彼らの仕事量は減ります。
複雑さが不変であることを受け入れるなら、その複雑さを誰が負担しているのかを常に意識する必要があります。
