はじめに
「ちゃんと考える」と「複雑にする」は、似ているようで別物です。
仕事でも開発でも、私たちはつい情報を集め、論点を増やし、例外を洗い出し、選択肢を並べます。もちろん、それ自体は大切です。ただ、考えを広げたまま意思決定の場に持ち込むと、今度は決められなくなります。
この記事では、認知負荷や選択過多の知見を手がかりに、エンジニアやチーム運営で使える「単純化」の考え方を整理します。単純化は、浅く考えることではありません。深く考えたうえで、最後に「今動くための判断基準」まで絞る技術です。
※本記事は個人の整理メモです。心理学・認知科学の知見は、実務にそのまま機械的に当てはめるものではなく、判断の補助線として扱います。
1. 情報を増やすだけでは、行動は増えない
複雑に考えるほど、賢く、安全で、失敗しにくくなるように感じます。
しかし実務では、選択肢が増えすぎると、むしろ次のような状態になりがちです。
- 会議では論点が増えたのに、決定事項が残らない
- 設計では考慮事項が増えたのに、最初の一手が決まらない
- タスクでは優先順位を考えすぎて、着手が遅れる
- レビューでは指摘が散らばり、直す側が何を守ればよいか分からない
つまり、複雑さは「理解の材料」にはなりますが、そのままでは「行動の形」になりません。
行動に変えるには、最後に余分なものを整理して、こう言える必要があります。
今回、何を守ればよいのか。
この一文に答えられる状態が、ここでいう「単純化された状態」です。
情報量と「動ける度合い」の関係を、補助線として図にすると次のようなイメージです。
情報が少なすぎても動けないし、多すぎても動けません。実務での感覚としては、「どこかに最も動きやすい情報量がある」と捉えると整理しやすいです。
2. 単純化は「手抜き」ではなく「精度を上げる作業」
単純化という言葉には、少し誤解があります。
「単純に考える」と聞くと、考えることを放棄する、細部を無視する、雑に決める、という印象を持つかもしれません。しかし成果につながる単純化は、その逆です。
一度は複雑さを引き受けます。
- 背景を確認する
- 制約を洗い出す
- 選択肢を比較する
- リスクを見積もる
- 関係者の視点を見る
そのうえで、意思決定や実行の段階では、不要な情報をいったん脇に置き、「今回の判断基準」だけを残します。
エンジニアリングで言えば、これは実装前の設計判断に近いです。すべての可能性をコードに押し込むのではなく、今回の要件に必要な境界を決める。過剰な抽象化を避け、今の変更理由に合う形へ落とす。
単純化は、情報量を減らすことではなく、行動に必要な信号の比率を上げることです。
3. なぜ情報量が多いと行動が止まりやすいのか
単純化が有効に見える背景には、いくつかの一般的な知見があります。なお、これらは古典的な研究を含み、近年の再現性検証で議論があるものもあります。本記事では「実務上の判断の補助線」として扱い、機械的な当てはめは避けます。
選択肢が多すぎると、選びにくくなる
Iyengar and Lepper の選択過多に関する研究では、選択肢が多いことが必ずしも動機づけや満足度を高めるわけではないことが示されています。たとえば、少ない選択肢の方が購入や課題提出につながりやすいケースが報告されています。
なお、この「選択過多効果」については、後年のメタ分析で効果は条件依存であり、文脈によっては明確に観察されないことも報告されています。「選択肢が多ければ常に動けなくなる」と一般化するのではなく、「条件によっては動きにくくなることがある」と慎重に受け取るのが妥当そうです。
実務でも似たことが起きます。
- 施策案が20個ある
- 設計案が5パターンある
- タスクの優先度が全部高い
- レビュー指摘が粒度違いで大量にある
この状態では、選択肢が豊かというより、判断の入口が散らばっている状態になります。
認知負荷が高いと、本来の目的に使う余力が減る
Sweller の認知負荷理論では、問題解決時に必要な処理が大きすぎると、学習や理解に使える認知資源が圧迫されると説明されます。
開発の現場に置き換えると、次のような状態です。
- 仕様書の構造が複雑で、要件そのものより読み解きに力を使う
- チケットに背景、要望、議論、例外が混ざり、次の作業が見えない
- 設計方針が曖昧で、実装中に毎回判断が発生する
このとき問題なのは、情報が多いこと自体ではありません。作業者が「何を判断すればよいか」を見つけるために、余計な負荷を払っていることです。
人が一度に扱える情報には限界がある
Miller の古典的な論文では、人間の情報処理容量には限界があることが論じられています。数字だけが独り歩きしがちな有名論文ですが、実務上の示唆はシンプルです。
人は、無限に多くの論点を同時には扱えません。
だからこそ、意思決定の場では、複雑な情報をそのまま渡すのではなく、扱える単位にまとめ直す必要があります。
4. 行動範囲の境界線を引く
実務で単純化を使うときは、まず行動範囲に境界線を引きます。
ここでいう境界線は、次のようなものです。
今日使うものと、今日は置いてよいものを分ける線。
すべてを抱えたまま動こうとすると、現実には動けません。大事なのは、捨てることではなく、いったん置くことです。
たとえば、タスク設計ならこうです。
- 今回のPRで直すこと
- 次のPRに回すこと
- 仕様確認が必要なこと
- 今は対応しないこと
この境界がないと、1つのPRが設計変更、リファクタ、UI調整、例外処理、将来拡張の全部を背負います。結果として、レビューも実装も重くなります。
境界線を引くとは、「やらないこと」を雑に切り捨てることではありません。今日の行動に必要な範囲を明確にすることです。
5. 速さよりも「精度」と「方向性」
現代の仕事では、速く決めることが評価されやすいです。
ただし、方向がずれているなら、速さは成果ではなく手戻りを増やします。急いで実装したあとに、要件の中心が違ったと分かる。会議で早く決めたのに、関係者の前提が揃っていなかった。こういう経験は珍しくありません。
単純化は、速度を落とすためのものではありません。
むしろ、最初に方向を揃えることで、後半の迷いを減らすためのものです。
次のような問いが役に立ちます。
- この作業の成功条件は何か
- 今回、最も守るべき制約は何か
- 逆に、今回は追わなくてよいものは何か
- 迷ったら、どの基準で判断するか
この問いに答えないまま速く動くと、進んでいるように見えて、実は判断を先送りしているだけかもしれません。
6. エンジニアの日常で使う単純化
会議では「論点」より「決めること」を先に置く
悪い会議は、論点が多い会議ではありません。何を決めれば終わりなのかが分からない会議です。
会議前に、次の一文を書いておくと議論の範囲がはっきりします。
この会議では、〇〇について「Aで進めるか / Bで進めるか」を決める。
論点を10個並べる前に、守るべき基準を1つ置きます。
今回は、実装速度よりも既存ユーザーへの影響を最小化することを優先する。
この基準があるだけで、議論の枝葉を戻す場所ができます。
チケットでは「背景」と「次の一手」を分ける
チケットに情報を詰め込むほど、親切に見えることがあります。しかし、読む側が最初に知りたいのは、多くの場合「で、何をすればよいのか」です。
おすすめは、冒頭にこの3点を置くことです。
## やること
- 〇〇画面で、保存時のバリデーションを追加する
## 完了条件
- 空文字の場合にエラー表示される
- 既存の正常系は変わらない
## 今回やらないこと
- エラーメッセージ文言の全面見直し
- APIレスポンス形式の変更
背景や議論は下に置けばよいです。情報を消すのではなく、行動に近い順番へ並べ替えます。
レビューでは「最重要指摘」を先に伝える
レビューで細かい指摘が多いと、直す側は優先順位を見失います。
最初に次のように書くと、受け取りやすくなります。
このPRで必ず直したいのは、認可チェックの位置です。
命名や整形は後でまとめて見ます。
単純化とは、指摘を減らすことではありません。相手が先に直すべき一点を見えるようにすることです。
家庭や日常でも「今日伝える一言」に絞る
これは仕事だけの話ではありません。
何かを伝えるとき、過去の不満、背景事情、相手への期待、正しさの説明を全部混ぜると、相手には「何を受け取ればよいか」が分からなくなります。
まずは一文にします。
今日は、帰る時間が変わるなら早めに連絡してほしい。
単純な一文は、相手を責めるためではなく、伝わる確率を上げるためにあります。
シンプルなチェックリスト
ここまでの流れを4ステップに整理すると、以下のようになります。
印刷して見返すなら、ここだけでも使えます。
1. 広げる
- 背景は何か
- 制約は何か
- 選択肢は何か
- リスクは何か
- 関係者は誰か
2. 分ける
- 今日使うものは何か
- 今日は置いてよいものは何か
- 今回やることは何か
- 今回やらないことは何か
3. 絞る
- 最も大切な判断基準は何か
- 迷ったときの判断基準は何か
- 成功条件を一文で言うと何か
4. 動く
- 次の一手は何か
- 誰がやるのか
- いつ確認するのか
- 完了条件は何か
まとめ
複雑に考えること自体は悪くありません。むしろ、浅い単純化は危険です。
大切なのは、複雑さを理解したあとに、そのまま抱え込まないことです。
- 選択肢が多すぎると、行動が止まりやすい（条件によるが、実務上の補助線として有効）
- 認知負荷が高いと、本来の目的に使う余力が減る
- 人が同時に扱える情報には限界がある
- だから、行動前には「今日使うもの」と「置いてよいもの」を分ける
- 最後に残すべきは、今動くための判断基準
深く考え抜いて、最後に判断基準まで絞る。
単純化とは、考える量を減らすことではなく、成果につながる行動の精度を上げるための整理術だと思います。
参考・関連情報
本文で研究者名を挙げたものは原典を示し、そのうえで日本語で読みやすい解説を別枠にしました。
本文で言及した研究の原典
- Sheena S. Iyengar, Mark R. Lepper, "When choice is demotivating: Can one desire too much of a good thing?", Journal of Personality and Social Psychology, 2000. DOI: 10.1037/0022-3514.79.6.995
- John Sweller, "Cognitive Load During Problem Solving: Effects on Learning", Cognitive Science, 1988. DOI: 10.1207/s15516709cog1202_4
- George A. Miller, "The magical number seven, plus or minus two: Some limits on our capacity for processing information", Psychological Review, 1956. DOI: 10.1037/h0043158
日本語で読める解説
- コンサルノート: 選択過多とは？選択肢が多すぎると意思決定の質が下がる心理を解説
- コンサルノート: 認知負荷理論とは？学習設計に活かす3つの負荷の仕組みと実践法