「SE時代の専門知識は、異業界ではそのまま通用しないのではないか？」
キャリアチェンジを考えるとき、こうした不安を抱くエンジニアは少なくありません。私自身、社内公募でSEからハードウェア・モノづくりの職場へ移り、ITの専門知識そのものはほとんど評価されないという現実に直面しました。異動までの経緯は、[社内公募シリーズ]にまとめています。
ただ、SEとしての経験が無駄になるわけではありません。異動先や面接官が知りたいのは、特定の言語やフレームワークの知識ではなく、開発現場の摩擦や失敗を通じて身につけた「仕事の進め方」です。
この記事では、私自身のSE時代の実体験と失敗談をもとに、モノづくりの現場でも通用する3つのアピールポイントを整理します。
SEの専門知識は、異職種ではそのまま通用しない
異動してすぐ、こんなことがありました。
上司
D.レイルさん、IT業界出身だったよね。新しいプリンターの設定方法わかる？
私
…
同じIT業界でも、専門が違えば門外漢です。しかし異業界の側からは、その違いが見えません。それほど、モノづくりとITはかけ離れた世界だということです。
そのため、言語名やツールの経験をそのまま並べても、相手にはそれが何かすら伝わらないことが多いです。武器にすべきは知識そのものではなく、失敗しながら身につけた仕事の進め方です。
アピールポイント①：口頭ではなく成果物で見る「進捗管理」
SEの実作業は1人分のタスクに分解されることが多く、担当レベルで関わる相手は限られます。
一方、モノづくりは設計・試作評価・調達・製造・品質保証・サプライヤーと関係者が多く、部署を横断して進める必要があります。関係者の状況を正しくつかみ、手を打てるかどうかが重要になります。
ケース１：あるプロジェクトで、Xさんに進捗を確認すると「予定通りです。来週中にはできます」との回答でした。順調だと思っていましたが、翌週になってもまったく仕上がっていませんでした。
ケース２：常に手一杯だったYさんに確認したところ「おそらくできます」との返事でしたが、やはり期限内には終わりませんでした。
この遅延から得た教訓は3つです。
教訓1：口頭確認で終わらせず、途中の成果物を見る
「順調です」は本人の感覚にすぎません。仕掛品や設計書を直接見ていれば、早い段階で遅れに気づけました。
教訓2：一人ひとりの「仕事の癖」を計画に織り込む
遅れがちな人、手戻りが多い人など、癖は人それぞれです。たとえば遅れがちな人の担当機能は結合試験の後半に回すなど、癖を前提に計画すれば、遅れが出ても全体は止まりません。
教訓3：本人の「できます」より、客観的な負荷で判断する
責任感から「できます」と答えても、容量を超えていれば破綻します。無理だと判断した時点で、別の人に割り振るなど早めに手を打ちます。
アピールポイント②：小さな違和感も拾える「報連相しやすい関係づくり」
モノづくりでは、設計だけでなく試作評価・製造・品質保証など多くの担当者と連携します。そこで品質を左右するのが、相手が気軽に相談・報告できる関係を作れているかどうかです。
若手の頃、相談に行くと高圧的な態度を取る人や、こちらの勘違いを鼻で笑う人がいました。そうした人に声をかけに行くのは、精神的にかなりしんどかったのを覚えています。
一方で、相談に行くとすぐに手を止め、快く話を聞いてくれる先輩もいました。その人には「小さな違和感でも早めに伝えておこう」と、自然と相談できていました。
この経験から得た教訓は2つです。
教訓1：はっきりしない違和感ほど、相手の反応次第で報告されなくなる
「いつもと手応えが違う」といった小さな違和感が、設計ミスの早期発見につながります。しかし「鼻で笑われたら嫌だ」と思わせてしまえば、不具合は見逃されたまま後工程へ流れてしまいます。
教訓2：空振りでも歓迎されることが、品質を守る
勘違いでも嫌な顔をされず、むしろ「早く言ってくれてありがとう」と感謝される。そんな関係が、重大な不具合を防ぐいちばんの近道です。
普段から自分の方から話しかけるようにしておき、コミュニケーションの習慣を作っておくと、相手もこちらに話しかけやすくなります。
アピールポイント③：思い込みに頼らない「原因分析力」
システムの不具合でも製造ラインの不具合でも、原因調査でいちばん危ないのは思い込みです。
モジュールAとBを連携させたとき、Bのデータベースにデータが入らない不具合が起きました。
A担当の先輩から「B側のバグだ」と言われ、実績もある人だったので、私はBのコードばかりを延々とデバッグしていました。
しかし原因は見つからず、ログを一から追い直したところ、Aが「add（追加）」の直後に「del（削除）」を送信していたことがわかりました。Bは指示通り正常に動いていただけでした。
この経験から得た教訓は3つです。
教訓1：「あの人が言うなら正しい」とは限らない
実績のある先輩でも、間違えることはあります。相手の経験や立場ではなく、事実をもとに検証することが欠かせません。
教訓2：絞り込みを誤ると、原因のない場所を調べ続けることになる
思い込みで調査範囲を狭めると、大きな時間のロスが生まれます。絞り込むときは、その前提が外れている可能性も踏まえておきます。
教訓3：自分が疑う側に回ったときも、決めつけない
原因がないのに犯人扱いされると、少し大げさに言えば自尊心を傷つけられ、そのしこりは次の仕事にも残ります。原因がわかるまでは、中立な立場で調べることがその後の関係を守ります。
まとめ：SEのキャリアチェンジでは「仕事の進め方」を自己PRしよう
SEからのキャリアチェンジで評価されるのは、プログラミング言語の知識ではありません。
- 本人の言葉ではなく、成果物と癖から逆算する「進捗管理」
- 空振りでも歓迎される関係を作り、違和感を早く拾う「相談しやすさ」
- 相手の実績や思い込みに左右されず、事実で切り分ける「原因分析力」
どれも、開発現場の摩擦や失敗を通じて身につけたもので、業界が変わっても通用します。専門知識の「直輸入」にこだわらず、自分が現場で学んできた仕事の進め方を、自信を持って伝えてください。
社内公募の具体的な進め方は、こちらのシリーズで詳しく解説しています。
