退職が教えてくれたこと
# 雑談ソフトウェア開発に踏み込んで、気づけば10年目にもなる。これまでに5〜6社ほど渡り歩いてきた。退職を決めたその時点で、後悔したことは一度もない。
僕は、自分の想像どおりの理想的な職場環境に出会ったことがない。
むしろよくあったのは、「この会社に居続けても意味がないのでは」「他の会社のほうがいいのでは」という感覚だし、退職後に転職活動を始めてから「あのときこうしていれば、違ったのでは」と振り返ることも多かった。
人生に後悔薬はない。退職のたびに学べることは多く、自分が発揮できる強みも少しずつ見えてくる。ただ、その前に本当に考え抜いたのか。僕は現場の開発者として、いくつかの生々しい事例を共有し、未来の自分への指針にしたいし、退職するか迷ったことのある人の助けにもなればと思う。
人それぞれ、キャリアに求めるものは違う。会社の中で職場ゲームを楽しみ、社内で働くことでより大きな達成感を得る人もいれば、受託や案件で働いて生活の柔軟さを保ちたい人もいる。あるいは、起業のようにまったく別の道を選ぶ人もいる。
どの道も、完全に間違っているわけではない。
僕がある会社を退職したとき、若かった僕は1万字を超える記事を書いた。そこで、会社での経験、同僚への感謝、会社の制度への不満、そしてその後に見えてきたことについて語った。
その記事は何度も転載され、会社の法務担当にも見られた。彼はさらに記事のコメント欄にまで来て、「会社が最も得意なのは、もともと会社に失望していた人を、退職後にさらに失望させることだ」と書き込んだ。
若者特有の衝動は貴重だが、今から振り返ると、あの頃の僕は少し未熟だったように思う。
若い頃の僕は、技術こそがすべてだとよく考えていた。
でも今感じているのは、安心して開発に集中できるのは、自分がより優秀になったからでも、何かが良くなったからでもなく、先人たちの犠牲があったからだということだ。
彼らが必死に環境を整え、基盤を作ってきた。上司が意味不明な要求を遮ってくれたかもしれないし、深夜に社長から怒鳴られたこともあったかもしれない。そういうことは、僕らには見えない。見えるのはただ、「うわ、僕ってめちゃくちゃすごいじゃん」という感覚だけだ。
そして、自分が深夜に社長から怒鳴られる側になるまで、それは続く。
退職は解毒剤ではない
後半では、優先的に退職を考えるべき状況について触れるが、退職する前に、まず自分がどちらのタイプなのか考えてみてほしい。
- 職場に嫌いなもの（感情、ストレス）があり、それから逃げたい
- 自分が本当に欲しいものがはっきりしていて、ここに居続けてもそれは得られないと分かっている
退職が単に環境の不完全さから逃げるためなら、次の職場でも同じ循環に陥りやすい。どんな組織にも、資源配分の偏り、コミュニケーション効率の悪さ、摩擦は必ずある。むしろそれらの制約こそ、成長の好機だ。
退職理由が「環境が悪い」（たとえば上司が強圧的、プロセスが混乱している）だとしても、今の環境でプロセス改善を試していなければ、新しい会社で似たような性格の人や似たような混乱に遭遇したとき、やはり対処の仕組みがないままだ。
僕はある案件で Tech Lead に昇進したが、当時は案件をどう前に進めるかに不慣れだった。
チームの中では技術を比較的多く理解していて、アイデアも多かった。でも、当時の僕は伝え方が下手で、同僚の提案にあれこれケチをつけ、かなり強圧的で協力しづらい人間に見えていたと思う。
後になって同僚からかなり重いネガティブ評価を受けた。僕の強圧的な態度はチームの士気に深刻な影響を与えるとされ、彼は僕の行動について pissed off だとまで書いた。
その後、僕は上司と 1 on 1 を行い、上司からも職場では影響力を発揮することのほうが重要だと、真剣に注意された。正直、最初はその意見にあまり納得できず、なぜ皆はコード品質をそれほど重視しないのか、なぜネガティブ評価を受けるのか、とよく思っていた。でも、不満をただ上司に報告するだけでは、何も変わらないし成長もしない。
あの経験は僕にとってかなり大きな学びと成長だった。周囲の人たちに配慮するようになり、どうすればチーム全体の成果をもっと大きくできるかを考えるようになった。管理や人間関係に関する本にも手を伸ばすようになった。
上司からの注意と、同僚からの重いネガティブ評価がなければ、僕は自分のやり方を変えなかったかもしれない。
価値観は諸刃の剣
価値観が完全に一致する職場で働くのは難しい。職場には、どうしても気が滅入るものがいくつかある。
- 上司がただ人に仕事を振るだけ
- 社内政治
以前、ある要件があった。ユーザーがページを離れたあと、自動で API を呼んで画像を削除したいというものだ。自然に考えれば sendBeacon を使いたくなる。だが、いくつかの理由で sendBeacon はその場面には適用できなかった。そこで別の同僚が ajax をそのまま使い、sync パラメータで HTTP リクエストを強制的に同期化した。
僕はその解法を見て、かなり腹が立った。なぜなら、そんなものは専門の開発者が出すべき案ではないと、反射的に思ってしまったからだ。
数年後に振り返ると、あのときの僕の態度も心の持ち方も良くなかった。なぜ Ajax で sync を使うのかを、素早くきちんと聞かなかったし、その開発者が出した解法は、確かにその時点の問題を解決できていた。
この事例から僕は、時には価値観が合わないのではなく、最初から相手の考えを理解する気がなかっただけなのだと気づいた。これはまったく別の話だ。
当たり前を言語化する
開発者として長くやっていると、たとえばこのコードの書き方にはどんな潜在的な問題があるか、ある関数の実装を見ればどこに Bug があるか、要件を聞いただけでだいたいアーキテクチャがどうなるか、分かるようになってくる。
環境変数は Git の履歴に残すべきではない、Secrets Manager で管理する、データベースを外部公開しない、パスワードは hash する、SSR（Server-Side Rendering）で SEO を強化する、データベースは正規化する。
こうした開発者にとって手癖のような「常識」を、僕は背後にある理由まで説明できるだろうか。
『超速！刻意練習』では、チェスの達人が盤面を5秒見せられただけで、20個以上の駒の位置や手順を記憶できるといった話が出てくる。
しかし、駒が完全にランダムに置かれている場合、達人と初心者の成績に有意差はない。これは、上級者が大量の経験を積み重ねており、直感だけで局面を推し量って記憶を助けられるからだ。
残念ながら、開発はチェスではない。職位がある程度高くなると、技術に詳しくない人、まったく技術を知らない人に、なぜそうするのかを説明しなければならない。そうなると、自分にとっては当たり前の常識を、他人が理解できるものへ変換する必要がある。
当たり前だと思っていることや気持ちの一部は、言葉にできないことがある。あるいは、言語化を避けているのかもしれない。考えや経験や常識を文字にすると、自分の論理の穴と向き合わざるを得なくなるからだ。
なぜ退職したいのか？
少し練習してみよう。なぜ僕は退職したいのか。
まずはいくつか理由を挙げてみる。
- 上司がうるさい
- 給料が低い
- 価値観が合わない
さらに具体化するとこうなる。
- 上司がうるさい → どういう意味でうるさいのか？
- 前回の案件で、僕は上司にリスクの可能性を報告したが、上司は真剣に受け止めなかった。ところがそのリスクが現実になった途端、責任を僕に押しつけた
- この1か月で、上司は僕に本来の職務範囲外の仕事、たとえばコーヒーを買うことやトイレ掃除を、10回も押しつけた
- 給料が低い → 理想の給与はいくらか
- 理想の給与は、現在の給与より20%高いこと
- 価値観が合わない → 自分の価値観と、観察した会社の価値観の差は何か
- 僕の観察では、会社は個人英雄主義をやや奨励している。誰かが素早く機能を完成させると上司は強く褒めるが、誰かがドキュメントを書いて知識を共有したり、デプロイ速度を改善したりしても、上司は何の反応も示さない。僕は、凝集力のあるチーム分業を重視する
- 会社には、社員の成長や評価の計画がない。オンボーディングの提案も却下された。だから僕は、この会社は長期的に一緒に戦うチームより、即戦力を重視する傾向があると考えている
このように実際の事例として整理すると、考える余地はもっと増える。
変えようとしたか
退職したい気持ちはあるし、原因も分析できた。
その原因を一つずつ取り除けたとして、それでもここに居続けたいか。もし答えが「はい」なら、変えようとしたのか。
まず自分に問いかけられることがいくつかある。
- 自分が直面している困難や課題が解決したら、僕はここに居続けたいか？
- これらの問題を解決しようと試みたか？それは僕にできる範囲での最善だったか？
- 3年後、5年後の目標を考えたとき、ここはそれに役立つか？
問題に直面すると、僕らは環境のせいにしやすい。これはごく自然なことだ。
『7つの習慣』には、2つの円についての話が出てくる。一つは影響の輪、もう一つは関心の輪だ。
関心の輪とは、僕が関心を持っている、あるいは不安に思っているすべての事柄を指す。影響の輪とは、その関心の輪の中で、行動によって直接変えられる事柄を指す。
自分の人生を主体的にしたいなら、関心の輪ではなく、影響の輪、つまり行動によって直接変えられることにもっと目を向けるべきだ。
たとえば給料が低いと感じるなら、拒絶されるかもしれないし不快かもしれないが、それでも上司に交渉しようとしたか。会社が自分に昇給を与えるべき根拠を提示しようとしたか。自分は何をして、どんな成果を出したのか。
「こういう雑務はやりたくない。僕は自分のアウトプットにもっと集中したい」と上司に言ったか。
価値観が合わないなら、上司に伝えたか。
コードが保守しづらいと感じるなら、改善案を出してリファクタリングや改善を進め、なぜそれが重要なのかを上司に説得しようとしたか。
それらをすべてやって、それでも変えられないと分かったなら、もう一度試して、それでも変わらないなら退職を考えていい。
自分が変えられることに集中するのだ。
大企業という保護傘
多くの人は、今の職場で多くのスキルを積み、多くの案件をこなしたと思っている。だが、突き詰めれば、それは先輩やテックリードが環境を整えてくれただけで、僕はその上に敷かれた道をなぞってタスクをこなしていただけかもしれない。
ある程度の規模がある会社、あるいは上場企業では、通常は職務範囲がはっきり分かれている。
案件にサーバー構築が必要なら、SRE チームに頼めばいい。彼らがネットワーク、権限、環境をすべて整え、自動デプロイ用のスクリプトも書いてくれる。Ansible や Terraform を使ってデプロイしてくれるのだ。
機能開発が終われば、専門の QA チームがテスト計画を作り、実行して、チケットまで起票してくれる。
すべて理想的に聞こえるだろう。
だが悪い点は、自分の責任範囲の中だけに集中するようになることだ。資源が限られ、環境を一から自分で構築しなければならない場面に来ると、そこで詰まるかもしれない。
そのときになって「雑務が多すぎる」と感じるわけだが、実際には雑務が多いのではない。これまでの職場が保護傘の中にあり、僕がそこから抜け出そうとしてこなかっただけだ。
「この出来事は『僕』が自ら推進したからこそ、何がどう変わった」と具体的に言えないなら、僕は実質的にサービスを受ける客にすぎない。そんな傍観者の感覚のまま転職し、いざ自分で切り開かなければならない環境に入ったら、絶対に大きな痛手を負う。
上を目指すなら、人と組織の難題から逃げられない
多くの開発者は、技術こそがすべてだと思っている。政治的なことは汚いし、不道徳だ、と。しかし、影響力の要求が個人の生産上限を超えたとき、目標を達成するには協力せざるを得ない。
素晴らしいコードや素晴らしいアーキテクチャを書くだけでは人を動かせない。論理的に正しいからといって相手に全面受諾を求めるのは、かなり傲慢な行為だ。
人間関係や組織構造は仕事を妨げるノイズではなく、仕事そのものの中核パラメータだ。これらの難題を避けることは、自分をスケールさせる機会を拒むことに等しい。
僕も開発者として、好みやこだわり、死守したい価値観は当然ある。完全にどちらかに寄るのは難しいが、できるのは自分が受け入れられる動的な均衡点を見つけることだ。
日本には「根回し」という言葉がある。会議の前、あるいは正式な意思決定会議の前に、影響力のある人たちに個別に会って意見を聞き、調整しておくという意味だ。
正式な会議で出したときに、受け入れられやすくなる。向き合う案件の範囲が大きくなるほど、こうした技術以外のことも観察する必要が出てくる。
以前、会社である案件があった。サーバーサイドレンダリング用のサーバーを一から立ち上げる必要があったのだ。
当時使っていた社内ツールのサポートが限られていたうえ、データを動的に取得する要件もあったため、僕は新しいアーキテクチャを提案して実装することにした。
このアーキテクチャには、複数部門の協力が必要だった。SRE はサーバーの準備と構築を行う必要があり、企画側はその機能が後にどんな利益をもたらすのか知りたがるだろうし、開発側は設計の概要を知りたがる。コード自体の実装は実は難しくない。Next.js のサーバーをデプロイするだけだ。
だが、こうした部門横断の人たちを説得するために、僕は大量のドキュメントを用意し、部門ごとに書き方も変えた。ちょうど人手も足りず、僕は部門間の調整を進めながら、自分でこのアーキテクチャも実装しなければならなかった。
幸い、上司の支援があり、この案件を終えたあと、かなり高額な昇給を得ることができた。
雇用関係 = 資本ゲーム
「この会社は僕がいないと回らない」などという考えで退職してはいけない。そんな心構えは非常に不健全だ。
資本主義の下では、会社にとって誰一人として代替不可能ではない。資本市場では、代わりになる人材は必ず見つかる。
雇用関係の本質は、労働力と資本の等価交換であって、感情を託すことではない。組織構造の中では、誰の機能もモジュール的に置き換え可能だ。これは資本主義が安定性を追求した結果として必然だ。
ただ、自分にとって会社に入るというのは価値観の選択でもある。会社で得たスキル、信頼、人脈は、代替のきかない資産だ。
僕はかつて創業者に、社員を仲間だと思っているかと聞いたことがある。後から振り返ると、少し幼い質問だった。たとえ本当に仲間だと思っていても、雇用関係そのものは残るからだ。
雇用関係である以上、会社が存続するための核心は二つしかない。会社が儲かっているか、そして運営が円滑かどうかだ。チームの存在目的は、お互いの仲間になることではなく、それぞれの目標を達成することにある。
当時、僕はさらに別の質問もした。もし社員が病気になったり、何か悩みを抱えたりしたとき、経営者として話術でやり過ごすのか、それとも本当に気にかけるのか。どちらのやり方でも結果が同じになることは分かっていたが、それでも僕の中では、上司には本心から社員を気にかけてほしいと思っていた。この考えは大きな間違いだった。
職場は、もともと本心を交換する場所ではない。上司の責務は会社を存続させ、チームに成果を出させることであって、社員の心の導師や親友になることではない。上司が適切な言葉で社員に尊重されていると感じさせ、士気を保ちつつ、私情を決定に持ち込まないようにすること。これこそがプロだ。
本心から気にかけるのは美しく聞こえるが、代償もある。上司がある社員に感情を注ぎすぎると、解雇のときにためらい、評価のときに甘くなり、資源配分でえこひいきが出る。そのためらいと偏りが、最終的にはチーム全体、ひいては会社全体を傷つける。
僕は自分の憧れを無理に当てはめて、雇用関係の本質を見落とすべきではなかった。社員は時間と能力を提供し、会社は報酬と舞台を与える。その双方がやるべきことをやり切ることこそ、最大の敬意だ。職場に必要なのは本心ではなく、物事を成し遂げる力だ。
成長は痛みから生まれる
I wish upon you ample doses of pain and suffering. — Jensen Huang
もちろん、職場に入る動機やキャリア目標は人それぞれだ。働いて自分を養う手段を確保しながら、本当に進みたい道を探すため、という人もいるだろう。
NVIDIA のCEOである黄仁勲は以前、できるだけ多くの苦難を経験してほしいと語っていた。特に、幼い頃から十分な資源に恵まれ、教育環境も家庭環境も良い中で育ち、高い期待を背負いながら高額な学費を払ってより良い教育体系に入れる人たちは、たいていしなやかさが足りないのだという。
彼は、本当に偉大なものは、必ずしも頭のいい人が作るわけではなく、苦しんだ人たちが作るのだと考えている。最初はその言葉があまり理解できなかったが、今は少しずつ分かる気がする。
僕は大学時代、そこまで多くの資源を持っていなかった。服やズボンのような身なりにかけるお金もなく、より良い機材を買う余裕もなかったし、電話代すら払えなかった。
だが、経済状況が良くなかったからこそ、僕には強い動機があった。何か一つの技術を早く身につけたい、うまく学びたい、そしてすぐにインターンへ行きたいと思っていた。
そのおかげで、大学在学中からソフトウェア開発の経験を積むことができたし、その後のキャリアでも、より高い技術力が求められ、待遇も良い会社を目指しやすくなった。
その後、職場では Tech Lead を任され、チームを率いて意思決定をしたり、他部門と調整したりする機会を得た。こうしたことは、最初にやるときは勘所が分からない。何も分からないうえに不確実性の高い環境で進めることになる。
管理職に上がれば、人であれ他のメンバーであれ、以前のように「とにかく僕のコードが十分に良くて、成果を出せば、良い結果が得られる」という思考ではやっていけない。チーム全体をもっと良くする方法を考えなければならない。
どの段階も、その場では必ずしも楽しいわけではない。むしろ苦しいことが多い。なぜなら、それはたいてい、今のやり方を変える必要があること、場合によっては自分の価値観を作り直すことを意味するからだ。
だが、下す決定が増え、解決する問題が増え、関わる人が増え、上司とのコミュニケーションが増え、見てきた案件が増えるほど、そうした比較的不慣れな環境で解法を見つけ、試行錯誤しながら案件を前に進めることで、苦しさはあるが、成長も非常に大きい。
今の案件は以前にも経験したことがある、と気づくようになる。アーキテクチャや技術の流れも、だいたい分かるようになる。案件を円滑に進めるためには、技術が最重要ではなくなることもある。
関係者とどうコミュニケーションするのか。どうやって自分の案の実現可能性を納得してもらうのか。相手の立場に立ってどう考えるのか。以前は気にしなかった細部こそが、実は案件を前に進める最重要要素なのだと、少しずつ分かってくる。
だから僕は、成長には必ず痛みが伴うと思っている。
職場で痛みを感じたとき、その痛みは自分を成長させるものかを考えてみてほしい。もしそうなら、逃げるべきではないかもしれない。
痛みには2種類ある。自分を成長させる痛みと、ただ内耗するだけの痛みだ。
最近、僕は走り始めた。別に走るのがすごく好きなわけではない。早起きしなければならないし、外は寒いのに走らなきゃいけないし、心臓が爆発しそうでも走らなきゃいけないし、脚に力が入らなくても走らなきゃいけない。
どれも痛い。でも、走行距離を積み重ねればもっと健康になり、心肺機能も上がると分かっている。
走っている最中は毎回つらい。それでも、後悔したことは一度もない。むしろ、家でだらだらして後悔することのほうが多い。
成長につながらない痛みは、あまり良くない。
排球をやりたいのに、ルールが野球だと気づいたようなものだ。排球のルールで野球をやっても、どうやっても勝てない。
厄介なのは、その場ではこの二つを見分けられないことだ。今のゲームのルールが野球なのか排球なのか、僕らには分からない。
以前、案件開発の途中で突然サービス終了が発表され、僕の評価も完全に消えたことがある。半年間の努力が一瞬で水泡に帰したのだ。
とはいえ、成長したいなら、走るのと同じで、痛みを積み重ね続けるしかない。最初は 9 分ペースで死ぬほど苦しかったのに、今では 8 分ペースでも息が切れない。乗り越えて初めて、痛みが成長をもたらしたと分かる。
FDE から職場を考える
最近、Forward Deployed Engineer という職種をよく目にする。たとえば OpenAI などだ。これは典型的な Software Engineer やコンサルタントではなく、十分に深い技術力を持ち、Prototype を本番環境にデプロイして、解決策へと仕上げられる人材だ。
これが 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.
一般的な Software Engineer がチームの中で担う役割は、要件を受け取り、PM や企画側がすでに精錬したものを、開発チームが実装することだ。
Forward Deployed Engineer は、客先の目の前で現場の動きを見て解決策を提示し、自ら解決方案を作り、案件をリリースまで進める。
そのためには、曖昧な要件を実行可能な形に変える力と、顧客と信頼関係を築く力が必要だ。
こうした仕事の内容を考えると、コミュニケーションが必要な場面はとても多い。関係者と話し、相手を説得し、限られた資源と期限の中で最適な案を出す必要がある。
それは必ずしも、自分の快適圏や慣れたことではない。
職場ゲームをやらなくてもいい
ここまで読んでも、きっと納得しない人はいるだろう。
なぜ僕は、自分と価値観が大きく異なる部門や上司、あるいは社長まで説得するために、こんなに大きな労力を割かなければならないのか。こんなの、あまりにも疲れる。
認知のずれを埋めるのは、疲れるし、苦しいし、無力感もある。職場の中で前に進みたいのに相手を説得できないのは、単にコミュニケーションが足りない、影響力が足りないというだけだ。認知のずれは免罪符ではないし、言い訳にもならない。ただ、職場ゲームのルールから離れたあとなら、自分が心底納得できないことを口にしても構わない。
このゲームに参加しないという選択も、もちろん可能だ。見下してもいいし、認めなくてもいい。こう言ってもいいだろう。「こんなに疲れるのは嫌だ。僕は僕らしくいたい。技術と開発に集中したい。technology will always win を証明したい」と。
それは完全に自由だ。
だが、その道を選んだあと、典型的な職場で上に上がるのはかなり難しくなるかもしれない。自分に本当に合う会社——上司が技術を理解し、エンジニアを尊重し、自身も優れた開発者で、なおかつ高い給与を払える会社——を見つけるために、他の人より多くの時間をかける必要があるかもしれない。
ただ、ここで非常に重要な前提がある。ゲームをしないのは一つの選択だが、ゲームをしないのに結果だけを不満として語るのは別問題だ。
職場の仕組みを学ぶことを拒みながら、「僕は本当に才能があるのに、なぜ理解者に出会えないんだ」と嘆くことはできない。
それは埋もれた才能ではない。自分で見られるレーンに入るのを選ばなかっただけだ。選択に正解も不正解もないが、どの選択にも代償はある。
今すぐ退職を考えるべき指標
退職前にはまず考え抜くべきだと勧めてきたが、ここでは今すぐ退職を考えるべき指標をいくつか挙げる。
心身が深刻な影響を受けている
内分泌の乱れとして現れるかもしれないし、夜よく眠れない、食欲がなくて食事が喉を通らない、といった形かもしれない。精神面では、頻繁に不安や抑うつが出たり、何をしてもやる気が出なくなったりする。
こうしたサインが出たら、無理に耐えないほうがいい。そのまま退職すべきだ。心身への傷は、取り返しがつかない。
権限と責任が釣り合っていない
任されたタスクについて、上司が自分の指示どおりにやれと言うだけで、自由に発揮する余地がない。にもかかわらず、成果や結果が期待以下だと、責任を問われ、疑われる。
評価システムの不調
会社の評価システムが自分の価値観と合わない。
たとえば、会社が親しい人に仕事を回すばかりで成長機会を与えない、あるいは社内に評価制度がまったくなく、何をしたら正当に評価されるのか分からない。会社が自分に何を期待しているのかも分からない。上司と話しても、返ってくるのは曖昧な答えばかりだ。
社内政治
特定の人間関係が近い、上司と親しい、あるいは親族や家族関係があるせいで、ある役職が成果ではなく関係で決まることがある。部門間の対立が露骨なこともある。
パワハラ、セクハラ
職場でパワハラやセクハラが頻発していたり、上司が人材を軽視していたり、社員の話を真に受けなかったり、反応はあっても改善しない場合だ。
そういうこともある。環境そのものが合っていないのだ。構造上の問題は、個人の力でどうにかできるものではない。
まとめ
ここまでいろいろ話してきたが、実はもう一つの考え方もある。それは、自分が何を欲しいのかをはっきり知っていることだ。
キャリアは人によっては、あくまで一つの仕事にすぎない。給料を得て、本当にやりたいことにもっと集中するための余裕を作る手段だ。
キャリアへのイメージも目標も、人それぞれ違う。上を目指すことや、成長し続けることだけが正解ではない。安定した生活を求める人もいる。それも一つの選択だ。
だからキャリアを考えるときは、まず自分に問いかけてみてほしい。仕事は自分にとって何を意味するのか。自分はこの会社に入って、何を達成したいのか。
雇用関係の本質はいまも資本ゲームだ。資本ゲームでは、個人は不利だ。いつでも代替されうるからだ。だが、積み上げたスキル、経験、人脈、判断力といった資産は、代替できない。
このことを考え抜くことは、退職するかどうかを決めることよりずっと重要だ。
最後に残るのが留まるか離れるかのどちらであっても、自分にとって最も有利な決断をしてほしい。そして、この文章が少しでも役に立てばうれしい。