退職が僕に教えてくれたこと

ソフトウェア開発の世界に足を踏み入れてから、今年で10年目を迎えた。これまで大体5〜6社ほど経験してきた。退職を決断した瞬間について、一度も後悔したことはない。

自分の理想に完全に合致する職場環境に出会ったことはない。

むしろ「この会社にいても意味がないんじゃないか」「他の会社のほうがいいのではないか」と思うことがよくあったし、退職して転職活動を始めてから「あのときああしていれば、何かが変わっていたのではないか」と振り返ることも多かった。

人生に後戻りの薬はない。退職するたびに多くの学びがあり、自分が発揮できる強みも少しずつ理解できるようになる。だが、退職する前に、本当に考え抜いただろうか？僕自身の生々しい実体験を一線の開発者として共有し、未来の自分への指針とするとともに、かつての僕のように退職すべきか迷っている誰かの助けになればと思う。

キャリアに対する追求は人それぞれだ。組織の中で社内政治というゲームをこなし、会社勤めの中に達成感を見出す人もいれば、フリーランスとして案件を受け、生活の柔軟性を保つことを好む人もいる。あるいは起業というまったく別の道を選ぶ人もいる。

完全に間違っている道など一つもない。

ある会社を退職したとき、まだ若かった僕は1万文字を超える長文記事を公開した。そこには社内での経験や同僚への感謝、会社の制度に対する不満、そして退職後に見えてきたことを赤裸々に書いた。

その記事は何度もシェアされ、会社の法務の目にも留まった。法務担当者はわざわざ記事のコメント欄に「会社が一番得意なのは、会社に失望していた人間を、退職後さらに失望させることだ」とまで書き残していった。

若さゆえの衝動は貴重なものだが、当時の自分を振り返ると、いささか未熟だったと思わざるを得ない。

若い頃の僕は、技術こそがすべてだと信じていた。

しかし今実感しているのは、安心して開発に専念できるのは、自分自身が優秀になったからでも、成長したからでもなく、先人たちの犠牲があったからだということだ。

彼らが懸命に環境を整え、インフラを構築してくれたからだ。上司が意味不明な要件をブロックしてくれたり、深夜に経営陣から怒鳴りつけられたりしていることなど、開発者は気づきもしない。ただ「うわ、僕ってなんてすごいんだ！」と自惚れるだけだ。

自分が深夜にボスから怒鳴られる立場になるまでは。

退職は特効薬ではない

後の章で優先的に退職を検討すべきケースについて触れるが、退職を決める前に、自分がどちらの状況に当てはまるかを一度考えてみてほしい：

• 職場に嫌なこと（感情的な問題、プレッシャー）があり、そこから逃げ出したい
• 自分が何を求めているかが明確で、ここに留まってもそれを手に入れられないと判断した

もし環境の不完全さから逃げるためだけに退職するなら、次の職場でも同じループに陥ることが多い。どんな組織にも、リソースの不均等な配分や非効率なコミュニケーション、人間関係の摩擦は必ず存在する。そうした制約こそが、むしろ成長のための絶好の機会なのだ。

退職の理由が「環境の悪さ」（例えば上司が高圧的、プロセスが混乱しているなど）でありながら、今の環境でプロセスを最適化する試みをしていないなら、新しい会社で似たような性格の人や同じような混乱に直面したとき、やはり対処する術を持てないままだ。

あるプロジェクトで、僕はテックリードに昇格した。当時の僕は、プロジェクトをどのように推進すべきかをよく理解していなかった。

チーム内で技術的な理解度が比較的高く、アイデアも多く持っていた。だが、当時の僕の伝え方は拙く、同僚の提案に対してあれこれと難癖をつけてしまい、周囲からは非常に高圧的で一緒に働きにくい人間だと思われていた。

その後、同僚から非常に厳しいネガティブフィードバックを受けた。僕の高圧的な態度はチームの士気を著しく下げるという指摘で、その同僚は僕の行動に対してはっきりと「pissed off（腹が立った）」と書いていた。

その後、上司と1on1を行い、上司からも職場でより重要なのは影響力を発揮することだと厳しく諭された。正直なところ、最初は納得がいかなかった。「なぜみんなコード品質を重視しないのか、そのうえなぜ自分が悪い評価を受けなければならないのか」と不満ばかり感じていた。だが、不満を上司にぶつけるだけでは、何の変化も成長も生まれない。

あの出来事は、僕にとって非常に大きな学びと成長の機会となった。周囲の人々に気を配るようになり、チームのアウトプットを最大化するために自分は何ができるかを考えるようになった。マネジメントや人間関係に関する書籍も読み漁るようになった。

もし上司の忠告と同僚からの重いネガティブフィードバックがなければ、僕は自分の仕事の進め方を改めることはなかっただろう。

価値観は諸刃の剣

価値観が完全に一致する職場で働くことは極めて難しい。職場には、不満を感じる要素が常にいくつかある：

• 指示を出すだけの上司
• 社内政治

かつてこんな要件があった。ユーザーがページを離脱した際、自動的にAPIを叩いて画像を削除したいというものだ。真っ先に思いつくのは sendBeacon の利用だが、何らかの理由でそのケースでは sendBeacon が適用できなかった。すると別の同僚は、直接 ajax を使い、sync パラメータを指定してHTTPリクエストを強制的に同期通信にしてしまった。

そのコードを見た瞬間、僕は激怒した。無意識のうちに「プロの開発者が提案するような解決策ではない」と感じたからだ。

数年後に振り返ってみて、当時の自分の態度と心構えは間違っていたと痛感した。なぜAjaxでsyncを使うのが良くないのかを論理的に説明しなかったし、その開発者が提案した方法は、現にその場の課題を解決できていたのだ。

この一件を通して気づいたのは、時に問題は価値観の不一致ではなく、最初から相手の考えを理解しようとしていなかったことにあるということだ。この2つはまったくの別物だ。

当たり前のことを言語化する

開発者を長く続けていると、こうコードを書けばどんな潜在的リスクがあるか、ある関数の書き方を見ればどこにバグが出るか、要件を聞いただけで大体のアーキテクチャがどうなるかが感覚的に分かるようになる。

環境変数をGitの履歴に含めるべきではない、Secrets Managerで管理すべきだ、データベースを外部ネットワークに公開してはいけない、パスワードはハッシュ化すべきだ、SSR（Server-Side Rendering）でSEOを強化する、データベースの正規化を行う。

開発者にとって当たり前のこうした「常識」について、背後にある理由や根拠をきちんと説明できるだろうか？

『超一流になるのは才能か努力か（原題：Peak: Secrets from the New Science of Expertise）』という本の中で、チェスのグランドマスターに関する話が取り上げられている。盤面をわずか5秒見せただけで、マスターは20個以上の駒の位置や手順を記憶できるという。

だが、駒を完全にランダムに配置した場合、マスターと初心者の成績に有意な差は見られなくなる。熟練者は膨大な経験の蓄積によって、チェスの定石や展開を直感的に推測し、それを記憶の助けにしているからだ。

残念ながら、ソフトウェア開発はチェスではない。一定の役職に達すると、技術に詳しくない人、あるいは技術をまったく理解していない人に対して、なぜそうするのかを説明しなければならなくなる。自分にとって当たり前の「常識」を、相手が理解できる言葉へと変換することが求められるのだ。

当たり前だと思っている事柄や心情ほど、言語化できないことに気づくだろう。あるいは、言語化することから逃げているのかもしれない。アイデアや経験、常識を文字に落とし込むことは、自分自身の論理の綻びと直面することを強いるからだ。

なぜ退職したいのか？

ここで少し練習をしてみよう。なぜ退職したいのだろうか？

まずはいくつかの理由を挙げてみる：

• ボスが理不尽すぎる
• 給与が低すぎる
• 価値観が合わない

これをさらに具体化してみる：

• ボスが理不尽すぎる → 「理不尽」とは具体的に何か？
  • 前回のプロジェクトで、想定されるリスクを報告したにもかかわらず真面目に取り合ってくれず、いざリスクが顕在化すると僕のせいにされた
  • 直近1ヶ月で、コーヒーの買い出しやトイレ掃除など、職務範囲外の雑用を命じられた回数が10回に及んだ
• 給与が低すぎる → 理想の給与はいくらか？
  • 現在の給与の20%アップが希望
• 価値観が合わない → 自分の価値観と、観察された会社の価値観とのギャップは何か？
  • 僕の観察では、会社は個人プレーのヒーロー主義を推奨している。誰かが機能を素早く仕上げたときには称賛が集まるが、ドキュメントを書いて知見を共有したり、デプロイ速度を改善したりしても評価されない。僕は結束力のあるチームワークを重視したい
  • 従業員の成長や評価の制度がなく、以前提案したオンボーディングの改善案も却下された。会社は長期的に共に戦うチームではなく、単なる即戦力を求めていると感じる

このように具体的な事実ベースで整理すると、思考を深めるべきポイントが見えてくる。

変えようと試みただろうか

退職したい気持ちがあり、その原因も分析できたとする。

その原因の中で、もしそれらの問題がすべて解決されたとしたら、自分はまだここに留まりたいと思うだろうか？もし答えが「イエス」なら、現状を変えるための行動を起こしただろうか？

以下の問いを自分に投げかけてみてほしい：

• 直面している困難や課題が解決されたら、ここに残りたいと思うか？
• これらの問題を解決するために行動したか？それは自分の能力の範囲で出し得るベストなアプローチだったか？
• 3年後、5年後の目標を考えたとき、この場所はその達成を助けてくれるか？

問題に直面したとき、環境のせいにしてしまうのは人間の自然な反応だ。

『7つの習慣』では、「関心の輪」と「影響の輪」という2つの概念が示されている。

関心の輪とは、自分が関心を持っている、あるいは不安を感じているすべての事象を指す。一方、影響の輪とは、関心の輪の中で、自分の行動によって直接変えられる事象を指す。

自分の人生の主導権を握りたいのであれば、関心の輪ではなく、行動によって直接変化を起こせる「影響の輪」に注力すべきだ。

例えば、給与が低すぎると感じるなら、断られたり気まずくなったりするリスクを恐れず、経営陣と交渉しただろうか？昇給に値する客観的な根拠を提示しただろうか？自分が何を行い、それがどんな成果をもたらしたかを伝えただろうか？

「自分のアウトプットにより集中したいので、こうした雑用は引き受けたくありません」とボスに伝えただろうか？

価値観の相違について、上司にフィードバックしただろうか？

コードの保守性が低すぎると感じるなら、リファクタリングや改善案を自ら提示し、なぜそれが重要なのかを上司に説得しただろうか？

すべて手を尽くしても変えられず、何度試みても状況が動かないのであれば、そのときは迷わず退職を考えればいい。

自分が変えられることだけに集中しよう。

大企業の保護シェルター

現職で多くのスキルを身につけ、いくつものプロジェクトを完遂したと自負している人は多い。だが実のところ、それはシニアな先輩やCTOが完璧な環境を用意してくれたおかげであり、自分は誰かが敷いてくれたレールの上でタスクをこなしていただけに過ぎないのかもしれない。

規模の大きい会社や上場企業では、職務範囲が明確に細分化されているのが一般的だ。

プロジェクトでサーバー構築が必要なら、SREチームに依頼すればネットワークや権限、環境構築をすべて整えてくれる。AnsibleやTerraformを使った自動デプロイスクリプトも書いてくれる。

機能開発が終われば、専任のQAチームがテスト計画を策定し、テストを実行してチケットを切ってくれる。

すべてが非常に理想的に聞こえるだろう。

しかしその弊害として、自分の職責の範囲内にしか視野が向かなくなる。リソースが限られた環境に移り、ゼロからすべてを自分で構築しなければならなくなったとき、完全に立ち往生してしまう。

そうなると「なぜこんなに雑用が多いのか」と不満を抱くようになる。だがそれは雑用が多いのではなく、これまでの自分が保護シェルターの中で生きてきて、そこから抜け出す試みをしてこなかっただけなのだ。

「この件は『僕』が主導して推進したからこそ、このような変化が生まれた」と具体的に語れないなら、実のところ自分はサービスを受ける「お客様」だったに過ぎない。そうした腰掛け気分を持ったまま転職すれば、ゼロから道を切り拓く必要がある環境に放り込まれたとき、手痛いしっぺ返しを食らうことになる。

上を目指すなら、人と組織の難題からは逃げられない

多くの開発者は、技術こそがすべてであり、組織の政治のようなものは薄汚く、不道徳なものだと考えがちだ。しかし、求められる影響力が個人のアウトプットの限界を超えたとき、他者と協調して目標を達成する以外に道はなくなる。

「素晴らしいコード」や「素晴らしいアーキテクチャ」を掲げるだけでは人を動かせない。論理的な正しさを盾にして相手に全面的な受け入れを迫るのは、極めて傲慢な振る舞いだ。

人間関係や組織構造は、仕事を阻害するノイズではなく、仕事そのものを構成するコアな変数なのだ。これらの難題を避けることは、自分自身のスケールアップを拒否することと同義である。

開発者なら誰しも独自のこだわりや譲れない価値観を持っていることはよく分かる。どちらか一方に完全に偏ることは難しいが、僕たちにできるのは、自分が納得できる動的なバランスを見つけ出すことだ。

日本には「根回し（nemawashi）」という言葉がある。会議の前や正式な意思決定の場を持つ前に、キーパーソンの元へ個別に足を運び、意見を聞き、事前に調整を図ることを意味する。

そうして正式な場で提案すれば、合意形成はずっと容易になる。担当するプロジェクトのスコープが大きくなればなるほど、技術以外のこうした側面に目を向ける必要が出てくる。

かつて社内のあるプロジェクトで、サーバーサイドレンダリング用のサーバーをゼロから立ち上げる必要があった。

当時使っていた社内ツールのサポートが限定的だったこと、さらに動的なデータフェッチが必要だったことから、僕は新たなアーキテクチャによる実装を提案した。

このアーキテクチャには多くの部門の協力が不可欠だった。SREにはサーバーの準備と構築を依頼しなければならず、企画側にはこの機能によって将来どんなメリットがもたらされるかを説明する必要があり、開発陣には全体設計の概要を共有しなければならなかった。コードの実装自体はそれほど難しくなく、Next.jsサーバーのデプロイに過ぎない。

だが、これら関係各所を説得するために、僕は膨大なドキュメントを用意し、部署ごとに切り口を変えて説明を重ねた。当時は人手不足だったこともあり、部門間の調整を推進しながら、自分自身でアーキテクチャの実装を進める必要があった。

幸いにも上司の強力なサポートがあり、プロジェクト完了後、僕は非常に大幅な昇給を勝ち取ることができた。

雇用関係＝資本主義のゲーム

「この会社は僕がいなければ立ち行かない」という思い込みを抱いて退職することだけは絶対に避けるべきだ。そうしたメンタリティは極めて不健全である。

資本主義において、会社にとって替えの利かない人間など存在しない。資本市場を探せば、自分と同じ役割を果たせる人間は必ず見つかる。

雇用関係の本質は、労働力と資本の等価交換であり、感情の拠り所ではない。組織構造において、個人の機能はモジュール化され、代替可能に設計されている。それこそが、資本主義が安定性を追求した結果の必然なのだ。

一方で個人にとって、ある会社に加わることは価値観の選択を意味する。その会社で獲得したスキル、信頼、人脈は、誰にも奪えない自分だけの資産となる。

以前、ある創業社長に「従業員のことをパートナーだと思っていますか」と尋ねたことがある。今振り返ると、ずいぶんナイーブな質問だったと思う——仮にパートナーだと思っていたとしても、雇用関係という現実は何ら変わらないからだ。

雇用関係である以上、会社が生き残るための核心は2つしかない。会社が利益を出しているか、そしてオペレーションが円滑に回っているかだ。チームの存在意義は互いに仲良しグループになることではなく、目標を一つひとつ達成することにある。

当時、僕はさらに別の質問も投げかけた。「もし従業員が病気になったり悩みを抱えたりしたとき、経営者として耳障りのいい言葉で体裁を取り繕いますか、それとも心から心配しますか？」どちらの対応を取ろうと結果は同じかもしれないが、当時の僕は、社長には従業員を心から気遣ってほしいと願っていたのだ。だが、この考え方は根本的に間違っていた。

職場は本来、真心を交換し合う場所ではない。経営陣の責務は会社を存続させ、チームに成果を出させることであり、従業員のメンターや親友になることではない。適切なコミュニケーションによって従業員に敬意を感じさせ、士気を維持しつつ、個人的な感情によって経営判断を歪めないことこそがプロフェッショナリズムなのだ。

心からの気遣いは耳ざわりが良いが、それには代償が伴う。経営者が特定の従業員に過度な感情移入をすれば、レイオフの決断を躊躇し、人事評価で手心を加え、リソース配分を偏らせてしまう。そうした迷いや偏りは、最終的にチーム全体、ひいては会社全体を傷つけることになる。

自分の勝手な憧れを押し付けて、雇用関係の本質を見失ってはならない。従業員は時間と能力を提供し、会社は報酬と活躍の場を与える。双方が成すべき責任を全うすることこそが最大の敬意なのだ。職場に求められるのは真心ではなく、物事を成し遂げる力だ。

成長は苦痛から生まれる

I wish upon you ample doses of pain and suffering. — Jensen Huang

もちろん、働く動機やキャリアの目標は人それぞれだ。生活のために給与を得ながら、自分が進むべき道を探している人もいるだろう。

NVIDIAのCEOであるジェンスン・フアンはかつて、すべての人に苦難を経験してほしいと語った。特に十分なリソースや恵まれた教育・家庭環境のもとで育ち、高い期待を背負って高額な学費を払い、優れた教育機関で学んできたような人々について、そうした人は往々にして打たれ強さに欠けると指摘している。

彼は、真に偉大な物事を成し遂げるのは必ずしも頭の良い人間ではなく、苦難を経験してきた人間だと考えている。当初、僕はこの言葉の意味を完全には飲み込めずにいたが、今なら少しずつ理解できる。

大学時代の僕にはリソースがまったくなかった。服や靴を買う余裕などなく、まともな機材を揃えることもできず、携帯電話の利用料金すら払えない状態だった。

だが、経済的に困窮していたからこそ、「何かの技術をいち早く身につけ、一刻も早くインターンとして働かなければならない」という強烈なモチベーションが生まれた。

そのおかげで学生時代から開発の実務経験を積むことができ、その後のキャリアにおいて、技術的ハードルが高く待遇の良い企業を目指す切符を手に入れることができた。

その後、職場でテックリードを務める機会に恵まれ、チームの意思決定や方針決定、他部署との調整を担うようになった。こうした仕事は、最初から要領が分かっているわけではない。手探りかつ不確実性の極めて高い環境の中で、泥臭く前に進めるしかないのだ。

マネージャーに昇格すると、今度は対人関係やメンバーマネジメントといった課題と向き合うことになる。「コードを綺麗に書いてアウトプットを出せば評価される」という従来の思考はもはや通用しない。チーム全体をどう底上げするかに思考を切り替える必要がある。

どのステージにいるときも、その瞬間が楽しいとは限らない。むしろ苦痛であることのほうが多い。なぜならそれは、これまでの仕事の進め方を根本から変え、自分自身の価値観すら再構築することを意味するからだ。

しかし、決断の数を重ね、課題を乗り越え、より多くの人と協業し、上層部との交渉を経験し、多様なプロジェクトを経験するにつれて、不慣れな環境下でも打開策を見つけ出せるようになっていく。試行錯誤を繰り返しプロジェクトを前進させるプロセスは苦痛に満ちているが、そこから得られる成長もまた極めて大きい。

やがて、「この手のプロジェクトは過去に経験があるから、アーキテクチャや必要な技術スタックの勘所がわかる」という状態になってくる。そして、プロジェクトを成功に導くために、技術そのものはもはや最重要の要素ではないことにも気づく。

ステークホルダーとどう対話するか？提案の実行可能性をどう納得してもらうか？いかに相手の視点に立って物事を捉えるか？かつては気にも留めなかった細部こそが、プロジェクトを前に進める最も決定的な要因だったのだと理解できるようになる。

だからこそ、成長には痛みが不可欠なのだと僕は思う。

職場で苦痛を感じたときは、立ち止まって考えてみてほしい。「この痛みは自分を成長させてくれるものだろうか？」もしそうなら、安易に逃げ出すべきではない。

苦痛には2種類ある。自分を成長させてくれる苦痛と、単に自分を摩耗させるだけの苦痛だ。

最近ランニングを始めたのだが、走ること自体が大好きというわけではない。早起きしなければならないし、凍えるような寒さの中でも走らなければならず、心臓が破裂しそうになっても、脚が動かなくなっても走り続けなければならない。

これらはすべて苦痛だ。だが、走行距離を積み重ねることで体が健康になり、心肺機能が強化されることを僕は知っている。

走っている最中はいつだって苦しいが、走り終えて後悔したことは一度もない。後悔するのは、いつだって家で自堕落に過ごしてしまったときだ。

一方で、成長をもたらさない苦痛は避けるべきだ。

それはまるで、バレーボールをやりたいのに、ゲームのルールが野球だったようなものだ。野球のグラウンドでバレーボールのルールをいくら適用しようとしても、絶対に勝てるわけがない。

厄介なのは、渦中にいる瞬間にはその2つを見分けるのが極めて難しいという点だ。今プレイしているのが野球なのかバレーボールなのかすら判別がつかない。

過去に、開発の真っ只中にあったプロジェクトが突然サービス終了を言い渡され、半年間の努力が水泡に帰し、人事評価もゼロになった経験がある。

とはいえ、成長を望むなら、ランニングと同じように苦痛を積み重ねるプロセスが必要だ。以前は1キロ9分ペースで死にそうになっていたのが、今では8分ペースでも息が上がらなくなる。痛みを乗り越えて初めて、それがもたらしてくれた成長を実感できるのだ。

FDEから職場を振り返る

最近、Forward Deployed Engineer（フォワード・デプロイド・エンジニア、OpenAI の例などを参照）という職種をよく目にする。これは典型的なソフトウェアエンジニアやコンサルタントとは異なり、高い技術力を背景にプロトタイプを本番環境へデプロイし、実行可能なソリューションへと昇華させる役割を担う。

以下は、その職務記述書（Job Description）の一例だ：

In this role, you will:

• Embed deeply with strategic customers to understand their business challenges and technical requirements in detail.
• Design, architect, and develop full-stack solutions using an experiment-driven, iterative approach.
• Prepare detailed scopes of work and project plans for both proof-of-concept prototypes and full production deployments.
• Work hands-on with customers’ technical teams as a technical expert and trusted advisor, coding side-by-side to drive projects to completion on their infrastructure.
• Collaborate with Product, Research and Applied teams to ensure seamless customer experiences, project success and actionable product feedback
• Contribute to internal knowledge bases, codifying best practices and sharing insights gained from customer engagements to scale the Forward Deployed Engineering function.

You’ll thrive in this role if you:

• 7+ years of professional full stack engineering experience (excluding internships) in relevant roles at tech and product-driven companies - customer-facing experience is highly desirable
• Former founder, or early engineer at a startup who has built a product from scratch is a plus
• Experience with relational databases like Postgres/MySQL
• Have a bias for action and willingness to work iteratively with your customers to deliver the right solution that solves their problem.

通常のチームにおけるソフトウェアエンジニアの役割は、PMや企画側が整理した要件を受け取り、それに基づいて実装することだ。

対してForward Deployed Engineerは、顧客の目の前に飛び込み、現場の運用状況を直接観察した上で解決策を提示し、自らソリューションを構築してリリースまでプロジェクトを推進する。

ここには、曖昧な要件を実行可能なタスクへと落とし込む能力や、顧客と強固な信頼関係を築く能力が求められる。

こうした業務において、膨大なコミュニケーションが発生することは想像に難くない。ステークホルダーと対話し、自らの提案の妥当性を説得し、限られたリソースと納期の中で最適な解を導き出す。

それは決して居心地の良いコンフォートゾーンにとどまる仕事ではないし、慣れ親しんだルーチンでもないはずだ。

社内ゲームを必ずしもプレイする必要はない

ここまで読んでも、納得がいかない人はいるかもしれない。

「なぜ自分と価値観のまったく異なる部門や上司、ましてや経営陣を説得するために、これほどの労力を割かなければならないのか？そんなの疲れるだけだ」と。

認識のギャップを埋める作業はひどく骨が折れるし、苦痛であり、無力感を覚えるものだ。職場で物事を進めたいのに相手を説得できないというのは、自分のコミュニケーションや影響力がまだ足りていないことを示しているに過ぎない。認識のギャップは言い訳にはならず、弁解の余地はない。ただ、組織のゲームのルールから降りるのであれば、心から納得できないことに対して率直に異を唱えたって構わないのだ。

このゲームに無理に参加する必要はまったくない。見下したっていいし、拒絶したっていい。「そんなのは疲れすぎる、自分らしく生きたい、純粋に技術と開発だけに専念したい、technology will always win（技術は常に勝利する）を証明したい」と主張するのも完全に自由だ。

それも一つの立派な生き方だ。

ただしその道を選んだ場合、典型的な企業組織の中で出世していくことは極めて難しくなる。技術を深く理解し、エンジニアをリスペクトし、経営者自身が卓越した開発者であり、かつ十分な給与を払ってくれる——そんな自分に完璧にフィットする企業を見つけ出すために、人一倍の時間を費やす覚悟が必要になる。

ここで極めて重要な前提がある。「ゲームに参加しない」のは個人の自由な選択だが、「ゲームに参加しないと言いながら、ゲームの結果に不平を漏らす」のは筋違いだということだ。

組織の力学を学ぶことを拒絶しながら、「自分はこれほどの名馬なのに、なぜそれを見出す名伯楽に出会えないのか」と嘆くのはお門違いだ。

それは才能が埋もれているのではなく、見出されるためのコースに立つことを自ら拒否した結果に過ぎない。選択そのものに善悪はないが、あらゆる選択には相応の代償が伴うのだ。

すぐに退職を検討すべき指標

退職の前によく考えることを勧めてはいるが、以下の兆候が見られる場合は、直ちに退職を検討すべきだ：

心身への深刻な悪影響

内分泌系の乱れ、不眠、食欲不振といった身体的症状として現れることがある。精神面では、慢性的な不安や抑うつ、何に対しても意欲が湧かない無気力状態に陥る。

こうしたサインが出たら、絶対に無理をしてはいけない。直ちに退職すべきだ。心身に負った深い傷は、簡単に元通りにはならない。

権限と責任の不均衡

業務を任されているにもかかわらず、上司から指示通りに動くことだけを求められ、裁量が一切与えられない。それにもかかわらず、成果が出なかったり効果が期待外れだったりしたときには、責任を押し付けられ追及されるケースだ。

評価制度の機能不全

会社の評価システムが、自分の価値観と著しく乖離している場合だ。

例えば、親しい人間にばかり仕事と成長機会が与えられ、社内に公正な評価基準が存在しないケース。何をすれば正当に評価されるのかが分からず、会社が自分に何を求めているのかも見えない。上司に相談しても、曖昧な回答しか返ってこないような職場だ。

蔓延する社内政治

特定の人たちが上司と私的に親密であったり、親族・血縁関係にあったりすることで、実力とは無関係に昇進が決まるような職場。あるいは、部門間で露骨な足の引っ張り合いが常態化しているケースだ。

パワハラ・セクハラ

職場内でパワーハラスメントやセクシャルハラスメントが頻発している、あるいは経営層が人材を軽視し、従業員の声に耳を貸さず、問題を報告しても改善の兆しが見られない場合。

環境そのものが破綻している場合、個人の努力で構造的な問題を覆すことは不可能に近い。

まとめ

ここまで色々と語ってきたが、結局のところ別の視点も存在する。「自分が何を求めているのかを正確に理解できているか」という点だ。

人によっては、キャリアとは単なる「生活のための仕事」に過ぎないかもしれない。給与を得ることで生活を安定させ、本当に自分が情熱を注ぎたいことにリソースを割くための手段だ。

キャリアに対する青写真やゴールは人それぞれであり、誰もが昇進や絶え間ない成長を追い求めなければならないわけではない。平穏で安定した生活を望むことも、立派な選択肢の一つだ。

だからこそキャリアを見つめ直す際には、まず自分自身に問いかけてみてほしい。「自分にとって仕事とはどんな意味を持つのか？」「この会社に入って何を成し遂げたいのか？」

雇用関係の本質は、どこまでいっても資本主義のゲームだ。そのゲームの枠組みの中では、個人は常に不利な立場に置かれており、いつでも替えが利く存在でしかない。だが、そこで培ったスキル、経験、人脈、そして判断力という資産だけは、決して誰にも奪うことのできないものだ。

この本質を見極めることは、会社を辞めるか否かを決めることよりもずっと重要だ。

留まるにせよ去るにせよ、最終的に自分にとって最も納得のいく決断を下せることを願っている。そして、この記事がかつての僕のように迷える誰かの役に立てば幸いだ。