こんにちは。 2025年11月1日にラクスル株式会社へ入社し、開発エンジニアをしています。

前職では外資系企業にてテクニカルサポートエンジニアとして1年7ヶ月勤務し、お客様の技術的な問題の解決をお手伝いしておりました。その中で「自分で価値を創る開発職へ」と決意し、現在に至ります。

学生時代、開発インターンに参加経験はあるものの、正社員としては初めての開発職です。この20日間は、毎日新しい壁にぶつかり、戸惑いながらも、エンジニアとしての「あたりまえ」がガラリと変わるのを感じています。

今回は、その20日間で特に「意識が変わった」「重要性を改めて認識した」5つのポイントに絞って、その学びを共有させていただきます。

1 見ている時間軸が「過去・現在」から「未来の運用」へとシフトした

テクニカルサポートエンジニア時代では すでに起きている問題(過去の事象) を扱っていました。ユーザーが困っている技術的な問題を分析し、原因の特定や、何かしらの解決策を提示しておりました。そのため焦点は過去にありました。

一方で現在は、問題が起こる前に、未来を想像すること が多いと感じました。

一例ですがコードレビュー時にいただいたコメントが未来視点の内容が多かったです。

そのため何かしら仕様を決める際やコードを書く際も、「この設計が将来的に拡張しにくくないか？等の未来」を意識的に考えるようになりました。

開発職の方からすれば当たり前かもしれません。

ただ他業種から転職してきた私にとって、この視点の変化は、非常に大きな違いとして感じています。

2 正解を判断する軸が多すぎるから、仮説を立ててすぐ相談

テクニカルサポートエンジニアでは、技術的な課題を解決するための提案を探す際、仮説を立て、検証環境で検証することで、その正しさを確認することができました。

しかし開発の世界では、どちらが明確な正解かを決めるのが難しいと感じました。

例えば、実現したいことに対する実装方針をAとBで迷ったとします。どちらも作りたいものは作れます。しかし「ビジネス価値」「保守性」「開発速度」といった複数の判断軸が存在するため、現時点の私では判断に迷う場面がありました。

そのため、現時点では「xxの理由でAだと思っているのですが、xxという観点で判断しかねています。アドバイスいただけないでしょうか？」と言ったように、可能な限り判断軸を明記して相談することを意識するようになりました。

テクニカルサポートエンジニア時代、技術的な課題の解消が主なゴールでした。

しかし現在は、「技術」を求めるだけでなく、「その技術がもたらすビジネスへの貢献度」 がゴールの基準になっていると感じます。

具体的には現在のゴールは、「ビジネス価値、保守コスト、開発速度」 といった複数の軸で評価し、何かしらのビジネス課題の解決に貢献するコードを書くことだと感じました。

実際に実装方針に関して相談をした際「その選択がビジネスにどんな影響を与えるか」が議論されていることを見かけました。

そのため技術的なことを考えるだけではなく、その先にある「ビジネス課題の解決への貢献」を意識的に考えるようになりました。

テクニカルサポートエンジニア時代、既存のコードや設定を読む際、その目的は「技術的な構造（なぜこう動いているか）」を理解することでした。

しかし、開発職として機能のコードを読んでいると、現状の仕様を理解しても「なぜその選択がとられたのか」「なぜ他の選択がとられなかったのか」はコードだけでは読み取るのが難しいと感じることがありました。

そのためコードを正しく理解し、変更するためには、技術的観点だけではなく、その機能が生まれた背景にあるビジネスの文脈（なぜその仕様になったか） を把握することも必要だと感じました。

テクニカルサポートエンジニア時代も情報発信は意識していましたが、現在はさらに情報発信の重要度が大きくなったと感じております。

現在の仕事は一人で完結することはなく、必ずどこかで他の方の協力を得ます（コードレビュー等）。

このとき、「何を考えて、なぜその設計に至ったか」という思考の過程が共有されていないと、チームメンバーの時間を奪ってしまい、無駄なコミュニケーションが発生すると感じました。

そのため連携やコミュニケーションがしやすいように、以下2点を意識するようになりました。 - 口頭で話してた際には、その内容をどこかしらに文章を残す - 誰でも状況を追いやすいように、自分の思考の過程をSlackに記録(Working Out Loud)

どの粒度で報告し、どの粒度で情報を残した方が良いかはっきりはわからないです。ただ情報は残されれば残されているほど良い、困ることにはつながらないと思うため、可能な限り情報を残すために、上記2点を意識しました。

特に私は入社したてなので、「今、何を、どう考えているか」を伝えるため、意識的に情報を発信するSlackでのWoking Out Loudを心がけています。

実際にWoking Out Loudを行なっていたおかげで、早期に困り事を助けていただいたり、情報を共有いただけることがありました。

たった20日ですが、テクニカルサポートエンジニアと開発職では、

見ている時間軸、気にするポイントが違うことを肌で感じました。

テクニカルサポートエンジニアでの考え方がまったく役に立たないというよりは、違いを感じやすいからこそ、開発職として重要なことを気づきやすい ように思いました。

この記事が同じようにキャリアチェンジを考えている人や新しい環境で頑張る誰かの参考になれば嬉しいです。

これからもっとプロダクトに貢献できるよう、日々精進してまいります。