【理想】「自動車開発×ソフトウェア」について書いてみた【現実】

はじめに

若干ぶっちゃけた話も書いてますが、

「個人の見解であり所属する組織の公式見解ではありません。(棒読み)」

基本的には自動車業界ではない職種の方、または学生さん向けに自動車業界の特にソフトウェアの領域がどのようになっているかを私の知見の範囲で書いています。

後半でどういう領域があるのか、どういったプロセスがあり得るのかを書いています。

本サイト自動車開発系記事

発端

TwitterのDMにて以下のような質問が来ました。

自動車業界で働いている身としては、とても嬉しい質問です。

ここでふと思ったのが以下です。

• ググったら情報出てくるかと思ったけど、初心者向けの話は無さそう。
• 自動車開発関係で個人で発信している人ってあまりいないな
• だから、情報が無くて困ってる学生が多いのかな？

というわけで需要があるかどうか全く分かりませんが、
私が認識している、

• 「自動車開発×ソフトウェア」の初心者向けの情報が少ない理由
• 「自動車開発×ソフトウェア」の情報発信が少ない理由。
• 「自動車開発×ソフトウェア」の各種領域。

を書いていきます。

初心者向けの情報が少ない理由

自動車開発でソフトウェア領域も情報が無いわけでは無いです。
企業レベルの発信であれば、かなりの情報が出回ってはいます。
しかし、企業レベルの発信は、B2B(企業対企業)を想定しているため、
情報としては、初心者向けでは無いことが多いと言えます。

対企業なので、「ある程度の前提知識は持っている」ことを前提に話が始まります。
「ある程度の前提知識は持っている」が結構曲者で
いわゆる自動車業界独自用語のオンパレードです。

(※ 私のブログも独自用語の説明なしで書いてるものが多いので、偉そうなことは言えないんですけどね。)

つまり、

自動車開発エンジニアはビジネス用語なんて比較にもならないレベルの宇宙語を話している！！

(※ いや、一応、地球語ですし、ビジネス用語の方が個人的には難しいです。つまり慣れの問題ってことだな。)

自動車開発関係で個人で発信している人があまりいない理由

母数としては決して少なくないです。むしろ多いはずです。
残念ながら「多いはず」を裏付ける適切なソースは見つけられませんでした。

ただ、IPAのIT人材白書2018によると
ソフトウェアエンジニアは100万人程度いると言われています。
(P16の「図表1-2-2 IT企業（IT提供側）のIT人材数推計結果」の合計値より。)

そこからの自動車開発系のエンジニアが何人かはわかりません。

日本のGDPの自動車関連の割合が10%らしいです。
単純に100万人の10%ってことで、
10万人はいると考えられます。(ホントか？)

では、なぜ発信数が少ないかを予想してみました。

• 発信しても内容がマニアックすぎるため読者が付かなく挫けやすい。
• 逆に読者ウケを狙い、プログラミング限定の発信にすると他業界の発信者の方が圧倒的に強く、負けてしまう。
• 機密に抵触し易い。

発信しても内容がマニアックすぎるため読者が付かなく挫けやすい

私も書いてはいますが、PV数はほぼ稼げていません。

• エンジンの噴射制御
• モータ制御
• MATLAB、Scilab関係

同業者が喰いついてもおかしくは無いのですが、
上記は知らなても業務には支障が出ない仕組みが企業内で作られていることも多いので、
あまり悩むことが無いというのも事実です。

つまり、

自動車開発エンジニアは発信もしなければ受信もしない！！

(※ いや、当然そうじゃない人もいますよ。傾向の話です。)

プログラミング限定の発信にすると他業界の発信者の方が圧倒的に強く、負けてしまう

一応、業界としてはC言語のシェアが圧倒的に強いです。
しかし、C言語で発信しても、市場はすでにレッドオーシャン。
相当な気力と工夫が無い限りは挫折してしまうのでしょう。

また、自動車業界のC言語は言語本来の自由度にかなりの制約を掛けています。
特殊な書き方による不具合や保守困難を他業界よりも強く恐れているためです。
これも厳密なルールの上でC言語になるので、
C言語を一番使っているにも関わらず、実はそれほどC言語の特性を知っているわけでは無いという現実があります。

(下手したらポインタ、構造体知りませんな人が居ても不思議ではない。関数ポインタ？何それ？おいしいの？)

つまり、

自動車開発エンジニアにはC言語のエキスパートはいない！！

(※ いや、当然エキスパートもいますよ。仙人みたいな人が身近にいますし。でも少数派ですよね？ね？)

機密に抵触し易い

これが発信が少ない最大の理由だと思っています。

自分が携わっている業務内容が特定企業の知財の可能性があり、
そうそう業務内容をしゃべれないし、書けないのです。

一応これに対して有効な対策があります。

• 現行業務を工学として確立しているものへ仕分けし、工学的なものは知財ではないので開示可能。
• 現行業務を標準仕様として開示されているものに置き換えれば開示可能。

私のブログ内で書いている内容は上の方式に則っています。
(きっと、たぶん、もしかしたら、ひょっとしたら？)

ただし、正直面倒というのも事実で、
しっかり自身の業務を分解/再構築する人は稀です。

つまり、

自動車開発エンジニアは、自分が今何をやってるか知らない！！

(※ いや、当然(省略) )

個人的には変に機密にせずにオープンにした方が業界の技術誘導ができたり、
技術者育成に繋がったりの利点はあると思っています。
しかし、
企業間の契約の話なので、なかなか一筋縄ではいかない問題です。

学生さん、新人さん向け業界用語情報(領域とプロセス)

顧客、上司、先輩から脈絡もなくシレっと出てくる謎キーワードがあります。
学生さんや自動車業界の新人さんが、恐らく言われて困りそうな謎キーワードを並べていくので参考にしてください。
参考にならなかったらごめんなさい。私の力量及び知識及び経験不足です。

自動車の中の領域

ざっくり4領域あります。
これは日本でなく、世界レベルで共通と思って良いです。

• インフォテイメント系
  • カーナビ、オーディオ等
• パワートレイン系
  • エンジン、モータ、トランスミッション等
• ボディ系
  • ステアリング、エアサス、ドア等
• シャーシ系
  • ステアリング、ブレーキ等

使用例：

自動車開発プロセスとしての領域

これは私の主観なんで、本当の意味で参考程度で。

• ECU開発系
  • ECU内のマイコン周りのI/Oのソフトウェア
  • センサ、アクチュエータ周りのソフトウェア
  • 主制御を担当するソフトウェア
• 設備系
  • HILS(Hardware In the Loop System)
  • テストベンチ
  • シャーシ・ダイナモ
• 計測系
  • 計測
  • キャリブレーション
  • 故障診断

ECU開発系は自動車に搭載されるものの開発に対し、
設備系と計測系は「デバッグ/検証」環境にあたります。

一般的なソフトウェア開発だと、「デバッグ/検証」は環境を買ってきて使うだけだと思うのですが、
自動車業界は、この「デバッグ/検証」に掛けるコストが膨大です。
理由としては、「作ったものの保証」がかなり強く求められるためです。
不具合混入は許されず、エビデンス(保証根拠)も確実に残していきます。
(当然、航空機とかロケットなどはさらに凄まじいと思いますが)

よって、「デバッグ/検証」環境も観察できる精度、再現度、自動化、他製品との連携可能性など多岐に分かれる強烈なニーズが発生します。

リコールとか起きたら、利益以上の金額が一気に吹っ飛びますからね。
当然と言えば当然。

(※ モノ依存のビジネスモデルとしては実は破綻している可能性はあります。
「売価以上の責任を負っている」可能性が高いのですが、ここでは言及しません。)

膨大なコストを掛けるということはビジネスになり得るということで、
結果、エンジニアの業務領域として設定可能と言えます。

使用例1：

使用例2:

プログラミング言語について

上でも書きましたがC言語が支配的です。
ただし、ECU開発系の上流側(研究、設計)にフォーカスすると
MATLAB、Pythonも使用されています。
というわけで、まとめると以下になります。

• C言語
  • ECUのソフトウェア実装全般
• MATLAB
  • 制御や制御対象の研究段階や設計段階で使用
• Python
  • 自動運転系の研究段階で使用。
  • MATLABからPythonを呼び出すこともある。

求めれられる言語スキルレベルはそれほど高くは無いです。
どちらかというと、高校レベルで良いので物理/数学をちゃんと押さえている人の方がチヤホヤされます。

まとめ

• 自動車業界のソフトウェアエンジニアのプログラミングスキルは決して高い方ではない。
  • 品質重視の開発プロセスであるため、自然とそうなっている。決してエンジニアがサボってるわけでは無い。
• 特殊な用語が多数出てくるが、頑張って慣れるしかない。
  • この業界に10年以上いても意味不明な用語は1週間に2、3回程度の頻度で出てくる。しかもググっても出てこない。
• プログラミング言語知識も重要ではあるが、それ以上に物理/数学の知識の方の付加価値が圧倒的に大きい。
  • 物理/数学の話をプログラミングへ落とし込めると最強。

再掲になりますが、
「個人の見解であり所属する組織の公式見解ではありません。(棒読み)」