1. はじめに
こんにちは、株式会社うるるにてバックエンドエンジニアをしている石原です。
突然ですが、皆さんの周りに 「C言語でメモリを1バイト単位で削り、時にはんだごてを握って電子工作をしていた」 というバックエンドエンジニアはどれくらいいますか？
Web業界の中では、ちょっとした 「レアキャラ」 🦕 ではないでしょうか。
一般的に、エンジニアのキャリアパスとして「フロントエンド ⇔ バックエンド」の行き来はよく聞きますが、「組込み（Embedded） → Webバックエンド」 というキャリアチェンジは、文化や技術スタックのギャップが大きく、比較的珍しいケースだと思います。
何故こんなことをお聞きしたかというと、私のキャリアのスタートがバックエンドエンジニアどころかWeb業界からだった訳でもなく、メーカー（製造業）の組込みエンジニアだったからです。
ここでそもそも「組込みエンジニアって何ぞや？」な方もいると思うのですが、ざっくり言えば「家電や自動車などのハードウェアの中に組み込まれたコンピュータを制御し、モノを直接動かすためのソフトウェアを作る仕事」のことを指しています。
私は具体的には自動車用品メーカー🚗にて車載デバイスのファームウェア開発などを行っていました。（ここでは自動車のタイヤ空気圧を監視するための受信機の開発であったり、ドライブレコーダー用のAndroidアプリ開発など色々面白いことに携わらせてもらいました）
そこから様々な紆余曲折もありWeb系の受託開発会社へ飛び込んだ後、バックエンドエンジニアとして様々な案件の開発を担ったり、担当していたメインプロジェクトで自身がPLを担って推進したりなど、いちエンジニアとして貴重な経験をさせていただきました。
（本当はこれまでの経緯から「そもそも何で組込みに興味？」や「なぜ組込みの世界からWeb業界に?」みたいなところも含め諸々述べたいところだったのですが、１記事としててんこ盛りな感じになりそうだったので別途また記事にする機会があれば投稿しようと思います😅）
そうした経験を経て、現在はバックエンド開発を主軸としたエンジニアをしているのですが、
本記事では、「低レイヤーの住人がWebの世界に来て、何に躓き、どう適応していったのか」 という実録をお届けしたいと思います。
2. 最初の洗礼：「動く」の定義が違う 🌊
かつての私の「開発」とは、以下のような世界でした。
- 📝 言語はC/C++
- 💀 メモリ確保（malloc/free）は自己責任
- 🧱 ハードウェアの制約（CPU/メモリ/通信速度）が絶対的なルール
そこからWebの世界、特に Ruby on Rails の環境に飛び込んだ時、最初に感じたのは 「便利すぎて逆に怖い」😱 という感覚です。
「Convention over Configuration」の壁 🚧
組込みの世界にいた頃はハードウェアを「どう動かすか」のすべてを事細かに命令的に記述することに慣れきっていました。（これはこれでとにかく骨が折れます笑）
ところがWebフレームワークの世界には 「Convention over Configuration（設定より規約）」 という全く異なる強力な文化が根付いていたことに一種のカルチャーショックを受けました。
-
失敗したこと 😫
最初はフレームワークのレールに乗るのが怖く、C言語時代の 「リソースは有限かつ枯渇するもの」という強迫観念が抜けませんでした。「SQLを隠蔽されたくない（自分で制御したい）」「メモリの解放タイミングが見えないのが不安」……。今となっては「そんなこと気にせず作り切れ！」と言いたくなりますが、当時はブラックボックスが怖くて仕方なかったのです。
その結果、便利なライブラリやメソッドを使えば1行で済むところを、わざわざ手続き的に書いてRailsの良さを殺してしまい、その道の長いベテラン先輩に 「それはRailsらしくない（もっと楽をしていいんだよ）」 と指摘されることもありました。 -
学んだこと 💡
「書かないこと」の美学（車輪の再発明をしない）です。
全てを自分で制御したがる「職人気質」も大切ですが、Web開発においては、既存のエコシステムに潔く乗っかるスピード感こそが正義だと痛感しました。
「どう動くか」への拘りを捨て、「何を実現するか」にフォーカスするために ActiveRecord や MVC といったレールに身を委ねる。この「委ねる勇気」 を持ってからは、自分でも驚くほど開発速度が上がりました。（はずです、、笑）
3. 転生して気づいた「変わらない武器」 ⚔️
一方で、畑違いの出身だからこそ強みになったこともあります。それは 「裏側で何が起きているか」を想像しようとする意識と解像感 です。
トラブルシューティングの勘所 🔍
Web受託開発会社時代、当時運用と開発を担当していたFC（ファンクラブ）サイトで「グッズの発送に関連する処理のJobが詰まり、サーバーが異常な高負荷状態で張り付いてしまいシステム全体の負荷が下がらない」という課題に直面しました 🔥。
アプリケーションのコードを追うだけでは原因が見えづらい状況でしたが、そこで役立ったのが組込み時代の感覚です。私は 「コード」ではなく「リソースの挙動」 に着目し、インフラ・低レイヤーの視点からボトルネックの特定を試みました。
-
やったこと 🛠️
FCサイトには「休日などのイベント開催時にはアクセスや処理が爆発的に増加するが、平日は凪のように静まり返っている」という極端な特性があります。これに対し、常時稼働のEC2で耐えようとするのはリソースの浪費だと感じました。
そこで、詰まりがちな特定のJob処理だけを 「外科手術」のように切り出すリプレイス を敢行しました。単に移行するだけでなく、データを分割してのバッチ処理化や、バルクインサート・トランザクションを最大限活用したコードレベルの修正も併せて実施し、必要な時だけ起動する「AWS Lambda（サーバーレス）」 へと処理基盤を移しました。 -
結果 📉
処理負荷を従来の1/10程度まで劇的に削減することに成功しました。
「限られたリソース（CPU/メモリ）を、必要な時に必要な分だけ割り当てる」。これはクラウドの定石ではありますが、私の思考の根底にあったのは、教科書的な知識ではなく、組込み時代に マイコンの極小リソースをやり繰りしていた時の「ケチケチ精神（最適化への執念）」 そのものでした。
かつて厳しいハードウェア制約の中で試行錯誤した経験が、「ボトルネックを見つけて潰す」という普遍的なスキルとして活きた瞬間です。
OSやネットワークの基礎知識だけでなく、こうした泥臭い執念やリソース意識こそがクラウドやAI時代でも強力な武器になると実感しています 💪。
4. 現在：「AI」をシステムの一部として手懐ける 🤖
私は現在、主にWebクローラーの開発・運用に携わっています 🕷️。（データ収集基盤であるクローラーまわりの開発に従事し、「AIを活用した新しい価値創出に携わる」をモットーに日々励んでおります）
ここでは「AIモデルそのもの」を作っているわけではありません。しかしクローラーという膨大なデータを収集・解析するプロセスの中で、LLM（大規模言語モデル） は活用されているため、「APIの裏側でどんな処理が走っているのか？」「この挙動はシステムとして許容範囲なのか？」といった問題提起は常に必要になります。（偉そうなことを言っていますが、私もまだ手探りの毎日で、胸を張って語れるレベルには程遠いのですが……笑）
ただ下記のような挑戦は今も現在進行形で意識して取り組むようにしています。
今の挑戦 🧗
AIは強力ですが、万能ではありません。APIの向こう側で何が起きているか見えにくいブラックボックスでもあります。 そこで活きているのが、これまでのキャリアで身についた 「今見えている場所から、層（レイヤー）を積み上げて理解しようとする姿勢」 です。
ポイントは、「完全に理解する」のではなく 「段階的に理解しようとする」 ことです。
大規模なシステムであればあるほど全体を一気に把握しようとすると、そのあまりの巨大さに絶望してしまいます（笑）。
だからこそ、「まずはライブラリのこの挙動だけ」「次は通信のここだけ」と、分かる範囲を少しずつ広げていく。
どんなに抽象化されたWebシステムやAIツールであっても、皮を剥けばOSがあり、メモリがあり、物理的なリソースが動いています。
「1から100まで全て」は分からなくても、「ブラックボックスの中身を、段階的に深掘りしながら調査する癖」 をつけること。表層的な実装で終わらせず、深層まで追従しようとするこのスタンスこそが、AI活用という未開拓な領域で私の支えになると信じています。
5. まとめ：新しい領域へ挑戦する人へ 🚀
「今の自分のスキルは、別の分野でも通用するのだろうか？」 そう不安に思っている方がいたら、私は 「エンジニアとしての基礎体力は、場所が変わっても裏切らない」 と伝えたいです。
- 🔄 変えるべきこと： その領域特有のスピード感や文化（テスト手法、エコシステムなど）への適応
- 💎 変えなくていいこと： 課題の本質を見抜く力、品質へのこだわり、要件定義の泥臭さ 、そして対象を段階的に理解しようとする粘り強さ
私は「組込み」から「Web」、そして「AI活用」へと軸足を移してきましたが、過去の経験はすべて今の業務に繋がっています。
未知の領域への挑戦は怖いものですが、異なるバックグラウンドや経験を「点」と「点」を繋ぎ合わせながら挑戦を続けていくことで、あなただけの 「ユニークな強み」 がきっと生まれるはずです✨