はじめに - 「シンプル」は合意を装った分裂である
「もっとシンプルにできないか」
この言葉には不思議な力があります。発した瞬間、全員がうなずく。誰も反対しない。なぜなら「シンプル = 良いこと」という暗黙の了解があるからです。
でも、その5分後に起きることを私たちは知っています。
- エンジニア A「ファイル数を減らせばシンプルになる」
- エンジニア B「いや、責務を分けた方がシンプルだ」
- デザイナー「そもそもユーザーから見てシンプルかどうかが大事では」
全員が「シンプル」に賛成したはずなのに、議論は空中戦になる。これは偶然ではありません。「シンプル」という言葉は、合意しているように見えて、実は何も合意していないのです。
問題は、「シンプル」という言葉が少なくとも4つの異なる意味を持っていることにあります。この記事では、その4つを分解し、チームで議論できる形に整理します。
4つの「シンプル」
「シンプル」と言われたとき、人が実際に意味しているものは以下の4つに分類できます。
| 意味 | 対義語 | 観点 | 説明 |
|---|---|---|---|
| 簡素 (Minimal) | 過剰 (Redundant) | 要素・量 | 余計なものがない、必要最小限 |
| 簡潔 (Concise) | 冗長 (Verbose) | 表現 | 端的に表現されている |
| 簡単 (Easy) | 煩雑 (Cumbersome) | 行為 | 手間がかからない、すぐできる |
| 単純 (Simple) | 複雑 (Complex) | 構造 | 構造が入り組んでいない |
これらは独立した概念です。ある側面では「シンプル」でも、別の側面ではそうでないことがあります。
簡素 (Minimal) - 余計なものがない
対義語: 過剰 (Redundant)
「簡素」は要素・量の話です。
コードであれば、行数、ファイル数、依存ライブラリの数。UI であれば、画面上の要素数、ボタンの数、入力項目の数。これらが少ない状態を指します。
簡素であることの価値
- 保守対象・管理対象が少なくなる
- 把握すべき範囲が狭まる
- 不要なものを削ぎ落とした洗練さがある
簡素さを追求したときに起きること
コードでは、行数を減らそうと三項演算子をネストする。ファイル数を減らそうと1ファイルへ複数の責務を詰め込む。
UI では、画面数を減らそうと1画面に機能を詰め込む。要素を減らそうとアイコンだけのボタンにする。
量を減らすことだけを目指すと、他の側面が犠牲になることがあります。「要素が少ない」と「わかりやすい」は別の話です。
簡素かどうかを問う
- 構成要素の数は必要最小限か
- 削れるものはないか
- 逆に、削りすぎて別の問題が起きていないか
簡潔 (Concise) - 端的に表現されている
対義語: 冗長 (Verbose)
「簡潔」は表現の話です。
コードであれば、読んだとき意図がすぐに伝わるかどうか。UI であれば、見たとき何をすべきかがすぐに伝わるかどうか。
簡潔であることの価値
- 認知負荷が下がる
- 意図が誤解されにくい
- 判断や理解が速くなる
簡潔さと簡素さの違い
簡素さは「量が少ないこと」、簡潔さは「表現が端的であること」です。
コードでは、丁寧なコメントを添えると行数は増えますが、意図は伝わりやすくなります。これは「簡素ではないが簡潔」な状態です。逆に、極限まで圧縮されたワンライナーは、行数は少ないですが、何をしているのか読み解くのに時間がかかります。これは「簡素だが簡潔ではない」状態です。
UI でも同じです。アイコンだけのボタンは要素としては少ないですが、「これは何のボタンか」がわからなければ簡潔ではありません。ラベルを添えれば要素は増えますが、意図は明確になります。
簡潔かどうかを問う
- 意図が伝わる表現になっているか
- 初見の人が見て、すぐに理解できるか
- 省略しすぎて、かえってわかりにくくなっていないか
簡単 (Easy) - 手間がかからない
対義語: 煩雑 (Cumbersome)
「簡単」は行為の話です。
やるべきことが少ない、手順が少ない、すぐに始められる、学習コストが低い。
簡単であることの価値
- 導入障壁が下がる
- 試行錯誤のサイクルが速くなる
- ミスが起きにくい
誰にとっての簡単か
この軸は特に「視点」の影響を受けます。
開発者にとって簡単なことが、ユーザーにとって簡単とは限りません。たとえば、エラーコードを表示するだけなら、開発者は内部の例外をそのまま出せばいいので実装が簡単です。しかしユーザーにとっては、「Error: ENOENT」と言われても何をすればいいかわかりません。
エンジニアとデザイナーでも視点は異なります。エンジニアが「実装が簡単」と言うとき、デザイナーは「ユーザーの操作が簡単」を想定していることがあります。同じ「簡単」でも、主語が違えば指すものも違います。
また、熟練者にとって簡単なことが、初心者にとって簡単とは限りません。「慣れれば簡単」は、裏を返せば「慣れるまでは煩雑」ということです。
簡単かどうかを問う
- 手順は最小限になっているか
- 誰にとっての「簡単」を想定しているか
- 学習コストはどの程度か
単純 (Simple) - 構造が入り組んでいない
対義語: 複雑 (Complex)
「単純」は構造の話です。
コードであれば、分岐や層が少なく、依存関係が一方向であること。UI であれば、画面遷移が一本道で、モードや状態が少ないこと。
英語では Simple ですが、ここでは「シンプル」全般ではなく、構造に関する意味に限定しています。実は、これこそが Simple の本来の意味です。
Simple の語源はラテン語の simplex で、「一つに折られた（one-fold）」を意味します。sim-（一つ）+ -plex（折る、編む）という構成で、対義語の complex（com- = 共に + -plex = 折る）が「複数が絡み合った」を意味するのと対照的です。つまり Simple の原義は「部品が絡み合っていない」「構造が入り組んでいない」という、まさに構造の話なのです。
単純であることの価値
- 動作が予測しやすい
- デバッグ・検証がしやすい
- 変更の影響範囲が限定される
単純さと簡素さの違い
簡素さは「数が少ないこと」、単純さは「構造が入り組んでいないこと」です。
コードでは、10個のモジュールがあっても、それぞれが独立していて依存関係がなければ、構造としては単純です。逆に、3つのモジュールしかなくても、相互に依存し合っていれば、構造としては入り組んでいます。
UI でも、画面が10個あっても遷移が一方向なら単純です。画面が3つでも、状態によって表示が変わり、どこからでも遷移できるなら入り組んでいます。
単純さと簡単さの違い
単純な構造が、必ずしも簡単に扱えるとは限りません。
コードでは、ローレベルな API は抽象化の層が薄く構造としては単純ですが、使いこなすには多くの知識と手順が必要です。一方、よく抽象化されたライブラリは、内部構造は入り組んでいても、使う側からすれば手間がかかりません。
UI でも、ウィザード形式は内部で分岐を持ちますが、ユーザーにとっては「次へ」を押し続けるだけで済みます。一方、すべての設定を1画面に並べれば構造は単純ですが、何をすればいいかユーザーが判断する手間は増えます。
単純かどうかを問う
- 分岐や条件は最小限か
- 依存関係は一方向になっているか
- 状態の数は管理可能な範囲か
4つの「シンプル」を使いこなす
ここまでの4つをまとめます。
| 意味 | 対義語 | 観点 | 説明 |
|---|---|---|---|
| 簡素 (Minimal) | 過剰 (Redundant) | 要素・量 | 余計なものがない、必要最小限 |
| 簡潔 (Concise) | 冗長 (Verbose) | 表現 | 端的に表現されている |
| 簡単 (Easy) | 煩雑 (Cumbersome) | 行為 | 手間がかからない、すぐできる |
| 単純 (Simple) | 複雑 (Complex) | 構造 | 構造が入り組んでいない |
議論が噛み合わないとき
「シンプルにしよう」という議論が空中戦になったら、どの意味で話しているのかを確認してみてください。
- 「それは簡素にしたいという話か、それとも簡潔にしたいという話か」
- 「構造を単純にしたいのか、操作を簡単にしたいのか」
エンジニアとデザイナーの間で認識がずれることも多いです。エンジニアが「実装が単純」という意味で「シンプル」と言ったとき、デザイナーは「ユーザーにとって簡単かどうか」を問うていることがあります。同じ「シンプル」でも、指しているものが違うのです。4つのどれを、誰の視点で話しているかを明示するだけで、議論は具体的になります。
「シンプル」を言い換える
「シンプル」という言葉を使いたくなったとき、4つのどれに該当するかを考えて言い換えると、意図が伝わりやすくなります。
- NG 🙅🏻「この画面、もっとシンプルにできないか」
- OK 🙆🏻「もっと簡素にできないか。要素が多すぎる」
- OK 🙆🏻「もっと簡潔にできないか。何をすればいいかわかりにくい」
- OK 🙆🏻「もっと簡単にできないか。操作の手順が多い」
- OK 🙆🏻「もっと単純にできないか。状態が多くて把握しきれない」
4つは互いに独立している
4つの「シンプル」は、一見トレードオフに見えることがあります。
- 簡素さを追求して要素を減らすと、簡潔さが失われる（アイコンだけのボタン）
- 簡単さを追求して抽象化すると、単純さが失われる（裏側の分岐が増える）
しかし、これらは実はトレードオフでないことも多々あります。4つの観点は独立しており、工夫次第で両立できることも多いです。上の例も「要素を減らしつつ意図を伝える方法」「抽象化しつつ構造を単純に保つ方法」を探ることで解決できる場合があります。
好例として、カレー屋などで見かけるメニューの辛さ表示があります。唐辛子マーク 🌶️ の数で辛さを表すあれです。要素としては唐辛子アイコンだけで簡素。しかし「5つだから結構辛いな」と一目で伝わるので簡潔でもある。簡素さと簡潔さを両立した優れたデザインです。
大切なのは、4つのどれを目指しているのかを明確にすることです。目指すものが明確になれば、コントロールしやすくなります。
まとめ - 「シンプル」は4つの顔を持っている
「シンプル」という言葉は、合意点のように見えて、実は分岐点です。4つの異なる意味が隠れています。
| 意味 | 対義語 | 観点 | 説明 |
|---|---|---|---|
| 簡素 (Minimal) | 過剰 (Redundant) | 要素・量 | 余計なものがない、必要最小限 |
| 簡潔 (Concise) | 冗長 (Verbose) | 表現 | 端的に表現されている |
| 簡単 (Easy) | 煩雑 (Cumbersome) | 行為 | 手間がかからない、すぐできる |
| 単純 (Simple) | 複雑 (Complex) | 構造 | 構造が入り組んでいない |
「シンプルにしよう」という発言を見かけたら、「それはどのシンプルですか」と問いかけてみてください。多くの場合、議論が前に進みやすくなります。
Discussion