組込みエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

組込みエンジニアのスキルシートは、製品分野、担当したソフトの層、マイコン・OS・開発の道具の系統をプロジェクトごとにそろえて書き、担当内容には「何を作ったか」に加えて「どんな切り分けや設計の判断をしたか」を書くのが基本です。組込みの案件では、読み手は「この人を、どの製品の、どの層に入れられるか」を、案件で使う構成との近さから判断しようとします。

製品名や顧客名を書けなくても、分野、層、構成、判断の中身は書けます。この記事では、組込みならではの項目の書き方と、架空の記入例を示します。案件で問われる技術の中身は組込みエンジニアのスキルの記事、独立までの準備は組込みエンジニアがフリーランスになるにはで扱っています。

スキル一覧は「系統」と「使い方」を分けて書く

組込みのスキル一覧で読み手が最初に確かめるのは、マイコンやOSの系統です。「マイコン」「RTOS」とだけ書くと、案件の構成と近いかどうかが判断できません。系統と、どう使ったかを括弧で添えます。

記入例（架空）：

使ったRTOSや開発環境の製品名は、一般に公開されているものなら書いてかまいません。ただし、社内で作った独自のOSや道具は名前を書いても伝わらないため、「社内製のリアルタイムOS（優先度つきのタスク切り替え）」のように中身で書きます。

計測器を書く欄を作る

組込みのシートで見落とされやすいのが、計測器の経験です。オシロスコープやロジックアナライザーを使って不具合を切り分けた経験は、評価の段階で頼れるかどうかの判断材料になります。スキル一覧に欄を作り、何を確かめるために使ったかを一言添えておきましょう。

プロジェクト欄は「分野・層・構成・工程」をそろえる

組込みのプロジェクト欄では、次の項目をすべてのプロジェクトで同じ順にそろえると、読み手が比べやすくなります。

1. 製品分野：家電、産業機器、車載、医療機器、通信機器など。製品名は書かない
2. 担当した層：ブートローダー・BSP、ドライバー、ミドルウェア、アプリケーション、評価用のソフトなど
3. 構成：マイコンやSoCの系統、OS、主な通信
4. 工程：要求仕様、方式設計、詳細設計、実装、単体試験、結合試験、評価
5. 局面：新規開発、派生開発、量産後の保守のどれか
6. 体制と立場：ソフトのチームの人数、自分の立場、ハードの担当者とのやり取りの有無

組込みでは、新規開発か、既存の製品をもとにした派生開発かで、経験の中身が大きく違います。派生開発の経験が長い方は、既存コードの読解や、変更の影響を見極めた経験として書くと強みになります。

担当内容には切り分けと判断を書く

組込みのシートで差がつくのは担当内容です。「〇〇の制御ソフトを担当」だけでは、どの深さで関わったかが伝わりません。書き換えの例を示します。

とくに、原因がハードかソフトかを切り分けた経験は、組込みの経験の深さを示す材料になります。ハードの担当者に根拠を添えて報告した、回路の修正につながった、といった流れが分かるように書くと伝わります。

製品名を伏せた書き方

組込みの経験は、発表前の製品や取引先の技術と結びついていることが多く、書き方に注意が要ります。

• 製品名・型番・顧客名：書かない。「産業用の制御機器」「家庭用の空調機器」のように分野でぼかす
• 性能の具体的な数値：製品の仕様に関わる数値は書かない。「応答時間の要件を満たした」のように方向で示す
• 未発表の機能：書かない。量産後に公開された機能でも、取引先との約束の範囲を確かめる
• 自分の判断と使った技術：一般的な言葉で書いてよいことが多い

どこまで書いてよいかの考え方はスキルシートと守秘義務の記事で扱っています。自動車業界の経験の書き方は自動車業界の経験をスキルシートで伝える書き方、製造業の経験は製造業界の経験の書き方も参考にしてください。

記入例（架空）

次は書き方の型を示すための例です。分野と規模はぼかしてあり、実在のプロジェクトではありません。

期間：20XX年4月〜翌年9月（1年6か月）
製品分野：産業用の制御機器（既存製品の後継機種の開発）
担当した層：デバイスドライバー、RTOS上のミドルウェア
構成：ARM Cortex-M系マイコン、RTOS、C、UART・SPI・CAN
工程：詳細設計、実装、単体試験、結合試験、評価での不具合対応
体制・立場：ソフトのチーム6名のうち、ドライバー担当のサブリーダー。ハードの担当者との仕様の確認を担当
担当内容：マイコンの変更にともなうドライバーの移植。新しく載ったセンサーのドライバーの作成。結合試験で出た不具合の切り分け
工夫・成果：旧機種と新機種の周辺機能の違いを一覧にし、移植の影響範囲をチームで共有した。評価で出た通信エラーを、波形の確認から基板側の配線の問題と特定し、ハードの担当者に根拠を添えて報告した

実際に書くときは、ご自身の経験に置き換えてください。

品質の手順と資格の書き方

車載や産業機器、医療機器などで、規格に沿った手順の中で開発した経験がある場合は、担当内容に「何の記録を作ったか」を書きます。たとえば「要求と試験の対応表の作成」「変更の影響分析の作成」「静的解析の指摘への対応と記録」です。規格の名前だけを並べるより、作った記録の種類を書くほうが、手順の中で働けることが伝わります。規格や基準の背景は自動車業界の規制の記事で扱っています。

資格は、取得した年月とあわせて資格欄に書きます。エンベデッドシステムスペシャリスト試験を持っている場合の書き方はエンベデッドシステムスペシャリスト試験の記事で解説しています。

よくある質問

製品名を書けないと、経験が伝わりませんか？

製品名がなくても、分野、担当した層、構成、判断の中身が書いてあれば、案件との近さは十分に伝わります。むしろ、製品名より、どの層で何を判断したかのほうが読み手にとって判断の材料になります。

評価・試験の経験が中心です。どう書けばよいですか？

試験の項目を作ったのか、試験を実施したのか、不具合の原因まで調べたのか、試験を自動化したのかを分けて書きましょう。計測器を使って原因を絞った経験や、修正の確認まで担った経験があれば、具体的に書くと担える範囲が広く伝わります。

古いマイコンや社内独自の環境の経験しかありません。

古い構成の経験も、保守や派生開発の案件では強みになります。社内独自の環境は、もとになっている技術や仕組みを一般的な言葉で書き、周辺機能の設定や割り込みの設計など、系統に関係なく生かせる経験を担当内容にくわしく書きましょう。