人はなぜ、深く考えずに巨大な過ちを引き起こすのか？
ハンナ・アーレントの名著『エルサレムのアイヒマン 新版 悪の陳腐さについての報告』は、この問いに真正面から挑み、人間の思考停止がもたらす悲劇を描き出します。
本記事では、ナチス戦犯アドルフ・アイヒマンの裁判レポートを通じて浮かび上がった“悪の陳腐さ”の本質を解説しつつ、そこからプロダクトマネージャーが得られる教訓を掘り下げます。
はい。PMであり、『エルサレムのアイヒマン 新版 悪の陳腐さについての報告』が好きな僕のエゴ企画です。もちろん、戦争とプロダクト開発と、対象にしている物事が圧倒的に違うのですが書籍のエッセンスは日々の僕たちの業務でも活用できると考えています。
僕はPMを務めるなかで600回以上のユーザーインタビューを行い、思考停止のまま開発を進める危険性を何度も痛感してきました。
「指示されたからやる」という姿勢がどんな問題を呼ぶのか。アーレントの警句を踏まえながら、実務への活かし方を具体的に提案します。
アドルフ・アイヒマンと裁判：書籍が生まれた背景
まずは、『エルサレムのアイヒマン』の内容に触れていきます。
『エルサレムのアイヒマン』は、政治思想家ハンナ・アーレントが1961年に行われたナチス戦犯アドルフ・アイヒマンの裁判を傍聴し、その模様を報告したものがベースとなっています。
アイヒマンはユダヤ人の大量移送計画（ホロコーストの一端）を推進した人物ですが、裁判では「自分は命令を実行しただけ」と主張。ある意味、感情を挟まず職務に忠実であろうとする姿に、アーレントは深い違和感と洞察を得ました。
アイヒマンが「冷酷な怪物」ではなく、むしろ“普通の官僚”として行動していた事実に衝撃を受け、「悪の陳腐さ（banality of evil）」という概念を提唱したのです。
ナチスの恐るべき犯罪に加担したアイヒマンは、従来のイメージとは違い、「ただ上司の指令を着実にこなし、自らのキャリアを守っていただけ」の凡庸な人物として描かれます。
アーレントは、そこにこそ本質的な恐ろしさ――つまり「思考停止がもたらす悪」があると指摘しました。大きな犯罪行為ですら、個々の人間が自分で考えずに命令に従うだけで起きてしまう。これが『エルサレムのアイヒマン』のもっとも重要な論点の一つです。
“悪の陳腐さ”の核心：思考しないまま巨大な罪へ加担する恐怖
本書が提起する「悪の陳腐さ」とは、「アイヒマンのように“大きな悪意”や“鬼のような非道”がなくとも、思考を止めた凡庸な人間が集団行動で大きな悪に繋がってしまう」という現象を指します。
アイヒマン自身は裁判で、終始「命令に逆らうという選択肢を考えなかった」と述べ、あくまで規則や上官の指示に従っただけだと弁明した。これは“明確な殺意”ではなく、“自律的な思考の放棄”によって、結果的にホロコーストに加担した形なのです。
アーレントはこの姿にショックを受けつつも、同時に「社会や組織において、こうした凡庸な人々の思考停止がいかに重大な結果をもたらしうるか」を論じています。
これは当時、強い議論を呼んだそうです。アイヒマンを単なる「悪魔的怪物」として処理するよりも、むしろ誰もが同じように思考停止に陥り、命令に従う可能性を示唆していたからです。
そして、我々ビジネスの世界においても、明確な殺意や悪意こそないにしても、“自分の頭で考えずに流される状態”がプロダクトや組織を間違った方向へ向かわせるリスクがあることは想像に難くありません。
裁判の詳細とアーレントの考察：思考停止の構造
アイヒマン裁判はイスラエルのエルサレムで開かれ、ユダヤ人虐殺に関わった罪で起訴されたアイヒマンが被告として法廷に立ちました。
公判でのやり取りを取材したアーレントは、アイヒマンが複雑な宗教的・人種的信条や強烈な憎悪を持っていたわけではなく、上からの命令を業務として処理し、それを自分の成功や出世に繋げる要素と捉えていたことを発見。そこに驚きを抱きました。
アイヒマンは優秀な官僚として認められるために、“この業務をうまく遂行すること”に集中していただけ。いわゆる「目の前の評価」に注力し、自分の行為の道徳的・人道的影響を顧みなかったのです。
アーレントはこの状況を「考えることを放棄した凡庸な人間が、巨大な悪事に関与する事例」と整理しました。
ここで言う“悪”は、極端な暴力や破壊だけではなく、社会や組織での無責任な決定や不作為といった形でも表面化する可能性があると考えられます。
＜補足＞
アーレント以降の研究によって、「アーレントの『陳腐』という表現は、あくまで『悪魔的・神秘的な偉大さを伴う悪』という誤解を正すためのもので、決して犯罪を矮小化するものではない」といった学説も存在しているので、この書籍における「陳腐」という表現の取り扱いには注意が必要です
参考）「アイヒマンの悪における「陳腐さ」について」（香月 恵理）
プロダクトマネジメントへの示唆：思考停止が生む失敗例と組織の停滞
プロダクトマネジメントの場面にも、「悪の陳腐さ」に類似する現象が潜んでいます。もちろんナチスの凶行とは比較にならないかもしれませんが、本質部分――自分の頭で考えず、与えられた指示や流れに無批判に従う――は、ビジネスでも見かける光景です。
例えば、次のような例が挙げられます：
- 上層部の要望を鵜呑みにして、顧客ニーズとかみ合わない機能をリソースをかけて実装
- 「ほかの企業がやっているから」というだけで新技術を導入し、中身を検証せずに大量の予算を浪費
- ユーザーの声を聞くヒマがなく、「なんとなく標準的なUIでいいだろう」と思考停止で進める
こうした「流される開発」は、チームやプロダクトを無駄な方向へ導き、競合に遅れをとったり顧客からの信用を失うことも。
思考停止には“自分が責任を負わずに済む”という甘い心理があるかもしれません。しかし、長期的にはプロダクト全体を危うくするリスクが大きいのです。
というか、PMは大体責任を追っている数字で判断されるので、誰の命令であっても結果的に数字が下がればマイナス評価なので普通に自分が責任を負います。
学び①：目的・理由を問う習慣が思考停止を防ぐ
『エルサレムのアイヒマン』を通じて学べるのは、「これは何のためにやるのか？」を問う姿勢が、思考停止の一番のブレーキになるという点。
アイヒマンは「命令だから」という理由で自身の行為を疑わなかった。プロダクトの世界でも、「会社が指示するから」「この機能を付けるように言われたから」というだけで動くと、やはり後になって「なぜ作ったのか不明」の機能だらけになる可能性がある。
対策として、「なぜこれを優先するのか？ どの指標やユーザー課題を解消するか？」を問い続ける方法があります。
- スプリントプランニングやロードマップ策定時、必ず目標指標（例：LTV向上、NPS改善）と紐付ける
- 要望や指示を受けたら、最低限「その施策で何が変わるか？」を一緒に記述するルールを設定
こうしたプロセスを設けるだけで、思考停止で押し付けられたタスクが大量に紛れ込む事態を減らせます。
学び②：ユーザーインタビューと仮説検証で“現場を見ない”事態を回避
プロダクトの現場でも顧客接点を避け、“自分の世界”で判断しがちな危険があります。
現場の声を聞かずに開発を進めれば、本当に困っている箇所やユーザーの感情を知る機会が失われ、思考停止で無用な機能や仕様を積み上げてしまいがち。
そこで重要なのが、ユーザーインタビューの徹底。
- 定期的に5〜6名のユーザーインタビューを行い、改善の方向を確認
- プロトタイプや紙芝居のUIを見せて、定性フィードバックを得る
- 定量分析とも突き合わせ、数字と声を両面からチェック(Nielsen & Landauer, 1993)
こうした仕組みを回すと、「本当に解決すべき課題」を早期に発見しやすく、思考停止に陥る隙が減ります。組織が「なぜこの機能が必要？」と疑問を持つ状態を常に作るのです。
学び③：オープンな議論と意思決定で、上意下達からの脱却
アイヒマン裁判が示すように、“上の指示に逆らえない環境”は個人の思考停止を招きやすい。本書からの教訓として、プロダクト開発でも“鶴の一声”で決まる文化を改め、オープンな議論と意思決定を目指すべきです。
具体的には、ロードマップレビュー会や機能優先度合意会議を定期開催し、エンジニア・デザイナー・CSなど多職能メンバーが発言できる仕組みが挙げられます。
一人の意見に従うだけでなく、全員が「これで本当にユーザーに役立つのか？」を問い、データやユーザーの声を交えて判断する流れを作ると、思考停止を防ぎつつより良い意思決定が進むのです。
加えて、意思決定の過程を短いドキュメントやSlackチャンネルで共有し、「なぜこの結論になったのか？」をチーム全員が見られるようにするとよいでしょう。
上位者が黙って方向性を押し付けるのではなく、根拠や背景をオープンにすることで、メンバーも「指示通り作るだけ」でなく、自分の頭で考え・納得しながら動けます。
こうした透明性が、アイヒマン的な服従構造を壊す鍵となります。
今日から実践できるアクション
- 「目的と理由」を全タスクに記載する習慣
スプリントバックログやロードマップの各項目に「なぜこれをやるのか」「どんな顧客課題を解決するか」を書いていない場合、着手不可とする。
これだけで思考停止のタスクが激減する。 - ユーザーインタビューを“必須工程”に設定
新機能をリリースする前、あるいは大きな仕様変更の前に、5人程度のインタビューや簡易テストを実施。
「現場を見ない」状態を組織的に防ぎ、思い込みを排除する。 - 議論の可視化と合意形成
ロードマップ作成時に多職能チームから意見を募り、根拠資料（データ・インタビュー結果）を共有しながら合意形成を行う。
議事録やSlackで公開し、“鶴の一声”で決定されない仕組みを作る。 - 検証結果を短いレポートでまとめ、再利用
ある機能の検証で「やる/やらない」を決めた理由を簡潔にまとめ、社内Wikiなどで共有。
後から同様の要望が出ても、そのレポートを参照することで思考停止での再開発を防げる。
9. Q&A
- Q1. 『エルサレムのアイヒマン』は戦争や歴史に関する本ですよね？なぜPMに関係あるのですか？
- A. 内容はナチスの戦犯裁判に関わるものですが、アーレントが指摘する「思考停止が大きな悪を可能にする」構造はあらゆる組織で起こりえます。
プロダクト開発でも、指示に従うだけの姿勢が重大な失敗を招く恐れがある、という共通点があるのです。
あとは冒頭にも紹介したのですが、僕がこの書籍が好きなので無理やり紐付けたエゴ企画でもあります - Q2. 思考停止を避けるには、常に全員が疑問を持てばいいのですか？現実的に難しくありませんか？
- A. もちろん100%疑い尽くすのは非効率。しかし、少なくとも「目的」「理由」「検証」が不明な施策には“ストップ”をかける仕組みを作るだけで大幅に改善できます。
疑問を持つのが当たり前の空気づくりが重要です。 - Q3. ユーザーインタビューしても、組織がトップダウンで決めてしまうと無意味では？
- A. そこで情報共有の透明性が効きます。インタビュー結果を共有し、具体的なデータを可視化すれば、トップダウンでも根拠に基づく議論に移行しやすい。
時間はかかる場合もありますが、一度成功事例を作ると組織全体が変わることが多いです。
参考情報
- Hannah Arendt『エルサレムのアイヒマン 新版 悪の陳腐さについての報告』（1963年原著, 各版）
- Jakob Nielsen & Thomas K. Landauer (1993). “A Mathematical Model of the Finding of Usability Problems.” Proceedings of ACM INTERCHI’93
- Eric Ries『The Lean Startup』（2011）
- 安宅和人『イシューからはじめよ』（ダイヤモンド社, 2010）
- ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム
- ユーザーインタビューの目的・設計・やり方・分析まで完全ガイド
- プロトタイプを使って、ユーザーインタビューで新機能の検証を行う方法・Tips
コメント