シンプルは、削ることから始まる
「シンプルにすることは、複雑にすることより難しい」——スティーブ・ジョブズはこう言った。
この言葉が示す逆説は本物だ。複雑さを作り出すのは易しい。アイデアを追加し、機能を加え、説明を長くする——これは努力なしにできる。しかし本質だけを残してあとをすべて削るには、深い理解と勇気が必要だ。
本質が何かを問う前に、「何が本質でないか」を見極めなければならない。余分なものを削るには、その余分なものがなぜ存在するのかを理解しなければならない。シンプル化は、削除の技術ではなく、本質への問いの技術だ。
余分を見つける問い（1-10）
- これが「なくなっても」、中心的な価値は損なわれないか？
ゼロベース思考——存在することを前提にせず、なければどうなるかを問う——が、不要な複雑さを発見する最も直接的な方法だ。機能・プロセス・ルール——それぞれについて、「なかったら何が困るか」を問うことで、本当に必要なものが浮かび上がる。
- この複雑さは「顧客のため」か、「自分たちの都合のため」か？
複雑さの受益者を問うことが、不要な複雑さの発見につながる。内部の事情（会計の都合、法務の要求、IT制約）によって生まれた複雑さが、顧客体験を損なっていることは多い。顧客視点からは不要な複雑さを、内部視点から作り続けていないかを問う。
- 「こうでなければならない」と思っていることの中に、「こうであるだけ」のことはないか？
制約の検証だ。長年やっているから、誰かがそう言ったから、以前は理由があったから——これらの理由で続いているプロセスや構造の中に、理由のなくなった複雑さが潜む。
- この説明は、もっと短く、もっと明確に言えないか？
言語のシンプル化は、思考のシンプル化の反映だ。長い説明は、しばしば不完全な理解の産物だ。「一文で言うと何か」を問うことで、理解の深さと説明の明瞭さが同時に試される。
- パレートの法則（80対20）を適用すると、20%の何が80%の価値を生んでいるか？
最重要の少数を特定する問いだ。機能の80%は使われない、顧客の20%が売上の80%を生む——この不均等の法則を意識することで、リソースを本当に価値のある部分に集中できる。
- このプロセスで「最も時間がかかっている」ステップは、本当に必要か？
ボトルネックの問いは、プロセスのシンプル化の起点だ。時間がかかっているステップには、不要な複雑さか、改善の余地が大きいプロセスが潜む。なぜそのステップが存在するのかを問い直すことで、削除・自動化・簡略化の機会が見つかる。
- 「例外対応」のために作ったルールが、標準を複雑にしていないか？
例外は例外のまま扱うべきだ。しかし例外のためにシステム全体を複雑化することが行われることがある。少数の例外ケースのために多数の標準ユーザーを不便にすることが、システムの複雑さの主要な原因の一つだ。
- 会議・報告書・承認プロセスの数は、実際に必要な数か？
組織の複雑さのバロメーターとして、会議と承認プロセスの数は有用だ。会議が増えるほど、承認が増えるほど、組織の意思決定は遅くなり、個人の裁量は小さくなる。「本当に必要な会議はどれか」という問いは、組織設計の根本に触れる。
- これを「10歳の子供」に説明するとしたら、どう説明するか？
ファインマン・テクニックの応用だ。専門用語なし、複雑な構造なしで説明できないなら、その複雑さは設計上の複雑さではなく、理解の不足から来ている可能性がある。
- この製品・サービスの「コアの約束」は何か？ すべての機能はその約束を強化しているか？
コアバリューへの一元化だ。製品の中心的な約束から離れた機能・サービスは、焦点を散漫にし、体験を複雑にする。コアの約束を定義した上で、すべての要素をその基準で評価する。
本質を見つける問い（11-20）
- 「なぜこれをやっているか」を5回繰り返すと、最後に残る答えは何か？
5Whysのシンプル化への応用だ。表面的な目的の奥にある本質的な目的を問い続けることで、本当に達成すべきことが明確になり、余分なことが自ずと見えてくる。
- もし最初から設計し直せるとしたら、今と同じにするか？
ゼロベース設計の問いは、既存の複雑さを相対化する。「今の設計は、歴史的な積み重ねの産物か、本質的な最適解か」を問うことで、慣性によって維持されている複雑さを発見できる。
- 「制約があるから複雑」なのか、「複雑にしているから制約が増えている」のか？
複雑さと制約は相互強化的だ。複雑さの起源を問うことで、鶏と卵の構造を解きほぐす手がかりが見つかる。複雑さを削減することで制約が減り、さらにシンプルにできることがある。
- 「あったら嬉しい機能」と「なくてはならない機能」の境界線はどこか？
Must-have vs Nice-to-haveの峻別が、製品設計のシンプル化の核心だ。この境界線は主観的に見えるが、実際のユーザーの行動データが最も正確な答えを与える。
- この問題を「引き算」で解決できないか？
イノベーションは「足すこと」で達成されるという思い込みがある。しかし削ることによるイノベーション——余分を排除することで体験が劇的に改善される——の事例は多い。iPodは「1000曲をポケットに」という一点への集中から生まれた。
- 「最もシンプルな解」が最初に思い浮かばないとしたら、なぜか？
オッカムの剃刀——必要以上に複雑な説明を避けよ——の原則を問いに変えた。シンプルな解が見えにくい理由を問うことで、複雑さを生み出している思考のクセが見えてくる。
- 「一度シンプルにしたもの」が再び複雑になっているとしたら、なぜか？
複雑さの引力——組織も製品も放っておけば複雑になる傾向——を意識する問いだ。シンプル化は一度行えば完了ではなく、継続的な努力を必要とする。複雑さが再び積み重なるメカニズムを理解することで、防止策を設計できる。
- ユーザーがこの機能・情報・ステップを「スキップしたい」と感じているなら、それは何を意味するか？
ユーザーが省略したいものは、価値を感じていないものだ。スキップされる機能・情報は、削除を検討すべき候補だ。「使われない機能は、ないのと同じ」という原則が、シンプル化の判断基準になる。
- 「シンプルに見える」ことと「本当にシンプル」であることの違いは何か？
外見のシンプルさと構造のシンプルさは異なる。表面を美しくシンプルに見せながら、裏側に複雑さを押し込んでいないか。真のシンプルは、見た目だけでなく構造・論理・プロセスの全体に及ぶ。
- この複雑さを「単純化できない理由」として挙げていることは、本当の障壁か？
合理化の検証だ。「複雑にせざるを得ない理由」として語られることの中に、実は変えたくない既得権益や習慣の維持のための言い訳が混じっていることがある。
シンプル化を実践する問い（21-30）
- 「まず削ってから考える」アプローチを試したことがあるか？
削減ファーストの実験が、新しい視点を生む。最初に削れるものをすべて削り、そこから本当に必要なものだけを戻していくプロセスが、シンプル化の徹底を促す。
- チームや組織の「ルール・手順・ポリシー」の数は、最近減っているか増えているか？
組織の複雑化傾向のモニタリングだ。ルールは追加されやすく、削除されにくい。定期的に「本当に必要なルールはどれか」を問い、不要なルールを積極的に廃止する文化が、組織のアジリティを維持する。
- 「シンプル化」によって失われるものはあるか？ そのトレードオフは意識できているか？
シンプル化にはトレードオフがある。機能を削ればユーザーの選択肢が減る。プロセスを簡略化すれば例外対応の柔軟性が失われる。意識的なトレードオフの選択が、後悔のないシンプル化を可能にする。
- 「なんとなく残っているもの」を、今すぐ一つリストアップできるか？
行動を促す問いだ。今すぐ見渡して、なぜ存在するのかわからないまま残っているもの——会議、書類、機能、習慣——を一つ特定することから、シンプル化は始まる。
- 「少なく、しかし確実に（less, but better）」というデザインの哲学を、今の仕事に適用するとしたら、何が変わるか？
ディーター・ラムスのデザイン哲学を仕事の哲学に翻訳する問いだ。量より質、範囲より深度、多機能より単機能の徹底——この転換が、真に価値あるものの創造を可能にする。
- 「美しいシンプルさ」と「怠惰なシンプルさ（手を抜いたシンプルさ）」の違いは何か？
深く理解した上での「選ばれたシンプルさ」と、考えることを省いた「放棄されたシンプルさ」は別物だ。本物のシンプルさは、複雑さを理解した先にある——この区別が、シンプル化の質を問う。
- 顧客・ユーザーの「認知負荷」を最小化するために、今できることは何か？
認知負荷の軽減は、体験設計の最も実用的なゴールの一つだ。選択肢を減らす、情報の階層を明確にする、デフォルト設定を使う——認知負荷を減らすことで、ユーザーは本当に大切な判断にエネルギーを使える。
- 「意味のあるシンプルさ」はユーザーに何を委ね、「意味のないシンプルさ」はユーザーから何を奪うか？
シンプル化は、複雑さをユーザーに押しつけることであってはならない。価値のある思考はユーザーに残し、価値のない摩擦は排除する——この区別が、真に優れたシンプル化の基準だ。
- この「シンプル化された状態」を、1年後も維持できる仕組みがあるか？
シンプルさの持続設計だ。一度達成されたシンプルさは、放置すれば複雑さに戻る。定期的なレビュー、削除の文化、複雑さを追加する提案への問い返し——シンプルさを守る仕組みを設計することが、長期的な維持を可能にする。
- 「完璧」を求めることが、シンプル化を妨げていないか？
完璧主義とシンプル化の矛盾を問う最後の問いだ。すべてのケースを対応しようとすると、複雑さは避けられない。「十分にシンプルで、十分に機能する」という基準への移行が、完璧主義という名の複雑さから自由にする。
この問いと向き合うとき
「付け加えるものがなくなったときではなく、取り去るものがなくなったとき」——サン＝テグジュペリのこの言葉を、シンプル化の問いに取り組むたびに思い出す。
問いの使い方
シンプル化の問いは、対象に応じて使い分けると効果的だ。
製品・サービスの設計: 問い1・10・14・15で、コアバリューへの集中と余分の削除を問う。「何を追加するか」より「何を削るか」を先に問う習慣が、設計の質を変える。
組織・プロセスの改善: 問い8・22・6で、会議・承認・ルールのシンプル化を問う。定期的な「削除レビュー」の設計が、組織の複雑化傾向への最も効果的な対抗策だ。
コミュニケーションの明確化: 問い4・9・12で、言語と論理のシンプル化を問う。説明がシンプルになるほど、理解の深さが証明される。
シンプルにすることは、本質を問うことだ。本質を問うことは、最も難しく、最も価値のある思考だ。
この問いをさらに深めるために
参考文献
- Maeda, J. (2006). The Laws of Simplicity. MIT Press（前田ジョン『シンプリシティの法則』）
- McKeown, G. (2014). Essentialism. Crown Business（マッキューン『エッセンシャル思考』）
- Norman, D. (2010). Living with Complexity. MIT Press