はじめに

この記事はRaiseTech Advent Calendar 2025 第12日目の記事です。

4月にエンジニアへ未経験転職し、約8ヶ月が経過しました。今回は振り返りも兼ねて、入社してからこれまでの自身の動き方を整理しようと思います。

ただ漫然と振り返るのではなく、「未経験1年目でもできる、利益貢献につながる具体的なアクション」という視点でまとめます。少しでも自身に近い境遇の方のお役に立てると嬉しいです。

自身の状況

34歳で異業種からエンジニアへ転職
受託開発会社にて、顧客対応から実装まで広く担当（チャンスをくれる環境に感謝！）

なぜ「利益貢献」という視点で振り返るのか

理由は2つです。

1つはこの視点で思考を整理することで、自身の動き方をよりブラッシュアップして、もっと会社に貢献したい！という理由です。

詳細は本文に譲りますが、ものすごくたくさんチャンスをくださる会社なので、なんとかして報いていきたい。

もう1つは、異業種からの未経験転職者にとって「ビジネス視点」が技術不足を補う比較優位（武器）になると感じているからです。

技術力の差は一朝一夕では埋まりませんが、前職で培ったビジネス視点・利益意識・マネジメント経験などは、今すぐ発揮できる強みになりえます。

エンジニアは「工数＝原価」をコントロールすることで利益に直結する動きができる職種です。
コスト意識を持つことは、未経験転職者にとって大きな武器になると感じているので、具体的な実践例をお伝えできればと考えています。

Ⅰ. リーダーの負担を減らす

あらためて開発において、利益（ = 売上 - 原価）を最大化するには、エンジニアの立場からは原価=人件費を最小化する必要があります。チームの中で最も原価が高いのは、一般的にリーダーになると思います。

なので、とくに入社直後はなるべくリーダーの手を煩わせないことを念頭に動きました。具体的に、たとえば自身は以下のようなことを意識的に行っていました。

質問・相談で時間を奪わない

開発を進めるうえで、質問や相談は必須です。一方で、質問・相談がリーダーの時間を奪うことも事実。
そこで、とくに以下の2点について意識しました。

1. なるべくYes/No、あるいは複数選択肢から選べるように整理する

例えばDB設計や実装方針で悩んだ際、以下のように整理して相談しました。

DB設計：正規化してテーブルを分けるか、パフォーマンス優先であえて非正規化するか
関連付け：ポリモーフィック関連付けを使うか、中間テーブルを明示的に増やすか
共通処理（Ruby）：親クラスを作って継承させるか、Module化してMixinするか

それぞれのメリット・デメリットや、今回の文脈における論点を整理したうえで相談するようにしていました。
とくに「なぜそれで悩んでいるか」「最終的に何を実現したいのか」という文脈の情報は厚めに伝えるようにしています。文脈が正しく伝わらないと、正しい判断が難しいと考えているためです。

2. 自身の理解度をなるべく具体的に伝える

技術的なエラーやバグにハマった際の質問では、リーダーのコミュニケーションコストを下げることを意識しています。
具体的には以下を具体的に伝えるようなイメージです。

どこまでは理解できていて、どこからが分からないのか
仮説として何を考えたか
参照した記事
実際に試したコード

これらをセットで共有することで、リーダーから「あ、そこまで分かってるなら、次はここを見てみて」とピンポイントで回答いただける上に、こちらも気づけていなかった視点や知らなかった技術的背景を得ることができて、とても勉強になります。

レビューコストを下げるようPR作成する

コードレビューはどうしたってリーダーの時間を奪います。とくに今のチームは常時最低でも3件以上のプロジェクトを進めており、リーダーがご自身で設計もコーディングもほとんどされていないプロジェクトもあります。

なので、できるだけリーダー含む、レビュワーの認知負荷を下げる工夫をしました。

具体的には以下のような取り組みをしています。

1. Descriptionだけで「全体像」が分かるようにする

PRを開いた瞬間に脳内モデルが構築できるよう、以下の項目をテンプレート化して記載しました。

概要：　なにをやったのかを3行程度にまとめる
背景：　どういう文脈でこのタスクを実施したのか
挙動：　1動画30秒以内で動作を録画、シンプルなUI変更ならbefore/afterを画像で
仕様：　何がどうなるべきなのか、を比較的詳細に記載
相談：　悩んでいる点やここが微妙…という点があれば記載
備考：　マージ後やデプロイ後に対応が必要であればメモ程度に記載

なお、この観点については以下の記事に大変助けられました。
おそらく10回以上は開いていると思います笑

とくに、UIの変化をbefore/afterで横並びにするのは視認性が格段に上がるのでおすすめ。
チームの評判も良かったです。

2. 「なぜ？」をコードに残す

以下のような場合にはコードにコメントを残すことで、質問ラリーが発生することを防ぎました。

複雑になってしまったロジック
抽象化して使い回せるようにしたメソッドの使い方
現状は時間的都合で未実装だが、今後行おうと思っているTODO

マネジメントの心理的コストを減らす

自身も過去に別職種でチームマネジメントをしていた経験から、リーダーはリーダーであるだけでそれなりの心理的負担感があるものだと感じています。

少しでも負担を下げられるように以下のようなことを行っていました。
※これはリーダーに対してというかチームに対して行っていたことです

修正レビューをいただいた際には必ず感謝を伝える
リーダー・先輩のすごいと思ったことは率直に伝える
進捗の共有をマメにする（共有のみの形で日に数回）
30分悩んだら素直に頼ったうえで感謝を伝える
mtgの場では必ず意見を言う
チームの飲み会のセッティングなどを積極的にする

一つ一つは地味ですが、やるとやらないではチームの雰囲気が変わってくるのと、ひいてはチーム全体の生産性に関わってくるところかと考えているので、割とマメに行っていました。

Ⅱ. リーダーのタスクを「巻き取る」

業務と会社に慣れてきてからは、リーダーのタスクを巻き取りにいくことに注力しました。

とくに「顧客対応」や「プロジェクト管理」といった調整業務は、リーダーにとって開発時間を削られる重たい業務である一方で、自身が前職までに培った経験を活かせると考えて、積極的に手を挙げるようにしました。

具体的に対応した内容は以下のようなタスクです。

顧客対応の一次受け

顧客からの保守・改修系の連絡は自分が一次対応し、判断が必要なものは情報を整理してからチームへ展開
実際に着手するタイミングで、対応内容や段取りを整理し、事前に簡単に相談することでコードレビューをいただく際の負担を減らせるように対応

顧客への要件ヒアリング

フロント担当として定例会議をセッティング、アジェンダ・議事録などの作成
顧客との共有・連携用に要件や仕様をドキュメント化し、スプレッドシートで一覧化
実装のイメージがつくものは即答し、自身では想定できない要望は持ち帰りチームへ展開

全体スケジュールの作成と予実管理（WBS）

新規機能開発案件の際に、要件定義・QA・リリースまでの工程を引き、WBSの素案を作成
工数・納期的に対応が難しい要望に対しては、リリース時期をわけるなどの代替案を提案
開発タスクをIssueとして起票、朝会時などに定期的にチーム内で確認
仕様やデザイン確認など顧客側タスクを管理し、必要に応じてリマインド

工数見積と提案書の作成

新規依頼や保守範囲を超える改修要望の工数見積の素案を作成
機能ごとにタスク分解し、見積の根拠を明示することで、リーダーがなるべく判断しやすいように対応

これらのタスクにおいて徹底したのは、「素案（たたき台）まで作りきり、自分なりの仮説や提案を添えてから相談する」ことです。
結果として、リーダーのコミュニケーションコストを最小限に抑えつつ、チームとしての意思決定スピードを落とさないことに少しは貢献できたのではないかと感じています。

Ⅲ. 「未来の工数」を削減する

いま担当している運用保守案件で、修正時にバグが出やすいアプリケーションがあります。

原因は、

コントローラーが責任を持ちすぎてファットになっている
似たようなコードがコピペされている
テストコードがほとんど存在しない

ということだと理解しています。
（もう一歩深めると、設計に時間をかけられないくらい開発時の納期が厳しかった＆その後もリファクタリングの余裕がなかった、という構造的な問題もありそう…）

この案件を担当させていただいて、適切な設計やテストコードの不在は「未来の工数」を奪うことになると体感したので、以下のような取り組みを行いました。

AIを活用したテストコード作成の導入

当時の課題

納期が厳しく、テストコードが存在しないプロジェクトが多かった
※上記のプロジェクトの他にも結構ありました…
そのため、保守時の手動テスト・デグレ確認に多くの工数を割かれてしまっていた

実施したアクション

工数をかけずに品質を担保するため、AIを活用したテストコード作成をリーダーに提案
まずは自分の修正範囲についてAIを使って小さく実践

結果

PR等を通じて「工数をかけずに導入できそう」「意外と使える」という雰囲気をチーム内に作れた
現在進行中の新規開発では基本的にテストコードが存在し、安心して改修できる状態になった

仕様変更に強いコードと保守性

実務経験が浅いなりに、スパゲッティコードによる「未来の負債」を残さないよう、方針と実装の両面でルールを設けていました。

方針

単一責任の原則: クラスやメソッドの役割を一つに絞り、修正の影響範囲を限定する
DRY: 同じロジックを散在させず、仕様変更時の修正箇所を1つにする
「なぜ」を残す: どうしてもコードが複雑になってしまう箇所には意図をコメントに残し、未来の解読コストを下げる

実装例（Ruby on Rails特有の記載によっています）

複数のモデルやコントローラーで使う共通ロジックは、ActiveSupport::Concern を活用してモジュール化（Mixin）し、一元管理する
データに紐づくロジックはコントローラーに書かず、モデルのインスタンスメソッドとして定義する
複数のモデルにまたがる処理はServiceクラスに切り出す
親モデルと子モデルを同時に更新する場合など、複数のモデルに跨るバリデーションや保存処理は、Form Objectを作成して責務を分離する
頻出する検索条件や複雑なクエリは scope として定義し、可読性と再利用性を高める

おわりに

未経験転職して8ヶ月。技術力に関しては、まだまだ先輩方の背中は遠く、日々勉強の毎日です。
しかし、「会社の利益に貢献する」という目的において、技術力以外で貢献できることは、意外と多くあるのでは？と感じています。

そしてそれらは、未経験や1年目のエンジニアであっても、というより他業界を経験している未経験転職者だからこそやりやすいことも多いのではないでしょうか？

自分は失敗も、技術力不足を痛感する場面もたくさんあるので、引き続き「どうしたら利益貢献できるか」という視点で頑張っていきます！
とくにAIドリブンな開発は生産性を一気に高めるものだと思うので、正しい使い方含め学んでいきます！

この記事がなにか一つでも、ここまで読んでくださった方のお役に立てたら何よりうれしいです。
最後までお読みくださり、ありがとうございました！