Skip to content
Published on

エンジニアのための哲学 — ストア哲学とプラグマティズムを仕事に活かす

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに：なぜエンジニアに哲学なのか

哲学と聞くと、たいてい二つの反応が返ってきます。一つは「それは暇な人の贅沢だ」という冷笑、もう一つは「そこに人生を変える秘密がある」という過剰な期待です。私はそのどちらも間違っていると思います。

エンジニアの仕事は、本質的に不確実性とコントロール不能なものを扱う仕事です。ビルドは壊れ、依存ライブラリはある日突然消え、よく書いたコードも予想外の入力の前で崩れます。同僚のレビューはときに鋭く、面接の結果はコントロールできず、会社の方向は一人の努力では変わりません。こうした環境で心をどこに置くか——これは抽象的な問いではなく、毎日ぶつかる実務的な問題です。

古代のストア哲学者と19世紀アメリカのプラグマティストは違う時代を生きましたが、どちらも「いかに生きるか」を実践の問題として捉えました。机の上の飾りではなく、道具としてです。この記事は、その道具を二つ三つ選び、エンジニアの机の上へ移してみる試みです。大げさな悟りを約束はしません。ただ、次のスプリントでふと思い出せるような、手につかめるものを残したいと思います。

ストア哲学：コントロールできることに集中する

コントロールの二分法

ストア哲学の核心はシンプルです。エピクテトスはこう言いました。

「あるものは我々の力の内にあり、あるものは力の外にある。」——エピクテトス『提要』第1章

我々の力の内にあるもの：自分の判断、自分の努力、コードを書くやり方、レビューに応じる態度。力の外にあるもの：他人の反応、面接官の評価、市場の変化、すでに起きた障害。

この区別は些細に見えますが、実際には不要な苦しみのほとんどが、この境界線を引き間違えたところから来ます。コントロールできないものをコントロールしようとすれば挫折し、コントロールできるものを放置すれば無力になります。

エンジニアの一日をこのレンズで分けると、こうなります。

コントロールできること          コントロールできないこと
--------------------------     --------------------------
自分が書くコードの品質          レビュアーがいつ応答するか
PR説明の明快さ                 PRがマージされるか
テストを十分に書いたか          本番で発生するエッジケース
面接準備の誠実さ               面接の結果
ふりかえりでの自分の発言        組織がそれを受け入れるか
学びに費やす時間               昇進のタイミング

ポイントは、左の列にエネルギーを注ぎ、右の列を淡々と受け入れる練習です。「最善を尽くしつつ結果に固執しない」はありふれた言葉ですが、ストア哲学はここに構造を与えます。結果はそもそも自分の領域ではないのだから、結果で自分を評価すること自体がカテゴリーの誤りだ、というわけです。

実務の事例：却下されたPR

具体的な状況を見ましょう。三日かけたPRが却下されました。「このアプローチは我々のアーキテクチャの方向に合わない」というコメントとともに。

ストア的でない反応：「時間を無駄にした。もっと早く言ってほしかった。このチームのコミュニケーションは最悪だ。」怒りと自己憐憫が混じり、その感情が次の作業にもついて回ります。

ストア的な反応は、問いをこう分けます。

コントロール可能：
  - 次は作業開始前に方向を確認する
  - このPRから再利用できる部分を拾い出す
  - レビュアーの懸念を正しく理解したか問い返す

コントロール不能：
  - すでに過ぎた三日間
  - レビュアーがもっと早く言わなかったという事実

過ぎた時間はサンクコストです。そこに怒りを足しても、損失が増えるだけです。ストア哲学は感情を抑えろとは言いません。ただ「この感情はコントロール可能なものに向いているか」を問わせます。怒りの方向を点検する短い立ち止まり——それだけですが、それが違いを生みます。

ネガティブ・ビジュアライゼーション：あらかじめ崩しておく

ストアのもう一つの道具は premeditatio malorum、ネガティブ・ビジュアライゼーションです。物事が悪く転んだ場合を、あらかじめ落ち着いて思い描くこと。これはエンジニアにはすでに馴染んだ考え方です。私たちはそれを「障害を前提とした設計」や「カオスエンジニアリング」と呼びます。

デプロイ前に「これが深夜3時に壊れたらどうなる」とあらかじめ想像すること、依存するサードパーティAPIが落ちた場合を仮定してフォールバックを入れること——これがネガティブ・ビジュアライゼーションのエンジニアリング版です。最悪をあらかじめ直視すると、二つのものが得られます。第一に、実際に備えを作ります。第二に、実際に起きたとき、驚きが小さい。すでに心の中で一度経験しているからです。

ただしバランスが必要です。ネガティブ・ビジュアライゼーションが慢性的な不安に変われば毒になります。鍵は「落ち着いて、一度、備えとともに」です。同じ災厄を頭の中で二十回回すのは可視化ではなく反芻(はんすう)であり、これはまったく別物です。

レジリエンス：障害が道になる

「行動を妨げる障害が、行動を前へ進める。道を塞ぐものが、道になる。」——マルクス・アウレリウス『自省録』第5巻

この一節はライアン・ホリデイが本のタイトルにして有名になりましたが、出典はローマ皇帝の日記です。エンジニアリングにおいて、これはほぼ文字どおり真です。手強いバグはシステムをより深く理解させ、厳しい制約はより優雅な設計を強い、一度の大きな障害はたいてい組織の運用成熟度を一段引き上げます。

もちろん、これを「すべての苦しみは贈り物」と美化するのは問題です。燃え尽きは贈り物ではなく、不当な扱いも贈り物ではありません。ストア哲学の本当の主張はもっと抑制的です。コントロールできない障害に出会ったとき、それを学びや鍛錬の材料として使う余地があるか、と問うのです。障害そのものを称えるのではなく、その中で自分がコントロールできる部分を探すのです。

プラグマティズム：うまくいくものが真理

真理のキャッシュバリュー

アメリカの哲学者ウィリアム・ジェームズは、真理を「それが真であることが、現実の生活にもたらす具体的な違い」と捉えました。彼はこれを真理の「キャッシュバリュー(cash value)」と呼びました。ある信念が真かを問う代わりに、「この信念に基づいて行動すると、どんな違いが生まれるか」を問うたのです。

エンジニアはすでに徹底したプラグマティストです。私たちは「このアーキテクチャは形而上学的に正しいか」とは問いません。「これは我々の負荷に耐えるか、チームが保守できるか、来四半期の要件を吸収できるか」を問います。うまくいけば採用し、いかなければ捨てます。

チャールズ・サンダース・パースのプラグマティズムの格率はもっと率直です。ある概念の意味は、それが生む実際的な結果に還元される、と。「この抽象化のほうが良い」という主張は、それが生み出す観察可能な違い——より少ないバグ、より速い変更、より楽なオンボーディング——に翻訳されてはじめて意味を持ちます。

ドグマではなく結果で論じる

プラグマティズムが日常で最も輝くのは技術論争です。エンジニアリングの議論はしばしばドグマの争いに堕します。「RESTが正しい vs GraphQLが正しい」「モノレポが正しい vs マルチレポが正しい」「OOP vs 関数型」。こうした論争は終わりません。本質的に信念の対決だからです。

プラグマティストは論争の枠組みを変えます。「どちらが正しいか」ではなく「我々の具体的な文脈で、どちらが観察可能なより良い結果を出すか」へと。

ドグマ的な問い               プラグマティズム的な問い
-----------------------     ------------------------------------
GraphQLのほうが良いか？      我々のクライアントが直面する
                            over-fetchingは実際の問題か？頻度と費用は？

マイクロサービスに行くべき？  今モノリスで最も痛む箇所は正確に
                            何で、分割はそれを解決するか？

このコードはクリーンか？      このコードを半年後に別の人が
                            安全に直せるか？

右側の問いは答えられます。測定でき、合意に至れます。プラグマティズムは「正解」が文脈によって変わることを受け入れさせます。これは相対主義ではありません。結果は依然として客観的に測られるからです。ただ、結果の基準を文脈の外にある抽象的な原理ではなく、私たちが実際に置かれた状況に置くだけです。

仮説としての設計

プラグマティズムはあらゆる信念を暫定的な仮説と見なします。デューイは探求を「疑いから始まり、安定した信念へ向かう、しかしいつでも新しい証拠に開かれた過程」と描きました。これはまさに良いエンジニアリングそのものです。

良い設計ドキュメントは「これが正解だ」とは宣言しません。「我々はXを仮定し、Yを試し、もしZ指標が悪化すればロールバックする」と書きます。設計を真理ではなく検証可能な仮説として扱う——これがプラグマティズム的な態度です。A/Bテスト、カナリアデプロイ、フィーチャーフラグは、すべて「信念を現実にぶつけて検証する」というプラグマティズムの認識論の道具です。

エッセンシャリズム：より少なく、しかしより良く

何をしないかを決める

グレッグ・マキューンが広めたエッセンシャリズム(essentialism)は「より少なく、しかしより良く」に要約されます。核心は「何をするか」と同じくらい「何をしないか」が重要だということです。

エンジニアのバックログは無限です。直せるバグ、改善できる性能、追加できる機能、減らせる技術的負債——終わりがありません。すべてが「やる価値」があるように見えます。だからエッセンシャリズムの本当の問いは「これは価値があるか」ではなく「これは他の何よりも価値があるか」です。

これは優先順位ではなくトレードオフの言葉です。すべてに「はい」と言うことは、実は最も重要なものに「いいえ」と言うのと同じです。時間は有限だからです。

実務でエッセンシャリズムはこんな問いとして現れます。

- このリファクタリングは今ユーザーに実際に何を変えるか？
- この抽象化は実際の要求か、想像した未来のためか？
- この会議がなくなったら何が壊れるか？（何も壊れないなら…）
- この機能を作らなければ誰が困るか？どれくらい？

特に「想像した未来のための抽象化」はエンジニアが最も陥りやすい罠です。YAGNI(You Aren't Gonna Need It)の原則はエッセンシャリズムのエンジニアリング版です。今必要ない柔軟性は、たいてい未来にも必要ないまま、現在の複雑さだけを増やします。

断りの技術

エッセンシャリズムの実践で最も難しいのは「いいえ」を言うことです。特に多くの職場文化ではなおさらです。しかし断りが無礼である必要はありません。鍵は、人を断るのではなく、依頼を優先順位の中に位置づけることです。

悪い断り：「それはできません。」

より良い断り：
「今AとBを進めていて、これを入れるとAが来週にずれます。
どちらが急ぐか一緒に決められると嬉しいです。」

後者は断りではなく、トレードオフを可視化することです。決定を依頼者と共有することで、「私は仕事を避けたいのではなく、有限の時間をどこに使うか一緒に決めたい」というメッセージを送ります。これはストアのコントロールの二分法ともつながります。自分の時間配分は、自分がコントロールできる領域だからです。

職人気質：仕事そのものを尊重する

結果ではなくプロセスへの誇り

プラグマティズムは結果を重んじ、エッセンシャリズムは選択を重んじますが、職人気質(craftsmanship)は働くプロセスそのものへの態度です。リチャード・セネットは『クラフツマン』で職人気質を「仕事をそれ自体のために良くやろうとする、人間の基本的で持続的な衝動」と定義しました。

ここには微妙なバランスがあります。プラグマティズムは「うまくいけば十分」と言い、職人気質は「良く作りたい」と言います。両者は衝突するでしょうか。たいていしません。良く作られたものは、より長く動き、より少ない費用で保守され、次の人がより安全に扱えるからです。職人気質の「良く」は、しばしばプラグマティズムの「うまくいく」の長期版です。

衝突が生じるのは、職人気質が自己満足に変質するときです。誰も見ないコードを完璧主義で磨くこと、ビジネス価値のない優雅さを追うこと——これは職人気質ではなく自我の投影です。本物の職人は「この手間が誰に届くか」を知っています。家具職人が見えない引き出しの裏までやすりをかけるのは、その滑らかさを使う人がいるからです。手間の対象があるとき職人気質であり、ないとき強迫です。

退屈な仕事を尊重する

職人気質のあまり目立たない部分は、反復的で退屈な仕事への態度です。ロギングを整え、テストを補強し、ドキュメントを更新し、エラーメッセージを明快にする仕事——華やかではないが、システムを支える仕事です。

ストアのマルクス・アウレリウスは毎朝、自分に「今日、私は仕事をするために起きる」と唱えました。仕事を特別なひらめきの瞬間としてではなく、黙々と成し遂げる何かとして見ました。職人気質とストア哲学が出会う地点がここです。偉大なシステムは英雄的な瞬間ではなく、毎日の誠実な反復によって作られます。

不確実性を扱う：判断の保留

エンジニアリングは、不完全な情報のなかで決定を下すことの連続です。要件はあいまいで、データは不足し、未来は分かりません。この不確実性に耐えることが、職業的成熟の大きな部分です。

古代の懐疑主義(ピュロン主義)はここに興味深い道具を与えます。懐疑主義者は epoché、すなわち判断の保留を実践しました。十分な根拠がないとき断定せず、判断を先延ばしにするのです。これは優柔不断とは違います。優柔不断は決定を回避することであり、判断の保留は「今は確信する根拠が足りない」という事実を正直に認めることです。

エンジニアの日常で、これは非常に実用的です。

性急な断定                   判断の保留
-------------------------     -------------------------------------
「これは明らかにDBの問題だ。」 「DBかもしれないが、まだ分からない。
                            ログをもっと見る必要がある。」
「あのライブラリはダメだ。」    「あのライブラリはX状況では合わなかった。
                            我々の状況は違うかもしれない。」
「この設計が正解だ。」         「この設計は現在の仮定では最善だ。
                            仮定が変われば見直す。」

障害をデバッグするとき、最も危険なのは性急な確信です。「きっとキャッシュの問題だ」と断定した瞬間、私たちはその仮説に合う証拠だけを探し、反対の証拠を無視します。確証バイアスに陥るのです。判断を少し保留して「データは何を言っているか」をまず問う節制——これは懐疑主義とプラグマティズムが出会う地点です。

ただしバランスが必要です。永遠に判断を先延ばしにはできません。あるときには不完全な情報でも決めなければなりません。核心は「確信の度合いを証拠の度合いに合わせること」です。強い証拠には強い確信を、弱い証拠には暫定的な結論を。そして新しい証拠が来れば喜んで考えを変えること。これは気まぐれではなく知的誠実さです。

比較の罠と自分の基準

エンジニアが心の平静を失う最もよくある理由の一つは比較です。より若い年齢でより高い役職に就いた同僚、華やかなサイドプロジェクトで注目される知人、カンファレンスで発表する同年代——ソーシャルメディアの時代に、比較の材料は無限です。

ストア哲学はここでもコントロールの二分法を適用します。他人の成果は自分がコントロールできません。そしてより重要なのは、私が見るのは彼らの「成果物のハイライト」であって、その裏の奮闘や失敗や運ではないということです。私たちは自分の舞台裏(混乱、疑い、失敗)を他人の完成した舞台と比べる、非対称なゲームをしています。

セネカはこう書きました。

「誰かがあなたより先に進んでいるなら、あなたは自分自身とではなく、その人と競っているのだ。」——セネカ『道徳書簡』からの変奏

自分の基準(self-referenced standard)へ移すことが解法です。「あの人より良いか」ではなく「去年の自分より良いか」を問うのです。前者はコントロール不能で終わりがなく、後者はコントロール可能で意味があります。プラグマティズム的にもこちらが良いのです。他人との比較は行動を生みませんが(嫉妬はコードを書いてくれません)、自分の基準での成長は具体的な次の行動を指し示します。

もちろん、比較がすべて悪いわけではありません。より良い人を見て学ぼうとする動機に使えば健全です。核心は、比較の結果が「自己卑下」で終わるか「具体的な学び」につながるかです。前者なら比較をやめ、後者ならその人に近づいて尋ねてください。

行き過ぎた自己啓発の罠を警戒する

ここまで哲学的な道具を紹介してきましたが、ここで必ずバランスを取らなければなりません。現代の「ストア哲学インフルエンサー」文化は、これらの哲学を危険に歪めることがあります。

第一に、個人化の罠です。「コントロールできることに集中せよ」という教えが、構造的な問題を個人のせいにするのに悪用されかねません。燃え尽きを引き起こすのは、しばしば非現実的なスケジュール、人員不足、まずいマネジメントです。これは「あなたのレジリエンス不足」の問題ではなく、組織の問題です。ストア哲学は不当さに耐えよという哲学ではありません。コントロールできないものを受け入れることと、変えられる構造を放置することは、まったく別物です。

第二に、感情抑圧の罠です。「感情に振り回されるな」が「感情を感じるな」と誤解されます。本物のストア哲学は感情を否定しません。感情を認知しつつ、その感情に基づく衝動的な判断を少し先延ばしにせよ、と言うのです。悲しみを感じるのは弱さではありません。悲しみを無視して働くのが強さでもありません。

第三に、生産性フェティシズムの罠です。自己啓発産業はすべての時間を「最適化」せよと煽ります。しかしエッセンシャリズムの本当のメッセージは正反対です。少なくやり、休み、空けることも本質的な選択です。24時間を隙間なく埋めるのはエッセンシャリズムではなく、その逆です。

哲学を道具として使いつつ、道具があなたを鞭打つ棒にならないようにしてください。この記事のすべての概念は、「より良い人間にならねばという圧力」ではなく、「不確実さの中で心をどこに置くか」として読まれるべきです。

学びと成長への応用

これらの哲学は、日常の危機管理だけでなく、長期的な学びとキャリアにも応用できます。エンジニアのキャリアは終わりのない学習の連続です。新しい言語、新しいフレームワーク、新しいパラダイムが絶えず登場し、その速度に圧倒されやすいものです。

ストアのコントロールの二分法は、ここで心の平静を与えます。すべての新技術を追いつくことはコントロールできません。それは不可能で、それを目標にすれば慢性的な不安に陥ります。コントロールできるのは「何を深く学ぶか選ぶこと」と「着実に学ぶ習慣」です。すべてを浅く知るより、本質を深く理解するほうが——エッセンシャリズムの観点からも——価値があります。

プラグマティズムは学習の優先順位を決めてくれます。「これを学ぶことが、私の実際の仕事と成長にどんな観察可能な違いを生むか？」流行しているという理由だけで何かを学ぶのは非効率です。逆に、基礎——データ構造、システム設計、デバッグ、明快な文章——はほぼすべての文脈でキャッシュバリューが高いものです。流行は変わりますが、基礎のキャッシュバリューは変わりません。

学びに哲学を適用する

  [ストア] すべての技術に追いつこうとしない。
          コントロール可能なのは「選択」と「着実さ」だ。

  [プラグマティズム] 「これが実際にどんな違いを生むか」で
                  学習の優先順位を決める。流行ではなく価値。

  [エッセンシャリズム] 浅くすべて知るより本質を深く知る。
                    「今最も大きなレバレッジを与える学習」に集中。

  [職人気質] 学び自体を楽しむ。結果(資格、承認)ではなく
            理解の深まりに満足を見いだす。

特に職人気質の観点が学習を持続可能にします。学習をひたすら外的報酬(昇進、給与)の手段としてのみ見ると、報酬が遅いとすぐに疲れます。しかし学び自体の楽しみ——知らなかったことが理解できる瞬間の小さな喜び——を動力にすれば、学習は義務ではなく楽しめるものになります。そして逆説的に、そうして楽しみながら学ぶ人が長期的により遠くへ行きます。

最後にグロースマインドセットとのつながりです。プラグマティズムが設計を仮説として見るように、自分の能力も固定されたものではなく変わりうる仮説として見ること——「私はこれがまだできない」のその「まだ」が、コントロール可能な領域(努力、時間)へ向かうストア的な信念と出会います。

仕事への応用：統合フレームワーク

三つの哲学を一つの実践の流れに織り込んでみましょう。どんな状況でも、この順序で通すことができます。

1. [ストア] この状況で自分がコントロールできるのは何か？
   コントロール不能な部分はいったん手放す。

2. [プラグマティズム] コントロール可能な選択肢のうち、
   観察可能なより良い結果を出すのはどれか？ドグマでなく
   結果で判断する。

3. [エッセンシャリズム] そのうち本当に重要な一つは何か？
   残りに「いいえ」と言う。

4. [職人気質] 選んだその仕事を、それが届く人を
   思いながら丁寧にやる。

5. [ストア、再び] 結果は自分の領域ではない。
   最善を尽くしたなら、結果は淡々と受け入れる。

この流れをコードレビューに当てはめてみましょう。同僚のPRに問題が見えます。(1) 自分がコントロールできるのは「自分がどうフィードバックするか」であって「相手がどう受け取るか」ではありません。(2) 非難調と質問調のどちらが実際にコードを改善する結果を出すでしょうか。経験上、質問調です。(3) 些細なスタイルの指摘十個と重要な設計の懸念一つ、どちらが本質でしょうか。(4) その一つのフィードバックを、相手が理解し成長するよう丁寧に書きます。(5) 相手が同意するかは自分の領域ではありません。

朝と夜の儀式：哲学を習慣にする

哲学が道具なら、道具は定期的に手に取ってこそ役に立ちます。ストア哲学者は抽象的な思索だけをしたのではなく、具体的な日常の儀式を持っていました。マルクス・アウレリウスの『自省録』そのものが毎日の自己点検の記録であり、セネカは毎晩一日を振り返る習慣を勧めました。

これをエンジニアの一日に移すと、二つの小さな儀式になります。

朝の点検

朝に (5分、コーヒー一杯とともに)：

  1. 今日コントロールできないことは何か？
     (例：面接の結果、レビュアーの応答、会議の決定)
     -> あらかじめ手放す。そこに感情を結びつけない。

  2. 今日本当に重要な一つは何か？
     (エッセンシャリズム：「今日が終わったとき、これだけ
      やれば成功」と言える一つ)

  3. 今日出会う困難は何で、どう対応するか？
     (ネガティブ・ビジュアライゼーション：厄介な会議、
      詰まるバグをあらかじめ落ち着いて思い描く)

セネカが勧めたネガティブ・ビジュアライゼーションの核心はこれです。一日を始める前に「今日、誰かが無礼かもしれない、仕事が詰まるかもしれない、計画が狂うかもしれない」とあらかじめ認めること。すると実際にそういうことが起きても「予想していたこと」になり、平静を失いにくくなります。

夜の振り返り

夜に (5分、眠る前)：

  1. 今日よくやったことは何か？ (自責ではなく承認)
  2. コントロール可能なもののうち、もっとよくできたことは？
     (非難ではなく学習。明日の小さな調整。)
  3. 今日感謝することを一つ。

ここに重要なバランスがあります。夜の振り返りが自己批判の時間になれば逆効果です。核心は「コントロール可能だったこと」だけに焦点を当てることです。コントロールできなかったことで自分を責めるのは、ストア哲学の正反対です。そして感謝を一つ加える理由は、暗い時期ほど私たちの注意が否定的なものに引っ張られるからです。良かったことを意図的に思い出すのは、単なるポジティブではなく、注意のバランスを取る練習です。

これらの儀式は大げさである必要はありません。それぞれ5分で十分で、完璧に毎日やる必要もありません。核心は、哲学を頭の中の知識ではなく、手に握った習慣にすることです。知っているだけの哲学は本棚の飾りで、毎日使う哲学は道具です。

対話例：哲学を実際の状況に適用する

抽象的な原理は、具体的な対話の前で無力になりがちです。二つの実際の状況を通じて、このフレームワークがどう働くかを見ましょう。

状況1：不当な成果評価

年末の評価で、期待より低い等級を受けました。あなたから見れば十分よくやったのにです。

ステップ1 [ストア] コントロール可能：自分の反応、次四半期の
   行動、マネージャーにフィードバックを明確に求めること。
   コントロール不能：すでに付けられた等級、マネージャーの認識。

ステップ2 [プラグマティズム] どの反応がより良い結果を生むか？
   怒りの発露 vs 具体的な質問。後者が次の評価を
   改善する可能性が高い。

ステップ3 実際の対話：
   悪いアプローチ：「この評価は不公正です。」
   より良いアプローチ：「この等級の根拠を理解したいです。
     私がどの部分で期待に届かなかったか、
     次四半期に何を変えればよいか
     具体的に教えていただけますか？」

後者は評価を覆そうとする試みではなく(それはコントロール外)、未来の行動を改善しようとする試みです(コントロール内)。そして懐疑主義の判断保留も働きます——「この評価は明らかに間違っている」と断定する前に、私が見ていない視点があるかをまず聞くのです。

状況2：同僚との技術論争

同僚が、あなたから見て間違ったアーキテクチャを強く主張します。

悪いアプローチ：「そのやり方は間違っています。私のが正しい。」
   -> ドグマ対ドグマ。信念の対決に堕する。

より良いアプローチ：「両方のトレードオフを整理しましょうか？
   それぞれがどの状況でより良いか、我々の実際の
   要件がどちらに近いか一緒に見ましょう。」
   -> 結果で論じる。測定可能な基準へ移る。

ここでエッセンシャリズムも働きます。すべての意見の違いを最後まで争う必要はありません。「この決定は本当に重要か、それとも元に戻せる決定か」をまず問います。元に戻しやすい決定なら、同僚のやり方でやってみてデータで判断するほうが、論争より速いかもしれません。プライドを本質と取り違えないこと——それが成熟です。

実践チェックリスト

次の一週間で試せる、具体的で小さな実践です。すべてやる必要はありません——エッセンシャリズムを思い出してください。

[ ] 挫折した瞬間、「これはコントロール可能か？」と一度問う。
[ ] 技術論争で「正しいか」を「我々の文脈でどんな結果を
    出すか」に置き換えてみる。
[ ] 今週のバックログから「やらないこと」を三つ決める。
[ ] 依頼を一つ断る。ただしトレードオフを可視化して断る。
[ ] 次のデプロイ前、「これが深夜3時に壊れたら？」を落ち着いて
    一度想像し、備えを点検する。
[ ] 退屈だが重要な仕事(テスト/ドキュメント/ロギング)を一つ、
    「届く人」を思い浮かべて丁寧にやる。
[ ] 一日に一度、意図的に何もしない10分を作る。
    (生産性フェティシズムの解毒剤)

おわりに：道具としての哲学

哲学はあなたをより良い人間にしてくれる魔法ではありません。そしてそうあるべきでもありません。ストア哲学、プラグマティズム、エッセンシャリズム、職人気質——これらは机の引き出しに入れておく道具です。必要なときに取り出して使い、合わなければ別のものを使います。

エンジニアの仕事は不確実性とコントロール不能の連続です。これらの道具が約束するのは、その不確実性を消すことではなく、その中で心をどこに置くかをより明確に決める手助けをすることです。コントロールできることに集中し、結果で判断し、本質に「はい」と言い、仕事を丁寧にやる。そしてそのすべての努力の結果は淡々と受け入れる。

最後に、これらすべてを完璧にやらねばという圧力は手放してください。その圧力こそ、私たちが警戒した自己啓発の罠だからです。哲学は鞭ではなく羅針盤です。道に迷ったとき、一度取り出して方向を確かめれば、それで十分です。

Discuss on Twitter • View on GitHub