自動車業界の経験をスキルシートで伝える書き方｜領域・立場・開発工程・安全要求の示し方

自動車業界の経験をスキルシートで伝えるには、領域、発注元の立場、担当した部分、開発の工程と試験環境、安全やセキュリティの要求の5つをそろえて書きます。「自動車関連のソフト開発」とだけ書くと、組込みなのかクラウドなのか業務システムなのかが分からず、読み手は何を任せられるかを判断できません。

一方で、自動車業界の経験には、発表前の車種や機能など、書いてはいけない情報が多く含まれます。この記事では、伝わる書き方と、書かない線の引き方をあわせて紹介します。スキルシートの全体の構成はスキルシートの書き方の記事をご覧ください。

自動車業界の案件で読み手が知りたいこと

自動車業界の案件のスキルシートを読むのは、メーカーや部品メーカーの開発の担当者、受託した会社のリーダーであることが多く、読み手自身が業界を知っています。そのため、次の点をシートから読み取ろうとします。

• 車載ソフト、コネクテッド・SDV、販売・アフター、生産・調達のどの領域の経験か
• メーカー、部品メーカー、販売会社のどの立場の仕事だったか
• クルマの中のどの部分（どの種類のECUや機能）、またはどの業務を担当したか
• 開発の流れのどこを担い、どんな試験環境を使ったか
• 安全やセキュリティの要求が高い開発に関わったか

4つの領域の中身は自動車業界のIT案件の記事で整理しています。シートでもこの区分の言葉を使うと、読み手と認識をそろえやすくなります。

プロジェクト欄に足したい5つの項目

基本の型（期間・概要・役割・体制・担当工程・技術）に、自動車業界では次の項目を足します。

立場を書くと、仕事の性格が伝わる

同じ車載ソフトでも、メーカーの立場で車両全体の仕様を取りまとめた経験と、部品メーカーの立場で担当ECUを作り込んだ経験では、強みが違います。社名を書かなくても、「完成車メーカーの開発部門」「部品メーカーからの受託」のように立場を書けば、読み手は仕事の性格をつかめます。

業務システムの経験は、業務の名前で書く

販売・アフターサービスや生産・調達の経験は、システム名より業務の名前で書くと伝わります。「販売会社の整備入庫と部品発注の業務」「保証修理の請求の業務」のように書き、扱った件数や拠点の数は大まかな範囲にとどめます。業務の流れの言葉は業務知識の記事で紹介しています。

記入例（架空）

車載ソフトの例

期間：（例）約1年半
概要：（例）部品メーカー向けの受託開発。運転支援機能のECUソフトの機能追加
領域・立場：車載ソフト。部品メーカーの開発を受託した会社のチームに参画
担当した部分：周辺の検知結果をもとに警告を出す機能の一部
工程と試験環境：ソフト詳細設計、実装、単体試験、結合試験。シミュレーションと、試験装置にECUをつないだ環境で検証
安全の要求：機能安全の要求があるソフト。要求と試験の対応表の作成と更新を担当
役割：メンバー。後半はサブリーダーとして試験の進み具合を取りまとめ
技術：（例）C、車載ネットワークの解析ツール、構成管理ツール

コネクテッドの例

期間：（例）約1年
概要：（例）完成車メーカーのコネクテッドサービスのクラウド側の機能追加
領域・立場：コネクテッド・SDV。完成車メーカーのサービス開発部門
担当した部分：クルマから送られる状態のデータを受け取り、アプリに表示するまでのAPIと処理
工程：基本設計〜結合試験。車載側の担当チームとの結合試験の調整
セキュリティの要求：通信の認証と、データの扱いのルールに沿った設計
技術：（例）クラウドのサーバーレスの構成、API設計、データ基盤

どちらも項目の埋め方を示すための架空の例です。実際の経験に置き換えて書いてください。

安全・セキュリティの経験の書き方

機能安全は「何をしたか」を書く

国土交通省の手引きは、ISO 26262で定義されたリスク分類としてASILを紹介し、A〜Dの4段階で、Dが最も高いと説明しています。安全に関わる開発の経験がある場合、読み手が知りたいのは規格の名前より、その中で自分が何を担ったかです。

• 安全に関わる要求の分析や、安全のための設計の一部を担当した
• 要求と試験の対応づけ、試験の記録の整備を担当した
• 安全に関わるレビューの手順に沿って、設計や実装のレビューを受けた・行った

ASILの段階や、どの部品が何段階かは、取引先の設計の情報にあたる場合があります。書く場合は「機能安全の要求があるソフト」のような一般的な表現にとどめ、具体的な段階を書いてよいかは契約や取引先のルールを確かめてからにしてください。

サイバーセキュリティとソフト更新は「どの部分か」を書く

国の保安基準では、一部の車両を除くクルマの電気装置に、サイバーセキュリティを確保できることと、組み込まれたプログラム等の書き換えを確かに行えることが求められています（道路運送車両の保安基準第17条の2第3項・第4項）。この基準に関わる仕事は、車載側の対策の実装、リスクの分析、通信によるソフト更新の配信の仕組みなど、範囲が広くあります。シートには、自分がそのどの部分を担ったかを書きます。基準の中身は規制の記事で解説しています。

書かないことの線を引く

書かないもの

自動車業界の経験では、次の情報は書かないのが基本です。

• 発表前の車種、機能、発売や量産の時期
• 開発のコード名や、社内の部品番号、仕様書の番号
• 取引先の社名や、取引先が公表していない取引の関係
• 不具合の具体的な内容や、改善措置の検討の経緯
• ASILの具体的な段階や、セキュリティの対策の具体的な中身（取引先の了承がない場合）

不具合やセキュリティの対策の詳細は、悪用されると危険な情報になり得ます。経験として伝えたい場合は、「不具合の原因の調査と再発防止の手順づくりを担当」のように、自分の役割だけを書きます。

組み合わせで特定されないようにする

一つひとつは一般的な情報でも、時期、機能、立場、地域を組み合わせると、どの会社のどの車種か分かってしまうことがあります。期間は「約1年」のように丸め、機能は種類の名前にとどめるなど、読み手が特定できない粒度にそろえます。書いてよいこと・いけないことの全体の考え方はスキルシートと守秘義務の記事、秘密保持契約の読み方は秘密保持契約の記事をご覧ください。

スキル一覧の書き方

スキル一覧には、言語やツールに加えて、次のような自動車業界ならではの項目を並べると、読み手が探しやすくなります。

経験年数は区分ごとに書き、触れた程度の経験と、主担当として担った経験を分けておくと、面談での質問に答えやすくなります。テストの経験を中心に書く場合はQAエンジニアのスキルシートの記事、車載情報機器のアプリの経験はAndroidエンジニアのスキルシートの記事も参考になります。

面談で口頭で伝えるときのコツ

面談では、シートに書けなかった中身を口頭で補う場面があります。そのときも、次の順で話すと、秘密に触れずに経験の深さが伝わります。

1. 領域と立場（どの領域で、どの立場の会社の仕事か）
2. 担当した部分（機能の種類と、自分の役割）
3. 工夫したこと（試験の進め方、関係するチームとの調整、記録の整え方）
4. 結果（品質や日程にどう効いたか。数字は一般的な範囲で）

製造業と共通する生産・調達の経験の書き方は、製造業のスキルシートの記事で詳しく扱っています。面談でよく聞かれる質問への備えは面談の質問の記事をご覧ください。

よくある質問

車種の名前を書かないと、経験の価値が伝わらないのではないですか？

読み手が知りたいのは、車種の名前より、どの領域で、どの部分を、どの工程で担ったかです。機能の種類と自分の役割、使った試験環境が書かれていれば、経験の価値は十分に伝わります。車種の名前は、取引先が公表していない情報と結びつきやすいため、書かないほうが安全です。

機能安全の規格に沿った開発に少しだけ関わった場合も、書いてよいですか？

書いてかまいませんが、関わった範囲を正直に書くことが大切です。「機能安全の要求があるソフトの試験を担当」のように、担った作業を具体的に書けば、読み手は経験の深さを判断できます。面談で詳しく聞かれたときに説明できる範囲で書くとよいでしょう。

販売会社の業務システムの経験は、自動車業界の経験として評価されますか？

販売・アフターサービスの領域の案件では、販売会社の業務の流れを知っていることが強みになります。どの業務（商談、整備、部品、保証など）を担当したかを業務の名前で書くと、自動車業界の経験として伝わりやすくなります。