こんにちは。スパイダープラスCREチームの脇です。
今回の記事では、
エンジニア知識0スタートのカスタマーサポートから社内のCREチームへキャリアチェンジした実体験をもとに、
何を学び、どんな壁にぶつかり、どう乗り越えたのかをお話していきたいと思います。
未経験から技術サイドに踏み込む人の参考になれば幸いです。
私は今まで、職歴の大半で接客・サービス業に従事しており、
情報系の学校にも通っておらず、潔いぐらいにエンジニアとはほど遠い生活を送っていました。
そんな中、なぜ思い切って未経験からエンジニアを目指そうと思ったのか。
モチベーションの源泉になったのは好奇心です。
2023年5月からスパイダープラスのカスタマーサポートに従事し、
ユーザー様からのお問い合わせ対応をしていました。
日々問合せ対応を進める上で、ユーザー様の生の声を沢山いただきます。
「こういう操作ができたらいいのに」
「現場だと〇〇作業をするから、こういう画面の方が使いやすい」
などなど…
そうしたお声を聞くたびに
「なぜその操作は実現できないのか」
「どうすればユーザビリティは上がるのか」
と自問自答を繰り返したことが、プロダクトの構造へ興味を持ったきっかけでした。
プロダクトの外側だけでなく、内側も理解したい。そう強く感じ、2024年の秋頃から独学をスタートしました。
とはいっても、エンジニア経験・知識0の私が即座に学習対象の言語を見つけられる訳もなく…
「何から勉強すればいいんだ」状態を打開するために模索していたところ、
当社HPの採用情報ページに目が留まりました。
公開されている紹介資料に技術スタック・開発環境も記載されており、それをヒントにWeb画面の構造理解に直結するHTML/CSS、そしてサーバサイドの入口としてのPHPを学習対象に選びました。
学習を進めていくと専用のアプリ開発ツールがない環境でもWebブラウザの開発者ツールからHTMLやCSS、JavaScriptを閲覧・デバッグできることを知り、
「HTMLってメモ帳でも作れるんだ…」とびっくりするぐらい手軽に触れられる事が最初の衝撃でした笑
サポートで目にしているUIの動きやエラーが、コードの観点だとどう見えるのか——
今思えば、視点が増えるほど問い合わせの「原因仮説」が立てやすくなり、お客様対応にも柔軟性が出せていたと思います。
その後フロントエンドの挙動理解の知識を補強する目的でJavaScriptにも触れ始め、
社内のキャリアチャレンジ制度を活用し、カスタマーサポート経験を活かせるCREチームへの異動を志願。
蓄積したプロダクト機能のナレッジとユーザー課題の把握力、再現手順の言語化、営業や開発との連携実績を強みとして提示しました。
晴れて2025年5月に異動が決まり、
現在は月平均130件前後プロダクトに関する技術的な調査対応依頼が入る中で、約40件程度を担当できるまでになりました。
具体的な業務としては、データベースの確認・処理、各機能のソースリーディング、開発部門への不具合報告と優先度調整、ナレッジ展開を行っています。
知識・経験が及ばない部分については、他メンバーのサポートを得ながら業務に励んでいます。
過去の記事でCREチームの調査対応事例を公開していますので、参考になればと思います。
ここからは実際に直面した課題なども交え、どのように業務と学習をリンクさせていったかをお話します。
意識したこと→どう実現したか→直面した課題→対策・対応
1. プロダクト理解を“外側から内側へ”拡張する
-
意識したこと
UIの見え方だけで終わらせず、裏側の仕組みまで含めて因果関係で説明できる状態を作ること。調査は「どこで何が起きているか」を段階的に特定することを意識した。 -
どう実現したか
UI視点の知識にHTML/CSS/JS/PHPの基礎を重ね、エラー再現→ログ/DB確認→コード確認の順で調査フローを固定化し、原因を追えるようにした。 -
直面した課題
DB/サーバ周りの基礎が弱く、ログやDBを見ても状況理解に時間がかかる点がボトルネックだった。 -
対策・対応
OSS-DB Silverのシラバスを学習の骨格にして体系立てて補強し、現場案件の用語・実データと結びつけて理解を定着させた。
エスカレーションの初動スピードを上げる
2.エスカレーションの初動スピードを上げる
- 意識したこと
最初の情報精度で後工程のスピードが決まるため、初動で調査の当たりを付けることを意識した。 - どう実現したか
サポート時代に蓄積した「再現手順の引き出し」を活用し、症状から再現パターンを素早く当てにいき、必要な確認観点を短時間で揃えた。 - 直面した課題
対応ノウハウが個人に寄りやすく、チームとして再現性のある動きになりづらい点（属人化）が課題だった。 - 対策・対応
誰でも使える社内共有知識として、判断基準と手順をナレッジ化することに注力する。
3. 不具合・仕様に対してユーザー視点から向き合う
- 意識したこと
不具合や仕様の話を「技術の都合」だけで終わらせず、ユーザーの期待値と現場影響を軸に整理して開発へ届けること。ユーザー視点の温度感を落とさないことを意識した。 - どう実現したか
不具合報告を、再現条件・期待値・影響範囲・暫定回避策・優先度根拠のセットで提出。営業と連携して顧客影響を先に定量化し、意思決定しやすい形で開発部へ連携した。 - 直面した課題
仕様と実装のギャップに対する認識ズレが起きやすく、ソースコード・DB理解が不足していると「どこが論点か」の特定が曖昧になりがちだった。 - 対策・対応
該当コードの断片だけで終わらせず参照箇所まで踏み込み、仕様と実装の差分が出ているボトルネックをピンポイントで示すようにして、認識合わせの精度を上げることを意識した。
4.学習継続の仕組み化
- 意識したこと
学習を気合いで続けるのではなく、業務に効く形で継続できる「仕組み」にすること。理解を点ではなく線で積み上げることを意識した。 - どう実現したか
資格（ITパスポート→基本情報→OSS-DB Silver）をマイルストーンに設定し、学習内容を社内の開発環境や実案件と結びつけて理解を深めた。 - 直面した課題
学習テーマの粒度が散らばり、優先順位がブレることで業務への直結感が薄れることがあった。 - 対策・対応
業務課題に直結するテーマから逆算して優先順位を調整し、「今必要な理解」を軸に学習の範囲と深さをコントロールした。
まとめ
この半年で変わったのは、「原因仮説の深さ」と「関係者を巻き込む精度」。
サポートの現場で鍛えた“ユーザー視点”は、CREになっていっそう価値が増したと感じています。
ユーザー影響を軸に技術的事実を束ねられること。それが未経験から技術サイドに移るうえでの最大の武器だと実感しています。
余談ですが、
今後はフロントエンド言語の理解を土台にSwift/Flutterでモバイル領域へ学習スコープを広げ、AWS資格取得を目指しクラウドの設計力を強化していく予定です。
目標は「ユーザー体験起点で、実装と運用まで語れるエンジニア」
です。
未経験でも、いまの業務で培った強みをどのように活かせるか考え、アウトプットすることで確かな道が開けます。
ぜひ、日常もしくは業務の中でふと気になったことを見逃さずに書き留めてみてください。
集めた興味のタネが、キャリアの幅を広げることに繋がると思います。
小さな気づきや疑問を学びに繋げてチームに還元する。その繰り返しが、キャリアを変えていきます。
最後に
スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
