なぜシリコンバレーのエンジニアは古代哲学を読むのか
2000年前のローマ帝国で書かれた本が、2026年のサンフランシスコで売れている。 マルクス・アウレリウスの『自省録』だ。
Twitter（現X）の創業者ジャック・ドーシーは、この本を「人生で最も重要な本」と公言してきた。 生産性の鬼として知られるティム・フェリスは、ポッドキャストでセネカを繰り返し引用する。 Y Combinatorの創業パートナーだったポール・グレアムは、エッセイのなかでエピクテトスの教えに言及した。
偶然の一致ではない。 シリコンバレーにはストア哲学への系統的な傾倒がある。 その流れは、Ryan Holidayの著書『The Obstacle Is the Way（邦題: 超訳 ストア派哲学入門）』が2014年に出版されて以降、急速に広まった。
だが、なぜプログラマーなのか。 なぜ弁護士でも医師でもなく、コードを書く人々が、2000年前の哲学に惹かれるのか。 そこには、プログラミングという行為の本質に触れる接点がある。
ストア哲学の核心——制御できるものと、できないもの
ストア哲学の中心的な教えは、驚くほどシンプルだ。 エピクテトスはこう書いている。
「我々の力の及ぶものと、及ばないものがある。我々の力の及ぶものは、判断、意欲、欲望、忌避。力の及ばないものは、身体、財産、評判、官職。要するに、我々自身の行為でないすべてのものだ」
世界を「自分がコントロールできるもの」と「できないもの」に二分する。 コントロールできるものに全力を注ぎ、できないものは受け入れる。 これがストア哲学の根幹だ。
この思考様式に、プログラマーは既視感を覚えるはずだ。
ソフトウェア開発において、エンジニアがコントロールできるものは限られている。 自分の書くコードの品質。テストのカバレッジ。ドキュメントの整備。設計判断の論理性。 これらは自分の手の内にある。
一方で、コントロールできないものも多い。 プロダクトの方向転換。予算のカット。チームメンバーの退職。ライブラリのBreaking Change。AWSの障害。 そしてユーザーが自分のプロダクトを気に入るかどうか。
優れたエンジニアが日常的にやっていることは、実はストア哲学の実践そのものだ。 「自分がコントロールできる変数に集中し、できない変数については堅牢な設計（フォールトトレランス）で対処する」。 これをエピクテトスが聞いたら、深くうなずいたに違いない。
関数型プログラミングと「不変性」の哲学
ストア哲学とプログラミングの接点は、もっと具体的なレベルにも見つかる。 関数型プログラミングの「不変性（immutability）」がそれだ。
関数型プログラミングでは、一度定義したデータを書き換えない。 変更が必要なときは、元のデータには触れず、新しいデータを生成する。 Reactの状態管理がまさにこの思想で設計されている。 stateを直接mutateせず、setStateで新しい状態を作る。
ストア哲学も、ある種の「不変性」を重視する。 外部の出来事は変えられない（immutable）。 変えられるのは、それに対する自分の判断と反応だけだ。
マルクス・アウレリウスはこう記した。
「事物はあなたの魂に触れはしない。事物はあなたの外にあり、静かに横たわっている。わずらわしいのは、ただ内なる臆見のみ」
プログラミングの言葉に翻訳すれば、こうなるだろう。 「外部APIのレスポンスは変えられない（immutable external state）。自分が制御できるのは、それをどうパースし、どうハンドリングするかだけだ」。
この類似は偶然ではないと考える。 関数型プログラミングとストア哲学は、ともに「予測可能性」を最高の価値とする。 副作用を排除し、入力と出力の関係を明確にする。 不確実な外界に対して、内部のロジックだけは一貫させる。 その思想の骨格が重なっている。
デバッグ思考と「観察する自己」
プログラマーが日常的に行うデバッグという行為にも、ストア哲学的な構造がある。
バグに遭遇したとき、優れたエンジニアはまず感情を脇に置く。 「なぜ動かないんだ」というフラストレーションに支配されたままでは、問題は解けない。 代わりに、冷静に状況を観察する。
- エラーメッセージは何を言っているか
- どの時点から挙動がおかしくなったか
- 変更前は正しく動いていたか
- 仮説を立て、一つずつ検証する
この「観察する自己」をストア哲学は中心に据える。 セネカは毎晩、その日の自分の行動を振り返り、判断の誤りがなかったかを検証したという。 感情に巻き込まれている自分を、もう一人の自分が上から観察する。 その距離を保つ能力が、ストア的な知恵の核心だ。
プログラマーは、コードに対してこの能力を自然に発揮している。 問題は、それを人生にも適用できるかどうかだ。
「自分の怒りを観察する。なぜ怒っているのか。その怒りは、自分がコントロールできないことへの反応ではないか。もしそうなら、怒りにエネルギーを使うのは非合理的だ」
こう考えるストア哲学者の思考プロセスは、デバッグのそれとほぼ同じだ。 感情というバグの原因を特定し、ロジカルに対処する。 エンジニアがストア哲学に親和性を感じるのは、この思考の型がすでに身体化されているからだろう。
「最悪のシナリオ」を想定する——ネガティブ・ビジュアライゼーション
ストア哲学の実践法の一つに「ネガティブ・ビジュアライゼーション（premeditatio malorum）」がある。 最悪のシナリオをあらかじめ想像しておくことで、実際にそれが起きたときの衝撃を和らげるという手法だ。
セネカはこう書いた。
「われわれは、起こりうるすべてのことを、あらかじめ心のなかで経験しておかねばならない」
ソフトウェアエンジニアリングの世界で、これはそっくりそのまま「障害対応の設計」に対応する。
SRE（Site Reliability Engineering）の基本原則は、「すべてはいずれ壊れる」だ。 サーバーはダウンする。ネットワークは切れる。データベースは壊れる。 そのとき何が起きるかをあらかじめ設計し、テストし、訓練しておく。 Chaos Engineeringはこの思想の極致だ。Netflixが開発したChaos Monkeyは、本番環境でランダムにインスタンスを停止させることで、システムの耐障害性を検証する。
ストア哲学者が心のなかで行っていたことを、エンジニアはインフラストラクチャのレベルで実装している。 最悪を想定し、それでも動き続ける仕組みを作る。 両者が辿り着いた結論は同じだ。 「最悪の事態を想定することは悲観主義ではない。最も楽観的な準備のかたちだ」。
禅とストア——東洋と西洋の合流点
日本のエンジニアにとって興味深いのは、ストア哲学と禅仏教の類似性だ。
AppleのSteve Jobsが禅に傾倒していたことはよく知られている。 彼のミニマリズム、集中力への執着、「Less is more」の哲学は、曹洞宗の乙川弘文老師の教えに深く影響されていた。
ストア哲学と禅は、異なる文化圏から出発して、驚くほど似た場所に到達している。
- 現在への集中: ストアの「今この瞬間に集中せよ」と、禅の「只管打坐（ただ座る）」。過去への執着と未来への不安を手放し、いまここにとどまる
- 執着の手放し: ストアの「コントロールできないものを手放す」と、禅の「放下着（ほうげじゃく）」。結果への執着を捨てることで、かえってパフォーマンスが上がるという逆説
- 自己観察: ストアの「内省」と、禅の「観（かん）」。自分の心の動きを客観的に見る訓練
- シンプルさの追求: ストアの質素な生活と、禅の簡素な美学。不要なものを削ぎ落とすことで、本質が見えてくる
プログラミングの世界にも、この「削ぎ落とし」の美学は息づいている。 UNIX哲学の「一つのことをうまくやる」。 KISSの原則（Keep It Simple, Stupid）。 YAGNI（You Ain't Gonna Need It）。
コードを書くとき、最も難しいのは「何を書かないか」を決めることだ。 機能を追加する誘惑に抗い、本当に必要なものだけを残す。 この判断力は、禅的であり、ストア的であり、そして最良のエンジニアリングでもある。
興味深いことに、日本のテック企業の一部では、マインドフルネスや坐禅をエンジニア向けの研修に取り入れる動きがある。 LINEヤフーやメルカリが社内でマインドフルネスプログラムを実施し、集中力の向上とバーンアウトの予防に効果があったと報告している。
哲学的プログラマーという生き方
ここまで、ストア哲学とプログラミングの接点を探ってきた。 最後に問いたいのは、この接続が実際のキャリアや人生にどう活きるのかということだ。
プログラマーの仕事は、本質的に「問題解決」だ。 与えられた制約のなかで、最適な解を見つける。 リソースは有限。時間も有限。完璧な解は存在しない。 その現実を受け入れたうえで、いま可能な最善を実装する。
ストア哲学も、根本的には同じことを言っている。 人生の制約を嘆くのではなく、その制約のなかで最善を尽くす。 完璧な人生は存在しない。だが、「良い人生」は、いまこの瞬間から始められる。
テック業界は、変化が速く、不確実性が高い。 昨日まで標準だった技術が、今日にはレガシーと呼ばれる。 自分が作ったプロダクトが、市場に受け入れられるかはわからない。 大量解雇の波がいつ自分のもとに来るかもわからない。
そのなかで、ストア哲学が提供するのは「心の安定装置」だ。 コントロールできないことに悩まない。 最悪のシナリオに備えておく。 自分の行動だけに集中する。 結果は受け入れる。
これは諦めではない。 むしろ、最も合理的なエネルギー配分の方法だ。 限られたCPUリソースを、処理できないタスクに割り当てない。 自分が実行できるプロセスだけに集中する。 エンジニアなら、このメタファーの有効性がわかるだろう。
Ryan Holidayはこう書いている。
「障害は道である（The Obstacle Is the Way）。困難そのものが、あなたを鍛え、前に進める力になる」
バグのないコードは存在しない。 障害のないインフラも存在しない。 そして、問題のない人生も存在しない。
だからこそ、問題との向き合い方が問われる。 ストア哲学は、2000年前からその向き合い方を教えてくれている。 そして、プログラマーはすでに、コードを通じてその一部を実践している。
あとは、ターミナルを閉じたあとの人生にも、同じ思考を適用するだけだ。 あなたは自分のコードに対するように、自分の人生をデバッグしたことがあるだろうか。
