こんにちは、ゆずです！
未経験からエンジニア転職して、気づけば三年が経ちました。
憧れだったIT業界に飛び込み、コードを書き、サービスを開発してリリースする。
そのすべてが新鮮で刺激的でしたが、同時に「本当にこの仕事、私に合っているのかな？」と、立ち止まって考える瞬間も数えきれないほどありました。
今日はそんな私が「エンジニアに向いてないかも…」と感じたリアルな瞬間を５つ紹介します。
これは、あくまで私個人の体験に基づくものであり、すべての方に当てはまるものではないと思います。
むしろ、IT業界が求める多様なスキルセットに、自分自身の特性がどれだけ適応できたかを振り返る内容です。
これからエンジニアを目指す人や、同じようにキャリアに悩んでいる人に届けばうれしいです。
数多くのコミュニケーションが必要とされ陰キャの自分にはツライ
エンジニアというと「PCと向き合って黙々と作業する仕事」というイメージを持っていたのですが、実際はコミュニケーション能力が非常に求められる仕事でした。
まず、クライアントとの要件定義ミーティングでは、「こういうものが欲しい」という漠然とした要望を、技術的な視点で整理して具体的な仕様に落とし込む必要があります。
そのためには相手の言葉の裏にある本質的なニーズを見極めなければならず、質問力や傾聴力、提案力が問われます。
また、社内でも営業、企画、デザイナー、QA、インフラエンジニアなど多職種との連携が必要で、認識のズレを防ぐためにも日々のやり取りが欠かせません。
Slackでのテキストベースのやり取りに加えて、週に何度も発生する打ち合わせ。
私はどちらかというと一人で考えごとをする時間に集中力を発揮するタイプで、言葉にすることが苦手です。
自分の考えを即座にまとめて発言する会議では、うまく伝えられず後から「こう言えばよかった」と落ち込むことも。
さらに、複数の立場の人たちの利害が絡む場面では、誰かの意見を尊重しつつも別の案を提案しなければならず、板挟みになって「自分が悪いのではないか」と感じてしまうことも多く、メンタルのコントロールが難しい局面が続きました。
この業界で求められる「円滑なコミュニケーション」というスキルが、私には思っていた以上に高いハードルだったのです。
プログラムを書いている時間よりマネジメントに追われる
エンジニアというと、「1日中コードを書いている仕事」というイメージを持っている人も多いかもしれません。
私もまさにその一人でした。技術を武器に、静かにパソコンに向き合って開発に没頭する──そんな働き方を想像していたのです。
しかし、現実はかなり違っていました。
プロジェクトが動き出すと、エンジニアに求められるのは「作業者」ではなく「設計者」や「調整役」の側面です。
以下のような業務が日常的に発生します。
- タスクやスケジュールの調整
- 工数の見積もりとガントチャートの作成
- UI/UXのレビューと改善提案
- 他部署や外注先との進捗共有・調整
- クライアント向けの報告資料や操作マニュアルの作成
これらはどれも重要な仕事であり、全体最適を目指すうえでは欠かせません。
ですが、正直なところ、「もっとコードを書いて技術を磨きたい」という思いを抱いていた私にとっては、理想と現実のギャップを強く感じる瞬間でもありました。
特に辛かったのは、会議に出ているだけで1日が終わる日が何度もあったこと。
「今日は何も生み出せなかった…」という無力感が積み重なり、自己肯定感が下がっていくのを感じていました。
また、私自身はロジックやコードの設計にじっくり向き合いたいタイプだったので、常に複数タスクを捌きながら調整を続ける業務スタイルにはなかなか適応できず、「自分はエンジニアとして何をしているんだろう？」と、時折アイデンティティを見失いそうになったことも。
もちろん、マネジメントや調整業務が得意な方もいますし、そこにやりがいを見出す人も多くいます。
ただ、私にはその業務割合が想像以上に大きく、「技術者としての成長」に対する焦りが募ってしまいました。
とにかく日々勉強
エンジニアは一生勉強、これは業界に飛び込む前から耳にしていた言葉でした。
でも、実際に仕事を始めてみると、その「勉強量」と「スピード感」は想像を遥かに超えていました。
業務に直結する知識だけでも以下のようなジャンルがあり、
- プログラミング言語の仕様変更（例：JavaScript, Python, TypeScript など）
- クラウドサービス（AWS, GCP, Azure）の新機能・最適化
- セキュリティの最新動向と対応
- 新しいフレームワークやライブラリ（Next.js, React, Vueなど）
- AIやデータサイエンス関連の基礎知識
毎週のように「新しい何か」が登場し、すぐにキャッチアップしないと現場で取り残される──そんなプレッシャーを感じていました。
本や記事を読んだり、UdemyやYouTubeで動画を見たり、技術系のコミュニティに参加したり…。
もちろん学ぶこと自体は嫌いではないけれど、キャッチアップできる余裕はほとんどなく、多くは仕事終わりや週末の時間を使って学習していました。
「仕事が終わってからが本番」のような生活でした。
「学んだことを試せる環境がすぐにあるとは限らない」ため、知識ばかりが頭に溜まり、手を動かして実践できずに焦るというジレンマも。
この業界で長くやっていくには、学び続ける姿勢を保ちつつ、自分にとってのバランスを見つけることが不可欠だと痛感しました。
そして私はそのバランスを取るのに、かなり苦労している自覚があります。
サービスをリリースしたら終わりではない
開発者にとって、サービスのリリースは一つの大きなゴールです。
しかし、実際にエンジニアとして働いてみて分かったのは、「リリースはむしろスタートライン」だったということでした。
リリース後は、以下のような「運用・保守」の業務が待っています
- ユーザーからの問い合わせ対応
- バグの修正や仕様変更の対応
- サーバー監視やログの分析
- パフォーマンス改善やセキュリティ対応
- 人事異動や引継ぎを前提としたドキュメント整備
リリース直後は達成感でいっぱいだったものの、その後も絶え間なく発生するタスクに、いつしか気力を削がれるようになっていきました。
特に印象に残っているのは、休日にサーバー障害の連絡が来た時です。
予定をすべてキャンセルしてPCに向かい、原因を調査し、仮対応をして、関係者に状況を説明して…。
サービスの安定稼働を守る大切さは理解しているのですが、オンとオフの切り替えが難しくなっていくのを感じました。
また、運用フェーズでは「いかに属人性を減らすか」も重要なテーマになります。
ドキュメントやコードに引継ぎやすさを意識するのですが、当初その感覚が掴めず、「作って終わり」ではない責任の重さに戸惑いました。
さらに、サービスが成長するほど、技術的負債やレガシーな設計の見直しといった、難易度の高い課題も出てきます。
こうした保守運用のフェーズは、地味に見えて実は非常に重要で、高度なスキルと根気が必要です。
どんなに良い設計をしても、運用ができなければプロダクトは成り立たない。その現実を痛感したからこそ、自分の適性やモチベーションとのギャップをより明確に感じるようになったのです。
抽象と具体の行き来が多く、言語化がうまくできない
エンジニアとして働く中で、最も苦手意識を感じたのが「要件定義」と「設計」フェーズでのコミュニケーションでした。
仕事ではよく、企画担当やクライアントから「こういうことをしたい」「こんな体験にしたい」といった、非常に抽象的なリクエストが飛んできます。
それを私たちエンジニアは、技術的に実現可能な粒度まで仕様として落とし込む必要があります。
つまり、「抽象」から「具体」へ変換する力が求められます。
さらに、実装が進んでいく中でも、状況に応じて抽象度を上げたり下げたりする場面が多く、常に「抽象」と「具体」の間を行き来する柔軟さが必要とされます。
私の場合、この行き来に非常に頭を使い、時間がかかる傾向がありました。
アイデアはあるのに言葉にできず、「なんとなくこういうイメージで…」という説明しかできないこともしばしば。
「こんなはずじゃなかった」という結果になってしまったことも。
また、要件をドキュメント化する際にも、どこまで細かく書くか、どのような言い回しが誤解されにくいかなど、細部まで神経を使います。
特に私のように感覚的に物事を捉えるタイプにとっては、言語化してロジカルに伝えるスキルはかなり高いハードルでした。
逆に、言語化が得意なエンジニアは、チームの中での調整役やリード的なポジションを任されていて、「こういう人になりたい」と憧れつつも、自分には届かないと感じることが何度もありました。
コードを書く力だけでなく、「言葉で伝える力」もエンジニアの重要なスキルのひとつ。それを痛感する日々でした。
それでも、得られたものは確かにあった
ここまで、「エンジニアに向いてないかも…」と感じた瞬間について正直に書いてきました。
確かに、私にとってこの仕事は決して楽ではなく、心が折れそうになることも多々ありました。
でも、それと同じくらい、得られたものも確かに存在していたのです。
まず何より大きかったのは、「自分の得意・不得意が明確になった」ということ。
コミュニケーションやマネジメントに苦手意識を感じる一方で、コードを書く集中力や、複雑なロジックを組み立てることにはやりがいを見出せました。
この気づきがあったからこそ、今後のキャリアをどう設計するかを真剣に考えるきっかけになりました。
また、日々の業務や壁にぶつかる中で、改善のために小さな努力を積み重ねる力も身につきました。
コミュニケーションが苦手なら、事前に議事録を用意して臨む。伝え方が苦手なら、図解やプロトタイプを活用する。
こうした工夫は、どの仕事においても役立つスキルです。
さらに、常に新しい情報をキャッチアップする文化の中で、「変化に適応する力」も鍛えられました。
今では新しいツールや技術が登場しても、まずは触ってみようという前向きな姿勢を持てるようになっています。
たとえ「自分には向いてないかも」と思っても、全く無駄だった経験なんて一つもない。
むしろ、その違和感や苦手意識を認識できたことこそが、次のステップに進むための貴重な財産だと感じています。
最後に：これからの自分に向けて
「エンジニアに向いてないかもしれない」。
そう感じることは決して恥ずかしいことではない、と今では思います。
むしろ、「思っていたのと違った」「自分には合わないかも」と気づくことができたのは、実際に行動を起こしたからこそ得られた気づきです。
未経験からエンジニアとして転職し、3年間働いてきた中で、私はたくさんのことを学びました。
そして、その過程で自分の価値観、働き方、強みと弱みについて深く見つめ直すことができました。
求められているスキルや働き方が、自分の性格やペースと合わなかったのかもしれません。
これからは、自分に合った働き方、自分が力を発揮しやすい環境を模索しながら、キャリアを築いていきたいと思っています。
たとえば、もっと静かな環境で技術に集中できる職場や、特定の分野に特化したエンジニア職。
あるいは、ライティングや教育、技術支援といった、技術を別の形で生かす道もあるかもしれません。
この記事をここまで読んでくださった方の中にも、今まさに「自分は向いてないかも」と悩んでいる方がいるかもしれません。
そんなときは、向き・不向きではなく、“どう在りたいか”に目を向けてみてほしい。
私もまだ模索の途中です。
でも、どんな形であれ、自分が納得できる働き方を見つけたいという気持ちは、これからも変わらず持ち続けていくつもりです。
ここまで読んでくださり、本当にありがとうございました。
